idnits 2.17.1 draft-ietf-sidr-rescerts-provisioning-06.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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 8, 2010) is 5101 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 490 -- Looks like a reference, but probably isn't: '1' on line 486 ** Obsolete normative reference: RFC 2050 (Obsoleted by RFC 7020) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 4049 (Obsoleted by RFC 6019) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-16 Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Inter-Domain Routing G. Huston 3 Internet-Draft R. Loomans 4 Intended status: Standards Track B. Ellacott 5 Expires: November 9, 2010 APNIC 6 R. Austein 7 ISC 8 May 8, 2010 10 A Protocol for Provisioning Resource Certificates 11 draft-ietf-sidr-rescerts-provisioning-06.txt 13 Abstract 15 This document defines a framework for certificate management 16 interactions between a resource issuer ("Issuer") and a resource 17 recipient ("Subject") through the specification of a protocol for 18 interaction between the two parties. The protocol supports the 19 transmission of requests from the ISP, and corresponding responses 20 from the Issuer encompassing the actions of certificate issuance, 21 certificate revocation and certificate status information reports. 22 This protocol is intended to be limited to the application of 23 resource certificate management and is not intended to be used as 24 part of a more general certificate management framework. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on November 9, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 4 64 3.1. CMS Profile . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1.1. SignedData Content Type . . . . . . . . . . . . . . . 5 66 3.1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . 10 67 3.2. Common Message format . . . . . . . . . . . . . . . . . . 12 68 3.3. Control - Resource Class Query . . . . . . . . . . . . . . 14 69 3.3.1. Resource Class List Query . . . . . . . . . . . . . . 14 70 3.3.2. Resource Class List Response . . . . . . . . . . . . . 14 71 3.4. CA - Certificate Issuance . . . . . . . . . . . . . . . . 19 72 3.4.1. Certificate Issuance Request . . . . . . . . . . . . . 19 73 3.4.2. Certificate Issuance Response . . . . . . . . . . . . 20 74 3.5. Certificate Revocation . . . . . . . . . . . . . . . . . . 21 75 3.5.1. Certificate Revocation Request . . . . . . . . . . . . 21 76 3.5.2. Certificate Revocation Response . . . . . . . . . . . 22 77 3.6. Request-Not-Performed Response . . . . . . . . . . . . . . 22 78 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 23 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 26 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 27 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 87 1. Introduction 89 This document defines a framework for certificate management 90 interactions between a resource issuer ("Issuer") and a resource 91 recipient ("Subject") through the specification of a protocol for 92 interaction between the two parties. The protocol supports the 93 transmission of requests from the ISP, and corresponding responses 94 from the Issuer encompassing the actions of certificate issuance, 95 certificate revocation and certificate status information reports. 96 This protocol is intended to be limited to the application of 97 resource certificate management and is not intended to be used as 98 part of a more general certificate management framework. 100 1.1. Terminology 102 It is assumed that the reader is familiar with the terms and concepts 103 described in "Internet X.509 Public Key Infrastructure Certificate 104 and Certificate Revocation List (CRL) Profile" [RFC5280], "X.509 105 Extensions for IP Addresses and AS Identifiers" [RFC3779], "Internet 106 Protocol" [RFC0791], "Internet Protocol Version 6 (IPv6) Addressing 107 Architecture" [RFC4291], "Internet Registry IP Allocation Guidelines" 108 [RFC2050], and related regional Internet registry address management 109 policy documents. 111 Additional terms used in this document are: 113 "Issuer" used in the context of this document as an entity 114 undertaking the role of resource issuer. An "Issuer" is a 115 Certificate Authority, and can issue Resource Certificates. 117 "Subject" used in the context of this document as an entity 118 undertaking the role of resource recipient who is the subject of a 119 Resource Certificate. A "Subject" may be issued with a CA-enabled 120 certificate, allowing the entity to also assume the role of an 121 "Issuer". 123 "resource class" a resource class refers to a collection of 124 resources that can be certified in a single resource certificate 125 by an issuer. 127 "server" in the context of this client/server protocol 128 specification, the Issuer assumes the role of the "server." 130 "client" in the context of this client/server protocol 131 specification, the Subject assumes the role of the "client." 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119. 137 2. Scope 139 This Resource PKI (RPKI) certificate provisioning protocol defines a 140 basic set of interactions that allow a Subject to request certificate 141 issuance, revocation and status information from the Issuer, and for 142 a Issuer to maintain an issued certificate set that is aligned to the 143 allocation records relating to each Subject. The Issuer's resource 144 allocation database, is the authoritative source of what resource 145 allocations the Issuer may certify for a Subject. 147 A resource recipient (Subject) may also undertake the role of a 148 resource issuer (Issuer). 150 This protocol specification does not encompass: 152 o signing of objects with keys that are certified by resource 153 certificates, nor the issuance of end-entity certificates. 155 o the specification of interaction with the Issuer's resource 156 allocation database, nor the specification of a protocol to manage 157 the publication repository. 159 o the interactions between client and server that establish 160 identities, exchange the keys used in the protection of the 161 communications channel between client and server, and the exchange 162 of the certificates and validation PKI contexts used in the 163 Cryptographic Message Syntax message exchange. 165 3. Protocol Specification 167 This RPKI certificate provisioning protocol is expressed as a simple 168 request/response interaction, where the client passes a request to 169 the server, and the server generates a corresponding response. 171 The protocol is implemented as an exchange of messages. 173 Messages are passed over an HTTPS [RFC2818] transport connection that 174 safeguards against interception and replay attacks. The HTTPS 175 session uses mutually authenticated Transport Layer Security (TLS) 176 [RFC5246]. The TLS keys and associated certificate chain used to 177 validate TLS transactions is assumed to have been previously 178 communicated between the two entities, through mechanisms not defined 179 in this protocol specification. The HTTPS connection will use 2 way 180 (mutual) identification. A message exchange commences with the 181 client initiating an HTTP POST with content type of "application/ 182 x-rpki", with the message object as the body. The server's response 183 will similarly be the body of the response with a content type of 184 "application/x-rpki". 186 The content of the POST, and the server's response, will be a "well- 187 formed" Cryptographic Message Syntax (CMS) [RFC5652] object, encoded 188 using the Distinguished Encoding Rules for ASN.1 (DER) [X.509-88], 189 formatted in accordance with the CMS profile as specified in the 190 following section. CMS is used as the signing format to sign the 191 message object. The public part of the signing key and the 192 associated certificate chain that is used to validate the CMS digital 193 signature is assumed to have been communicated between the two 194 entities, through mechanisms not defined in this protocol 195 specification. The CMS keys and certificates MAY be the same as 196 those used for TLS. 198 The protocol's request / response interaction is assumed to be 199 reliable, in that all requests will generate a matching response. 200 The protocol requires sequential operation for each distinct client, 201 where the server MUST NOT accept a client's request unless it has 202 generated and sent a response to the client's previous request. 203 Attempts by the client to initiate multiple requests in parallel MUST 204 be detected by the server and rejected with an error response. 206 3.1. CMS Profile 208 The format of the CMS object is: 210 ContentInfo ::= SEQUENCE { 211 contentType ContentType, 212 content [0] EXPLICIT ANY DEFINED BY contentType } 214 ContentType ::= OBJECT IDENTIFIER 216 The protocol objects are all instances of CMS signed-data objects, 217 where the ContentType used is the signed-data type of id-data, namely 218 id-signedData, OID = 1.2.840.113549.1.7.2. 220 3.1.1. SignedData Content Type 222 According to [RFC5652], signed-data content types shall have the 223 ASN.1 type SignedData: 225 SignedData ::= SEQUENCE { 226 version CMSVersion, 227 digestAlgorithms DigestAlgorithmIdentifiers, 228 encapContentInfo EncapsulatedContentInfo, 229 certificates [0] IMPLICIT CertificateSet OPTIONAL, 230 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 231 signerInfos SignerInfos } 233 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 235 SignerInfos ::= SET OF SignerInfo 237 3.1.1.1. version 239 The version is the syntax version number. It MUST be 3, 240 corresponding to the signerInfo structure having version number 3. 242 3.1.1.2. digestAlgorithms 244 The digestAlgorithms set MUST include only SHA-256, the OID for which 245 is 2.16.840.1.101.3.4.2.1 [RFC4055]. It MUST NOT contain any other 246 algorithms. 248 3.1.1.3. encapContentInfo 250 encapContentInfo is the signed content, consisting of a content type 251 identifier and the content itself. 253 EncapsulatedContentInfo ::= SEQUENCE { 254 eContentType ContentType, 255 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 257 ContentType ::= OBJECT IDENTIFIER 259 3.1.1.3.1. eContentType 261 The eContentType for the RPKI Protocol Message object is defined as 262 id-ct-xml, and has the numerical value of 1.2.840.113549.1.9.16.1.28. 264 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 265 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 267 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 269 id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 } 271 3.1.1.3.2. eContent 273 The content of a RPKI XML Protocol Object consists of a single 274 protocol message, structured according to a define XML schema, as 275 defined in subsequent sections of this document. The eContent field 276 of the CMS object is formally defined using ASN.1 as: 278 id-ct-xml ::= OCTET STRING -- XML encoded message 280 3.1.1.4. certificates 282 The certificates field MUST be present, and MUST contain the EE 283 certificate of the key pair whose private key value was used to sign 284 the CMS. This MUST NOT be an RPKI certificate, and SHOULD be a 285 certificate that is recognised to attest to the identity of the party 286 that created the CMS object. 288 This field MAY contain other certificates that a relying party may 289 use to validate the digital signature of the CMS object. 291 3.1.1.5. crls 293 This field MUST be present. The contents of the field are specified 294 in [RFC5652]. 296 3.1.1.6. signerInfo 298 SignerInfo is defined under CMS as: 300 SignerInfo ::= SEQUENCE { 301 version CMSVersion, 302 sid SignerIdentifier, 303 digestAlgorithm DigestAlgorithmIdentifier, 304 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 305 signatureAlgorithm SignatureAlgorithmIdentifier, 306 signature SignatureValue, 307 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 309 3.1.1.6.1. version 311 The version number MUST be 3, corresponding with the choice of 312 SubjectKeyIdentifier for the sid. 314 3.1.1.6.2. sid 316 The sid is defined as: 318 SignerIdentifier ::= CHOICE { 319 issuerAndSerialNumber IssuerAndSerialNumber, 320 subjectKeyIdentifier [0] SubjectKeyIdentifier } 322 In this profile, the sid MUST be a SubjectKeyIdentifier. 324 3.1.1.6.3. digestAlgorithm 326 The digestAlgorithm MUST be SHA-256, the OID for which is 327 2.16.840.1.101.3.4.2.1. [RFC4055] 329 3.1.1.6.4. signedAttrs 331 Signed Attributes are defined as: 333 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 335 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 337 Attribute ::= SEQUENCE { 338 attrType OBJECT IDENTIFIER, 339 attrValues SET OF AttributeValue } 341 AttributeValue ::= ANY 343 The signer MUST digitally sign a collection of attributes along with 344 the content payload. Each attribute in the collection MUST be DER- 345 encoded. The syntax for attributes is defined in [X.501], and the 346 X.500 Directory provides a rich attribute syntax. A very simple 347 subset of this syntax is used extensively in [RFC5652], where 348 ATTRIBUTE.Type and ATTRIBUTE.id are the only parts of the ATTRIBUTE 349 class that are employed. 351 Each of the attributes used with this CMS profile has a single 352 attribute value. Even though the syntax is defined as a SET OF 353 AttributeValue, there MUST be exactly one instance of AttributeValue 354 present. 356 The SignedAttributes syntax within signerInfo is defined as a SET OF 357 Attribute. The SignedAttributes MUST include only one instance of 358 any particular attribute. 360 The signer MUST include the content-type, message-digest and signing- 361 time signed attributes. The signer MAY also include the binary- 362 signing-time signed attribute. Other signed attributes that are 363 deemed appropriate MAY also be included. The intent is to allow 364 additional signed attributes to be included if a future need is 365 identified. This does not cause an interoperability concern because 366 unrecognized signed attributes are ignored at verification. 368 3.1.1.6.4.1. Content-Type Attribute 370 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 371 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 373 ContentType ::= OBJECT IDENTIFIER 375 A content-type attribute is required to contain the same object 376 identifier as the content type contained in the 377 EncapsulatedContentInfo. The signer MUST include a content-type 378 attribute containing the appropriate content type. Section 11.1 of 379 [RFC5652] defines the content-type attribute. 381 3.1.1.6.4.2. Message-Digest Attribute 383 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 384 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 386 MessageDigest ::= OCTET STRING 388 The signer MUST include a message-digest attribute, having as its 389 value the output of a one-way hash function computed on the content 390 that is being signed. Section 11.2 of [RFC5652] defines the message- 391 digest attribute. 393 3.1.1.6.4.3. Signing-Time Attribute 395 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 396 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 398 SigningTime ::= Time 400 Time ::= CHOICE { 401 utcTime UTCTime, 402 generalizedTime GeneralizedTime } 404 The signing-time attribute MUST be present. 406 The signing-time attribute specifies the time, based on the local 407 system clock, when the digital signature was applied to the content. 408 Section 11.3 of [RFC5652] defines the content-type attribute. 410 3.1.1.6.4.4. Binary-Signing-Time Attribute 412 id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1) 413 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 414 smime(16) aa(2) 46 } 416 BinarySigningTime ::= BinaryTime 418 BinaryTime ::= INTEGER (0..MAX) 420 The signer MAY include a binary-signing-time attribute, specifying 421 the time at which the digital signature was applied to the content. 422 If the binary-signing-time is present, the time that is represented 423 MUST represent the same time value as the signing-time attribute. 424 The binary-signing-time attribute is defined in [RFC4049]. 426 3.1.1.6.5. signatureAlgorithm 428 The signatureAlgorithm MUST be RSA (rsaEncryption), the OID for which 429 is 1.2.840.113549.1.1.1. 431 3.1.1.6.6. signature 433 The signature value is defined as: 435 SignatureValue ::= OCTET STRING 437 The signature characteristics are defined by the digest and signature 438 algorithms. 440 3.1.1.6.7. unsignedAttrs 442 unsignedAttrs MUST be omitted. 444 3.1.2. ASN.1 446 The following is the ASN.1 specification of the CMS signed object 447 used by the RPKI provisioning protocol. 449 ContentInfo ::= SEQUENCE { 450 contentType ContentType, 451 content [0] EXPLICIT ANY DEFINED BY contentType } 453 ContentType ::= OBJECT IDENTIFIER 455 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 456 rsadsi(113549) pkcs(1) pkcs9(9) 16 } 458 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 460 id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 } 462 id-ct-xml ::= OCTET STRING -- XML encoded message 464 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 465 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 467 SignedData ::= SEQUENCE { 468 version CMSVersion, 469 digestAlgorithms DigestAlgorithmIdentifiers, 470 encapContentInfo EncapsulatedContentInfo, 471 certificates [0] IMPLICIT CertificateSet OPTIONAL, 472 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 473 signerInfos SignerInfos } 475 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 477 SignerInfos ::= SET OF SignerInfo 479 SignerInfo ::= SEQUENCE { 480 version CMSVersion, 481 sid SignerIdentifier, 482 digestAlgorithm DigestAlgorithmIdentifier, 483 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 484 signatureAlgorithm SignatureAlgorithmIdentifier, 485 signature SignatureValue, 486 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 488 SignerIdentifier ::= CHOICE { 489 issuerAndSerialNumber IssuerAndSerialNumber, 490 subjectKeyIdentifier [0] SubjectKeyIdentifier } 492 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute 494 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute 496 Attribute ::= SEQUENCE { 497 attrType OBJECT IDENTIFIER, 498 attrValues SET OF AttributeValue } 500 AttributeValue ::= ANY 502 SignatureValue ::= OCTET STRING 504 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 505 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } 507 ContentType ::= OBJECT IDENTIFIER 509 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 510 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } 512 MessageDigest ::= OCTET STRING 514 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 515 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } 517 SigningTime ::= Time 519 Time ::= CHOICE { 520 utcTime UTCTime, 521 generalizedTime GeneralizedTime } 523 id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1) 524 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 525 smime(16) aa(2) 46 } 527 BinarySigningTime ::= BinaryTime 529 BinaryTime ::= INTEGER (0..MAX) 531 3.2. Common Message format 533 The XML template for all messages is as follows: 535 --------------------------------------------------------------- 537 538 544 [payload] 546 548 --------------------------------------------------------------- 549 version: 550 the value of this attribute is the version of this protocol. This 551 document describes version 1. 553 sender: 554 the value of this attribute is the agreed name of the message 555 sender, as determined between the client and the server by prior 556 arrangement. 558 recipient: 559 the value of this attribute is the agreed name of the message 560 recipient, as determined between the client and the server by 561 prior arrangement. 563 type: 564 the possible values of this attribute are "list", "list_response", 565 "issue", "issue_response", "revoke", "revoke_response", and 566 "error_response". 568 Conforming parsers MUST reject any document with a version number 569 they do not understand, or with any elements or attributes they do 570 not understand. Servers must generate an error response when 571 receiving such a request. Clients should generate an operator alert 572 error when receiving such a response. 574 A message in this protocol is a digitally signed object that makes 575 use of CMS [RFC5652], and is encoded as DER. It uses the signed-data 576 object contentType OID: 1.2.840.113549.1.7.2. The attribute "id- 577 signingTime" (contentType OID: 1.2.840.113549.1.9.5) MUST be present 578 in the CMS object. 580 The encapsulated content of the CMS wrapping is an XML document. The 581 remainder of this protocol specification omits this CMS wrapper and 582 only discusses the XML document. 584 Messages are checked using the following tests: 586 1. Check the integrity of the HTTPS message and validate the TLS 587 certificate using the PKI that has been determined by prior 588 arrangement between client and server. 590 2. Check that the CMS is well-formed. 592 3. Check that the XML is well-formed. 594 4. Check that the XML sender and recipient attributes reference a 595 known client and this server's system respectively. 597 5. Verify the digital signature using the public key provided in the 598 certificate carried in the CMS wrapper. 600 6. Validate the CMS-provided certificate using the PKI that has been 601 determined by prior arrangement between client and server. 603 7. Check that the value of the version number of the message is 1. 605 The checks should generally be applied in the order specified here. 607 Any errors encountered while checking items 1 through 6 will cause 608 the server to generate an "HTTP 400 Bad Data" response to the HTTPS 609 POST operation. An error in step 7 will cause the server to generate 610 a "Request-Not-Performed" error response. 612 3.3. Control - Resource Class Query 614 3.3.1. Resource Class List Query 616 The value of the message "type" message attribute for this query is: 618 type="list" 620 --------------------------------------------------------------- 622 Payload: 624 [No message payload is defined for this query] 626 --------------------------------------------------------------- 628 3.3.2. Resource Class List Response 630 The value of the message "type" element for this response is: 632 type="list_response" 634 --------------------------------------------------------------- 636 Payload: 638 645 649 [certificate] 650 652 ... 654 (repeated for each current certificate where the client 655 is the certificate's subject) 657 [issuer's certificate] 658 660 ... 662 (repeated for each of the issuer's resource class where the 663 client has been allocated resources) 665 --------------------------------------------------------------- 667 Where the client has been allocated resources from multiple resource 668 classes, then the response will contain multiple class elements, 669 corresponding to the complete set of the issuer's resource classes 670 where the client holds allocated resources. Those issuer's resource 671 classes where the client holds no allocated resources will not be 672 included in the response. 674 Where the issuer has issued multiple certificates in a resource class 675 signed with different keys (as may occur during a staged issuer-key 676 rollover), only the most recent certificate issued with the currently 677 "active" issuer's key will be listed in the response. 679 Each "class" element describes a set of resources that are certified 680 within the scope of a single certificate, referring to a single 681 resource class with a common validation path. 683 class_name: 684 the value of this attribute is the issuer-assigned name of the 685 issuer's Resource Class. 687 cert_url: 688 in the context of a class element, the value of this attribute is 689 a pointer to the issuer's CA certificate (i.e. a reference to the 690 immediate superior certificate, being the CA-enabled certificate 691 where the issuer is the certificate's subject). Its value is a 692 comma-separated list of URIs, of which at least one MUST be an 693 RSYNC URI. Any comma values within a URI MUST be escaped ("%2C"). 694 The ordering of the list may be interpreted by the client as a 695 relative preference for access methods as expressed by the 696 publisher of this certificate. 698 resource_set_as: 699 in the context of a class element, the value of this attribute is 700 the set of AS numbers and AS number ranges that the issuer has 701 allocated to the client within the scope of this resource class, 702 presented in ASCII as a comma-separated list. The list elements 703 are decimal integer values and ranges of decimal integers 704 specified by the low and high value of the range with a hyphen 705 delimiter, using the canonical order as described in [RFC3779], 706 without leading zeros, and with no white space or punctuation 707 other than the comma and the hyphen range designator (e.g.: 708 resource_set_as="123,456-789,123456"). If there are no AS numbers 709 in this Resource Class the empty set will be represented by a null 710 string value ("") for this attribute. 712 resource_set_ipv4: 713 in the context of a class element, the value of this attribute is 714 the set of IPv4 addresses that the issuer has allocated to the 715 client within the scope of this resource class. The value is 716 presented in ASCII as a comma-separated list of elements. Each 717 element is either an address prefix using the notation of /mask length, or a range specified as low and high range 719 values in dotted quad notation with a hyphen delimiter. The list 720 is presented in canonical order, as described in [RFC3779]. The 721 dotted quad notation is without leading zeros, and the list 722 contains no white space or punctuation other than the period, 723 forward slash, hyphen and comma. (e.g. 724 resource_set_ipv4="192.0.2.0/26,192.0.2.66-192.0.2.76") If there 725 are no IPv4 addresses in this resource class the empty set will be 726 represented by a null string value ("") for this attribute. 728 resource_set_ipv6: 729 in the context of a class element, the value of this attribute is 730 the set of IPv6 addresses that the issuer has allocated to the 731 client within the scope of this resource class. The value is 732 presented in ASCII as a comma-separated list of elements. Each 733 element is either an address prefix using the notation of /mask length, or a range specified as low and high 735 range values in hex nibble notation with a hyphen delimiter. 736 Trailing zero nibbles are truncated and represented by '::'. The 737 list is presented in canonical order, as described in [RFC3779]. 738 The hex nibble sequence notation is without leading zeros, and the 739 list contains no white space or punctuation other than the colon, 740 forward slash, hyphen and comma (e.g. resource_set_ipv6="2001: 741 0DB8::/48,2001:0DB8:002::-2001:0DB8:005::"). The XML Schema data 742 type is "http://www.w3.org/TR/xmlschema-2/#hexBinary" and value is 743 case insensitive, with the canonical form being upper case. If 744 there are no IPv6 addresses in this resource class the empty set 745 will be represented by a null string value ("") for this 746 attribute. 748 resource_set_notafter: 749 The value of this attribute specified the date/time that would be 750 set in the Validity notAfter field in any new certificate issued 751 for this particular client within the scope of this resource 752 class, should the client request a new certificate. The time 753 format used for the value of this attribute is specified as ISO 754 8601 [ISO.8601:2004], and MUST use UTC time (i.e. YYYY-MM- 755 DDThh:mm:ssZ, e.g. 2007-11-29T04:40:00Z). If the client's 756 certificate has a validity notAfter time that is different to this 757 time then the client SHOULD request a new certificate to be issued 758 for this resource class. 760 suggested_sia_head: (OPTIONAL) 761 If this field is present then it's value is a directory URI that 762 indicates a repository publication point that the server has made 763 available to the client to use for the client's collection of 764 published products. This specification does not encompass the 765 protocols that the client may use with the operator of the 766 repository publication point in order to publish objects at this 767 publication point. 769 [issuer's certificate] 770 value is the Base64 encoding of the DER-encoded issuer's CA 771 certificate (the CA-enabled certificate where the issuer is the 772 certificate's subject). 774 Each certificate element describes the most recently issued current 775 certificate where the certificate's subject refers to the client for 776 each active client key pair. A "current" certificate is a non- 777 expired, non-revoked certificate. If no current certificate has been 778 issued, then no certificate element will be included in the response. 780 cert_url: 781 in the context of a certificate element, this is a pointer to the 782 location where the certificate issuer has published this 783 certificate. This field is the issuer's suggestion for the AIA 784 field for the subject to use in subordinate certificates that are 785 issued by the subject. According to the Resource Certificate 786 Profile [I-D.sidr-res-certs] the AIA field is a non-empty 787 (contains a minimum of 1 element) list of URI's, one of which MUST 788 be an RSYNC URI. The order of URI's in the AIA field may be 789 interpreted as the publisher's relative preference for access 790 methods for this certificate. The cert_url conforms to this AIA 791 specification. Its value is a comma-separated list of URIs, one 792 of which MUST be an RSYNC URI. Any comma values within a URI MUST 793 be escaped ("%2C"). 795 req_resource_set_as: 796 the set of AS numbers that were specified in the corresponding 797 original certificate request that defined the maximal requested 798 span of the certified AS number set, following the syntax 799 described above. If this attribute was present in the certificate 800 request, then the attribute MUST be present in this response, 801 otherwise it MUST NOT be present. 803 req_resource_set_ipv4: 804 the set of IPv4 addresses that were specified in the corresponding 805 original certificate request that defined the maximal requested 806 span of the certified IPv4 address set, following the syntax 807 described above. If this attribute was present in the certificate 808 request, then the attribute MUST be present in this response, 809 otherwise it MUST NOT be present. 811 req_resource_set_ipv6: 812 the set of IPv6 addresses that were specified in the corresponding 813 original certificate request that defined the maximal requested 814 span of the certified IPv6 address set, following the syntax 815 described above. If this attribute was present in the certificate 816 request, then the attribute MUST be present in this response, 817 otherwise it MUST NOT be present. 819 [certificate] 820 value is the Base64 encoding of the DER-encoded certificate. 822 3.4. CA - Certificate Issuance 824 3.4.1. Certificate Issuance Request 826 The value of the message "type" element for this request is: 828 type="issue" 830 --------------------------------------------------------------- 832 Payload: 834 839 [Certificate request] 840 842 --------------------------------------------------------------- 844 The client must use different key pairs for each distinct resource 845 class. 847 If any of the req_resource_set attributes are specified in the 848 request, then any missing req_resource_set attributes are to be 849 interpreted as specifying the complete set of the corresponding 850 resource type that match the client's current resource allocation. 851 If the value of any req_resource_set attributes is the null value 852 (""), then this indicates that no resources of that resource type are 853 to be certified with this request. 855 The requested resource set values are held as a local record by the 856 issuer against the resource class and the client's public key. Any 857 subsequent Certificate Issuance Requests that specify the same 858 Resource Class and the same client's public key will (re)set the 859 issuer's local record of the requested resource sets to the most 860 recently specified values. 862 class_name: 863 value is the server's identifier of a Resource Class. 865 req_resource_set_as: (OPTIONAL) 866 the set of AS numbers that define the maximal requested span of 867 the certified AS number set, formatted as per the resource_set_as 868 attribute of the Resource Class List Response. 870 req_resource_set_ipv4: (OPTIONAL) 871 the set of IPv4 addresses that define the maximal requested span 872 of the certified IPv4 address set, formatted as per the 873 resource_set_ipv4 attribute of the Resource Class List Response. 875 req_resource_set_ipv6: (OPTIONAL) 876 the set of IPv6 addresses that define the maximal requested span 877 of the certified IPv6 address set, formatted as per the 878 resource_set_ipv6 attribute of the Resource Class List Response. 880 [Certificate request] 881 value is the certificate request. This is a Base-64 encoded DER 882 version of a request formatted using PKCS#10. 884 3.4.2. Certificate Issuance Response 886 The value of the message "type" element for this response is: 888 type="issue_response" 890 --------------------------------------------------------------- 892 Payload: 894 899 903 [certificate] 904 905 [issuer's certificate] 906 908 --------------------------------------------------------------- 909 If the certificate issuer determines that the issued certificate 910 would be identical in all respects to the most recently issued 911 certificate for this client, other than the certificate's serial 912 number, were the certificate to be issued, the issuer may choose to 913 respond with the most recently issued certificate and not issue a new 914 certificate for this request. 916 The definition of the attributes and syntax of the values is the same 917 as the resource class list response, but the response only references 918 the (single) named resource class, and the (single) certificate 919 issued against the client's public key as provided in the 920 corresponding certificate request. 922 3.5. Certificate Revocation 924 3.5.1. Certificate Revocation Request 926 The value of the message "type" element for this request is: 928 type="revoke" 930 --------------------------------------------------------------- 932 Payload: 934 937 --------------------------------------------------------------- 939 This command 'retires' a client's key pair by requesting the issuer 940 to revoke all certificates for this client that contain the matching 941 public key, within the scope of a named Resource Class. Individual 942 issued certificates cannot be revoked within the scope of this 943 protocol. 945 This command directs the issuer to immediately mark all issued valid 946 certificates issued by this issuer within the named Resource Class 947 with this client's SKI value to be marked as revoked, causing the 948 issued certificates to be withdrawn from the publication repository 949 and to be listed in the server's subsequent CRLs within this Resource 950 Class. 952 class_name: 953 value is the issuer-assigned name of the issuer's Resource Class. 955 ski: 956 value is the encoded hash of the client's public key that is to be 957 revoked. The algorithm for the encoding is to generate the 160- 958 bit SHA-1 hash of the client's public key, as defined in method 959 (1) of section 4.2.1.2 of [RFC5280], and encode this value using 960 the Base 64 encoding with URL and Filename Safe Alphabet, as 961 defined in section 5 of [RFC4648]. 963 3.5.2. Certificate Revocation Response 965 The value of the message "type" element for this response is: 967 type="revoke_response" 969 --------------------------------------------------------------- 971 Payload: 973 976 --------------------------------------------------------------- 978 class_name: 979 value is the issuer-assigned name of the server's Resource Class. 981 ski: 982 value is the encoded hash of the client's public key that is to be 983 revoked. The algorithm for the encoding is to generate the 160- 984 bit SHA-1 hash of the client's public key, as defined in method 985 (1) of section 4.2.1.2 of [RFC5280], and encode this value using 986 the Base 64 encoding with URL and Filename Safe Alphabet, as 987 defined in section 5 of [RFC4648]. 989 3.6. Request-Not-Performed Response 991 The value of the message "type" element for this response is: 993 type="error_response" 995 --------------------------------------------------------------- 997 Payload: 999 [Code] 1000 [Readable text] 1002 --------------------------------------------------------------- 1004 All states where an error response if to be generated, either due to 1005 detected errors or inconsistencies in the content of the request or 1006 server-side states that prevent the request being performed, generate 1007 a Request-Not-Performed response. 1009 description: 1010 value is a text field. This element MAY be present. It's value 1011 has no defined meaning within the scope of this protocol, and 1012 implementations may assume that some form of human-readable text 1013 may be used here. If the HTTP request that triggered this error 1014 response includes an Accept-Language header as defined in section 1015 14.4 of the HTTP/1.1 specification [RFC2616] then the server will 1016 make a best effort to include a second description element using 1017 the highest ranked preferred language of the client. The en-US 1018 description will always be included if the element is present. 1020 The error code set is: 1022 Code Value Description 1023 1101 already processing request 1024 1102 version number error 1025 1103 unrecognised request type 1026 1201 request - no such resource class 1027 1202 request - no resources allocated in resource class 1028 1203 request - badly formed certificate request 1029 1301 revoke - no such resource class 1030 1302 revoke - no such key 2000+ Server Error 1031 2001 Internal Server Error - Request not performed 1033 4. XML Schema 1035 The following is a RelaxNG compact form schema describing the Issuer- 1036 Subject Protocol, version 1. 1038 default namespace = "http://www.apnic.net/specs/rescerts/up-down/" 1040 grammar { 1041 start = element message { 1042 attribute version { xsd:positiveInteger { maxInclusive="1" } }, 1043 attribute sender { xsd:token { maxLength="1024" } }, 1044 attribute recipient { xsd:token { maxLength="1024" } }, 1045 payload 1046 } 1048 payload |= attribute type { "list" }, list_request 1049 payload |= attribute type { "list_response"}, list_response 1050 payload |= attribute type { "issue" }, issue_request 1051 payload |= attribute type { "issue_response"}, issue_response 1052 payload |= attribute type { "revoke" }, revoke_request 1053 payload |= attribute type { "revoke_response"}, revoke_response 1054 payload |= attribute type { "error_response"}, error_response 1056 list_request = empty 1057 list_response = class* 1059 class = element class { 1060 attribute class_name { xsd:token { maxLength="1024" } }, 1061 attribute cert_url { xsd:string { maxLength="4096" } }, 1062 attribute resource_set_as { xsd:string { maxLength="512000" 1063 pattern="[\-,0-9]*" } }, 1064 attribute resource_set_ipv4 { xsd:string { maxLength="512000" 1065 pattern="[\-,/.0-9]*" } }, 1066 attribute resource_set_ipv6 { xsd:string { maxLength="512000" 1067 pattern="[\-,/:0-9a-fA-F]*" } }, 1068 attribute resource_set_notafter { xsd:dateTime }, 1069 attribute suggested_sia_head { xsd:anyURI { maxLength="1024" 1070 pattern="rsync://.+"} }?, 1071 element certificate { 1072 attribute cert_url { xsd:string { maxLength="4096" } }, 1073 attribute req_resource_set_as { xsd:string { 1074 maxLength="512000" pattern="[\-,0-9]*" } }?, 1075 attribute req_resource_set_ipv4 { xsd:string { 1076 maxLength="512000" pattern="[\-,/.0-9]*" } }?, 1077 attribute req_resource_set_ipv6 { xsd:string { 1078 maxLength="512000" pattern="[\-,/:0-9a-fA-F]*" } }?, 1079 xsd:base64Binary { maxLength="512000" } 1080 }*, 1081 element issuer { xsd:base64Binary { maxLength="512000" } } 1082 } 1084 issue_request = element request { 1085 attribute class_name { xsd:token { maxLength="1024" } }, 1086 attribute req_resource_set_as { xsd:string { 1087 maxLength="512000" pattern="[\-,0-9]*" } }?, 1088 attribute req_resource_set_ipv4 { xsd:string { 1089 maxLength="512000" pattern="[\-,/.0-9]*" } }?, 1090 attribute req_resource_set_ipv6 { xsd:string { 1091 maxLength="512000" pattern="[\-,/:0-9a-fA-F]*" } }?, 1092 xsd:base64Binary { maxLength="512000" 1093 } 1094 } 1095 issue_response = class 1097 revoke_request = revocation 1099 revoke_response = 1100 revocation 1102 revocation = element key { attribute class_name { xsd:token { 1103 maxLength="1024" } }, attribute ski { 1104 xsd:token { maxLength="1024" } } 1105 } 1107 error_response = 1108 element status { xsd:positiveInteger { 1109 maxInclusive="999999999999999" } 1110 }, 1111 element description { attribute xml:lang { xsd:language }, 1112 xsd:string { maxLength="1024" } 1113 }? 1114 } 1116 5. Security Considerations 1118 The intent of this protocol is to define a protocol to support the 1119 maintenance of Resource Certificates that the Issuer issues for a 1120 Subject in certifying resources that have been allocated or assigned 1121 by the Issuer to the Subject [I-D.sidr-arch]. This protocol assumes 1122 that the Issuer and Subject are known to each other and have 1123 exchanged credentials so as to support the operation of a TLS channel 1124 with mutual identification. The mechanisms used to perform this 1125 credential exchange are not described in this specification. 1127 The primary objective of this provisioning protocol is to ensure that 1128 attempts to disrupt the interaction between client and server are 1129 identifiable by both parties. The mechanisms used to support this 1130 level of integrity of protocol operation include the use of TLS 1131 [RFC5246] with mutual identification, and the use of message objects 1132 that are digitally signed and dated using CMS [RFC5652]. This is 1133 intended to ensure that the communication is resistant to attempts to 1134 disrupt the communication or to replay earlier communication 1135 fragments (man-in-the middle disruption and replay attacks). 1137 The protocol is a minimal query / response protocol, that imposes 1138 strict serialization on each query / response transaction, reducing 1139 the potential for the Subject and the Issuer to lose synchronization 1140 over the issued certificate state. 1142 The inner protocol elements explicitly reference the intended sender 1143 and receiver to present an Issuer or an Subject attempting to 1144 masquerade as another party within the secure channel. 1146 6. IANA Considerations 1148 [Note to IANA, to be removed prior to publication: there are no IANA 1149 considerations stated in this version of the document.] 1151 7. Acknowledgements 1153 The authors would like to acknowledge the valued contributions from 1154 Russ Housley, Steve Kent, Randy Bush, George Michaelson, and Robert 1155 Kisteleki in the preparation of the protocol described in this 1156 document. 1158 8. References 1160 8.1. Normative References 1162 [ISO.8601:2004] 1163 ISO, "ISO 8601:2004 Representation of dates and Times", 1164 2004. 1166 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1167 September 1981. 1169 [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and 1170 J. Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES", 1171 BCP 12, RFC 2050, November 1996. 1173 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1174 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1175 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1177 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1179 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 1180 Addresses and AS Identifiers", RFC 3779, June 2004. 1182 [RFC4049] Housley, R., "BinaryTime: An Alternate Format for 1183 Representing Date and Time in ASN.1", RFC 4049, 1184 April 2005. 1186 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 1187 Algorithms and Identifiers for RSA Cryptography for use in 1188 the Internet X.509 Public Key Infrastructure Certificate 1189 and Certificate Revocation List (CRL) Profile", RFC 4055, 1190 June 2005. 1192 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1193 Architecture", RFC 4291, February 2006. 1195 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1196 Encodings", RFC 4648, October 2006. 1198 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1199 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1201 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1202 Housley, R., and W. Polk, "Internet X.509 Public Key 1203 Infrastructure Certificate and Certificate Revocation List 1204 (CRL) Profile", RFC 5280, May 2008. 1206 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", 1207 RFC 5652, September 2009. 1209 [X.501] CCITT, "Recommendation X.501: The Directory - Models", 1210 1988. 1212 [X.509-88] 1213 CCITT, "Recommendation X.509: The Directory - 1214 Authentication Framework", 1988. 1216 8.2. Informative References 1218 [I-D.sidr-arch] 1219 Lepinski, M. and S. Kent, "An Infrastructure to Support 1220 Secure Internet Routing", draft-ietf-sidr-arch (work in 1221 progress), July 2009. 1223 [I-D.sidr-res-certs] 1224 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 1225 X.509 PKIX Resource Certificates", Work in progress: 1226 Internet Drafts draft-ietf-sidr-res-certs-16.txt, 1227 February 2009. 1229 Authors' Addresses 1231 Geoff Huston 1232 Asia Pacific Network Information Centre 1234 Email: gih@apnic.net 1235 URI: http://www.apnic.net 1237 Robert Loomans 1238 Asia Pacific Network Information Centre 1240 Email: robertl@apnic.net 1241 URI: http://www.apnic.net 1243 Byron Ellacott 1244 Asia Pacific Network Information Centre 1246 Email: bje@apnic.net 1247 URI: http://www.apnic.net 1249 Rob Austein 1250 Internet Systems Consortium 1252 Email: sra@isc.org