A Protocol for Provisioning Resource Certificates
draft-ietf-sidr-rescerts-provisioning-01.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on December 20, 2008.

Abstract

This document defines a framework for certificate management interactions between a resource issuer ("Internet Registry" or "IR") and a resource recipient ("Internet Service Provider" or "ISP") through the specification of a protocol for interaction between the two parties. The protocol supports the transmission of requests from the ISP, and corresponding responses from the IR encompassing the actions of certificate issuance, certificate revocation and certificate status information reports. This protocol is intended to be limited to the application of resource certificate management and is not intended to be used as part of a more general certificate management framework.

Table of Contents

1.  Introduction
    1.1.  Terminology
2.  Scope
3.  Protocol Specification
    3.1.  CMS Profile
        3.1.1.  SignedData Content Type
        3.1.2.  ASN.1
    3.2.  Common Message format
    3.3.  Control - Resource Class Query
        3.3.1.  Resource Class List Query
        3.3.2.  Resource Class List Response
    3.4.  CA - Certificate Issuance
        3.4.1.  Certificate Issuance Request
        3.4.2.  Certificate Issuance Response
    3.5.  Certificate Revocation
        3.5.1.  Certificate Revocation Request
        3.5.2.  Certificate Revocation Response
    3.6.  Request-Not-Performed Response
4.  XML Schema
5.  Security Considerations
6.  IANA Considerations
7.  Acknowledgements
8.  Normative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

This document defines a framework for certificate management interactions between a resource issuer ("Internet Registry" or "IR") and a resource recipient ("Internet Service Provider" or "ISP") through the specification of a protocol for interaction between the two parties. The protocol supports the transmission of requests from the ISP, and corresponding responses from the IR encompassing the actions of certificate issuance, certificate revocation and certificate status information reports. This protocol is intended to be limited to the application of resource certificate management and is not intended to be used as part of a more general certificate management framework.

1.1.  Terminology

It is assumed that the reader is familiar with the terms and concepts described in "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC3280] (Housley, R., Polk, W., Ford, W., and D. Solo, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” April 2002.), "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779] (Lynn, C., Kent, S., and K. Seo, “X.509 Extensions for IP Addresses and AS Identifiers,” June 2004.), "Internet Protocol" [RFC0791] (Postel, J., “Internet Protocol,” September 1981.), "Internet Protocol Version 6 (IPv6) Addressing Architecture" [RFC4291] (Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture,” February 2006.), "Internet Registry IP Allocation Guidelines" [RFC2050] (Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and J. Postel, “INTERNET REGISTRY IP ALLOCATION GUIDELINES,” November 1996.), and related regional Internet registry address management policy documents.

Additional terms used in this document are:

"IR"

an abbreviation of "Internet Registry", using in the context of this document as an entity undertaking the role of resource issuer. An IR is a Certificate Authority, and can issue Resource Certificates.

"ISP"

an abbreviation of "Internet Service Provider", using in the context of this document as an entity undertaking the role of resource recipient who is the subject of a Resource Certificate. An ISP may be issued with a CA-enabled certificate, allowing the entity to also assume the role of an IR.

"resource class"

a resource class refers to a collection of resources that can be certified in a single resource certificate by an issuer.

"server"

in the context of this client/server protocol specification, the IR assumes the role of the "server."

"client"

in the context of this client/server protocol specification, the ISP assumes the role of the "client."

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

2.  Scope

This Resource PKI (RPKI) certificate provisioning protocol defines a basic set of interactions that allow an ISP to request certificate issuance, revocation and status information from the IR, and for a IR to maintain an issued certificate set that is aligned to the allocation records relating to each ISP. The IR's resource allocation database, is the authoritative source of what resource allocations the IR may certify for an ISP.

A resource recipient (ISP) may also undertake the role of a resource issuer (IR), such as in the case of a Local Internet Registry (LIR).

This protocol specification does not encompass:

• signing of objects with keys that are certified by resource certificates, nor the issuance of end-entity certificates.
  
  
• the specification of interaction with the IR's resource allocation database, nor the specification of a protocol to manage the publication repository.
  
  
• the interactions between client and server that establish identities, exchange the keys used in the protection of the communications channel between client and server, and the exchange of the certificates and validation PKI contexts used in the Cryptographic Message Syntax message exchange.
  
  

3.  Protocol Specification

This RPKI certificate provisioning protocol is expressed as a simple request/response interaction, where the client passes a request to the server, and the server generates a corresponding response.

The protocol is implemented as an exchange of messages.

Messages are passed over an HTTPS [RFC2818] (Rescorla, E., “HTTP Over TLS,” May 2000.) transport connection that safeguards against interception and replay attacks. The HTTPS session uses mutually authenticated TLS. The TLS keys and associated certificates have been previously established between the two entities. The HTTPS connection will use 2 way (mutual) identification. A message exchange commences with the client initiating an HTTP POST with content type of "application/x-rpki", with the message object as the body. The server's response will similarly be the body of the response with a content type of "application/x-rpki".

The content of the POST, and the server's response, will be a "well-formed" Cryptographic Message Syntax (CMS) [RFC3852] (Housley, R., “Cryptographic Message Syntax (CMS),” July 2004.) object, encoded using the Distinguished Encoding Rules for ASN.1 (DER) [X.509‑88] (CCITT, “Recommendation X.509: The Directory - Authentication Framework,” 1988.), formatted in accordance with the CMS profile as specified in the following section. CMS is used as the signing format to sign the message object. The public part of the signing key and the associated certificate that is used to validate the signature has been previously established between the two entities through mechanisms not defined in this protocol specification. The CMS keys and certificates MAY be the same as those used for TLS.

The protocol's request / response interaction is assumed to be reliable, in that all requests will generate a matching response. The protocol requires sequential operation, where the server MUST NOT accept a client's request unless it has generated and sent a response to the client's previous request. Attempts by the client to initiate multiple requests in parallel MUST be detected by the server and rejected with an error response.

3.1.  CMS Profile

The format of the CMS object is:

      ContentInfo ::= SEQUENCE {
        contentType ContentType,
        content [0] EXPLICIT ANY DEFINED BY contentType }

      ContentType ::= OBJECT IDENTIFIER

The protocol objects are all instances of CMS signed-data objects, where the ContentType used is the signed-data type of id-data, namely id-signedData, OID = 1.2.840.113549.1.7.2.

3.1.1.  SignedData Content Type

According to [RFC3852] (Housley, R., “Cryptographic Message Syntax (CMS),” July 2004.), signed-data content types shall have the ASN.1 type SignedData:

      SignedData ::= SEQUENCE {
        version CMSVersion,
        digestAlgorithms DigestAlgorithmIdentifiers,
        encapContentInfo EncapsulatedContentInfo,
        certificates [0] IMPLICIT CertificateSet OPTIONAL,
        crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
        signerInfos SignerInfos }

      DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

      SignerInfos ::= SET OF SignerInfo

3.1.1.1.  version

The version is the syntax version number. It MUST be 3, corresponding to the signerInfo structure having version number 3.

3.1.1.2.  digestAlgorithms

The digestAlgorithms set MUST include only SHA-256, the OID for which is 2.16.840.1.101.3.4.2.1 [RFC4055] (Schaad, J., Kaliski, B., and R. Housley, “Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” June 2005.). It MUST NOT contain any other algorithms.

3.1.1.3.  encapContentInfo

encapContentInfo is the signed content, consisting of a content type identifier and the content itself.

     EncapsulatedContentInfo ::= SEQUENCE {
       eContentType ContentType,
       eContent [0] EXPLICIT OCTET STRING OPTIONAL }

     ContentType ::= OBJECT IDENTIFIER

3.1.1.3.1.  eContentType

The eContentType for the RPKI Protocol Mesage object is defined as id-ct-xml, and has the numerical value of 1.2.840.113549.1.9.16.1.28.

      id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
                                rsadsi(113549) pkcs(1) pkcs9(9) 16 }

      id-ct OBJECT IDENTIFIER ::= { id-smime 1 }

      id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 }

3.1.1.3.2.  eContent

The content of a RPKI XML Protocol Object consists of a single protocol message, structured according to a define XML schema, as defined in subsequent sections of this document. The eContent field of the CMS object is formally defined using ASN.1 as:

          id-ct-xml ::= OCTET STRING -- XML encoded message

3.1.1.4.  certificates

The certificates field MAY be present.

If present, this field MUST contain the EE certificate of the key pair whose private key value was used to sign the CMS. This MUST NOT be an RPKI certificate, and SHOULD be a certificate that is recognised to attest to the identity of the party that created the CMS object.

If present, this field MAY contain other certificates that a relying party may use to validate the digital signature of the CMS object.

3.1.1.5.  crls

This field MUST be present if the certificates field is present, and MUST be omitted otherwise. The contents of the field are as specified in [RFC3852] (Housley, R., “Cryptographic Message Syntax (CMS),” July 2004.).

3.1.1.6.  signerInfo

SignerInfo is defined under CMS as:

      SignerInfo ::= SEQUENCE {
        version CMSVersion,
        sid SignerIdentifier,
        digestAlgorithm DigestAlgorithmIdentifier,
        signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
        signatureAlgorithm SignatureAlgorithmIdentifier,
        signature SignatureValue,
        unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

3.1.1.6.1.  version

The version number MUST be 3, corresponding with the choice of SubjectKeyIdentifier for the sid.

3.1.1.6.2.  sid

The sid is defined as:

      SignerIdentifier ::= CHOICE {
        issuerAndSerialNumber IssuerAndSerialNumber,
        subjectKeyIdentifier [0] SubjectKeyIdentifier }

In this profile, the sid MUST be a SubjectKeyIdentifier.

3.1.1.6.3.  digestAlgorithm

The digestAlgorithm MUST be SHA-256, the OID for which is 2.16.840.1.101.3.4.2.1. [RFC4055] (Schaad, J., Kaliski, B., and R. Housley, “Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” June 2005.)

3.1.1.6.4.  signedAttrs

Signed Attributes are defined as:

      SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

      UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute

      Attribute ::= SEQUENCE {
        attrType OBJECT IDENTIFIER,
        attrValues SET OF AttributeValue }

      AttributeValue ::= ANY

The signer MUST digitally sign a collection of attributes along with the content payload. Each attribute in the collection MUST be DER-encoded. The syntax for attributes is defined in [X.501] (CCITT, “Recommendation X.501: The Directory - Models,” 1988.), and the X.500 Directory provides a rich attribute syntax. A very simple subset of this syntax is used extensively in [RFC3852] (Housley, R., “Cryptographic Message Syntax (CMS),” July 2004.), where ATTRIBUTE.Type and ATTRIBUTE.id are the only parts of the ATTRIBUTE class that are employed.

Each of the attributes used with this CMS profile has a single attribute value. Even though the syntax is defined as a SET OF AttributeValue, there MUST be exactly one instance of AttributeValue present.

The SignedAttributes syntax within signerInfo is defined as a SET OF Attribute. The SignedAttributes MUST include only one instance of any particular attribute.

The signer MUST include the content-type and message-digest attributes. The signer MAY also include the signing-time signed attribute, the binary-signing-time signed attribute, or both signed attributes. Other signed attributes that are deemed appropriate MAY also be included. The intent is to allow additional signed attributes to be included if a future need is identified. This does not cause an interoperability concern because unrecognized signed attributes are ignored at verification.

3.1.1.6.4.1.  Content-Type Attribute

      id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }

      ContentType ::= OBJECT IDENTIFIER

A content-type attribute is required to contain the same object identifier as the content type contained in the EncapsulatedContentInfo. The signer MUST include a content-type attribute containing the appropriate content type. Section 11.1 of [RFC3852] (Housley, R., “Cryptographic Message Syntax (CMS),” July 2004.) defines the content-type attribute.

3.1.1.6.4.2.  Message-Digest Attribute

      id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }

      MessageDigest ::= OCTET STRING

The signer MUST include a message-digest attribute, having as its value the output of a one-way hash function computed on the content that is being signed. Section 11.2 of [RFC3852] (Housley, R., “Cryptographic Message Syntax (CMS),” July 2004.) defines the message-digest attribute.

3.1.1.6.4.3.  Signing-Time Attribute

      id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }

      SigningTime ::= Time

      Time ::= CHOICE {
        utcTime UTCTime,
        generalizedTime GeneralizedTime }

The signing-time attribute MUST be present.

The signing-time attribute specifies the time, based on the local system clock, at which the digital signature was applied to the content. If both signing-time and binary-signing-time are present, the time that is represented in both attributes MUST represent the same time value. Section 11.3 of [RFC3852] (Housley, R., “Cryptographic Message Syntax (CMS),” July 2004.) defines the content-type attribute.

3.1.1.6.4.4.  Binary-Signing-Time Attribute

      id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1)
          member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
          smime(16) aa(2) 46 }

      BinarySigningTime ::= BinaryTime

      BinaryTime ::= INTEGER (0..MAX)

The signer MAY include a binary-signing-time attribute, specifying the time at which the digital signature was applied to the content. If both signing-time and binary-signing-time are present, the time that is represented in both attributes MUST represent the same time value. The binary-signing-time attribute is defined in [RFC4049] (Housley, R., “BinaryTime: An Alternate Format for Representing Date and Time in ASN.1,” April 2005.).

3.1.1.6.5.  signatureAlgorithm

The signatureAlgorithm MUST be RSA (rsaEncryption), the OID for which is 1.2.840.113549.1.1.1.

3.1.1.6.6.  signature

The signature value is defined as:

          SignatureValue ::= OCTET STRING

The signature characteristics are defined by the digest and signature algorithms.

3.1.1.6.7.  unsignedAttrs

unsignedAttrs MUST be omitted.

3.1.2.  ASN.1

The following is the ASN.1 specification of the CMS signed object used by the RPKI provisioning protocol.

      ContentInfo ::= SEQUENCE {
        contentType ContentType,
        content [0] EXPLICIT ANY DEFINED BY contentType }

      ContentType ::= OBJECT IDENTIFIER

      id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
                                rsadsi(113549) pkcs(1) pkcs9(9) 16 }

      id-ct OBJECT IDENTIFIER ::= { id-smime 1 }

      id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 }

      id-ct-xml ::= OCTET STRING -- XML encoded message

      id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
                         us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }

      SignedData ::= SEQUENCE {
        version CMSVersion,
        digestAlgorithms DigestAlgorithmIdentifiers,
        encapContentInfo EncapsulatedContentInfo,
        certificates [0] IMPLICIT CertificateSet OPTIONAL,
        crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
        signerInfos SignerInfos }

      DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

      SignerInfos ::= SET OF SignerInfo

      SignerInfo ::= SEQUENCE {
        version CMSVersion,
        sid SignerIdentifier,
        digestAlgorithm DigestAlgorithmIdentifier,
        signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
        signatureAlgorithm SignatureAlgorithmIdentifier,
        signature SignatureValue,
        unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

      SignerIdentifier ::= CHOICE {
        issuerAndSerialNumber IssuerAndSerialNumber,
        subjectKeyIdentifier [0] SubjectKeyIdentifier }

      SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

      UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute

      Attribute ::= SEQUENCE {
        attrType OBJECT IDENTIFIER,
        attrValues SET OF AttributeValue }

      AttributeValue ::= ANY

      SignatureValue ::= OCTET STRING

      id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }

      ContentType ::= OBJECT IDENTIFIER

      id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }

      MessageDigest ::= OCTET STRING

      id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }

      SigningTime ::= Time

      Time ::= CHOICE {
        utcTime UTCTime,
        generalizedTime GeneralizedTime }

      id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1)
          member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
          smime(16) aa(2) 46 }

      BinarySigningTime ::= BinaryTime

      BinaryTime ::= INTEGER (0..MAX)

3.2.  Common Message format

The XML template for all messages is as follows:

---------------------------------------------------------------

<?xml version="1.0" encoding="UTF-8"?>
<message xmlns="http://www.apnic.net/specs/rescerts/up-down/"
         version="1"
         sender="sender name"
         recipient = "recipient name"
         type="message type">

[payload]

</message>

---------------------------------------------------------------

version:

the value of this attribute is the version of this protocol. This document describes version 1.

sender:

the value of this attribute is the agreed name of the message sender, as determined between the client and the server by prior arrangement.

recipient:

the value of this attribute is the agreed name of the message recipient, as determined between the client and the server by prior arrangement.

type:

the possible values of this attribute are "list", "list_response", "issue", "issue_response", "revoke", "revoke_response", and "error_response".

Conforming parsers MUST reject any document with a version number they do not understand, or with any elements or attributes they do not understand. Servers must generate an error response when receiving such a request. Clients should generate an operator alert error when receiving such a response.

A message in this protocol is a digitally signed object that makes use of CMS [RFC3852] (Housley, R., “Cryptographic Message Syntax (CMS),” July 2004.), and is encoded as DER. It uses the signed-data object contentType OID: 1.2.840.113549.1.7.2. The attribute "id-signingTime" (contentType OID: 1.2.840.113549.1.9.5) MUST be present in the CMS object.

The encapsulated content of the CMS wrapping is an XML document. The remainder of this protocol specification omits this CMS wrapper and only discusses the XML document.

Messages are checked using the following tests:

1. Check the integrity of the HTTPS message and validate the TLA certificate using the PKI that has been determined by prior arrangement between client and server.
   
   
2. Check that the CMS is well-formed.
   
   
3. Check that the XML is well-formed.
   
   
4. Check that the XML sender and recipient attributes reference a known client and this server's system respectively.
   
   
5. Verify the digital signature using the public key provided in the certificate carried in the CMS wrapper.
   
   
6. Validate the CMS-provided certificate using the PKI that has been determined by prior arrangement between client and server.
   
   
7. Check that the value of the version number of the message is 1.

The checks should generally be applied in the order specified here.

Any errors encountered while checking items 1 through 6 would cause the server to generate an "HTTP 400 Bad Data" response to the HTTPS POST operation. An error in step 7 would cause the server to generate a "Request-Not-Performed" error response.

3.3.  Control - Resource Class Query

3.3.1.  Resource Class List Query

The value of the message "type" message attribute for this query is:

type="list"

---------------------------------------------------------------

Payload:

[No message payload is defined for this query]

---------------------------------------------------------------

3.3.2.  Resource Class List Response

The value of the message "type" element for this response is:

type="list_response"

---------------------------------------------------------------

Payload:

 <class class_name="class name"
     cert_url="url"
     resource_set_as="as resource set"
     resource_set_ipv4="ipv4 resource set"
     resource_set_ipv6="ipv6 resource set"
     resource_set_notafter="datetime"
     suggested_sia_head="[directory uri]" >
     <certificate cert_url="url"
         req_resource_set_as="as resource set"
         req_resource_set_ipv4="ipv4 resource set"
         req_resource_set_ipv6="ipv6 resource set" >
     [certificate]
     </certificate>

     ...

     (repeated for each current certificate where the client
      is the certificate's subject)

     <issuer>[issuer's certificate]</issuer>
     </class>

 ...

 (repeated for each of the issuer's resource class where the
  client has been allocated resources)


---------------------------------------------------------------

Where the client has been allocated resources from multiple resource classes, then the response will contain multiple class elements, corresponding to the complete set of the issuer's resource classes where the client holds allocated resources. Those issuer's resource classes where the client holds no allocated resources will not be included in the response.

Where the issuer has issued multiple certificates in a resource class signed with different keys (as may occur during a staged issuer-key rollover), only the most recent certificate issued with the currently "active" issuer's key will be listed in the response.

Each "class" element describes a set of resources that are certified within the scope of a single certificate, referring to a single resource class with a common validation path.

class_name:

the value of this attribute is the issuer-assigned name of the issuer's Resource Class.

cert_url:

in the context of a class element, the value of this attribute is a pointer to the issuer's CA certificate (i.e. a reference to the immediate superior certificate, being the CA-enabled certificate where the issuer is the certificate's subject). Its value is a comma-separated list of URIs, of which at least one MUST be an RSYNC URI. Any comma values within a URI MUST be escaped ("%2C"). The ordering of the list may be interpreted by the client as a relative preference for access methods as expressed by the publisher of this certificate.

resource_set_as:

in the context of a class element, the value of this attribute is the set of AS numbers and AS number ranges that the issuer has allocated to the client within the scope of this resource class, presented in ASCII as a comma-separated list. The list elements are decimal integer values and ranges of decimal integers specified by the low and high value of the range with a hyphen delimiter, using the canonical order as described in [RFC3779] (Lynn, C., Kent, S., and K. Seo, “X.509 Extensions for IP Addresses and AS Identifiers,” June 2004.), without leading zeros, and with no white space or punctuation other than the comma and the hyphen range designator (e.g.: resource_set_as="123,456-789,123456"). If there are no AS numbers in this Resource Class the empty set will be represented by a null string value ("") for this attribute.

resource_set_ipv4:

in the context of a class element, the value of this attribute is the set of IPv4 addresses that the issuer has allocated to the client within the scope of this resource class. The value is presented in ASCII as a comma-separated list of elements. Each element is either an address prefix using the notation of <dotted quad>/mask length, or a range specified as low and high range values in dotted quad notation with a hyphen delimiter. The list is presented in canonical order, as described in [RFC3779] (Lynn, C., Kent, S., and K. Seo, “X.509 Extensions for IP Addresses and AS Identifiers,” June 2004.). The dotted quad notation is without leading zeros, and the list contains no white space or punctuation other than the period, forward slash, hyphen and comma. (e.g. resource_set_ipv4="192.0.2.0/26,192.0.2.66-192.0.2.76") If there are no IPv4 addresses in this resource class the empty set will be represented by a null string value ("") for this attribute.

resource_set_ipv6:

in the context of a class element, the value of this attribute is the set of IPv6 addresses that the issuer has allocated to the client within the scope of this resource class. The value is presented in ASCII as a comma-separated list of elements. Each element is either an address prefix using the notation of <hex nibble sequence>/mask length, or a range specified as low and high range values in hex nibble notation with a hyphen delimiter. Trailing zero nibbles are truncated and represented by '::'. The list is presented in canonical order, as described in [RFC3779] (Lynn, C., Kent, S., and K. Seo, “X.509 Extensions for IP Addresses and AS Identifiers,” June 2004.). The hex nibble sequence notation is without leading zeros, and the list contains no white space or punctuation other than the colon, forward slash, hyphen and comma (e.g. resource_set_ipv6="2001:0DB8::/48,2001:0DB8:002::-2001:0DB8:005::"). The XML Schema data type is http://www.w3.org/TR/xmlschema-2/#hexBinary and value is case insensitive, with the canonical form being upper case. If there are no IPv6 addresses in this resource class the empty set will be represented by a null string value ("") for this attribute.

resource_set_notafter:

The value of this attribute specified the date/time that would be set in the Validity notAfter field in any new certificate issued for this particular client within the scope of this resource class, should the client request a new certificate. The time format used for the value of this attribute is specified as ISO 8601 [ISO.8601:2004] (ISO, “ISO 8601:2004 Representation of dates and Times,” 2004.), and MUST use UTC time (i.e. YYYY-MM-DDThh:mm:ssZ, e.g. 2007-11-29T04:40:00Z). If the client's certificate has a validity notAfter time that is different to this this time then the client SHOULD request a new certificate to be issued for this resource class.

suggested_sia_head:

(OPTIONAL)If this field is present then it indicates a publication namespace which the server has made available to the client to use for its own collection of published products. Presence of this field does not mean that the client has permission from the repository operator to lodge under this URI, only that the client has permission from the server to lodge under this URI.

[issuer's certificate]

value is the Base64 encoding of the DER-encoded issuer's CA certificate (the CA-enabled certificate where the issuer is the certificate's subject).

Each certificate element describes the most recently issued current certificate where the certificate's subject refers to the client for each active client key pair. A "current" certificate is a non-expired, non-revoked certificate. If no current certificate has been issued, then no certificate element will be included in the response.

cert_url:

in the context of a certificate element, this is a pointer to the location where the certificate issuer has published this certificate. This field is the issuer's suggestion for the AIA field for the subject to use in subordinate certificates that are issued by the subject. According to the Resource Certificate Profile [insert ref here] the AIA field is a non-empty (contains a minimum of 1 element) list of URI's, one of which MUST be an RSYNC URI. The order of URI's in the AIA field may be interpreted as the publisher's relative preference for access methods for this certificate. The cert_url conforms to this AIA specification. Its value is a comma-separated list of URIs, one of which MUST be an RSYNC URI. Any comma values within a URI MUST be escaped ("%2C").

req_resource_set_as:

the set of AS numbers that were specified in the corresponding original certificate request that defined the maximal requested span of the certified AS number set, following the syntax described above. If this attribute was present in the certificate request, then the attribute MUST be present in this response, otherwise it MUST NOT be present.

req_resource_set_ipv4:

the set of IPv4 addresses that were specified in the corresponding original certificate request that defined the maximal requested span of the certified IPv4 address set, following the syntax described above. If this attribute was present in the certificate request, then the attribute MUST be present in this response, otherwise it MUST NOT be present.

req_resource_set_ipv6:

the set of IPv6 addresses that were specified in the corresponding original certificate request that defined the maximal requested span of the certified IPv6 address set, following the syntax described above. If this attribute was present in the certificate request, then the attribute MUST be present in this response, otherwise it MUST NOT be present.

[certificate]

value is the Base64 encoding of the DER-encoded certificate.

3.4.  CA - Certificate Issuance

3.4.1.  Certificate Issuance Request

The value of the message "type" element for this request is:

type="issue"

---------------------------------------------------------------

Payload:

<request
           class_name="class name"
           req_resource_set_as="as resource set"
           req_resource_set_ipv4="ipv4 resource set"
           req_resource_set_ipv6="ipv6 resource set">
           [Certificate request]
           </request>

---------------------------------------------------------------

The client must use different key pairs for each distinct resource class.

If any of the req_resource_set attributes are specified in the request, then any missing req_resource_set attributes are to be interpreted as specifying the complete set of the corresponding resource type that match the client's current resource allocation. If the value of any req_resource_set attributes is the null value (""), then this indicates that no resources of that resource type are to be certified with this request.

The requested resource set values are held as a local record by the issuer against the resource class and the client's public key. Any subsequent Certificate Issuance Requests that specify the same Resource Class and the same client's public key will (re)set the issuer's local record of the requested resource sets to the most recently specified values.

class_name:

value is the server's identifier of a Resource Class.

req_resource_set_as:

(OPTIONAL)the set of AS numbers that define the maximal requested span of the certified AS number set, formatted as per the resource_set_as attribute of the Resource Class List Response.

req_resource_set_ipv4:

(OPTIONAL)the set of IPv4 addresses that define the maximal requested span of the certified IPv4 address set, formatted as per the resource_set_ipv4 attribute of the Resource Class List Response.

req_resource_set_ipv6:

(OPTIONAL)the set of IPv6 addresses that define the maximal requested span of the certified IPv6 address set, formatted as per the resource_set_ipv6 attribute of the Resource Class List Response.

[Certificate request]

value is the certificate request. This is a Base-64 encoded DER version of a request formatted using PKCS#10.

3.4.2.  Certificate Issuance Response

The value of the message "type" element for this response is:

type="issue_response"

---------------------------------------------------------------

Payload:


 <class class_name="class name"
        cert_url="url"
        resource_set_as="as resource set"
        resource_set_ipv4="ipv4 resource set"
        resource_set_ipv6="ipv6 resource set" >
         <certificate cert_url="url"
               req_resource_set_as="as resource set"
               req_resource_set_ipv4="ipv4 resource set"
               req_resource_set_ipv6="ipv6 resource set" >
         [certificate]
         </certificate>
         <issuer>[issuer's certificate]</issuer>
       </class>

---------------------------------------------------------------

If the certificate issuer determines that the issued certificate would be identical in all respects to the most recently issued certificate for this client, other than the certificate's serial number, were the certificate to be issued, the issuer may choose to respond with the most recently issued certificate and not issue a new certificate for this request.

The definition of the attributes and syntax of the values is the same as the resource class list response, but the response only references the (single) named resource class, and the (single) certificate issued against the client's public key as provided in the corresponding certificate request.

3.5.  Certificate Revocation

3.5.1.  Certificate Revocation Request

The value of the message "type" element for this request is:

type="revoke"

---------------------------------------------------------------

Payload:


<key class_name="class name"
     ski="encoded hash of the subject public key]" />


---------------------------------------------------------------

This command 'retires' a client's key pair by requesting the issuer to revoke all certificates for this client that contain the matching public key, within the scope of a named Resource Class. Individual issued certificates cannot be revoked within the scope of this protocol.

This command directs the issuer to immediately mark all issued valid certificates issued by this issuer within the named Resource Class with this client's SKI value to be marked as revoked, causing the issued certificates to be withdrawn from the publication repository and to be listed in the server's subsequent CRLs within this Resource Class.

class_name:

value is the issuer-assigned name of the issuer's Resource Class.

ski:

value is the encoded hash of the client's public key that is to be revoked. The algorithm for the encoding is to generate the 160-bit SHA-1 hash of the client's public key, as defined in method (1) of section 4.2.1.2 of [RFC3280] (Housley, R., Polk, W., Ford, W., and D. Solo, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” April 2002.), and encode this value using the Base 64 encoding with URL and Filename Safe Alphabet, as defined in section 5 of [RFC4648] (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” October 2006.).

3.5.2.  Certificate Revocation Response

The value of the message "type" element for this response is:

type="revoke_response"

---------------------------------------------------------------

Payload:


<key class_name="class name"
     ski="encoded hash of the subject public key" />

---------------------------------------------------------------

class_name:

value is the issuer-assigned name of the server's Resource Class.

ski:

value is the encoded hash of the client's public key that is to be revoked. The algorithm for the encoding is to generate the 160-bit SHA-1 hash of the client's public key, as defined in method (1) of section 4.2.1.2 of [RFC3280] (Housley, R., Polk, W., Ford, W., and D. Solo, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” April 2002.), and encode this value using the Base 64 encoding with URL and Filename Safe Alphabet, as defined in section 5 of [RFC4648] (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” October 2006.).

3.6.  Request-Not-Performed Response

The value of the message "type" element for this response is:

type="error_response"

---------------------------------------------------------------

Payload:


<status>[Code]</status>
<description xml:lang="en-US">[Readable text]</description>

---------------------------------------------------------------

All states where an error response if to be generated, either due to detected errors or inconsistencies in the content of the request or server-side states that prevent the request being performed, generate a Request-Not-Performed response.

description:

value is a text field. This element MAY be present. It's value has no defined meaning within the scope of this protocol, and implementations may assume that some form of human-readable text may be used here. If the HTTP request that triggered this error response includes an Accept-Language header as defined in section 14.4 of the HTTP/1.1 specification [insert reference to RFC2616] then the server will make a best effort to include a second description element using the highest ranked preferred language of the client. The en-US description will always be included if the element is present.

The error code set is:

   Code Value    Description
   1101          already processing request
   1102          version number error
   1103          unrecognised request type
   1201          request - no such resource class
   1202          request - no resources allocated in resource class
   1203          request - badly formed certificate request
   1301          revoke - no such resource class
   1302          revoke - no such key 2000+ Server Error
   2001          Internal Server Error - Request not performed

4.  XML Schema

The following is a RelaxNG compact form schema describing the IR-ISP Protocol, version 1.

default namespace = "http://www.apnic.net/specs/rescerts/up-down/"

  grammar {
    start = element message {
      attribute version { xsd:positiveInteger { maxInclusive="1" } },
      attribute sender { xsd:token { maxLength="1024" } },
      attribute recipient { xsd:token { maxLength="1024" } },
      payload
    }

    payload |= attribute type { "list" }, list_request
    payload |= attribute type { "list_response"}, list_response
    payload |= attribute type { "issue" }, issue_request
    payload |= attribute type { "issue_response"}, issue_response
    payload |= attribute type { "revoke" }, revoke_request
    payload |= attribute type { "revoke_response"}, revoke_response
    payload |= attribute type { "error_response"}, error_response

    list_request = empty
    list_response = class*

    class = element class {
      attribute class_name { xsd:token { maxLength="1024" } },
      attribute cert_url { xsd:string { maxLength="4096" } },
      attribute resource_set_as { xsd:string { maxLength="512000"
        pattern="[\-,0-9]*" } },
      attribute resource_set_ipv4 { xsd:string { maxLength="512000"
        pattern="[\-,/.0-9]*" } },
      attribute resource_set_ipv6 { xsd:string { maxLength="512000"
        pattern="[\-,/:0-9a-fA-F]*" } },
      attribute resource_set_notafter { xsd:dateTime },
      attribute suggested_sia_head { xsd:anyURI { maxLength="1024"
        pattern="rsync://.+"} }?,
      element certificate {
        attribute cert_url { xsd:string { maxLength="4096" } },
        attribute req_resource_set_as { xsd:string {
          maxLength="512000" pattern="[\-,0-9]*" } }?,
        attribute req_resource_set_ipv4 { xsd:string {
          maxLength="512000" pattern="[\-,/.0-9]*" } }?,
        attribute req_resource_set_ipv6 { xsd:string {
          maxLength="512000" pattern="[\-,/:0-9a-fA-F]*" } }?,
        xsd:base64Binary { maxLength="512000" }
      }*,
      element issuer { xsd:base64Binary { maxLength="512000" } }
    }

    issue_request = element request {
      attribute class_name { xsd:token { maxLength="1024" } },
      attribute req_resource_set_as { xsd:string {
        maxLength="512000" pattern="[\-,0-9]*" } }?,
      attribute req_resource_set_ipv4 { xsd:string {
        maxLength="512000" pattern="[\-,/.0-9]*" } }?,
      attribute req_resource_set_ipv6 { xsd:string {
        maxLength="512000" pattern="[\-,/:0-9a-fA-F]*" } }?,
      xsd:base64Binary { maxLength="512000"
      }
    }
    issue_response = class

    revoke_request = revocation

    revoke_response =
      revocation

    revocation = element key { attribute class_name { xsd:token {
      maxLength="1024" } }, attribute ski {
        xsd:token { maxLength="1024" } }
      }

    error_response =
      element status { xsd:positiveInteger {
        maxInclusive="999999999999999" }
      },
      element description { attribute xml:lang { xsd:language },
        xsd:string { maxLength="1024" }
      }?
  }

5.  Security Considerations

[To be defined]

6.  IANA Considerations

[Note to IANA, to be removed prior to publication: there are no IANA considerations stated in this version of the document.]

7.  Acknowledgements

The authors would like to acknowledge the valued contributions from Randy Bush, George Michaelson, and Robert Kisteleki in the preparation of the protocol described in this document.

8. Normative References

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.