1 Trust Model for Security 

2 Automation Data 1.0 (TMSAD) 

3 (DRAFT)

4 Harold Booth

5 Adam Halbardier

6

NIST Interagency Report 7802 

(DRAFT)
7

8

NIST Interagency Report 7802 

(DRAFT)

Trust Model for Security Automation Data 

1.0 (TMSAD) (DRAFT)

Harold Booth

Adam Halbardier

C O M P U T E R S E C U R I T Y

Computer Security Division

Information Technology Laboratory

National Institute of Standards and Technology

Gaithersburg, MD 20899-8930

July 2011

U.S. Department of Commerce

Gary Locke, Secretary

National Institute of Standards and Technology

Dr. Patrick D. Gallagher, Director
TRUST MODEL FOR SECURITY AUTOMATION DATA 1.0 (TMSAD) (DRAFT)

iii

9

10 Reports on Computer Systems Technology

11

12 The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology 

13 (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation’s 

14 measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of 

15 concept implementations, and technical analysis to advance the development and productive use of 

16 information technology. ITL’s responsibilities include the development of technical, physical, 

17 administrative, and management standards and guidelines for the cost-effective security and privacy of 

18 sensitive unclassified information in Federal computer systems. This Interagency Report discusses ITL’s 

19 research, guidance, and outreach efforts in computer security and its collaborative activities with industry, 

20 government, and academic organizations.

21

22

23

24

25

26

27

28

29

30

31

32

33

Certain commercial entities, equipment, or materials may be identified in this 

document in order to describe an experimental procedure or concept adequately. 

Such identification is not intended to imply recommendation or endorsement by the 

National Institute of Standards and Technology, nor is it intended to imply that the 

entities, materials, or equipment are necessarily the best available for the purpose.

National Institute of Standards and Technology Interagency Report 7802 (DRAFT)

25 pages (July 2011)
TRUST MODEL FOR SECURITY AUTOMATION DATA 1.0 (TMSAD) (DRAFT)

iv

34 Acknowledgments

35 The authors wish to thank their colleagues who reviewed drafts of this document and contributed to its 

36 technical content.

37 Abstract

38 This report defines the Trust Model for Security Automation Data 1.0 (TMSAD), which permits users to 

39 establish integrity, authentication, and traceability for security automation data. Since security automation 

40 data is primarily stored and exchanged using Extensible Markup Language (XML) documents, the focus 

41 of the trust model is on the processing of XML documents. The trust model is composed of 

42 recommendations on how to use existing specifications to represent signatures, hashes, key information, 

43 and identity information in the context of an XML document within the security automation domain.

44 Audience

45 The primary audiences for the TMSAD specification are developers of security automation specifications, 

46 IT products that could leverage TMSAD’s capabilities, and organizations that could take advantage of 

47 TMSAD to establish integrity, authentication, and traceability of their security automation data. NIST 

48 welcomes feedback on improving the TMSAD specification.

49 Trademark Information

50 All names are registered trademarks or trademarks of their respective companies.

51
TRUST MODEL FOR SECURITY AUTOMATION DATA 1.0 (TMSAD) (DRAFT)

v

52 Table of Contents

53 1. Introduction ...................................................................................................................... 1

54 1.1 Purpose and Scope...................................................................................................1

55 1.2 Document Structure ..................................................................................................1

56 1.3 Document Conventions .............................................................................................2

57 2. Abbreviations ................................................................................................................... 3

58 3. Relationship to Existing Specifications and Standards ................................................ 4

59 4. Conformance.................................................................................................................... 5

60 4.1 Product Conformance................................................................................................5

61 4.2 Content Conformance ...............................................................................................5

62 5. Algorithms and Parameters............................................................................................. 6

63 5.1 RSA-SHA256 ............................................................................................................6

64 5.2 ECDSA-SHA256 .......................................................................................................6

65 5.3 Digest Algorithms ......................................................................................................7

66 5.3.1 SHA-256 ....................................................................................................... 7

67 5.3.2 SHA-384 ....................................................................................................... 7

68 5.3.3 SHA-512 ....................................................................................................... 7

69 6. Model Overview................................................................................................................ 8

70 6.1 Signature Types ........................................................................................................8

71 6.1.1 Detached....................................................................................................... 9

72 6.1.2 Enveloped..................................................................................................... 9

73 6.1.3 Enveloping ...................................................................................................10

74 6.2 XML Signature Syntax Overview .............................................................................10

75 6.2.1 SignedInfo....................................................................................................11

76 6.2.2 KeyInfo.........................................................................................................12

77 6.2.3 Object ..........................................................................................................12

78 6.2.4 References...................................................................................................13

79 6.3 Conventions ............................................................................................................14

80 6.3.1 Canonicalization...........................................................................................14

81 6.3.2 Countersigning.............................................................................................14

82 6.3.3 Id Values......................................................................................................14

83 7. Processing Requirements ..............................................................................................15

84 7.1 Signature Identifiers ................................................................................................15

85 7.2 Signature Verification ..............................................................................................15

86 7.3 Manifest References ...............................................................................................15

87 7.4 KeyInfo....................................................................................................................15

88 7.5 Countersigning ........................................................................................................15

89

90 List of Appendices

91 Appendix A— Example Usage ...............................................................................................16

92 Appendix B— References .....................................................................................................17
TRUST MODEL FOR SECURITY AUTOMATION DATA 1.0 (TMSAD) (DRAFT)

vi

93 B.1 Normative References.............................................................................................17

94 B.2 Informative References ...........................................................................................17

95 Appendix C— Change Log.....................................................................................................19

96

97 List of Figures and Tables

98 Table 1 – Conventional XML Mappings...................................................................................... 2

99 Figure 1 – High-Level Signature Diagram .................................................................................. 8

100 Figure 2 – Detached Signature in a Separate Document ........................................................... 9

101 Figure 3 – Detached Signature in the Same Document.............................................................. 9

102 Figure 4 – Enveloped Signature................................................................................................. 9

103 Figure 5 – Enveloping Signature ...............................................................................................10

104 Figure 6 – XML Signature Syntax Element Hierarchy ...............................................................11

105 Table 2 – dt:signature-info ........................................................................................................13

106

107

108
TRUST MODEL FOR SECURITY AUTOMATION DATA 1.0 (TMSAD) (DRAFT)

1

109 1. Introduction

110 A trust model is a necessary component for handling security automation data to permit users to establish 

111 integrity, authentication, and traceability for the data. The trust model can be leveraged to determine 

112 authorization—that a requestor of a particular piece of information is permitted access to that information, 

113 or that a particular piece of content is permitted to be processed. A trust model may also be used to 

114 implement traceability of results, giving increased assurance that a set of results are from a particular 

115 source. Finally, a trust model will allow for content integrity to be affirmed, assuring that content has not 

116 been modified since it was produced, whether by human or machine.

117 1.1 Purpose and Scope

118 This document provides guidelines and recommendations for how a common trust model, called the Trust 

119 Model for Security Automation Data (TMSAD), can be applied to specifications within the security 

120 automation domain, such as Security Content Automation Protocol (SCAP). Since information in the 

121 security automation domain is primarily exchanged using Extensible Markup Language (XML), the focus 

122 of this model is on the processing of XML documents [XML]. The trust model is composed of 

123 recommendations on how to use existing specifications to represent signatures, hashes, key information, 

124 and identity information in the context of an XML document within the security automation domain.

125 This document makes extensive use of the W3C recommendation XML Signature Syntax and Processing

126 [XMLDSIG], referencing the features and syntax of [XMLDSIG]. The requirements of those features are 

127 described in the W3C recommendation and are not repeated in this document. It is expected that readers 

128 of this document will already be familiar with the details of [XMLDSIG].

129 Detailing a method for managing and exchanging public keys is out of scope for this document. This 

130 document provides information on how X.509 certificates or public keys may be represented within the 

131 model; however, this document defers to the content consumer for establishing a trust relationship to a 

132 particular identity or key.

133 1.2 Document Structure

134 This report is organized into the following major sections:

135 Section 2 defines selected terms and abbreviations used in this specification.

136 Section 3 provides an overview of related specifications and standards.

137 Section 4 defines the high-level conformance rules for this specification.

138 Section 5 defines the cryptographic algorithms and parameters to those algorithms that may be 

139 used for hashing and signing.

140 Section 6 provides a brief overview of the XML Signature Syntax and Processing specification; it 

141 defines how that specification will be used and what additional requirements security automation 

142 will impose.

143 Section 7 describes processing requirements for the trust model.

144 Appendix A provides some examples of usage of the defined trust model.

145 Appendix B lists normative and informative references.
TRUST MODEL FOR SECURITY AUTOMATION DATA 1.0 (TMSAD) (DRAFT)

2

146 Appendix C provides a change log that documents significant changes to major drafts of the 

147 specification.

148 1.3 Document Conventions

149 The key words ―MUST‖, ―MUST NOT‖, ―REQUIRED‖, ―SHALL‖, ―SHALL NOT‖, ―SHOULD‖, 

150 ―SHOULD NOT‖, ―RECOMMENDED‖, ―MAY‖, and ―OPTIONAL‖ in this document are to be 

151 interpreted as described in [RFC2119].

152 Text intended to represent computing system input, output, or algorithmic processing is presented in 

153 fixed-width Courier font.

154 Table 1 shows the conventional XML mappings used in this document.

155 Table 1 – Conventional XML Mappings

Prefix Namespace Schema 

dc http://purl.org/dc/elements/1.1/ Simple Dublin Core elements

dsig http://www.w3.org/2000/09/xmldsig# Interoperable XML digital signatures

dt http://scap.nist.gov/schema/xml-dsig/1.0 Trust Model for Security Automation Data

extensions

xs http://www.w3.org/2001/XMLSchema XML Schema schema document
TRUST MODEL FOR SECURITY AUTOMATION DATA 1.0 (TMSAD) (DRAFT)

3

156 2. Abbreviations

157 This section defines selected abbreviations, including acronyms, used within the document. 

158 DSS – Digital Signature Standard 

159 ECDSA – Elliptic Curve Digital Signature Algorithm

160 FIPS – Federal Information Processing Standards

161 IR – Interagency Report

162 RFC – Request for Comments

163 SCAP – Security Content Automation Protocol

164 SHA – Secure Hash Algorithm

165 SP – Special Publication

166 TMSAD – Trust Model for Security Automation Data

167 URI – Uniform Resource Identifier

168 W3C – World Wide Web Consortium

169 XML – Extensible Markup Language

170 XSLT – Extensible Stylesheet Language Transformation

171
TRUST MODEL FOR SECURITY AUTOMATION DATA 1.0 (TMSAD) (DRAFT)

4

172 3. Relationship to Existing Specifications and Standards

173 This document makes use of existing specifications such as XML Signature Syntax and Processing

174 [XMLDSIG] to establish a trust model. This document further specifies and constrains usage of 

175 [XMLDSIG] and other W3C recommendations to satisfy requirements exposed within the security 

176 automation domain.

177 Although XML Signature Syntax and Processing Version 1.1 [XMLDSIG-11] is not a W3C 

178 recommendation as of mid-2011, this document adds requirements for selected cryptographic algorithms 

179 consistent with the requirements currently included in [XMLDSIG-11].
TRUST MODEL FOR SECURITY AUTOMATION DATA 1.0 (TMSAD) (DRAFT)

5

180 4. Conformance

181 Products and organizations may want to claim conformance with this specification for a variety of 

182 reasons. For example, a software vendor may want to assert that its product uses the trust model properly 

183 and can interoperate with any other product using the trust model. Another example is a policy mandating 

184 that an organization use the trust model for establishing suitability of content for use, or establishing 

185 provenance of content.

186 This section provides the high-level requirements that a product or document containing signature 

187 information MUST meet for conformance with this specification. Most of the requirements listed in this 

188 section reference other sections in the document that fully define the requirements.

189 Other specifications that use the trust model defined within this document MAY define additional 

190 requirements and recommendations. In addition, other specifications or standards MAY define additional 

191 requirements on the correct implementation of the cryptographic algorithms in specific environments or 

192 situations. Such requirements and recommendations are outside the scope of this publication.

193 4.1 Product Conformance

194 There are two types of products that may be conformant with the trust model: content authors and content 

195 consumers. Content authors are products that generate content that uses the trust model, while content 

196 consumers are products that process content that leverages the trust model. All products claiming 

197 conformance with this specification MUST comply with the following requirements:

198 1. Content consumers MUST consume and correctly process well-formed trust model documents as 

199 defined in Section 6. This includes following all of the processes defined in Section 7.

200 2. Content authors MUST ensure that all trust model documents they produce are well-formed. This 

201 includes following all of the processes defined in Section 7, and adhering to the syntax, structural, and 

202 other trust model document development requirements defined in Section 6.

203 3. All products MUST support the algorithms and parameters identified in Section 5.

204 4. Make an explicit claim of conformance to this specification in documentation provided to end users.

205 4.2 Content Conformance

206 Organizations creating or maintaining documents that claim conformance with this specification SHALL 

207 adhere to the syntax, structural, and other trust model document development requirements defined in 

208 Section 6.

209 In addition there are recommendations in Section 5 that organizations SHOULD consider when creating 

210 or maintaining trust model documents.
TRUST MODEL FOR SECURITY AUTOMATION DATA 1.0 (TMSAD) (DRAFT)

6

211 5. Algorithms and Parameters

212 Since [XMLDSIG] does not require support for all of the signature and hash algorithms needed for the 

213 trust model, this section adds requirements for supporting the RSA Algorithm signature method with 

214 SHA-256 algorithm and the ECDSAwithSHA256 signature algorithm. This section adds these selected 

215 algorithms into the trust model consistent with both RFC 4051 [RFC4051] and the currently under 

216 development [XMLDSIG-11]. The RSA algorithm refers to the RSASSA-PKCS1-v1_5 algorithm 

217 described in section 8.2 of RFC 3447 [PKCS1].

218 Other algorithms not otherwise required by [XMLDSIG] or this section MAY OPTIONALLY be used by 

219 content authors and supported by content consumers, but only the algorithms and parameters required by 

220 [XMLDSIG] and this section are assured to be interoperable across all implementations. If an algorithm 

221 identifier has been specified in [RFC4051], the identifier specified within [RFC4051] SHOULD be used. 

222 Section 7 includes additional processing requirements for content consumers.

223 NIST Federal Information Processing Standards (FIPS) 186-3, Digital Signature Standard (DSS)

224 [FIPS186-3] and NIST Special Publication (SP) 800-57, Recommendation for Key Management – Part 1: 

225 General [SP800-57] provide additional information relating to security considerations in key size choice 

226 for various algorithms.

227 5.1 RSA-SHA256

228 The RSA Algorithm signature method with SHA-256 algorithm MUST be supported. Consistent with 

229 section 2.3.2 of [RFC4051] and section 6.4.2 of [XMLDSIG-11], the RSA Algorithm signature method 

230 with SHA-256 algorithm MUST be identified using the following algorithm identifier:

231 http://www.w3.org/2001/04/xmldsig-more#rsa-sha256

232 The <dsig:SignatureValue> content for this identifier MUST be the base64 encoding, as 

233 described in RFC 2045 [RFC2045], of the octet string, S, specified in section 8.2.1 of RFC 3447 

234 [PKCS1]. Signature computation and verification does not require implementation of an ASN.1 parser.

235 For the RSA Algorithm, content consumers MUST support 2048-bit keys and SHOULD support 3072-bit

236 keys. Content authors SHOULD use a key size of either 2048 or 3072 bits.

237 5.2 ECDSA-SHA256

238 The ECDSAwithSHA256 signature algorithm MUST be supported, which is ECDSA [FIPS186-3] over 

239 the P-256 prime curve specified in Appendix D of [FIPS186-3] and using the SHA-256 algorithm. 

240 Consistent with section 2.3.6 of [RFC4051] and section 6.4.3 of [XMLDSIG-11], the 

241 ECDSAwithSHA256 MUST be identified using the following algorithm identifier:

242 http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256

243 The ECDSA algorithm signature is a pair of integers referred to as (r, s). The 

244 <dsig:SignatureValue> consists of the base64 [RFC2045] encoding of the concatenation of two 

245 octet-streams that respectively result from the octet-encoding of the values r and s, in that order. Integer to 

246 octet-stream conversion MUST be done according to the I2OSP operation defined in Section 4.1 of RFC 

247 3447 [PKCS1] with the xLen parameter equal to the size of the base point order of the curve in bytes (32 

248 for the P-256 curve).
TRUST MODEL FOR SECURITY AUTOMATION DATA 1.0 (TMSAD) (DRAFT)

7

249 5.3 Digest Algorithms

250 While content consumers are still REQUIRED to support the SHA-1 Digest algorithm as defined in 

251 section 6.2.1 of [XMLDSIG], content authors SHOULD NOT use the SHA-1 Digest algorithm. Content 

252 authors SHOULD instead use one of the algorithms defined within this section. The identifiers used 

253 below are consistent with either [RFC4051] or the identifiers used in XML Encryption Syntax and 

254 Processing [XMLENC], and with the current work occurring on [XMLDSIG-11]. The SHA-256 Digest 

255 algorithm MUST be supported by conforming implementations. SHA-384 and SHA-512 are OPTIONAL 

256 to support.

257 5.3.1 SHA-256

258 The SHA-256 algorithm [FIPS180-3] MUST be identified using the following algorithm identifier:

259 http://www.w3.org/2001/04/xmlenc#sha256

260 The SHA-256 algorithm produces a 256-bit digest string. The content of the <dsig:DigestValue>

261 MUST be the base64 [RFC2045] encoding of the digest string viewed as a 32-octet octet stream.

262 5.3.2 SHA-384

263 The SHA-384 algorithm [FIPS180-3] MUST be identified using the following algorithm identifier:

264 http://www.w3.org/2001/04/xmldsig-more#sha384

265 The SHA-384 algorithm produces a 384-bit digest string. The content of the <dsig:DigestValue>

266 MUST be the base64 [RFC2045] encoding of the digest string viewed as a 48-octet octet stream.

267 5.3.3 SHA-512 

268 The SHA-512 algorithm [FIPS180-3] MUST be identified using the following algorithm identifier:

269 http://www.w3.org/2001/04/xmlenc#sha512

270 The SHA-512 algorithm produces a 512-bit digest string. The content of the <dsig:DigestValue>

271 MUST be the base64 [RFC2045] encoding of the digest string viewed as a 64-octet octet stream.
TRUST MODEL FOR SECURITY AUTOMATION DATA 1.0 (TMSAD) (DRAFT)

8

272 6. Model Overview

273 The syntax and processing of the trust model is based on the [XMLDSIG] W3C Recommendation, and 

274 content authors and consumers MUST follow the conformance requirements found in [XMLDSIG]. This 

275 section provides a high-level overview and gives recommendations on how [XMLDSIG] can be used to 

276 establish a mechanism where signature information can be provided for the XML documents used within 

277 the security automation domain.

278 Figure 1 shows an informative, high-level composition of a signature. Not all signatures will contain all 

279 elements, and some signatures could contain additional elements. Content authors can create the signature 

280 block based on the documents necessary for their use case. Content consumers can validate the signature 

281 block prior to processing the signed content.

282 6.1 Signature Types

283 As defined by [XMLDSIG], there are three main ways that a signature can relate to a given reference, and 

284 it is possible that the same signature will contain references with different signature relationships. The 

285 three possible signature relationships are:

286 Detached - the signature is over content external to the signature itself

287 Enveloped - the signature is embedded within the content that is signed

288 Enveloping - the signature contains the content that is signed

289 The following subsections provide more information on selecting the appropriate style of signature.

Signature Block

reference - document reference - manifest

reference - signature properties

manifest

reference - external1 reference - external2

reference - external3

signature properties

Figure 1 – High-Level Signature Diagram
TRUST MODEL FOR SECURITY AUTOMATION DATA 1.0 (TMSAD) (DRAFT)

9

290 6.1.1 Detached

291

292 A detached signature typically occurs when the signature and signed content are separate. Figure 2

293 represents the case when the signed content and the signature are in two separate documents. Figure 3

294 represents a detached signature where the signed content and signature are in the same document but are 

295 sibling nodes (or a child node of a sibling). Note that in Figure 3 the ―Signature‖ can occur either before 

296 or after the ―Signed Content‖. The consequence of a detached signature is that the content being signed 

297 may be managed independently, and it is not necessary for the content being signed to provide an element 

298 for containing the signature. It is necessary that another file containing the signature, or a file format 

299 capable of containing the signature and the signed content must be created or used. ―Detached‖ is most 

300 commonly useful when a collection of documents must be signed with a single signature, or if a 

301 document must be signed but a signature element has not been provided.

302 6.1.2 Enveloped

Document1 Document2

Signed Content Signature

Figure 2 – Detached Signature in a Separate Document

Document

Signed Content

Signature

Figure 3 – Detached Signature in the Same Document

Document

Signed Content

Signature

Figure 4 – Enveloped Signature
TRUST MODEL FOR SECURITY AUTOMATION DATA 1.0 (TMSAD) (DRAFT)

10

303 Figure 4 shows how an enveloped signature relates to the signed content. The signed content has an 

304 element that contains the signature. A named transform is used to exclude the signature element during 

305 signature validation. In contrast to the detached signature, when the signature is enveloped in the content 

306 being signed, a specific version of the signature specification must be referenced by the content being 

307 signed. Additionally, whenever content is signed, the signature will always be available with the content,

308 unlike with a detached signature where the signature may be located separately. Enveloped is most 

309 commonly useful when a single standalone document must be signed independent of any other 

310 documents.

311 6.1.3 Enveloping

312 Figure 5 shows how an enveloping signature relates to the signed content. The signed content is contained 

313 as a child of the <dsig:Object> node within the signature. To process the signed content, the 

314 signature syntax will also need to be processed. If the same content is unsigned, it will have a different 

315 format from the signed version of the content. As with enveloped, the signature will always be available 

316 with the content if it has been signed. Most commonly, enveloping is useful for when the content is 

317 another signature that must signed. Manifest and signature properties also have an enveloping relationship 

318 to the signature which includes these elements.

319 6.2 XML Signature Syntax Overview

320 All signature content MUST conform to the [XMLDSIG] specification and validate against the schema 

321 found at http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd. Section 

322 2.0 of [XMLDSIG] has a figure showing an informal representation of the syntax. Figure 6 is a modified 

323 version of that figure to show additional areas of interest. The additional highlighted items are the 

324 <dsig:KeyValue>, <dsig:X509Data>, <dsig:Manifest>, and 

325 <dsig:SignatureProperties> elements. The <dsig:KeyValue> and <dsig:X509Data>

326 elements are ways to obtain the public key that can be used to validate the signature. In Figure 6 the "?", 

327 "+", and "*" characters represent the number of times the preceding element or attribute is to be used. "?" 

328 represents once or not at all, "+" represents one or more times, and "*" represents zero or more times.

Document

Signature

Signed Content

Figure 5 – Enveloping Signature
TRUST MODEL FOR SECURITY AUTOMATION DATA 1.0 (TMSAD) (DRAFT)

11

329 The <dsig:Manifest> element is used to provide additional references which compose the content.

330 The <dsig:SignatureProperties> element is used to provide metadata about the signature. An 

331 additional use would be for the inclusion of timestamp information according to the recommendations in 

332 NIST SP 800-102, Recommendation for Digital Signature Timeliness [SP800-102].

333 Once a signature has been created, the signature and the content referred to by <dsig:Reference>

334 elements cannot be reformatted, except as is permissible by the XML Canonicalization transform that has 

335 been applied [XML-C14N, XML-C14N11, and XML-exc-C14N]. The possible scope of reformatting is 

336 very limited and content consumers SHOULD maintain the format of received content.

337 6.2.1 SignedInfo

338 <dsig:SignedInfo> includes the canonicalization method for the signature block itself, the signature 

339 method, and references to the content that is part of what is signed. Any element outside of the 

340 <dsig:SignedInfo> element that is not referenced is not included as part of the signature validation.

341 According to [XMLDSIG] a <dsig:SignedInfo> element MUST include at least one

342 <dsig:Reference>. If only one <dsig:Reference> is provided, it SHOULD be to the content 

<Signature ID?> 

<SignedInfo>

 <CanonicalizationMethod/>

 <SignatureMethod/>

 <Reference URI? >

 <Transforms/>?

 <DigestMethod/>

 <DigestValue/>

 </Reference>)+

 </SignedInfo>

 <SignatureValue/>

 <KeyInfo>

 <KeyValue/>?

 <X509Data/>?

 </KeyInfo>

 <Object ID>

 <Manifest>

 <Reference URI? >

 <Transforms/>?

 <DigestMethod/>

 <DigestValue/>

 </Reference>)+

 </Manifest>

 </Object>?

 <Object ID>

 <SignatureProperties>

 <SignatureProperty/>+

 </SignatureProperties>

 </Object>

 <Object ID?>*

</Signature>

Figure 6 – XML Signature Syntax Element Hierarchy
TRUST MODEL FOR SECURITY AUTOMATION DATA 1.0 (TMSAD) (DRAFT)

12

343 being signed. An additional <dsig:Reference> to a <dsig:SignatureProperties> element 

344 as described in Section 6.2.3.2 SHOULD also be included. If the content being signed is dependent upon 

345 additional references, see Section 6.2.3.1 for additional guidelines.

346 6.2.2 KeyInfo

347 The <dsig:KeyInfo> element MAY be used to provide information about how to obtain the key 

348 needed for signature validation. In addition to the requirements in section 4.4 of [XMLDSIG],

349 applications MUST implement support for the <dsig:X509Data> element in section 4.4.4 of 

350 [XMLDSIG].

351 RFC 4050 [RFC4050] describes a possible <dsig:KeyValue> representation for an ECDSA key. The 

352 representation and processing instructions described in [RFC4050] are not completely compatible with 

353 [XMLDSIG-11]; therefore, ECDSA keys SHOULD NOT be provided through a <dsig:KeyValue>

354 element.

355 Note that unless a <dsig:Reference> to the <dsig:KeyInfo> is included, the 

356 <dsig:KeyInfo> is not validated as part of the signature.

357 6.2.3 Object

358 The <dsig:Object> element holds data that can be referenced, usually for an enveloping signature.

359 The <dsig:SignatureProperties> and <dsig:Manifest> elements are both children of 

360 <dsig:Object>.

361 6.2.3.1 Manifest

362 The <dsig:Manifest> element SHOULD be used when additional document references beyond the 

363 main document reference are necessary. This is typically the case when a collection of documents is 

364 needed to represent all of the necessary content or when a primary document has dependencies on content 

365 in additional documents. When the <dsig:Manifest> element is used, there MUST be a 

366 <dsig:Reference> within the <dsig:SignedInfo> element which references the 

367 <dsig:Manifest>. See Section 6.2.4 for the requirements on how the reference is accomplished. The 

368 content of the <dsig:Reference> elements MUST follow the requirements in Section 6.2.4. A 

369 <dsig:Reference> element included as a child of a <dsig:Manifest> will not be validated 

370 during signature validation.

371 6.2.3.2 SignatureProperty

372 A <dsig:SignatureProperties> element SHOULD be included on a signature as a child element 

373 of <dsig:Object>. The <dsig:SignatureProperties> element MUST contain at least one 

374 <dsig:SignatureProperty> element. The <dsig:SignatureProperty> element captures

375 metadata information about the signature. If the RECOMMENDED <dt:signature-info>

376 element is included, it MUST be included as the lone child of a <dsig:SignatureProperty>

377 element included within a <dsig:SignatureProperties> element. This parent 

378 <dsig:SignatureProperty> element MUST include the @Target attribute populated with ―#‖ + 

379 ID of the signature. Table 2 describes the <dt:signature-info> data model.
TRUST MODEL FOR SECURITY AUTOMATION DATA 1.0 (TMSAD) (DRAFT)

13

380 Table 2 – dt:signature-info

Element Name: dt:signature-info

Definition A root element capturing common metadata about an XML digital signature.

Properties Name Type Count Definition

dc:creator literal – string 0-n The person, organization, or tool that created the 

signature.

dc:date literal – dateTime 0-1 The date and time when the signature was created.

nonce literal – token 0-1 A token value. Possible uses include ordering of 

requests and preventing replay attacks.

381

382 An example of a <dsig:SignatureProperties> is included below:

383 <dsig:Object>

384 <dsig:SignatureProperties Id="signature-prop-global-id1">

385 <dsig:SignaturePropertyTarget="#digital-sig-gloabl-id1">

386 <dt:signature-info>

387 <dc:creator>John Smith</dc:creator>

388 <dc:creator>ACME Inc</dc:creator>

389 <dc:date>2011-07-01T00:00:00Z</dc:date>

390 <dsig:nonce>04EED3035045C9E7</dsig:nonce>

391 </dt:signature-info>

392 </dsig:SignatureProperty>

393 </dsig:SignatureProperties>

394 </dsig:Object>

395 The XML Schema for the <dt:signature-info> element is at 

396 http://scap.nist.gov/specifications/tmsad/#resource-1.0.

397 6.2.4 References

398 References are an essential part of an XML digital signature. This section contains requirements specific 

399 to the construction of references. These requirements apply to a <dsig:Reference> that is a child of 

400 either <dsig:SignedInfo> or <dsig:Manifest>.

401 If the document that contains the signature is referenced, it SHOULD be referenced by setting the @URI

402 attribute on <dsig:Reference> to the empty string (i.e., @URI=―‖). When referencing items in the 

403 signature that have an attribute of type xs:ID such as <dsig:Object>, <dsig:Manifest>, or 

404 <dsig:SignatureProperties>, they SHOULD be referenced using a URI fragment (e.g.,

405 @URI=“#referenceIdentifier”).

406 When referencing a <dsig:Object>, <dsig:Manifest>, or 

407 <dsig:SignatureProperties> from a <dsig:Reference>, the @Type attribute MUST be 

408 specified, and it MUST contain http://www.w3.org/2000/09/xmldsig#Object, 

409 http://www.w3.org/2000/09/xmldsig#Manifest, or 

410 http://www.w3.org/2000/09/xmldsig#SignatureProperties, respectively.

411 When specifying XPath transforms, content authors SHOULD use only XPath Filter 2.0 [XPath Filter-2] , 

412 which is consistent with XML Digital Signature best practices [XMLDSIG-BEST]. Due to the more 

413 limited support of XPath 2.0, XPath transforms SHOULD use only XPath 1.0 [XPath] expressions.
TRUST MODEL FOR SECURITY AUTOMATION DATA 1.0 (TMSAD) (DRAFT)

14

414 When referencing the root node of an XML document, if an ID exists on the root node that is not of type 

415 xs:ID, then the reference SHOULD specify an [XPath Filter-2] transform targeting the root node by ID. 

416 For example, if the root node of a document is <root-node id=”root123”>, then the [XPath 

417 Filter-2] expression would be ―root-node[@id = “root123”]‖ with a @Filter attribute value 

418 of ―intersect‖. This approach is preferable because if the signed document is later included as a child 

419 node within another XML document, the signature can still be valid (unless there is an ID conflict).

420 Unnamed XSLT transforms SHOULD be avoided. Specifications requiring XSLT transform capabilities 

421 SHOULD create named XSLT transforms to avoid the issues with XSLT transforms identified in 

422 [XMLDSIG-BEST].

423 When specifying multiple transforms on a reference, the transforms SHOULD be specified in this order:

1. Enveloped Signature Transform (only when the signature is enveloped1424 )

425 2. XPath Filter 2 Transforms (if applicable)

426 3. Named or XSLT Transforms (if applicable)

427 4. XML Canonicalization (only if the last transform outputs XML)

428 This ordering resulted from issues with an implementation of the [XMLDSIG] specification, when the 

429 enveloped signature transform was not the first transform. Additionally, because there is no guarantee that 

430 a Named or XSLT transform will result in XML, those transforms SHOULD come after the XPath Filter 

431 2 transforms.

432 6.3 Conventions

433 This section contains additional conventions that apply to the creation of the signature.

434 6.3.1 Canonicalization

435 No additional support for canonicalization algorithms is necessary beyond what is specified in 

436 [XMLDSIG]. Content authors SHOULD use the Canonical XML 1.1 method [XML-C14N11].

437 6.3.2 Countersigning

438 Countersigning is the creation of a signature for content that has already been signed while maintaining 

439 the previous signature. Keeping the previous signature allows for provenance to be preserved over the 

440 content. A countersigner is signing the existing signature and not the content itself; therefore, the existing 

441 signature MUST validate successfully prior to countersigning. When countersigning an existing signature,

442 content authors MUST include the original signature as a child to a <dsig:Object> element of the 

443 new signature and reference the <dsig:Object> within the new signature. The original signature 

444 MUST then be removed from the document and replaced with the new countersigning signature.

445 6.3.3 Id Values

446 <dsig:Signature>, <dsig:SignatureProperties>, <dsig:Manifest>, and 

447 <dsig:Object> each have an @Id attribute. The @Id attribute for these elements SHOULD be 

448 globally unique to permit document composition.

 

1

http://www.w3.org/TR/xmldsig-core/#def-SignatureEnveloped
TRUST MODEL FOR SECURITY AUTOMATION DATA 1.0 (TMSAD) (DRAFT)

15

449 7. Processing Requirements

450 All implementations MUST implement the processing requirements specified in [XMLDSIG]. This 

451 section describes additional general processing requirements that implementations of the trust model 

452 MUST follow to correctly process the trust model.

453 7.1 Signature Identifiers

454 If an algorithm identifier has been specified in [RFC4051] and the identifier specified within [RFC4051]

455 was used, implementations SHOULD follow any processing guidance associated with the identifier as 

456 specified within [RFC4051]. If, during validation of a signature, a content consumer encounters an 

457 algorithm or algorithm parameter that the content consumer does not support, an error MUST be issued. 

458 Algorithm parameters also include any implicit parameters such as the length in bits of the key.

459 7.2 Signature Verification

460 While not a requirement, when performing signature verification, implementations are encouraged to 

461 follow the relevant best practices in XML Signature Best Practices [XMLDSIG-BEST].

462 7.3 Manifest References

463 Although the content within a <dsig:Manifest> element is validated, the content for a 

464 <dsig:Reference> element that is a child of a <dsig:Manifest> element is not validated during 

465 signature validation. All content consumers that validate a signature MUST also validate a reference 

466 according to the reference validation requirements identified in section 3.2.1of [XMLDSIG].

467 7.4 KeyInfo

468 When processing a signature, if the <dsig:KeyInfo> element has not been provided, then a content 

469 consumer MUST either issue an error or provide a method for associating the content with a key that can 

470 be used to validate the signature.

471 7.5 Countersigning

472 When a signature (i.e., countersigning signature) countersigns another signature (i.e., countersigned 

473 signature) by including the countersigned signature as a child element to a <dsig:Object>, and the 

countersigned signature specifies the ―Enveloped Signature Transform‖2474 on one of its references, then 

475 special processing rules apply. Specifically, after validating the countersigning signature, the 

476 countersigning signature MUST be replaced in the XML content by the countersigned signature. If the 

477 ―Enveloped Signature Transform‖ is not specified on any of the countersigned signature’s references, 

478 then the replace step MAY be skipped. Lastly, the countersigned signature MUST be validated. An error 

479 MUST be issued if a chain of signature references results in a cycle.

 

2

http://www.w3.org/TR/xmldsig-core/#sec-EnvelopedSignature
TRUST MODEL FOR SECURITY AUTOMATION DATA 1.0 (TMSAD) (DRAFT)

16

480 Appendix A—Example Usage

481 Example demonstrations of the information in this document can be found at 

482 http://scap.nist.gov/specifications/tmsad/#resource-1.0. Examples are:

483 signing/hashing of a single document

484 signing with a manifest

485 countersigning (signing an already signed document)
TRUST MODEL FOR SECURITY AUTOMATION DATA 1.0 (TMSAD) (DRAFT)

17

486 Appendix B—References 

487 B.1 Normative References

488 [FIPS180-3] United States. National Institute of Standards and Technology. Federal Information 

489 Processing Standards Publication 180-3, Secure Hash Standard (SHS). October 2008. See 

490 http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf.

491 [FIPS186-3] United States. National Institute of Standards and Technology. Federal Information 

492 Processing Standards Publication 186-3, Digital Signature Standard (DSS). June 2009. See

493 http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf.

494 [PKCS1] Jonsson, J. and B. Kaliski (2003). Public-Key Cryptography Standards (PKCS) #1: RSA 

495 Cryptography Specifications Version 2.1. February 2003. See http://www.ietf.org/rfc/rfc3447.txt. 

496 [RFC2045] Freed, N. and N. Borenstein, (1996). Multipurpose Internet Mail Extensions (MIME) Part 

497 One: Format of Internet Message Bodies. November 1996. See http://www.ietf.org/rfc/rfc2045.txt.

498 [RFC2119] Bradner, S. (1997). Key words for use in RFCs to Indicate Requirement Levels. March 1997. 

499 See http://www.ietf.org/rfc/rfc2119.txt.

500 [RFC4051] Eastlake, D. (2005). Additional XML Security Uniform Resource Identifiers (URIs). April 

501 2005. See http://www.ietf.org/rfc/rfc4051.txt.

502 [XML-C14N] Boyer, John (2001). Canonical XML Version 1.0, W3C Recommendation, March 2001. 

503 See http://www.w3.org/TR/2001/REC-xml-c14n-20010315 or http://www.ietf.org/rfc/rfc3076.txt.

504 [XML-C14N11] Boyer, John and Glenn Marcy (2008). Canonical XML Version 1.1, W3C 

505 Recommendation, May 2008. See http://www.w3.org/TR/2008/REC-xml-c14n11-20080502.

[XMLDSIG] Eastlake, Donald, et al. (2008). XML Signature Syntax and Processing, 2nd 506 Edition, W3C 

507 Recommendation, June 2008. See http://www.w3.org/TR/xmldsig-core/.

508 [XML-exc-C14N] Boyer, John, Donald Eastlake, and Joseph Reagle (2002). Exclusive XML 

509 Canonicalization Version 1.0, W3C Recommendation, July 2002. See http://www.w3.org/TR/2002/REC510 xml-exc-c14n-20020718/.

511 [XPath] Clark, James and Steve DeRose (1999). XML Path Language (XPath) Version 1.0, W3C 

512 Recommendation. October 1999. See http://www.w3.org/TR/1999/REC-xpath-19991116.

513 [XPath Filter-2] Boyer, John, Merlin Hughes, and Joseph Reagle (2002). XML-Signature XPath Filter 

514 2.0, W3C Recommendation, November 2002. See http://www.w3.org/TR/2002/REC-xmldsig-filter2-

515 20021108/.

516 B.2 Informative References

517 [FIPS140-2] United States. National Institute of Standards and Technology. Federal Information 

518 Processing Standards Publication 140-2, Security Requirements for Cryptographic Modules. 25 May 

519 2001. See http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf.

520 [RFC4050] Blake-Wilson, S., et al. (2005). Using the Elliptic Curve Signature Algorithm (ECDSA) for 
TRUST MODEL FOR SECURITY AUTOMATION DATA 1.0 (TMSAD) (DRAFT)

18

521 XML Digital Signatures. April 2005. See http://www.ietf.org/rfc/rfc4050.txt.

522 [SP800-57] United States. National Institute of Standards and Technology. Special Publication 800-57, 

523 Recommendation for Key Management – Part 1: General. March 2007. See 

524 http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf.

525 [SP800-102] United States. National Institute of Standards and Technology. Special Publication 800-102, 

526 Recommendation for Digital Signature Timeliness. September 2009. See

527 http://csrc.nist.gov/publications/nistpubs/800-102/sp800-102.pdf.

[XML] Bray, Tim, et al. (2008). Extensible Markup Language (XML) 1.0, 5th 528 Edition, W3C 

529 Recommendation, November 2008. See http://www.w3.org/TR/2008/REC-xml-20081126/.

530 [XMLDSIG-11] Eastlake, Donald, et al. (2011). XML Signature Syntax and Processing Version 1.1, W3C 

531 Candidate Recommendation, March 2011. See http://www.w3.org/TR/2011/CR-xmldsig-core1-

532 20110303/.

533 [XMLDSIG-BEST] Hirsch, Frederick, and Datta, Pratik. (2010). XML Signature Best Practices, August 

534 2010. See http://www.w3.org/TR/xmldsig-bestpractices/.

535 [XMLENC] Eastlake, Donald and Joseph Reagle. (2002). XML Encryption Syntax and Processing, W3C 

536 Recommendation, December 2002. See http://www.w3.org/TR/xmlenc-core/.
TRUST MODEL FOR SECURITY AUTOMATION DATA 1.0 (TMSAD) (DRAFT)

19

537 Appendix C—Change Log

538 Release 0 – July 2011

539 Initial public release