idnits 2.17.1
draft-ietf-sidr-rescerts-provisioning-11.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 (August 27, 2011) is 4620 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 578
-- Looks like a reference, but probably isn't: '1' on line 574
** Downref: Normative reference to an Informational draft:
draft-huston-sidr-rpki-algs (ref. 'ID.sidr-rpki-algs')
** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
** Downref: Normative reference to an Informational RFC: RFC 2986
** Downref: Normative reference to an Informational RFC: RFC 5781
== Outdated reference: A later version (-22) exists of
draft-ietf-sidr-res-certs-16
Summary: 4 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: February 28, 2012 APNIC
6 R. Austein
7 ISC
8 August 27, 2011
10 A Protocol for Provisioning Resource Certificates
11 draft-ietf-sidr-rescerts-provisioning-11.txt
13 Abstract
15 This document defines a framework for certificate management
16 interactions between an Internet Number Resource issuer ("Issuer")
17 and an Internet Number Resource recipient ("Subject") through the
18 specification of a protocol for interaction between the two parties.
19 The protocol supports the transmission of requests from the Subject,
20 and corresponding responses from the Issuer encompassing the actions
21 of certificate issuance, certificate revocation and certificate
22 status information reports. This protocol is intended to be limited
23 to the application of Internet Number Resource Certificate management
24 and is not intended to be used as part of a more general certificate
25 management framework.
27 Status of this Memo
29 This Internet-Draft is submitted in full conformance with the
30 provisions of BCP 78 and BCP 79.
32 Internet-Drafts are working documents of the Internet Engineering
33 Task Force (IETF). Note that other groups may also distribute
34 working documents as Internet-Drafts. The list of current Internet-
35 Drafts is at http://datatracker.ietf.org/drafts/current/.
37 Internet-Drafts are draft documents valid for a maximum of six months
38 and may be updated, replaced, or obsoleted by other documents at any
39 time. It is inappropriate to use Internet-Drafts as reference
40 material or to cite them other than as "work in progress."
42 This Internet-Draft will expire on February 28, 2012.
44 Copyright Notice
46 Copyright (c) 2011 IETF Trust and the persons identified as the
47 document authors. All rights reserved.
49 This document is subject to BCP 78 and the IETF Trust's Legal
50 Provisions Relating to IETF Documents
51 (http://trustee.ietf.org/license-info) in effect on the date of
52 publication of this document. Please review these documents
53 carefully, as they describe your rights and restrictions with respect
54 to this document. Code Components extracted from this document must
55 include Simplified BSD License text as described in Section 4.e of
56 the Trust Legal Provisions and are provided without warranty as
57 described in the Simplified BSD License.
59 Table of Contents
61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
63 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
64 3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 4
65 3.1. CMS Profile . . . . . . . . . . . . . . . . . . . . . . . 5
66 3.1.1. SignedData Content Type . . . . . . . . . . . . . . . 5
67 3.1.2. CMS Object Validation . . . . . . . . . . . . . . . . 10
68 3.1.3. ASN.1 Specification of the CMS Signed Object . . . . . 12
69 3.2. Common Message format . . . . . . . . . . . . . . . . . . 14
70 3.3. Control - Resource Class Query . . . . . . . . . . . . . . 16
71 3.3.1. Resource Class List Query . . . . . . . . . . . . . . 16
72 3.3.2. Resource Class List Response . . . . . . . . . . . . . 16
73 3.4. CA - Certificate Issuance . . . . . . . . . . . . . . . . 21
74 3.4.1. Certificate Issuance Request . . . . . . . . . . . . . 21
75 3.4.2. Certificate Issuance Response . . . . . . . . . . . . 23
76 3.5. Certificate Revocation . . . . . . . . . . . . . . . . . . 24
77 3.5.1. Certificate Revocation Request . . . . . . . . . . . . 24
78 3.5.2. Certificate Revocation Response . . . . . . . . . . . 25
79 3.6. Request-Not-Performed Response . . . . . . . . . . . . . . 26
80 3.7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 27
81 4. Security Considerations . . . . . . . . . . . . . . . . . . . 29
82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
83 5.1. application/rpki-updown . . . . . . . . . . . . . . . . . 30
84 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
86 7.1. Normative References . . . . . . . . . . . . . . . . . . . 31
87 7.2. Informative References . . . . . . . . . . . . . . . . . . 32
88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
90 1. Introduction
92 This document defines a framework for certificate management
93 interactions between an Internet Number Resource issuer ("Issuer")
94 and an Internet Number Resource recipient ("Subject") through the
95 specification of a protocol for interaction between the two parties.
96 The protocol supports the transmission of requests from the Subject,
97 and corresponding responses from the Issuer encompassing the actions
98 of certificate issuance, certificate revocation and certificate
99 status information reports. This protocol is intended to be limited
100 to the application of Internet Number Resource certificate management
101 and is not intended to be used as part of a more general certificate
102 management framework.
104 1.1. Terminology
106 Terms used in this document are:
108 "Internet Number Resource" (or "resource") used in the context of
109 this document to refer to Autonomous System (AS) numbers, IP
110 version 4 addresses, and IP version 6 addresses.
112 "Issuer" used in the context of this document as an entity
113 undertaking the role of resource issuer. An "Issuer" is a
114 Certificate Authority, and can issue Resource Certificates.
116 "Subject" used in the context of this document as an entity
117 undertaking the role of resource recipient who is the subject of a
118 Resource Certificate. A "Subject" may be issued with a CA-enabled
119 certificate, allowing the entity to also assume the role of an
120 "Issuer".
122 "resource class" a resource class refers to a collection of
123 resources that can be certified in a single resource certificate
124 by an issuer.
126 "server" in the context of this client/server protocol
127 specification, the Issuer assumes the role of the "server."
129 "client" in the context of this client/server protocol
130 specification, the Subject assumes the role of the "client."
132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
134 document are to be interpreted as described in RFC 2119.
136 2. Scope
138 This Resource Public Key Infrastructure (RPKI) certificate
139 provisioning protocol defines a basic set of interactions that allow
140 a Subject to request certificate issuance, revocation and status
141 information from the Issuer, and for a Issuer to maintain an issued
142 certificate set that is aligned to the allocation records relating to
143 each Subject. The Issuer's resource allocation database is the
144 authoritative source of what resource allocations the Issuer may
145 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, and the exchange of the certificates and validation
161 Public Key Infrastructure (PKI) contexts used in the Cryptographic
162 Message Syntax (CMS) [RFC5652] message exchange.
164 o the interactions between client and server that allow respective
165 local CMS signing time values to be reset to mutually recognised
166 values.
168 3. Protocol Specification
170 This RPKI certificate provisioning protocol is expressed as a simple
171 request/response interaction, where the client passes a request to
172 the server, and the server generates a corresponding response.
174 The protocol is implemented as an exchange of messages.
176 Messages are passed over an HTTP [RFC2616] end-to-end connection. A
177 message exchange commences with the client initiating an HTTP POST
178 with content type of "application/rpki-updown", with the message
179 object as the body. The server's response is similarly an HTTP
180 response, with the message object carried as the body of the response
181 and with a response content type of "application/rpki-updown".
183 The content of the POST, and the server's response, are "well-formed"
184 CMS [RFC5652] objects, encoded using the Distinguished Encoding Rules
185 for ASN.1 (DER) [X.509-88], formatted in accordance with the CMS
186 profile specified in the following section. CMS is used as the
187 signing format to sign the message object. The public part of the
188 signing key and the associated certificate chain that is used to
189 validate the CMS digital signature is assumed to have been
190 communicated between the two entities, through mechanisms not defined
191 in this specification.
193 The protocol's request / response interaction is assumed to be
194 reliable, in that all requests MUST generate a matching response.
195 The protocol requires sequential operation for each distinct client,
196 where the server MUST NOT accept a client's request unless it has
197 generated and sent a response to the client's previous request.
198 Attempts by the client to initiate multiple requests in parallel
199 (i.e. multiple concurrent requests with a common sender attribute
200 (see section 3.2) in the request) MUST be detected by the server and
201 rejected with an error response (i.e. an error code 1101 response).
203 3.1. CMS Profile
205 The format of the CMS object is:
207 ContentInfo ::= SEQUENCE {
208 contentType ContentType,
209 content [0] EXPLICIT ANY DEFINED BY contentType }
211 ContentType ::= OBJECT IDENTIFIER
213 The ContentType is the signed-data type of id-data, namely id-
214 signedData, OID = 1.2.840.113549.1.7.2. [RFC5652]
216 3.1.1. SignedData Content Type
218 According to the CMS standard [RFC5652], signed-data content types is
219 the ASN.1 type SignedData:
221 SignedData ::= SEQUENCE {
222 version CMSVersion,
223 digestAlgorithms DigestAlgorithmIdentifiers,
224 encapContentInfo EncapsulatedContentInfo,
225 certificates [0] IMPLICIT CertificateSet OPTIONAL,
226 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
227 signerInfos SignerInfos }
229 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
230 SignerInfos ::= SET OF SignerInfo
232 Additionally, the SignerInfos set MUST contain only a single
233 SignerInfo object.
235 3.1.1.1. version
237 The version is the syntax version number. It MUST be 3,
238 corresponding to the signerInfo structure having version number 3.
240 3.1.1.2. digestAlgorithms
242 The digestAlgorithms set contains the OIDs of the digest algorithm(s)
243 used in signing the encapsulated content. This set MUST contain
244 exactly one digest algorithm OID, and the OID MUST be selected from
245 those specified in [ID.sidr-rpki-algs].
247 3.1.1.3. encapContentInfo
249 encapContentInfo is the signed content, consisting of a content type
250 identifier and the content itself. The encapContentInfo represents
251 the payload of the RPKI certificate provisioning protocol.
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 an RPKI XML Protocol Object consists of a single
274 protocol message, structured according to a defined 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 RPKIXMLProtocolObject ::= OCTET STRING -- XML encoded message
280 3.1.1.4. certificates
282 This field MUST be present, and MUST contain the single 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 CA certificates that a relying party MAY use
289 to validate the EE certificate.
291 3.1.1.5. crls
293 This field MUST be present. The contents of the field are specified
294 in [RFC5652]. The Certificate Revocation List (CRL) contained in
295 this field MUST be issued by the same CA that issued the EE
296 certificate of the key pair whose private key value was used to sign
297 the CMS.
299 3.1.1.6. signerInfo
301 SignerInfo is defined in CMS as:
303 SignerInfo ::= SEQUENCE {
304 version CMSVersion,
305 sid SignerIdentifier,
306 digestAlgorithm DigestAlgorithmIdentifier,
307 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
308 signatureAlgorithm SignatureAlgorithmIdentifier,
309 signature SignatureValue,
310 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
312 3.1.1.6.1. version
314 The version number MUST be 3, corresponding with the choice of
315 SubjectKeyIdentifier for the sid.
317 3.1.1.6.2. sid
319 The sid is defined as:
321 SignerIdentifier ::= CHOICE {
322 issuerAndSerialNumber IssuerAndSerialNumber,
323 subjectKeyIdentifier [0] SubjectKeyIdentifier }
325 In this profile, the sid MUST be the SubjectKeyIdentifier that
326 appears in the EE certificate carried in the CMS certificates field.
328 3.1.1.6.3. digestAlgorithm
330 The digestAlgorithm MUST consist of the OID of a digest algorithm
331 that conforms to the RPKI Algorithms and Key Size Profile
332 specification [ID.sidr-rpki-algs].
334 3.1.1.6.4. signedAttrs
336 The signedAttrs field is defined as:
338 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
340 UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute
342 Attribute ::= SEQUENCE {
343 attrType OBJECT IDENTIFIER,
344 attrValues SET OF AttributeValue }
346 AttributeValue ::= ANY
348 The signedAttr element MUST be present and MUST include the content-
349 type, and message-digest [RFC5652] attributes. If the either the
350 signing-time [RFC5652] attribute or the the binary-signing-time
351 attribute [RFC6019] attribute, or both attributes, are present they
352 MUST also be included as the SignedAttributes. Other signed
353 attributes MUST NOT be included.
355 The signedAttr MUST include only a single instance of any particular
356 attribute. Additionally, even though the syntax allows for a SET OF
357 AttributeValue, in this profile the attrValues MUST consist of only a
358 single AttributeValue.
360 3.1.1.6.4.1. Content-Type Attribute
362 The ContentType attribute MUST be present. The attrType OID for the
363 ContentType attribute is 1.2.840.113549.1.9.3.
365 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
366 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }
368 ContentType ::= OBJECT IDENTIFIER
370 The attrValues for the ContentType attribute MUST match the
371 eContentType in the EncapsulatedContentInfo. This OID value is
372 defined as id-ct-xml, and has the numerical value of
373 1.2.840.113549.1.9.16.1.28.
375 3.1.1.6.4.2. Message-Digest Attribute
377 The MessageDigest Attribute MUST be present. The attrType OID for
378 the MessageDigest Attribute is 1.2.840.113549.1.9.4.
380 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
381 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }
383 MessageDigest ::= OCTET STRING
385 The attrValues for the MessageDigest attribute contains the output of
386 the digest algorithm applied to the content being signed, as
387 specified in Section 5.4 of [RFC5652].
389 3.1.1.6.4.3. SigningTime Attribute
391 The SigningTime attribute MAY be present. The attrType OID for the
392 SigningTime attribute is 1.2.840.113549.1.9.5.
394 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
395 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }
397 SigningTime ::= Time
399 Time ::= CHOICE {
400 utcTime UTCTime,
401 generalizedTime GeneralizedTime }
403 The SigningTime attribute specifies the time, based on the local
404 system clock, when the digital signature was applied to the content.
406 Guidelines regarding the use of UTCTime and GeneralizedTime in the
407 Signing Time attribute can be found in Section 11.3 of [RFC5652].
409 Either one of the SigningTime attribute or the BinarySigningTime
410 attribute, or both attributes, MUST be present. If both the
411 SigningTime and BinarySigningTime attributes are present they MUST
412 both represent the same underlying time value.
414 3.1.1.6.4.4. BinarySigningTime Attribute
416 The BinarySigningTime attribute MAY be present. The attrType OID for
417 the Binary-SigningTime attribute is 1.2.840.113549.1.9.16.2.46.
419 id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1)
420 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
421 smime(16) aa(2) 46 }
423 BinarySigningTime ::= BinaryTime
425 BinaryTime ::= INTEGER (0..MAX)
427 The BinarySigningTime attribute specifies the time, based on the
428 local system clock, when the digital signature was applied to the
429 content. The precise definition of the BinarySigningTime attribute
430 can be found at [RFC6019].
432 Either one of the SigningTime or the BinarySigningTime attributes, or
433 both attributes, MUST be present. If both the SigningTime and
434 BinarySigningTime attributes are present they MUST both represent the
435 same underlying time value.
437 3.1.1.6.5. signatureAlgorithm
439 The signatureAlgorithm MUST conform to the RPKI Algorithms and Key
440 Size Profile specification [ID.sidr-rpki-algs].
442 3.1.1.6.6. signature
444 The signature value is defined as:
446 SignatureValue ::= OCTET STRING
448 The signature characteristics are defined by the digest and signature
449 algorithms.
451 3.1.1.6.7. UnsignedAttributes
453 unsignedAttrs MUST be omitted.
455 3.1.2. CMS Object Validation
457 Before a recipient of a CMS signed object can use the content of the
458 object, the recipient MUST validate the signed object by verifying
459 that all of the following conditions hold. A recipient may perform
460 these checks in any order.
462 1. The CMS object is well formed, such that the signed object syntax
463 complies with this specification. In particular, that each of
464 the following is true:
466 a. The contentType of the CMS object is SignedData (OID
467 1.2.840.113549.1.7.2)
469 b. The version of the SignedData object is 3.
471 c. The certificates field in the SignedData object is present
472 and contains one EE certificate, the SubjectKeyIdentifier
473 field of which matches the sid field of the SignerInfo
474 object.
476 d. The crls field in the SignedData object is present.
478 e. The version of the SignerInfo is 3.
480 f. The signedAttrs field in the SignerInfo object is present and
481 contains one each of the ContentType attribute (OID
482 1.2.840.113549.1.9.3), the MessageDigest attribute (OID
483 1.2.840.113549.1.9.4), and either or both of a single
484 instance of the SigningTime attribute (OID
485 1.2.840.113549.1.9.5) and the BinarySigningTime attribute
486 (OID 1.2.840.113549.1.9.16.2.46), and no other attributes.
488 g. The eContentType in the EncapsulatedContentInfo is an OID
489 that matches the attrValue in the ContentType attribute, and
490 has the attrValue of id-ct-xml.
492 h. The unsignedAttrs field in the SignerInfo object is omitted.
494 i. If both the SigningTime attribute and the BinarySigningTime
495 attribute are present, then their values represent the same
496 time.
498 j. The digestAlgorithm in the SignedData and SignerInfo objects
499 conforms to the RPKI Algorithms and Key Size Profile
500 specification [ID.sidr-rpki-algs].
502 k. The signatureAlgorithm in the SignerInfo object conforms to
503 the RPKI Algorithms and Key Size Profile specification
504 [ID.sidr-rpki-algs].
506 l. The signed object is DER encoded.
508 2. The public key of the EE certificate (contained within the CMS
509 signed-data object) can be used to successfully verify the
510 signature on the signed object.
512 3. The EE certificate (contained within the CMS signed-data object)
513 is a valid EE certificate. In particular, there exists a valid
514 certification path from a trust anchor selected by the recipient
515 to this EE certificate.
517 4. At the current time the EE certificate is not revoked. This can
518 be determined by confirming that the CRL contained in the crls
519 field of the CMS signed data object is a current valid CRL,
520 issued by the same CA that issued the EE certificate, and the CRL
521 does not list the serial number of EE certificate.
523 5. The time represented by the SigningTime attribute or the
524 BinarySigningTime attribute is greater than or equal to the time
525 value passed in previously valid CMS objects that were passed
526 from the same originator to this recipient. This signing time
527 time value MAY lie within the Validity Time of the EE
528 Certificate, but the EE certificate SHOULD NOT be considered
529 invalid if this is not the case when all other checks listed here
530 are passed.
532 3.1.3. ASN.1 Specification of the CMS Signed Object
534 The following is the ASN.1 specification of the CMS signed object
535 used by the RPKI provisioning protocol.
537 ContentInfo ::= SEQUENCE {
538 contentType ContentType,
539 content [0] EXPLICIT ANY DEFINED BY contentType }
541 ContentType ::= OBJECT IDENTIFIER
543 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
544 rsadsi(113549) pkcs(1) pkcs9(9) 16 }
546 id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
548 id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 }
550 RPKIXMLProtocolObject ::= OCTET STRING -- XML encoded message
552 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
553 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }
555 SignedData ::= SEQUENCE {
556 version CMSVersion,
557 digestAlgorithms DigestAlgorithmIdentifiers,
558 encapContentInfo EncapsulatedContentInfo,
559 certificates [0] IMPLICIT CertificateSet OPTIONAL,
560 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
561 signerInfos SignerInfos }
563 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
565 SignerInfos ::= SET OF SignerInfo
567 SignerInfo ::= SEQUENCE {
568 version CMSVersion,
569 sid SignerIdentifier,
570 digestAlgorithm DigestAlgorithmIdentifier,
571 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
572 signatureAlgorithm SignatureAlgorithmIdentifier,
573 signature SignatureValue,
574 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
576 SignerIdentifier ::= CHOICE {
577 issuerAndSerialNumber IssuerAndSerialNumber,
578 subjectKeyIdentifier [0] SubjectKeyIdentifier }
580 SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
582 Attribute ::= SEQUENCE {
583 attrType OBJECT IDENTIFIER,
584 attrValues SET OF AttributeValue }
586 AttributeValue ::= ANY
588 SignatureValue ::= OCTET STRING
590 id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
591 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }
593 ContentType ::= OBJECT IDENTIFIER
595 id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
596 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }
598 MessageDigest ::= OCTET STRING
600 id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
601 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }
603 SigningTime ::= Time
605 Time ::= CHOICE {
606 utcTime UTCTime,
607 generalizedTime GeneralizedTime }
609 id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1)
610 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
611 smime(16) aa(2) 46 }
613 BinarySigningTime ::= BinaryTime
615 BinaryTime ::= INTEGER (0..MAX)
617 3.2. Common Message format
619 The XML template for all messages is informally described as follows
620 (The RelaxNG compact form schema that formally describes the Issue-
621 Subject Protocol message objects is contained in Section 3.7.):
623 ---------------------------------------------------------------
625
626
632 [payload]
634
636 ---------------------------------------------------------------
638 version:
639 the value of this attribute is the version of this protocol. This
640 document describes version 1.
642 sender:
643 the value of this attribute is the agreed name of the message
644 sender, as determined between the client and the server by prior
645 arrangement.
647 recipient:
648 the value of this attribute is the agreed name of the message
649 recipient, as determined between the client and the server by
650 prior arrangement.
652 type:
653 the possible values of this attribute are "list", "list_response",
654 "issue", "issue_response", "revoke", "revoke_response", and
655 "error_response".
657 Conforming parsers MUST reject any document with a version number
658 they do not understand, or with any elements or attributes they do
659 not understand. Servers must generate an error response when
660 receiving such a request. Clients should generate an error when
661 receiving such a response.
663 The encapsulated content of the CMS wrapping is an XML document. The
664 remainder of this protocol specification omits this CMS wrapper and
665 only discusses the XML document.
667 Messages are checked using the following tests:
669 1. Check that the CMS is well-formed (see test 1 of Section 3.1.2).
671 2. Check that the XML is well-formed.
673 3. Check that the XML sender and recipient attributes reference a
674 known client and this server's system respectively for a query
675 and the previously addressed server and this client for a
676 response.
678 4. Verify the digital signature using the public key provided in the
679 certificate carried in the CMS wrapper (see test 2 of
680 Section 3.1.2).
682 5. Validate the CMS-provided certificate using the PKI that has been
683 determined by prior arrangement between client and server (see
684 test 3 of Section 3.1.2).
686 6. Check that the CMS-signing time is equal to or greater than the
687 signing time provided in the most recent previous message that
688 this recipient has received from this sender (see test 4 of
689 Section 3.1.2).
691 7. Check that the value of the version number of the message is 1.
693 These checks SHOULD be applied in the order specified here.
695 Any errors encountered while checking items 1 through 7 MUST cause a
696 server to generate an "HTTP 400 Bad Request" response to the HTTP
697 POST operation. An error in step 7 MUST cause the server to generate
698 a "Request-Not-Performed" error response. Any errors encountered in
699 these tests by a client SHOULD cause the client to generate an error.
701 A server MAY perform flow control on the rate of processed requests.
702 Requests not processed due to such a flow control constraint MAY
703 cause the server to generate a "HTTP 503 Service Unavailable"
704 response. A HTTP 503 response MAY include a HTTP Retry-After: header
705 as a hint to the client.
707 3.3. Control - Resource Class Query
709 This query is used for a client to query a server for a list of all
710 resources that have been allocated or assigned by the server to the
711 client. In addition, the server's response will contain a copy of
712 the current certificates issued by the server's CA where this client
713 is the certificate's subject./
715 3.3.1. Resource Class List Query
717 The value of the message "type" message attribute for this query is:
719 type="list"
721 ---------------------------------------------------------------
723 Payload:
725 [No message payload is defined for this query]
727 ---------------------------------------------------------------
729 3.3.2. Resource Class List Response
731 The value of the message "type" element for this response is:
733 type="list_response"
735 ---------------------------------------------------------------
737 Payload:
739
746
750 [certificate]
751
753 ...
755 (repeated for each current certificate where the client
756 is the certificate's subject)
758 [issuer's certificate]
759
761 ...
763 (repeated for each of the issuer's resource class where the
764 client has been allocated resources)
766 ---------------------------------------------------------------
768 Where the client has been allocated resources from multiple resource
769 classes, then the response MUST contain multiple class elements,
770 corresponding to the complete set of the issuer's resource classes
771 where the client holds allocated resources. Those issuer's resource
772 classes where the client holds no allocated resources MUST NOT be
773 included in the response.
775 Where the issuer has issued multiple certificates in a resource class
776 signed with different keys (as may occur during a staged issuer-key
777 rollover), only the most recent certificate issued with the currently
778 "active" issuer's key is to be listed in the response.
780 Each "class" element describes a set of resources that are certified
781 within the scope of a single certificate, referring to a single
782 resource class with a common validation path.
784 class_name:
785 the value of this attribute is the issuer-assigned name of the
786 issuer's Resource Class.
788 cert_url:
789 in the context of a class element, the value of this attribute is
790 a pointer to the issuer's CA certificate (i.e. a reference to the
791 immediate superior certificate, being the CA-enabled certificate
792 where the issuer is the certificate's subject). Its value is a
793 comma-separated list of URIs, of which at least one MUST be an
794 RSYNC URI [RFC5781]. Any comma values within a URI MUST be
795 escaped ("%2C"). The ordering of the list may be interpreted by
796 the client as a relative preference for access methods as
797 expressed by the publisher of this certificate.
799 resource_set_as:
800 in the context of a class element, the value of this attribute is
801 the set of AS numbers and AS number ranges that the issuer has
802 allocated to the client within the scope of this resource class,
803 presented in ASCII as a comma-separated list. The list elements
804 are decimal integer values and ranges of decimal integers
805 specified by the low and high value of the range with a hyphen
806 delimiter, using the canonical order as described in [RFC3779],
807 without leading zeros, and with no white space or punctuation
808 other than the comma and the hyphen range designator (e.g.:
809 resource_set_as="123,456-789,123456"). If there are no AS numbers
810 in this Resource Class, then the empty AS set is represented by a
811 null string value ("") for this attribute.
813 resource_set_ipv4:
814 in the context of a class element, the value of this attribute is
815 the set of IPv4 addresses that the issuer has allocated to the
816 client within the scope of this resource class. The value is
817 presented in ASCII as a comma-separated list of elements. Each
818 element is either an address prefix using the notation of /mask length, or a range specified as low and high range
820 values in dotted quad notation with a hyphen delimiter. The list
821 is presented in canonical order, as described in [RFC3779]. The
822 dotted quad notation is without leading zeros, and the list
823 contains no white space or punctuation other than the period,
824 forward slash, hyphen and comma. (e.g.
825 resource_set_ipv4="192.0.2.0/26,192.0.2.66-192.0.2.76") If there
826 are no IPv4 addresses in this resource class the empty IPv4
827 address set is represented by a null string value ("") for this
828 attribute.
830 resource_set_ipv6:
831 in the context of a class element, the value of this attribute is
832 the set of IPv6 addresses that the issuer has allocated to the
833 client within the scope of this resource class. The value is
834 presented in ASCII as a comma-separated list of elements. Each
835 element is either an address prefix using the notation of /mask length, or a range specified as low and high
837 range values in hex nibble notation with a hyphen delimiter.
838 Trailing zero nibbles are truncated and represented by '::'. The
839 list is presented in canonical order, as described in [RFC3779].
840 The hex nibble sequence notation is without leading zeros, and the
841 list contains no white space or punctuation other than the colon,
842 forward slash, hyphen and comma, and conforms to the canonical
843 format of [RFC5952] (e.g. resource_set_ipv6="2001:db8::/
844 48,2001:db8:2::-2001:db8:5::"). The XML Schema data type is
845 "http://www.w3.org/TR/xmlschema-2/#hexBinary" and value is case
846 insensitive, with the canonical form being lower case. If there
847 are no IPv6 addresses in this resource class the empty IPv6
848 address set is represented by a null string value ("") for this
849 attribute.
851 resource_set_notafter:
852 The value of this attribute specifies the date/time that would be
853 set in the Validity notAfter field in any new certificate issued
854 for this particular client within the scope of this resource
855 class, should the client request a new certificate. The time
856 format used for the value of this attribute is specified as ISO
857 8601 [ISO.8601:2004], and MUST use UTC time (i.e. YYYY-MM-
858 DDThh:mm:ssZ, e.g. 2007-11-29T04:40:00Z). If the client's
859 certificate has a validity notAfter time that is different to this
860 time then the client SHOULD request a new certificate to be issued
861 for this resource class.
863 suggested_sia_head: (OPTIONAL)
864 If this field is present then it's value is a directory URI that
865 indicates a repository publication point that the server has made
866 available to the client to use for the client's collection of
867 published products. This specification does not encompass the
868 protocols that the client may use with the operator of the
869 repository publication point in order to publish objects at this
870 publication point.
872 [issuer's certificate]
873 value is the Base64 encoding of the DER-encoded issuer's CA
874 certificate (the CA-enabled certificate where the issuer is the
875 certificate's subject).
877 Each certificate element describes the most recently issued current
878 certificate where the certificate's subject refers to the client for
879 each active client key pair. A "current" certificate is a non-
880 expired, non-revoked certificate. If no current certificate has been
881 issued, then no certificate element is to be included in the
882 response.
884 cert_url:
885 in the context of a certificate element, this is a pointer to the
886 location where the certificate issuer has published this
887 certificate. This field is the issuer's suggestion for the AIA
888 field for the subject to use in subordinate certificates that are
889 issued by the subject. According to the Resource Certificate
890 Profile [ID.sidr-res-certs] the AIA field is a non-empty (contains
891 a minimum of 1 element) list of URI's, one of which MUST be an
892 RSYNC URI [RFC5781]. The order of URI's in the AIA field may be
893 interpreted as the publisher's relative preference for access
894 methods for this certificate. The cert_url conforms to this AIA
895 specification. Its value is a comma-separated list of URIs, one
896 of which MUST be an RSYNC URI. Any comma values within a URI MUST
897 be escaped ("%2C").
899 req_resource_set_as:
900 the set of AS numbers that were specified in the corresponding
901 original certificate request that defined the maximal requested
902 span of the certified AS number set, following the syntax
903 described above. If this attribute was present in the certificate
904 request, then the attribute MUST be present in this response,
905 otherwise it MUST NOT be present.
907 req_resource_set_ipv4:
908 the set of IPv4 addresses that were specified in the corresponding
909 original certificate request that defined the maximal requested
910 span of the certified IPv4 address set, following the syntax
911 described above. If this attribute was present in the certificate
912 request, then the attribute MUST be present in this response,
913 otherwise it MUST NOT be present.
915 req_resource_set_ipv6:
916 the set of IPv6 addresses that were specified in the corresponding
917 original certificate request that defined the maximal requested
918 span of the certified IPv6 address set, following the syntax
919 described above. If this attribute was present in the certificate
920 request, then the attribute MUST be present in this response,
921 otherwise it MUST NOT be present.
923 [certificate]
924 value is the Base64 encoding of the DER-encoded certificate.
926 3.4. CA - Certificate Issuance
928 This query is used by the client to request the server's CA to issue
929 a resource certificate for the resources that have been allocated or
930 assigned to the client. If the request can be sucessfully processed
931 then the server's response includes the issued certificate.
933 3.4.1. Certificate Issuance Request
935 The value of the message "type" element for this request is:
937 type="issue"
939 ---------------------------------------------------------------
941 Payload:
943
948 [Certificate request]
949
951 ---------------------------------------------------------------
953 The client MUST use different key pairs for each distinct resource
954 class.
956 The req_resource_set attributes are optional in the request.
958 If none of the req_resource_set attributes are specified then the
959 request signifies that the the complete set of all resources that
960 match the client's current resource allocation is to be included in
961 the issued certificate.
963 If any of the req_resource_set attributes are specified in the
964 request, then any missing req_resource_set attributes are to be
965 interpreted as specifying the complete set of the corresponding
966 resource type that match the client's current resource allocation are
967 to be included in the issued certificate.
969 If the value of any included req_resource_set attribute is the null
970 value (""), then this indicates that no resources of that resource
971 type are to be included in the issued certificate.
973 The requested resource set values are held as a local record by the
974 issuer against the resource class and the client's public key. Any
975 subsequent Certificate Issuance Requests that specify the same
976 Resource Class and the same client's public key will (re)set the
977 issuer's local record of the requested resource sets to the most
978 recently specified values.
980 class_name:
981 value is the server's identifier of a Resource Class.
983 req_resource_set_as: (OPTIONAL)
984 the set of AS numbers that define the maximal requested span of
985 the certified AS number set, formatted as per the resource_set_as
986 attribute of the Resource Class List Response.
988 req_resource_set_ipv4: (OPTIONAL)
989 the set of IPv4 addresses that define the maximal requested span
990 of the certified IPv4 address set, formatted as per the
991 resource_set_ipv4 attribute of the Resource Class List Response.
993 req_resource_set_ipv6: (OPTIONAL)
994 the set of IPv6 addresses that define the maximal requested span
995 of the certified IPv6 address set, formatted as per the
996 resource_set_ipv6 attribute of the Resource Class List Response.
998 [Certificate request]
999 value is the certificate request. This is a Base-64 encoded DER
1000 version of a request formatted using PKCS#10 [RFC2986]. The
1001 certificate request is signed using the private key part of the
1002 key pair whose public part is the subject key value in the
1003 certification request. The signing algorithm is specified
1004 in[ID.sidr-rpki-algs]. (This signature component is intended to
1005 demonstrate proof of possession of the private key.)
1007 The response to this request is a Certificate Issuance Response if
1008 the request can be processed online. If the request cannot be
1009 undertaken immediately then the server MUST response with a Request-
1010 Not-Performed message, using the appropriate error code.:
1012 o If the resource class is not defined by the server, then the
1013 server MUST return error code 1201.
1015 o If the client holds no resources in a defined resource class then,
1016 the server MUST return error code 1202 and not proceed with the
1017 request.
1019 o If the certificate request payload is badly formed, then the
1020 server MUST return error code 1203.
1022 o If the public key used in the certificate request implies that
1023 client is attempting to use identical key pairs for multiple
1024 resource classes, then the server MUST respond with a 1204 error
1025 code.
1027 o If the certificate issuer uses an off-line process to undertake
1028 certificate issuance, and the server cannot directly respond to
1029 the certificate issuance request with an issued certificate, then
1030 the certificate issuer MUST respond to the first instance of this
1031 request with an error code 1104 to indicate that the request is
1032 being processed asynchronously. Subsequent repetitions of this
1033 request while the off-line actions are being undertaken SHOULD
1034 cause a response with error code 1101. In this context, where
1035 off-line processes are invoked for certificate issuance, if the
1036 certificate issuer determines in processing the request that the
1037 issued certificate would be identical in all respects to the most
1038 recently issued certificate for this client, other than the
1039 certificate's serial number, were the certificate to be issued,
1040 the issuer may choose to respond with the most recently issued
1041 certificate and not initiate an off-line certificate issuance
1042 request.
1044 It is noted that a client, when receiving a 1104 response to a
1045 certificate issuance request MAY periodically resubmit the
1046 request, in which case the client MUST receive an error code
1047 1101 response while the request is being processed, and a
1048 Certificate Issuance Response when the certificate issuance
1049 process has completed. In such circumstances a client SHOULD
1050 limit the frequency of such repeated requests to no more than 1
1051 request in each 24 hour interval.
1053 3.4.2. Certificate Issuance Response
1055 The value of the message "type" element for this response is:
1057 type="issue_response"
1059 ---------------------------------------------------------------
1061 Payload:
1063
1068
1072 [certificate]
1073
1074 [issuer's certificate]
1075
1077 ---------------------------------------------------------------
1079 If the certificate issuer determines that the issued certificate
1080 would be identical in all respects to the most recently issued
1081 certificate for this client, other than the certificate's serial
1082 number, were the certificate to be issued, the issuer may choose to
1083 respond with the most recently issued certificate and not issue a new
1084 certificate for this request.
1086 The definition of the attributes and syntax of the values is the same
1087 as the resource class list response, but the response only references
1088 the (single) named resource class, and the (single) certificate
1089 issued against the client's public key as provided in the
1090 corresponding certificate request.
1092 3.5. Certificate Revocation
1094 This request 'retires' a client's key pair by requesting the server's
1095 CA to revoke all certificates for this client (i.e. where this client
1096 is the subject) that contain the matching public key, within the
1097 scope of a named Resource Class. Individual issued certificates
1098 cannot be revoked within the scope of this protocol.
1100 3.5.1. Certificate Revocation Request
1102 The value of the message "type" element for this request is:
1104 type="revoke"
1106 ---------------------------------------------------------------
1108 Payload:
1110
1113 ---------------------------------------------------------------
1115 This command directs the server's CA to immediately mark all issued
1116 valid certificates issued by this issuer within the named Resource
1117 Class with this client's Subject name and the provided SKI value to
1118 be marked as revoked, causing the issued certificates to be withdrawn
1119 from the publication repository and to be listed in the server's
1120 subsequent CRLs within this Resource Class. The issuer MUST ensure
1121 that all certificates to be revoked were issued with the requesting
1122 client as the certificate's subject.
1124 class_name:
1125 value is the issuer-assigned name of the issuer's Resource Class.
1127 ski:
1128 value is the encoded hash of the client's public key that is to be
1129 revoked. The algorithm for the encoding is to generate the 160-
1130 bit SHA-1 hash of the client's public key, as defined in method
1131 (1) of section 4.2.1.2 of [RFC5280], and encode this value using
1132 the Base 64 encoding with URL and Filename Safe Alphabet, as
1133 defined in section 5 of [RFC4648].
1135 3.5.2. Certificate Revocation Response
1137 The value of the message "type" element for this response is:
1139 type="revoke_response"
1141 ---------------------------------------------------------------
1143 Payload:
1145
1148 ---------------------------------------------------------------
1150 class_name:
1151 value is the issuer-assigned name of the server's Resource Class.
1153 ski:
1154 value is the encoded hash of the client's public key that is to be
1155 revoked. The algorithm for the encoding is to generate the 160-
1156 bit SHA-1 hash of the client's public key, as defined in method
1157 (1) of section 4.2.1.2 of [RFC5280], and encode this value using
1158 the Base 64 encoding with URL and Filename Safe Alphabet, as
1159 defined in section 5 of [RFC4648].
1161 3.6. Request-Not-Performed Response
1163 The value of the message "type" element for this response is:
1165 type="error_response"
1167 ---------------------------------------------------------------
1169 Payload:
1171 [Code]
1172 [Readable text]
1174 ---------------------------------------------------------------
1176 All states where an error response if to be generated, either due to
1177 detected errors or inconsistencies in the content of the request or
1178 server-side states that prevent the request being performed, generate
1179 a Request-Not-Performed response.
1181 description:
1182 value is a text field. This element MAY be present. It's value
1183 has no defined meaning within the scope of this protocol, and
1184 implementations may assume that some form of human-readable text
1185 may be used here. If the HTTP request that triggered this error
1186 response includes an Accept-Language header as defined in section
1187 14.4 of the HTTP/1.1 specification [RFC2616] then the server MAY
1188 include a second description element using the highest ranked
1189 preferred language of the client. The en-US description MUST
1190 always be included if the element is present.
1192 The error code set is:
1194 Code Value Description
1195 1101 already processing request
1196 1102 version number error
1197 1103 unrecognised request type
1198 1104 request scheduled for processing
1199 1201 request - no such resource class
1200 1202 request - no resources allocated in resource class
1201 1203 request - badly formed certificate request
1202 1204 request - already used key in request
1203 1301 revoke - no such resource class
1204 1302 revoke - no such key
1205 2001 Internal Server Error - Request not performed
1207 3.7. XML Schema
1209 The following is a RelaxNG compact form schema describing the Issuer-
1210 Subject Protocol, version 1.
1212 Note: "The namespace name, to serve its intended purpose, SHOULD
1213 have the characteristics of uniqueness and persistence. It is not
1214 a goal that it be directly usable for retrieval of a schema (if
1215 any exists)." ["Namespaces in XML 1.0 (Third Edition)", W3C
1216 Recommendation 8 December 2009,
1217 http://www.w3.org/TR/2009/REC-xml-names-20091208/]
1219 default namespace = "http://www.apnic.net/specs/rescerts/up-down/"
1221 grammar {
1222 resource_set_as = xsd:string { maxLength="512000"
1223 pattern="[\-,0-9]*" }
1224 resource_set_ip4 = xsd:string { maxLength="512000"
1225 pattern="[\-,/.0-9]*" }
1226 resource_set_ip6 = xsd:string { maxLength="512000"
1227 pattern="[\-,/:0-9a-fA-F]*" }
1229 class_name = xsd:token { minLength="1" maxLength="1024" }
1230 ski = xsd:token { minLength="27" maxLength="1024" }
1231 label = xsd:token { minLength="1" maxLength="1024" }
1232 cert_url = xsd:string { minLength="10" maxLength="4096" }
1233 base64_binary = xsd:base64Binary { minLength="4"
1234 maxLength="512000" }
1236 start = element message {
1237 attribute version { xsd:positiveInteger {
1238 maxInclusive="1" } },
1239 attribute sender { label },
1240 attribute recipient { label },
1241 payload
1242 }
1244 payload |= attribute type { "list" }, list_request
1245 payload |= attribute type { "list_response"}, list_response
1246 payload |= attribute type { "issue" }, issue_request
1247 payload |= attribute type { "issue_response"}, issue_response
1248 payload |= attribute type { "revoke" }, revoke_request
1249 payload |= attribute type { "revoke_response"}, revoke_response
1250 payload |= attribute type { "error_response"}, error_response
1252 list_request = empty
1253 list_response = class*
1255 class = element class {
1256 attribute class_name { class_name },
1257 attribute cert_url { cert_url },
1258 attribute resource_set_as { resource_set_as },
1259 attribute resource_set_ipv4 { resource_set_ip4 },
1260 attribute resource_set_ipv6 { resource_set_ip6 },
1261 attribute resource_set_notafter { xsd:dateTime },
1262 attribute suggested_sia_head { xsd:anyURI { maxLength="1024"
1263 pattern="rsync://.+"} }?,
1264 element certificate {
1265 attribute cert_url { cert_url },
1266 attribute req_resource_set_as { resource_set_as }?,
1267 attribute req_resource_set_ipv4 { resource_set_ip4 }?,
1268 attribute req_resource_set_ipv6 { resource_set_ip6 }?,
1269 base64_binary
1270 }*,
1271 element issuer { base64_binary }
1272 }
1274 issue_request = element request {
1275 attribute class_name { class_name },
1276 attribute req_resource_set_as { resource_set_as }?,
1277 attribute req_resource_set_ipv4 { resource_set_ip4 }?,
1278 attribute req_resource_set_ipv6 { resource_set_ip6 }?,
1279 base64_binary
1280 }
1281 issue_response = class
1283 revoke_request = revocation
1284 revoke_response = revocation
1286 revocation = element key {
1287 attribute class_name { class_name },
1288 attribute ski { ski }
1289 }
1291 error_response =
1292 element status { xsd:positiveInteger { maxInclusive="9999" } },
1293 element description { attribute xml:lang { xsd:language },
1294 xsd:string { maxLength="1024" } }*
1295 }
1297 4. Security Considerations
1299 This protocol supports the maintenance of Resource Certificates that
1300 the Issuer issues for a Subject in certifying resources that have
1301 been allocated or assigned by the Issuer to the Subject
1302 [ID.sidr-arch]. This protocol assumes that the Issuer and Subject
1303 are known to each other and have exchanged credentials so as to
1304 support the mutual recognition of the digital signatures used to sign
1305 the CMS messages. The mechanisms used to perform the associated
1306 credential exchange are not described in this specification.
1308 The protocol is a minimal query / response protocol, that imposes
1309 strict serialization on each query / response transaction, reducing
1310 the potential for the Subject and the Issuer to lose synchronization
1311 over the issued certificate state.
1313 The inner protocol elements explicitly reference the intended sender
1314 and receiver to present an Issuer or an Subject attempting to
1315 masquerade as another party within the secure channel.
1317 Validation of protocol objects (Section 3.1.2) requires that the CMS
1318 signing time value be greater than or equal to the time value passed
1319 in the previously valid protocol objects that were passed from the
1320 same originator to the same recipient. If a party inadvertently
1321 sends a valid message (protocol object) with a signing time in the
1322 future, then subsequent messages from the party in the same client /
1323 server context can use signing time values consistent with this
1324 validation constraint, such that the signing times contained in
1325 subsequent messages are greater than or equal to the signing time
1326 value of the previous valid message. (It is noted that it not a
1327 normative requirement that the signing time be precisely aligned to a
1328 time of day clock, thus permitting arbitrarily large clock skew
1329 values in the context of this protocol message exchange.) If the
1330 client and server wish to reset the signing time to a mutually agreed
1331 value then, as noted in Section 2, the interactions between the
1332 client and the server to achieve this outcome are not encompassed in
1333 this protocol.
1335 5. IANA Considerations
1337 IANA is requested to register the following media type:
1339 application/rpki-updown
1341 5.1. application/rpki-updown
1343 Type name: application
1344 Subtype name: rpki-updown
1345 Required parameters: None
1346 Optional parameters: None
1347 Encoding considerations: binary
1348 Security considerations: Carries an RPKI Provisioning Protocol
1349 Message, as defined in this document.
1350 Interoperability considerations: None
1351 Published specification: This document
1352 Applications that use this media type: HTTP [RFC5652]
1353 Additional information:
1354 Magic number(s): None
1355 File extension(s):
1356 Macintosh File Type Code(s):
1357 Person & email address to contact for further information: Geoff
1358 Huston
1359 Intended usage: COMMON
1360 Restrictions on usage: Only to be used as an RPKI Provisioning
1361 Protocol message object type, as defined in this document.
1362 Author: Geoff Huston
1363 Change controller: Geoff Huston
1365 6. Acknowledgements
1367 The authors would like to acknowledge the valued contributions from
1368 Russ Housley, Steve Kent, Randy Bush, George Michaelson, Robert
1369 Kisteleki, Tim Bruijnzeels and Carsten Bormann in the preparation of
1370 the protocol described in this document.
1372 7. References
1374 7.1. Normative References
1376 [ID.sidr-rpki-algs]
1377 Huston, G., "A Profile for Algorithms and Key Sizes for
1378 use in the Resource Public Key Infrastructure",
1379 draft-huston-sidr-rpki-algs-00.txt (work in progress),
1380 July 2009.
1382 [ISO.8601:2004]
1383 ISO, "ISO 8601:2004 Representation of dates and Times",
1384 2004.
1386 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1387 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
1388 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1390 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
1391 Request Syntax Specification Version 1.7", RFC 2986,
1392 November 2000.
1394 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
1395 Addresses and AS Identifiers", RFC 3779, June 2004.
1397 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
1398 Encodings", RFC 4648, October 2006.
1400 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1401 Housley, R., and W. Polk, "Internet X.509 Public Key
1402 Infrastructure Certificate and Certificate Revocation List
1403 (CRL) Profile", RFC 5280, May 2008.
1405 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)",
1406 RFC 5652, September 2009.
1408 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI
1409 Scheme", RFC 5781, February 2010.
1411 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
1412 Address Text Representation", RFC 5952, August 2010.
1414 [RFC6019] Housley, R., "BinaryTime: An Alternate Format for
1415 Representing Date and Time in ASN.1", RFC 6019,
1416 September 2010.
1418 [X.509-88]
1419 CCITT, "Recommendation X.509: The Directory -
1420 Authentication Framework", 1988.
1422 7.2. Informative References
1424 [ID.sidr-arch]
1425 Lepinski, M. and S. Kent, "An Infrastructure to Support
1426 Secure Internet Routing", draft-ietf-sidr-arch (work in
1427 progress), July 2009.
1429 [ID.sidr-res-certs]
1430 Huston, G., Michaelson, G., and R. Loomans, "A Profile for
1431 X.509 PKIX Resource Certificates", Work in progress:
1432 Internet Drafts draft-ietf-sidr-res-certs-16.txt,
1433 February 2009.
1435 Authors' Addresses
1437 Geoff Huston
1438 APNIC
1440 Email: gih@apnic.net
1441 URI: http://www.apnic.net
1443 Robert Loomans
1444 APNIC
1446 Email: robertl@apnic.net
1447 URI: http://www.apnic.net
1449 Byron Ellacott
1450 APNIC
1452 Email: bje@apnic.net
1453 URI: http://www.apnic.net
1455 Rob Austein
1456 Dragon Research Labs
1458 Email: sra@hactrn.net