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