idnits 2.17.1 draft-ietf-sidr-signed-object-01.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 (October 4, 2010) is 4924 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 260 -- Looks like a reference, but probably isn't: '1' on line 247 == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-18 ** Downref: Normative reference to an Informational draft: draft-huston-sidr-rpki-algs (ref. 'I-D.sidr-rpki-algs') == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-11 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 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: April 7, 2011 BBN 6 October 4, 2010 8 Signed Object Template for the Resource Public Key Infrastructure 9 draft-ietf-sidr-signed-object-01.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 April 7, 2011. 28 Copyright Notice 30 Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . 9 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 [draft-ietf-sidr-roa-format] for an example of a 117 document that uses this template to specify a particular type of 118 signed 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 partially undefined by this profile. The eContent 210 is the payload of the signed object and MUST be specified by the 211 Internet standards track document that defines the RPKI object. 213 At the outermost level, the eContent field MUST be an ASN.1 SEQUENCE. 214 The first element of the SEQUENCE MUST be the version number, in 215 order to enable transition to new versions of signed objects over 216 time. 218 ContentTemplate ::= SEQUENCE { 219 version [0] INTEGER DEFAULT 0, 220 ... } 222 The Internet standards track document that defines the specific RPKI 223 object MUST specify the remaining fields, represented as ellipses 224 (...). 226 2.1.4. certificates 228 The certificates field MUST be included, and MUST contain exactly one 229 certificate, the RPKI End Entity (EE) certificate needed to validate 230 this signed object. 232 2.1.5. crls 234 The crls field MUST be omitted. 236 2.1.6. signerInfos 238 SignerInfo is defined in CMS as: 240 SignerInfo ::= SEQUENCE { 241 version CMSVersion, 242 sid SignerIdentifier, 243 digestAlgorithm DigestAlgorithmIdentifier, 244 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 245 signatureAlgorithm SignatureAlgorithmIdentifier, 246 signature SignatureValue, 247 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 249 2.1.6.1. version 251 The version number MUST be 3, corresponding with the choice of 252 SubjectKeyIdentifier for the sid. 254 2.1.6.2. sid 256 The sid is defined as: 258 SignerIdentifier ::= CHOICE { 259 issuerAndSerialNumber IssuerAndSerialNumber, 260 subjectKeyIdentifier [0] SubjectKeyIdentifier } 262 For RPKI signed objects, the sid MUST be the SubjectKeyIdentifier 263 that appears in the EE certificate carried in the CMS certificates 264 field. 266 2.1.6.3. digestAlgorithm 268 The digestAlgorithm MUST consist of the OID of a digest algorithm 269 that conforms to the RPKI Algorithms and Key Size Profile 270 specification [I-D.sidr-rpki-algs]. 272 2.1.6.4. signedAttrs 274 The signedAttrs is defined as: 276 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 277 Attribute ::= SEQUENCE { 278 attrType OBJECT IDENTIFIER, 279 attrValues SET OF AttributeValue } 281 AttributeValue ::= ANY 283 The signedAttr element MUST be present and MUST include the content- 284 type and message-digest attributes [RFC5652]. The signer MAY also 285 include the signing-time signed attribute [RFC5652], the binary- 286 signing-time signed attribute [RFC6019], or both signing-time 287 attributes. Other signed attributes MUST NOT be included. 289 The signedAttr MUST include only a single instance of any particular 290 attribute. Additionally, even though the syntax allows for a SET OF 291 AttributeValue, in an RPKI signed object the attrValues MUST consist 292 of only a single AttributeValue. 294 2.1.6.4.1. Content-Type Attribute 296 The ContentType attribute MUST be present. The attrType OID for the 297 ContentType attribute is 1.2.840.113549.1.9.3. 299 The attrValues for the ContentType attribute MUST match the 300 eContentType in the EncapsulatedContentInfo. Thus, attrValues MUST 301 contain the OID that specifies the payload type of the specific RPKI 302 signed object carried in the CMS signed data structure. 304 2.1.6.4.2. Message-Digest Attribute 306 The MessageDigest Attribute MUST be present. The attrType OID for 307 the MessageDigest Attribute is 1.2.840.113549.1.9.4. 309 The attrValues for the MessageDigest attribute contains the output of 310 the digest algorithm applied to the content being signed, as 311 specified in Section 5.4 of [RFC5652]. 313 2.1.6.4.3. SigningTime Attribute 315 The SigningTime Attribute MAY be present. Note that the presence or 316 absence of the SigningTime attribute MUST NOT affect the validity of 317 the signed object (as specified in Section 3). The attrType OID for 318 the SigningTime attribute is 1.2.840.113549.1.9.5. 320 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 321 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 323 The attrValues for the SigningTime attribute is defined as: 325 SigningTime ::= Time 327 Time ::= CHOICE { 328 utcTime UTCTime, 329 generalizedTime GeneralizedTime } 331 The Time element specifies the time, based on the local system clock, 332 at which the digital signature was applied to the content. 334 The definition of Time matches the one specified in the 1997 version 335 of X.509. Additional information regarding the use of UTCTime and 336 GeneralizedTime can be found in [RFC5652]. 338 2.1.6.4.4. BinarySigningTime Attribute 340 The BinarySigningTime Attribute MAY be present. Note that the 341 presence or absence of the BinarySigningTime attribute MUST NOT 342 affect the validity of the signed object (as specified in Section 3). 343 The attrType OID for the BinarySigningTime attribute is 344 1.2.840.113549.1.9.16.2.46. 346 id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1) 347 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 348 smime(16) aa(2) 46 } 350 The attrValues for the SigningTime attribute is defined as: 352 BinarySigningTime ::= BinaryTime 354 BinaryTime ::= INTEGER (0..MAX) 356 The BinaryTime element specifies the time, based on the local system 357 clock, at which the digital signature was applied to the content. The 358 precise definition of the BinaryTime element can be found in 359 [RFC6019]. 361 2.1.6.5. signatureAlgorithm 363 The signatureAlgorithm MUST conform to the RPKI Algorithms and Key 364 Size Profile specification [I-D.sidr-rpki-algs]. 366 2.1.6.6. signature 368 The signature value is defined as: 370 SignatureValue ::= OCTET STRING 372 The signature characteristics are defined by the digest and signature 373 algorithms. 375 2.1.6.7. unsignedAttrs 377 unsignedAttrs MUST be omitted. 379 3. Signed Object Validation 381 Before a relying party can use a signed object, the relying party 382 MUST validate the signed object by verifying that all of the 383 following conditions hold. A relying party may perform these checks 384 in any order. Note that these checks are necessary but not 385 sufficient: in general, further validation MUST be performed based on 386 the specific type of signed object. 388 1. The signed object syntax complies with this specification. In 389 particular, that each of the following is true: 391 a. The contentType of the CMS object is SignedData (OID 392 1.2.840.113549.1.7.2) 394 b. The version of the SignedData object is 3. 396 c. The certificates field in the SignedData object is present 397 and contains one EE certificate, the SubjectKeyIdentifier 398 field of which matches the sid field of the SignerInfo 399 object. 401 d. The crls field in the SignedData object is omitted. 403 e. The version of the SignerInfo is 3. 405 f. The signedAttrs field in the SignerInfo object is present and 406 contains both the ContentType attribute (OID 407 1.2.840.113549.1.9.3) and the MessageDigest attribute (OID 408 1.2.840.113549.1.9.4). 410 g. The signedAttrs field in the SignerInfo object does not 411 contain any attributes other than the following four: the 412 ContentType attribute (OID 1.2.840.113549.1.9.3), the 413 MessageDigest attribute (OID 1.2.840.113549.1.9.4), the 414 SigningTime attribute (OID 1.2.840.113549.1.9.5), and the 415 BinarySigningTime attribute (OID 1.2.840.113549.1.9.16.2.46). 416 Note that the SigningTime and BinarySigningTime attributes 417 MAY be present, but are not required. 419 h. The eContentType in the EncapsulatedContentInfo is an OID 420 that matches the attrValues in the ContentType attribute. 422 i. The unsignedAttrs field in the SignerInfo object is omitted. 424 j. The digestAlgorithm in the SignedData and SignerInfo objects 425 conforms to the RPKI Algorithms and Key Size Profile 426 specification [I-D.sidr-rpki-algs]. 428 k. The signatureAlgorithm in the SignerInfo object conforms to 429 the RPKI Algorithms and Key Size Profile specification 430 [I-D.sidr-rpki-algs]. 432 l. The signed object is DER encoded. 434 2. The public key of the EE certificate (contained within the CMS 435 signed-data object) can be used to successfully verify the 436 signature on the signed object. 438 3. The EE certificate (contained within the CMS signed-data object) 439 is a valid EE certificate in the RPKI as specified by [I-D.sidr- 440 res-certs]. In particular, there exists a valid certification 441 path from a trust anchor to this EE certificate. 443 If the above procedure indicates that the signed object is invalid, 444 then the signed object MUST be discarded and treated as though no 445 signed object were present. If the all of the conditions above are 446 true, then the signed object may be valid. The relying party MUST 447 then perform any additional validation steps required for the 448 particular type of signed object. 450 Note that a previously valid signed object will cease to be valid 451 when the associated EE certificate ceases to be valid (for example, 452 when the end of the certificate's validity period is reached, or when 453 the certificate is revoked by the authority that issued it). See [I- 454 D.sidr-res-certs] for a complete specification of resource 455 certificate validity. 457 4. Definition of Specific Signed Objects 459 Each RPKI signed object MUST be defined in an Internet standards 460 track document based on this profile, by specifying the following 461 data elements and validation procedure: 463 1. eContentType: Obtain an OID to be used for the eContentType 464 field in encapContentInfo. This OID uniquely identifies the type 465 of signed object. 467 2. eContent: Define an ASN.1 syntax for the eContent field in 468 encapContentInfo. The syntax MUST consist of an ASN.1 SEQUENCE 469 whose first element is "version" expressed as an ASN.1 INTEGER. 471 3. Content-Type Attribute: The mandatory Content-Type Attribute 472 MUST have its attrValues field set to the same OID as 473 eContentType in item 1. 475 4. Additional Validation: Define a set of additional validation 476 steps for the specific signed object. Before using this specific 477 signed object, a relying party MUST perform both the generic 478 validation steps in Section 3 above, as well as these additional 479 steps. 481 5. Security Considerations 483 There is no assumption of confidentiality for the data in an RPKI 484 signed object. The integrity and authenticity of each signed 485 object is based on the verification of a digital signature for 486 the object, and on the validation of the EE certificate used to 487 perform that verification. It is anticipated that signed objects 488 will be stored in repositories that will be publicly accessible. 490 Since RPKI signed objects make use of CMS as an encapsulation 491 format, the security considerations for CMS apply [RFC5652]. 493 6. IANA Considerations 495 None. 497 7. Acknowledgements 499 The authors wish to thank Charles Gardiner, Russ Housley, and 500 Derek Kong for their help and contributions. Additionally, the 501 authors would like to thank Rob Austein, Roque Gagliano, Danny 502 McPherson, Sean Turner, and Sam Weiler for their careful reviews 503 and helpful comments. 505 8. Normative References 507 [I-D.sidr-res-certs] Huston, G., Michaelson, G., and R. Loomans, "A 508 Profile for X.509 PKIX Resource Certificates", 509 draft-ietf-sidr-res-certs-18.txt (work in progress), May 510 2010. 512 [I-D.sidr-rpki-algs] Huston, G., "A Profile for Algorithms and Key 513 Sizes for use in the Resource Public Key Infrastructure", 514 draft-huston-sidr-rpki-algs-00.txt (work in progress), 515 July 2009. 517 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 518 Requirement Levels", BCP 14, RFC 2119, March 1997. 520 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 521 Addresses and AS Identifiers", RFC 3779, June 2004. 523 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 524 Housley, R., and W. Polk, "Internet X.509 Public Key 525 Infrastructure Certificate and Certificate Revocation List 526 (CRL) Profile", RFC 5280, May 2008. 528 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 529 5652, September 2009. 531 [X.208-88] CCITT. Recommendation X.208: Specification of Abstract 532 Syntax Notation One (ASN.1), 1988. 534 [X.509-88] CCITT. Recommendation X.509: The Directory Authentication 535 Framework, 1988. 537 9. Informative References 539 [I-D.sidr-arch] Lepinski, M. and S. Kent, "An Infrastructure to 540 Support Secure Internet Routing", 541 draft-ietf-sidr-arch-11.txt (work in progress), September 542 2010. 544 [RFC6019] Housley, R., "BinaryTime: An Alternate Format for 545 Representing Date and Time in ASN.1", RFC 6019, September 546 2010. 548 Authors' Addresses 550 Matt Lepinski 551 BBN Technologies 552 10 Moulton Street 553 Cambridge MA 02138 555 Email: mlepinski@bbn.com 557 Andrew Chi 558 BBN Technologies 559 10 Moulton Street 560 Cambridge MA 02138 562 Email: achi@bbn.com 564 Stephen Kent 565 BBN Technologies 566 10 Moulton Street 567 Cambridge MA 02138 569 Email: kent@bbn.com