idnits 2.17.1 draft-ietf-sidr-signed-object-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 9, 2011) is 4729 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 253 -- Looks like a reference, but probably isn't: '1' on line 240 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Inter-Domain Routing M. Lepinski 3 Internet-Draft A. Chi 4 Intended status: Standards Track S. Kent 5 Expires: November 9, 2011 BBN 6 May 9, 2011 8 Signed Object Template for the Resource Public Key Infrastructure 9 draft-ietf-sidr-signed-object-04.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF). Note that other groups may also distribute 18 working documents as Internet-Drafts. The list of current Internet- 19 Drafts is at http://datatracker.ietf.org/drafts/current/. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 This Internet-Draft will expire on August 16, 2011. 28 Copyright Notice 30 Copyright (c) 2011 IETF Trust and the persons identified as the 31 document authors. All rights reserved. 33 This document is subject to BCP 78 and the IETF Trust's Legal 34 Provisions Relating to IETF Documents 35 (http://trustee.ietf.org/license-info) in effect on the date of 36 publication of this document. Please review these documents 37 carefully, as they describe your rights and restrictions with respect 38 to this document. Code Components extracted from this document must 39 include Simplified BSD License text as described in Section 4.e of 40 the Trust Legal Provisions and are provided without warranty as 41 described in the Simplified BSD License. 43 Abstract 45 This document defines a generic profile for signed objects used in 46 the Resource Public Key Infrastructure (RPKI). These RPKI signed 47 objects make use of Cryptographic Message Syntax (CMS) as a standard 48 encapsulation format. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.2. Note on Algorithms . . . . . . . . . . . . . . . . . . . . 3 55 2. Signed Object Syntax . . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Signed-Data Content Type . . . . . . . . . . . . . . . . . 4 57 2.1.1. version . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1.2. digestAlgorithms . . . . . . . . . . . . . . . . . . . 5 59 2.1.3. encapContentInfo . . . . . . . . . . . . . . . . . . . 5 60 2.1.3.1. eContentType . . . . . . . . . . . . . . . . . . . 5 61 2.1.3.2. eContent . . . . . . . . . . . . . . . . . . . . . 5 62 2.1.4. certificates . . . . . . . . . . . . . . . . . . . . . 5 63 2.1.5. crls . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.1.6. signerInfos . . . . . . . . . . . . . . . . . . . . . . 6 65 2.1.6.1. version . . . . . . . . . . . . . . . . . . . . . . 6 66 2.1.6.2. sid . . . . . . . . . . . . . . . . . . . . . . . . 6 67 2.1.6.3. digestAlgorithm . . . . . . . . . . . . . . . . . . 6 68 2.1.6.4. signedAttrs . . . . . . . . . . . . . . . . . . . . 6 69 2.1.6.4.1. Content-Type Attribute . . . . . . . . . . . . 7 70 2.1.6.4.2. Message-Digest Attribute . . . . . . . . . . . 7 71 2.1.6.4.3. SigningTime Attribute . . . . . . . . . . . . . 7 72 2.1.6.4.4. BinarySigningTime Attribute . . . . . . . . . . 8 73 2.1.6.5. signatureAlgorithm . . . . . . . . . . . . . . . . 8 74 2.1.6.6. signature . . . . . . . . . . . . . . . . . . . . . 8 75 2.1.6.7. unsignedAttrs . . . . . . . . . . . . . . . . . . . 8 76 3. Signed Object Validation . . . . . . . . . . . . . . . . . . . 9 77 4. Definition of Specific Signed Objects . . . . . . . . . . . . . 10 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 11 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 81 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 82 9. Informative References . . . . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 85 1. Introduction 87 The purpose of the Internet IP Address and Autonomous System (AS) 88 Number Resource Public Key Infrastructure (RPKI) system is to support 89 assertions by current resource holders of IP (v4 and v6) address 90 space and AS numbers, based on the records of the organizations that 91 act as Certification Authorities (CAs). IP address and AS number 92 resource information is carried in X.509 certificates via RFC 3779 93 extensions [I-D.sidr-res-certs]. Other information assertions about 94 resources are expressed via digitally signed, non-X.509 data 95 structures that are referred to as "signed objects" in the RPKI 96 context [I-D.sidr-arch]. This document standardizes a template for 97 specifying signed objects that can be validated using the RPKI. 99 RPKI signed objects make use of Cryptographic Message Syntax (CMS) 100 [RFC5652] as a standard encapsulation format. CMS was chosen to take 101 advantage of existing open source software available for processing 102 messages in this format. RPKI signed objects adhere to a profile 103 (specified in Section 2) of the CMS signed-data object. 105 The template defined in this document for RPKI signed objects is not 106 a complete specification for any particular type of signed object, 107 and instead includes only the items which are common to all RPKI 108 signed objects. That is, fully specifying a particular type of signed 109 object requires an additional document that specifies the details 110 which are specific to a particular type of signed object. Such 111 details include Abstract Syntax Notation One (ASN.1) [X.208-88] 112 syntax for the object's payload and any additional steps required to 113 validate the particular type of signed object. Section 4 describes in 114 more detail the additional pieces that must be specified in order to 115 define a new type of RPKI signed object that uses this template. 116 Additionally, see [I-D.sidr-roa-format] for an example of a document 117 that uses this template to specify a particular type of signed 118 object, the Route Origination Authorization. 120 1.1. Terminology 122 It is assumed that the reader is familiar with the terms and concepts 123 described in "Internet X.509 Public Key Infrastructure Certificate 124 and Certificate Revocation List (CRL) Profile" [RFC5280] and "X.509 125 Extensions for IP Addresses and AS Identifiers" [RFC3779], and 126 "Cryptographic Message Syntax (CMS)" [RFC5652]. 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 1.2. Note on Algorithms 133 Cryptographic Message Syntax is a general format capable of 134 accommodating a wide variety of signature and digest algorithms. The 135 algorithms used in the RPKI (and associated key sizes) are specified 136 in [I-D.sidr-rpki-algs]. 138 2. Signed Object Syntax 140 The RPKI signed object is a profile of the Cryptographic Message 141 Syntax (CMS) [RFC5652] signed-data object, with the restriction that 142 RPKI signed objects MUST be encoded using the ASN.1 Distinguished 143 Encoding Rules (DER) [X.509-88]. 145 The general format of a CMS object is: 147 ContentInfo ::= SEQUENCE { 148 contentType ContentType, 149 content [0] EXPLICIT ANY DEFINED BY contentType } 151 ContentType ::= OBJECT IDENTIFIER 153 The ContentType is the signed-data type of id-data, namely the id- 154 signedData OID, 1.2.840.113549.1.7.2. [RFC5652] 156 2.1. Signed-Data Content Type 158 According to the CMS standard, the signed-data content type is the 159 ASN.1 type SignedData: 161 SignedData ::= SEQUENCE { 162 version CMSVersion, 163 digestAlgorithms DigestAlgorithmIdentifiers, 164 encapContentInfo EncapsulatedContentInfo, 165 certificates [0] IMPLICIT CertificateSet OPTIONAL, 166 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 167 signerInfos SignerInfos } 169 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 171 SignerInfos ::= SET OF SignerInfo 173 Additionally, the SignerInfos set MUST contain only a single 174 SignerInfo object. 176 2.1.1. version 178 The version is the syntax version number. It MUST be 3, 179 corresponding to the signerInfo structure having version number 3. 181 2.1.2. digestAlgorithms 183 The digestAlgorithms set contains the OIDs of the digest algorithm(s) 184 used in signing the encapsulated content. This set MUST contain 185 exactly one digest algorithm OID, and the OID MUST be selected from 186 those specified in [I-D.sidr-rpki-algs]. 188 2.1.3. encapContentInfo 190 encapContentInfo is the signed content, consisting of a content type 191 identifier and the content itself. The encapContentInfo represents 192 the payload of the RPKI signed object. 194 EncapsulatedContentInfo ::= SEQUENCE { 195 eContentType ContentType, 196 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 198 ContentType ::= OBJECT IDENTIFIER 200 2.1.3.1. eContentType 202 This field is left undefined by this profile. The eContentType is an 203 OID specifying the type of payload in this signed object and MUST be 204 specified by the Internet standards track document that defines the 205 object. 207 2.1.3.2. eContent 209 This field is left undefined by this profile. The eContent is the 210 payload of the signed object and MUST be specified by the Internet 211 standards track document that defines the RPKI object. 213 Note that the signed object profile does not provide version numbers 214 for signed objects. Therefore, in order to facilitate transition to 215 new versions of the signed objects over time, it is RECOMMENDED that 216 signed objects using this profile include a version number within 217 their eContent. 219 2.1.4. certificates 221 The certificates field MUST be included, and MUST contain exactly one 222 certificate, the RPKI End Entity (EE) certificate needed to validate 223 this signed object. 225 2.1.5. crls 227 The crls field MUST be omitted. 229 2.1.6. signerInfos 231 SignerInfo is defined in CMS as: 233 SignerInfo ::= SEQUENCE { 234 version CMSVersion, 235 sid SignerIdentifier, 236 digestAlgorithm DigestAlgorithmIdentifier, 237 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 238 signatureAlgorithm SignatureAlgorithmIdentifier, 239 signature SignatureValue, 240 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 242 2.1.6.1. version 244 The version number MUST be 3, corresponding with the choice of 245 SubjectKeyIdentifier for the sid. 247 2.1.6.2. sid 249 The sid is defined as: 251 SignerIdentifier ::= CHOICE { 252 issuerAndSerialNumber IssuerAndSerialNumber, 253 subjectKeyIdentifier [0] SubjectKeyIdentifier } 255 For RPKI signed objects, the sid MUST be the SubjectKeyIdentifier 256 that appears in the EE certificate carried in the CMS certificates 257 field. 259 2.1.6.3. digestAlgorithm 261 The digestAlgorithm MUST consist of the OID of a digest algorithm 262 that conforms to the RPKI Algorithms and Key Size Profile 263 specification [I-D.sidr-rpki-algs]. 265 2.1.6.4. signedAttrs 267 The signedAttrs is defined as: 269 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 271 Attribute ::= SEQUENCE { 272 attrType OBJECT IDENTIFIER, 273 attrValues SET OF AttributeValue } 275 AttributeValue ::= ANY 277 The signedAttr element MUST be present and MUST include the content- 278 type and message-digest attributes [RFC5652]. The signer MAY also 279 include the signing-time signed attribute [RFC5652], the binary- 280 signing-time signed attribute [RFC6019], or both signing-time 281 attributes. Other signed attributes MUST NOT be included. 283 The signedAttr MUST include only a single instance of any particular 284 attribute. Additionally, even though the syntax allows for a SET OF 285 AttributeValue, in an RPKI signed object the attrValues MUST consist 286 of only a single AttributeValue. 288 2.1.6.4.1. Content-Type Attribute 290 The ContentType attribute MUST be present. The attrType OID for the 291 ContentType attribute is 1.2.840.113549.1.9.3. 293 The attrValues for the ContentType attribute MUST match the 294 eContentType in the EncapsulatedContentInfo. Thus, attrValues MUST 295 contain the OID that specifies the payload type of the specific RPKI 296 signed object carried in the CMS signed data structure. 298 2.1.6.4.2. Message-Digest Attribute 300 The MessageDigest Attribute MUST be present. The attrType OID for 301 the MessageDigest Attribute is 1.2.840.113549.1.9.4. 303 The attrValues for the MessageDigest attribute contains the output of 304 the digest algorithm applied to the content being signed, as 305 specified in Section 5.4 of [RFC5652]. 307 2.1.6.4.3. SigningTime Attribute 309 The SigningTime Attribute MAY be present. Note that the presence or 310 absence of the SigningTime attribute MUST NOT affect the validity of 311 the signed object (as specified in Section 3). The attrType OID for 312 the SigningTime attribute is 1.2.840.113549.1.9.5. 314 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 315 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 317 The attrValues for the SigningTime attribute is defined as: 319 SigningTime ::= Time 321 Time ::= CHOICE { 322 utcTime UTCTime, 323 generalizedTime GeneralizedTime } 325 The Time element specifies the time, based on the local system clock, 326 at which the digital signature was applied to the content. 328 The definition of Time matches the one specified in the 1997 version 329 of X.509. Additional information regarding the use of UTCTime and 330 GeneralizedTime can be found in [RFC5652]. 332 2.1.6.4.4. BinarySigningTime Attribute 334 The BinarySigningTime Attribute MAY be present. Note that the 335 presence or absence of the BinarySigningTime attribute MUST NOT 336 affect the validity of the signed object (as specified in Section 3). 337 The attrType OID for the BinarySigningTime attribute is 338 1.2.840.113549.1.9.16.2.46. 340 id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1) 341 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 342 smime(16) aa(2) 46 } 344 The attrValues for the SigningTime attribute is defined as: 346 BinarySigningTime ::= BinaryTime 348 BinaryTime ::= INTEGER (0..MAX) 350 The BinaryTime element specifies the time, based on the local system 351 clock, at which the digital signature was applied to the content. The 352 precise definition of the BinaryTime element can be found in 353 [RFC6019]. 355 2.1.6.5. signatureAlgorithm 357 The signatureAlgorithm MUST conform to the RPKI Algorithms and Key 358 Size Profile specification [I-D.sidr-rpki-algs]. 360 2.1.6.6. signature 362 The signature value is defined as: 364 SignatureValue ::= OCTET STRING 366 The signature characteristics are defined by the digest and signature 367 algorithms. 369 2.1.6.7. unsignedAttrs 371 unsignedAttrs MUST be omitted. 373 3. Signed Object Validation 375 Before a relying party can use a signed object, the relying party 376 MUST validate the signed object by verifying that all of the 377 following conditions hold. A relying party may perform these checks 378 in any order. Note that these checks are necessary but not 379 sufficient: in general, further validation MUST be performed based on 380 the specific type of signed object. 382 1. The signed object syntax complies with this specification. In 383 particular, that each of the following is true: 385 a. The contentType of the CMS object is SignedData (OID 386 1.2.840.113549.1.7.2) 388 b. The version of the SignedData object is 3. 390 c. The certificates field in the SignedData object is present 391 and contains one EE certificate, the SubjectKeyIdentifier 392 field of which matches the sid field of the SignerInfo 393 object. 395 d. The crls field in the SignedData object is omitted. 397 e. The version of the SignerInfo is 3. 399 f. The signedAttrs field in the SignerInfo object is present and 400 contains both the ContentType attribute (OID 401 1.2.840.113549.1.9.3) and the MessageDigest attribute (OID 402 1.2.840.113549.1.9.4). 404 g. The signedAttrs field in the SignerInfo object does not 405 contain any attributes other than the following four: the 406 ContentType attribute (OID 1.2.840.113549.1.9.3), the 407 MessageDigest attribute (OID 1.2.840.113549.1.9.4), the 408 SigningTime attribute (OID 1.2.840.113549.1.9.5), and the 409 BinarySigningTime attribute (OID 1.2.840.113549.1.9.16.2.46). 410 Note that the SigningTime and BinarySigningTime attributes 411 MAY be present, but are not required. 413 h. The eContentType in the EncapsulatedContentInfo is an OID 414 that matches the attrValues in the ContentType attribute. 416 i. The unsignedAttrs field in the SignerInfo object is omitted. 418 j. The digestAlgorithm in the SignedData and SignerInfo objects 419 conforms to the RPKI Algorithms and Key Size Profile 420 specification [I-D.sidr-rpki-algs]. 422 k. The signatureAlgorithm in the SignerInfo object conforms to 423 the RPKI Algorithms and Key Size Profile specification 424 [I-D.sidr-rpki-algs]. 426 l. The signed object is DER encoded. 428 2. The public key of the EE certificate (contained within the CMS 429 signed-data object) can be used to successfully verify the 430 signature on the signed object. 432 3. The EE certificate (contained within the CMS signed-data object) 433 is a valid EE certificate in the RPKI as specified by [I-D.sidr- 434 res-certs]. In particular, there exists a valid certification 435 path from a trust anchor to this EE certificate. 437 If the above procedure indicates that the signed object is invalid, 438 then the signed object MUST be discarded and treated as though no 439 signed object were present. If all of the conditions above are 440 true, then the signed object may be valid. The relying party MUST 441 then perform any additional validation steps required for the 442 particular type of signed object. 444 Note that a previously valid signed object will cease to be valid 445 when the associated EE certificate ceases to be valid (for example, 446 when the end of the certificate's validity period is reached, or when 447 the certificate is revoked by the authority that issued it). See [I- 448 D.sidr-res-certs] for a complete specification of resource 449 certificate validity. 451 4. Definition of Specific Signed Objects 453 Each RPKI signed object MUST be defined in an Internet standards 454 track document based on this profile, by specifying the following 455 data elements and validation procedure: 457 1. eContentType: A single OID to be used for both the eContentType 458 field and the Content-Type attribute. This OID uniquely 459 identifies the type of signed object. 461 2. eContent: Define the syntax for the eContent field in 462 encapContentInfo. This is the payload that contains the data 463 specific to a given type of signed object. 465 3. Additional Validation: Define a set of additional validation 466 steps for the specific signed object. Before using this specific 467 signed object, a relying party MUST perform both the generic 468 validation steps in Section 3 above, as well as these additional 469 steps. 471 5. Security Considerations 473 There is no assumption of confidentiality for the data in an RPKI 474 signed object. The integrity and authenticity of each signed 475 object is based on the verification of a digital signature for 476 the object, and on the validation of the EE certificate used to 477 perform that verification. It is anticipated that signed objects 478 will be stored in repositories that will be publicly accessible. 480 Since RPKI signed objects make use of CMS as an encapsulation 481 format, the security considerations for CMS apply [RFC5652]. 483 6. IANA Considerations 485 IANA is requested to create a registry of signed objects types 486 that utilize the template defined in this document. This registry 487 shall contain three fields, an informal name for the signed 488 object, the OID for the eContentType of the signed object, and a 489 specification pointer that references the RFC in which the signed 490 object is specified. The entries in this registry shall be 491 managed by IETF Standards Action. 493 The registry shall be initially populated with the following two 494 entries. 496 Name | OID | Specification 497 ---------------------------------------------------------------- 498 ROA | 1.2.840.113549.1.9.16.1.24 | I-D.sidr-roa-format 499 Manifest | 1.2.840.113549.1.9.16.1.26 | I-D.sidr-rpki-manifests 501 Note that when draft-ietf-sidr-roa-format and draft-ietf-sidr- 502 rpki-manifests are published as RFCs, IANA is requested to 503 replace the Internet Draft names in the registry with the RFC 504 numbers of corresponding RFCs. 506 7. Acknowledgements 508 The authors wish to thank Charles Gardiner, Russ Housley, and 509 Derek Kong for their help and contributions. Additionally, the 510 authors would like to thank Rob Austein, Roque Gagliano, Danny 511 McPherson, Sean Turner, and Sam Weiler for their careful reviews 512 and helpful comments. 514 8. Normative References 516 [I-D.sidr-res-certs] Huston, G., Michaelson, G., and R. Loomans, "A 517 Profile for X.509 PKIX Resource Certificates", 518 draft-ietf-sidr-res-certs (work in progress), December 519 2010. 521 [I-D.sidr-rpki-algs] Huston, G., "A Profile for Algorithms and Key 522 Sizes for use in the Resource Public Key Infrastructure", 523 draft-ietf-sidr-rpki-algs (work in progress), November 524 2010. 526 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 527 Requirement Levels", BCP 14, RFC 2119, March 1997. 529 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 530 Addresses and AS Identifiers", RFC 3779, June 2004. 532 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 533 Housley, R., and W. Polk, "Internet X.509 Public Key 534 Infrastructure Certificate and Certificate Revocation List 535 (CRL) Profile", RFC 5280, May 2008. 537 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 538 5652, September 2009. 540 [X.208-88] CCITT. Recommendation X.208: Specification of Abstract 541 Syntax Notation One (ASN.1), 1988. 543 [X.509-88] CCITT. Recommendation X.509: The Directory Authentication 544 Framework, 1988. 546 9. Informative References 548 [I-D.sidr-arch] Lepinski, M. and S. Kent, "An Infrastructure to 549 Support Secure Internet Routing", draft-ietf-sidr-arch 550 (work in progress), November 2010. 552 [I-D.sidr-roa-format] Lepinski, M., Kent, S., and D. Kong, "A Profile 553 for Route Origin Authorizations (ROAs)", 554 draft-ietf-sidr-roa-format (work in progress), November 555 2010. 557 [RFC6019] Housley, R., "BinaryTime: An Alternate Format for 558 Representing Date and Time in ASN.1", RFC 6019, September 559 2010. 561 Authors' Addresses 563 Matt Lepinski 564 BBN Technologies 565 10 Moulton Street 566 Cambridge MA 02138 568 Email: mlepinski@bbn.com 570 Andrew Chi 571 BBN Technologies 572 10 Moulton Street 573 Cambridge MA 02138 575 Email: achi@bbn.com 577 Stephen Kent 578 BBN Technologies 579 10 Moulton Street 580 Cambridge MA 02138 582 Email: kent@bbn.com