SIDR G. Michaelson Internet-Draft APNIC Intended status: Standards Track S. Kent Expires: August 31, 2009 BBN G. Huston APNIC February 27, 2009 A Profile for Trust Anchor Material for the Resource Certificate PKI draft-ietf-sidr-ta-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 August 31, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Michaelson, et al. Expires August 31, 2009 [Page 1] Internet-Draft Resource Certificate TAs February 2009 Abstract This document defines a standard profile for the publication of Trust Anchor material for the Resource Certificate Public Key Infrastructure. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Trust Anchors for Resource Certificates . . . . . . . . . . . 4 3. Publication of Trust Anchor Material . . . . . . . . . . . . . 6 4. Cryptographic Message Syntax Profile for RPKI Trust Anchor Material . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Signed-Data ContentType . . . . . . . . . . . . . . . . . 9 4.1.1. encapContentInfo . . . . . . . . . . . . . . . . . . . 9 4.1.2. signerInfos . . . . . . . . . . . . . . . . . . . . . 10 4.2. RPKI Trust Anchor Object Validation . . . . . . . . . . . 13 5. Relying Party use of Trust Anchor Material . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Michaelson, et al. Expires August 31, 2009 [Page 2] Internet-Draft Resource Certificate TAs February 2009 1. Introduction This document defines a standard profile for the publication of Trust Anchor (TA) material for the Resource Certificate Public Key Infrastructure [ID.sidr-arch]. The format may be used to distribute trust anchor material using a mix of out-of-band and online means. Procedures used by relying parties (RPs) to verify RPKI signed objects SHOULD support this format to facilitate interoperability between creators of TA material and RPs. In the context of the public Internet, and the use of public number resources within this context, it is intended that Resource Certificates are used in a manner that is explicitly aligned with the public number resource distribution function. This corresponds to a hierarchical PKI structure, as described in section 1.5.1 of [RFC4158], where there is a unique certification path between a certification authority operating at an apex of a resource distribution hierarchy and any RPKI certificate. Validation of a Resource Certificate in a PKI is effected by establishing a validated certificate chain from a certificate issued by a trust anchor certification authority to the certificate being validated [RFC4158]. Because Resource Certificates contain [RFC3779] IP number resource extensions, certificate validation requires that each subject's resources are fully encompassed by those of the issuer at each step in the certificate chain. Certificate path validation in this context corresponds to validation of an associated set of assignment or allocation actions of IP number resources. The constraints imposed by the RFC 3779 extensions are applied to the entire certificate chain, starting with a TA. Thus it is potentially difficult for a relying party to manage trust anchors locally in a fashion that incorporates certificates by well known entities in the RPKI and accommodates certificates that describe private IPv4 address space, private use AS numbers, and IPv6 ULA prefixes. To address this problem, this document defines a compound TA model, in which the one portion of the TA is not an RPKI certificate, and thus need not meet the requirements imposed by RFC 3779. This document describes a data structure for representing Trust Anchors for use in the RPKI. The structure is designed to enable Relying Parties (RPs) to acquire and locally manage trust anchors in a fashion that preserves the resource subset constraints imposed by the use the RFC 3779 extensions. Michaelson, et al. Expires August 31, 2009 [Page 3] Internet-Draft Resource Certificate TAs February 2009 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" [RFC5280], "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779], and "Internet X.509 Public Key Infrastructure: Certification Path Building" [RFC4158]. 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. Trust Anchors for Resource Certificates This document does not nominate any organizations as default trust anchors for the RPKI. The data structures and procedures described here are capable of accommodating a variety of trust anchor arrangements, involving entities such as IANA, the RIRs, NIRs, LIRs, etc., and involving various forms of off-line and on-line two-tier models for trust anchor management. The constraints imposed by use of RFC 3779 extensions imply that a unique path exists between any RPKI certificate and a TA and there are no loops. It is common to represent a trust anchor as a long-lived, self-signed certificate, although PKI standards (e.g., [RFC5280]) do not mandate this representation. A TA is long-lived because it is usually delivered out-of-band and thus verifying the integrity and authenticity of a TA is "expensive". The self-signed certificate format is commonly employed because it is readily processed by software that is prepared to process certificates, e.g., OpenSSL [OpenSSL],. The self-signed certificate also provides a basic level of consistency checking, as a self-signed certificate cannot be modified (undetectably) by other than the holder of the private key corresponding to the public key in the certificate. A resource certificate held by an RIR, NIR, or LIR may change over a period of some months, in response to resource allocation activity, or in response to other forms of movement of resources between entities. This means that the RFC 3779 extensions will change in these certificates. This makes such certificates poor candidates as trust anchors, since it violates the notion of the TA certificate as being long-lived and, hence, unchanged. This observation about the potential volatility of resource holdings over time by various entities who may be in a position to offer their service as a trust anchor for use by RPs motivates the consideration Michaelson, et al. Expires August 31, 2009 [Page 4] Internet-Draft Resource Certificate TAs February 2009 of a compound trust anchor structure for the RPKI. This structure permits the distribution of a trust anchor that is invariant over long periods, while still allowing the resource certificate intended as a TA for RPKI certificate verification to vary over shorter time intervals. This consideration does not necessarily apply in the context of trust anchor material published by the IANA with respect to the apex of the IP number resource allocation hierarchy. If such IANA-issued trust anchor material described the entirety of the number resource set, then this would constitute "long-lived" material. This would allow the trust anchor to be represented as a long-lived, self-signed resource certificate that contained the IP resource extension of 0/0 in IPv4, 0/0 in IPv6, and an AS resource extension of 0-4294967296. However, a commonly used model of trust anchor management is to use an offline CA for the very long-term, self-signed TA, and use a subordinate certificate for an online (and potentially more vulnerable) CA. This implies that even for the situation of an IANA- issued TA, the compound trust anchor structure described here would also be a useful approach to support the long term integrity of such a TA. A similar consideration relating to the use of a compound trust anchor structure applies in the domain of use of resource certificates in scoped environments using certification of private address space and private AS numbers. For example, in IPv6 Unique Local Address (ULA) prefixes are generated locally with a random prefix generation, but can be used in a (semi-) private confederation context. Such address prefixes are are intended to be contextually unique, but are not testable from any external allocating registry. Such a confederation of two or more entities who wish to share routing information using ULAs may choose to instantiate a scoped RPKI over their respective ULA spaces, and may do so using this mechanism. The compound trust anchor model can also support operational arrangemets of the form of an offline CA for the self-signed TA and an online subordinate CA. The first part of a structured trust anchor in the RPKI is a self- signed CA certificate that contains no resource extensions. It conforms to the certificate profile as defined in [ID.sidr-res-certs], except for the omission of IP Resource and AS Resource extensions. This CA certificate will be referred to as an "external TA" (certificate), or ETA. The ETA will issue a CRL and one EE certificate. The CRL conforms to the [ID.sidr-res-certs] profile. The EE certificate also conforms to the [ID.sidr-res-certs] profile, except for the omission of IP Resource and AS Resource Michaelson, et al. Expires August 31, 2009 [Page 5] Internet-Draft Resource Certificate TAs February 2009 extensions. This certificate will be referred to as a "ETA EE" (certificate). The second part of a structured trust anchor in the RPKI is a self- signed RPKI CA certificate that includes RFC 3779 extensions. This certificate will function as a TA for purposes of processing resource certificates, i.e., the certificate path will terminate at this certificate. This certificate is referred to as an "RPKI TA" (certificate) or an RTA. The format used to represent the ETA is based on ongoing IETF PKIX WG activities to define a format for trust anchor material. There are no required relationships between the (Subject/Issuer) names used in the ETA certificates and RPKI TA certificate, but the (public) keys used in the two certificates SHOULD be different. Because both of these certificates are self-signed, it is not possible to verify the RPKI TA certificate directly from the ETA certificate. Instead, the two TAs are related by the use of a CMS object [RFC3852]. The RPKI TA certificate is encapsulated in a CMS structure that is signed by the private key associated with the ETA EE certificate. Section 4 describes this CMS structure in detail, profiling the CMS signed-object format, and provides the algorithm that MUST be employed to validate this object and extract the RTA for use in validating RPKI certificate chains. 3. Publication of Trust Anchor Material The RPKI architecture [ID.sidr-arch] calls for certificates to be issued by the entities that allocate Internet number resources (addresses and AS numbers). This suggests that the structure of certificates in the RPKI that relate to the use of public number resources is a public context should reflect the hierarchy used to allocate these resources. This document does not mandate nor even recommend a specific set of default TAs, but it does observe that, for most RPs, the IANA is in a unique role as the default TA for representing public address space and public AS numbers. In any PKI an important principle is that entities issuing certificates are authoritative for the information in the certificates they issue. In the context of the RPKI, this means that an organization represented by an RTA SHOULD be authoritative for the resources enumerated in its (self-signed) certificate. Any deviation from this principle creates opportunities for accidental (or malicious) misrepresentation. It will be necessary for an RP to establish RTAs in ways that deviate Michaelson, et al. Expires August 31, 2009 [Page 6] Internet-Draft Resource Certificate TAs February 2009 from this principle in order to represent private-use address space, locally-scoped address space, and private-use AS numbers. However, this is a "safe" RTA management practice because it affects only those RPs that choose to configure their local TA store in this fashion. It does not "endanger" other RPs who are not a participant in such locally scoped environments. An ETA certificate that is not managed on an entirely local basis, where the TA issuer and the RP are essentially the same entity, is presumed to be long-lived as it will likely be distributed with relying party validation software, or via a similar out-of-band means. An entity offering itself as a putative trust anchor in the context of the RPKI is required to regularly publish an RPKI TA certificate at a stable URL, and to publish at this URL its CRL and the CMS- signed object that contains its RTA. The recommended operational maintenance procedures for publication of this material are as follows: * The entity issues an RTA certificate. This certificate MUST be reissued periodically, prior to its expiration, and MUST be reissued upon any change in the resource set that has been allocated to the entity operating this RPKI TA. The validity interval of this certificate SHOULD reflect the anticipated period of changes to the entity's resource set. * The entity issues an ETA certificate. Remember that this certificate contains no RFC 3779 extension. The validity period of this certificate should be very long, as is the conventional practice for trust anchor material. The SIA of this certificate references a publication point where the CRL and the CMS object (defined in Section 4) are published. * The ETA issues an ETA EE certificate with a validity period identical to the validity period of the RTA certificate. This ETA EE certificate MUST have the digitalSignature bit set, and this MUST be the only bit set to TRUE in the key usage extension. There is no BasicConstraints extension in this certificate (since it is an EE certificate). * The ETA regularly issues a CRL. The CRL issuance cycle SHOULD be shorter than the validity period for the RTA certificate. * Each time an RTA certificate is re-issued, or prior to the expiration of the ETA EE certificate, the ETA generates a Cryptographic Message Syntax (CMS) [RFC3852] signed-data Michaelson, et al. Expires August 31, 2009 [Page 7] Internet-Draft Resource Certificate TAs February 2009 object, the payload of which is an RTA certificate. The object is CMS-signed with the private key corresponding to the ETA EE certificate. The ETA EE certificate MUST be included as a CMS signed attribute in the CMS object. The ETA certificate and the associated CRL MUST NOT be included in the CMS object. The format of the CMS object is specified in Section 4. The CMS object is published at the location referenced in the SIA of the ETA certificate. * The entity publicly distributes its ETA in an out-of-band fashion, e.g., as part of widely-distributed relying party software, or by passing the ETA to a relying party in person. [Author note: possible placeholder for an explanation of how an RP can deal with generation and installation of ETAs and RTAs that are not part of a distributed putative TA set.] [Author note: a diagram would help here!] If a trust anchor chooses to reissue its RTA certificate before the expiration of that certificate, it MUST perform the follow actions: * revise the nextUpdate time of the ETA's CRL to reflect the issue date for the new ETA EE certificate, * issue a new ETA EE certificate and a new CMS object with the new RTA CA certificate, and * revoke the old ETA EE certificate at the nextUpdate time in the next issued CRL. This revocation will provide an indication to relying parties to perform the retrieve the RTA CA certificate at a time earlier than the normal update cycle time. 4. Cryptographic Message Syntax Profile for RPKI Trust Anchor Material Using the Cryptographic Message Syntax (CMS) [RFC3852], a RPKI Trust Anchor Object is a type of signed-data object. The general format of a CMS object is: ContentInfo ::= SEQUENCE { contentType ContentType, content [0] EXPLICIT ANY DEFINED BY contentType } ContentType ::= OBJECT IDENTIFIER As an RTA Trust Anchor Object is a signed-data object, it uses the corresponding OID, 1.2.840.113549.1.7.2. [RFC3852]. Michaelson, et al. Expires August 31, 2009 [Page 8] Internet-Draft Resource Certificate TAs February 2009 4.1. Signed-Data ContentType According to the CMS specification, the signed-data content type shall have 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 The elements of the signed-data content type are as follows: version The version is the syntax version number. It MUST be 3, corresponding to the signerInfo structure having version number 3. digestAlgorithms The digestAlgorithms set MUST include only SHA-256, the OID for which is 2.16.840.1.101.3.4.2.1. [RFC4055]. It MUST NOT contain any other algorithms. encapContentInfo This element is defined in Section 4.1.1. certificates The certificates element MUST be included and MUST contain only the single PKI EE certificate needed to validate this CMS Object. The CertificateSet type is defined in section 10 of [RFC3852] crls The crls element MUST be omitted. signerInfos This element is defined in Section 4.1.2. 4.1.1. encapContentInfo encapContentInfo is the signed content, consisting of a content type identifier and the content itself. Michaelson, et al. Expires August 31, 2009 [Page 9] Internet-Draft Resource Certificate TAs February 2009 EncapsulatedContentInfo ::= SEQUENCE { eContentType ContentType, eContent [0] EXPLICIT OCTET STRING OPTIONAL } ContentType ::= OBJECT IDENTIFIER The elements of this signed content type are as follows: eContentType The ContentType for an RTA Trust Anchor Object is defined as id-ct-RPKITrustAnchor and has the numerical value of 1.2.840.113549.1.9.16.1.33. 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-RPKITrustAnchor OBJECT IDENTIFIER ::= { id-ct 33 } eContent The content of an RTA Trust Anchor Object is an RPKI self- signed CA certificate.It is formally defined as: [Author note: Need to change this in the next rev of this document, because as the ASN.1 constructs are from CMS, then we have to stick with the SETs and SEQUENCEs, even though this profile requires exactly one element in the set.] id-ct-RPKITrustAnchor ::= Certificate The definition of Certificate is taken from [X.509]. 4.1.2. signerInfos 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 } The content of the SignerInfo element are as follows: Michaelson, et al. Expires August 31, 2009 [Page 10] Internet-Draft Resource Certificate TAs February 2009 version The version number MUST be 3, corresponding with the choice of SubjectKeyIdentifier for the sid. sid The sid is defined as: SignerIdentifier ::= CHOICE { issuerAndSerialNumber IssuerAndSerialNumber, subjectKeyIdentifier [0] SubjectKeyIdentifier } For a RTA Trust Anchor Object, the sid MUST be a SubjectKeyIdentifier. digestAlgorithm The digestAlgorithm MUST be SHA-256, the OID for which is 2.16.840.1.101.3.4.2.1. [RFC4055] signedAttrs The signedAttrs element is defined as: SignedAttributes ::= SET SIZE (1..MAX) OF Attribute Attribute ::= SEQUENCE { attrType OBJECT IDENTIFIER, attrValues SET OF AttributeValue } AttributeValue ::= ANY The signedAttr element MUST be present and 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 by the relying party. The signedAttr MUST include only a single instance of any particular attribute. Additionally, even though the syntax allows for a SET OF AttributeValue, in a RTA Trust Anchor object the attrValues must consist of only a single AttributeValue. Michaelson, et al. Expires August 31, 2009 [Page 11] Internet-Draft Resource Certificate TAs February 2009 [Author note: Note to recheck this, as it may be required to use a SET with a single member in the CMS specification.] ContentType Attribute The ContentType attribute MUST be present. The attrType OID for the ContentType attribute is 1.2.840.113549.1.9.3. The attrValues for the ContentType attribute in a RTA Trust Anchor Object MUST be 1.2.840.113549.1.9.16.1.24 (matching the eContentType in the EncapsulatedContentInfo). MessageDigest Attribute The MessageDigest attribute MUST be present. The attrType OID for the MessageDigest Attribute is 1.2.840.113549.1.9.4. The attrValues for the MessageDigest attribute contains the output of the digest algorithm applied to the content being signed, as specified in Section 11.1 of [RFC3852]. SigningTime Attribute The SigningTime attribute MAY be present. If it is present it MUST be ignored by the relying party. The presence of absence of the SigningTime attribute in no way affects the validation of the RTA Trust Anchor Object. The attrType OID for the SigningTime attribute is 1.2.840.113549.1.9.5. The attrValues for the SigningTime attribute is defined as: SigningTime ::= Time Time ::= CHOICE { utcTime UTCTime, generalizedTime GeneralizedTime } The Time element specifies the time, based on the local system clock, at which the digital signature was applied to the content. Michaelson, et al. Expires August 31, 2009 [Page 12] Internet-Draft Resource Certificate TAs February 2009 BinarySigningTime Attribute The BinarySigningTime attribute MAY be present. If it is present it MUST be ignored by the relying party. The presence of absence of the BinarySigningTime attribute in no way affects the validation of the RTA Trust Anchor Object. The attrType OID for the SigningTime attribute is 1.2.840.113549.1.9.16.2.46. The attrValues for the SigningTime attribute is defined as: BinarySigningTime ::= BinaryTime BinaryTime ::= INTEGER (0..MAX) The BinaryTime element specifies the time, based on the local system clock, at which the digital signature was applied to the content. signatureAlgorithm The signatureAlgorithm MUST be RSA (rsaEncryption), the OID for which is 1.2.840.113549.1.1.1.q signature The signature value is defined as: SignatureValue ::= OCTET STRING The signature characteristics are defined by the digest and signature algorithms. unsignedAttrs unsignedAttrs MUST be omitted. 4.2. RPKI Trust Anchor Object Validation Before a relying party can use an RTA Trust Anchor Object, the relying party must first validate the object by performing the following steps. 1. Verify that the RTA Trust Anchor Object syntax complies with this specification. In particular, verify the following: Michaelson, et al. Expires August 31, 2009 [Page 13] Internet-Draft Resource Certificate TAs February 2009 a. The contentType of the CMS object is SignedData (OID 1.2.840.113549.1.7.2). b. The version of the SignedData object is 3. c. The digestAlgorithm in the SignedData object is SHA-256 (OID 2.16.840.1.101.3.4.2.1). d. The certificates field in the SignedData object is present and contains a single EE certificate whose Subject Key Identifier (SKI) matches the CMS sid field of the SignerInfo object. e. The CMS crls field in the SignedData object is omitted. f. The eContentType in the EncapsulatedContentInfo is id-ct- RPKITrustAnchor (OID 1.2.840.113549.1.9.16.1.33) g. The version of the SignerInfo is 3. h. The digestAlgorithm in the SignerInfo object is SHA-256 (OID 2.16.840.1.101.3.4.2.1). i. The signatureAlgorithm in the SignerInfo object is RSA (OID 1.2.840.113549.1.1.1). j. The signedAttrs field in the SignerInfo object is present and contains both the ContentType attribute (OID 1.2.840.113549.1.9.3) and the MessageDigest attribute (OID 1.2.840.113549.1.9.4). k. The unsignedAttrs field in the SignerInfo object is omitted. 2. Use the public key in the EE certificate to verify the signature on the RTA Trust Anchor Object. 3. Verify that the ETA EE certificate is a valid end-entity certificate issued directly under ETA, and the ETA's CRL has not revoked this certificate, and that the ETA's CRL is valid. 5. Relying Party use of Trust Anchor Material Relying Parties can assemble the putative trust anchor collection by using the ETA certificate for each putative trust anchor: Michaelson, et al. Expires August 31, 2009 [Page 14] Internet-Draft Resource Certificate TAs February 2009 * The ETA's CRL and CMS objects are retrieved from the publication point referenced by the SIA in the ETA certificate. * Extract the EE certificate from the CMS object and verify this certificate using the ETA certificate. * Verify the ETA's CRL (using the ETA certificate) and use this CRL to verify the revocation status of the ETA EE certificate from the CMS object. * Verify the signature on the CMS object using the (already verified) ETA EE certificate from the CMS object. * The relying party can then load the enclosed RPKI TA certificate and use it to validate other RPKI certificates. Relying Parties SHOULD perform this retrieval and validation operation at intervals no less frequent than the nextUpdate time of the published ETA CRL, and SHOULD perform the retrieval operation prior to the expiration of the ETA EE certificate, or upon revocation of the ETA EE certificate. 6. Security Considerations The security considerations noted in [RFC4158] are applicable here. 7. IANA Considerations [Note to IANA, to be removed prior to publication: there are no IANA considerations stated in this document in terms of IANA registry actions. The document discussed a potential role for the IANA in the operational management of a trust anchor for the public resource RPKI, but does not specifically mandate or recommend that IANA undertake such a role.] 8. References 8.1. Normative References [ID.sidr-res-certs] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", Work in progress: Internet Drafts draft-ietf-sidr-res-certs-16.txt, February 2009. Michaelson, et al. Expires August 31, 2009 [Page 15] Internet-Draft Resource Certificate TAs February 2009 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004. [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004. [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", RFC 4055, June 2005. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [X.509] ITU-T, "Recommendation X.509: The Directory - Authentication Framework", 2000. 8.2. Informative References [ID.sidr-arch] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", Work in progress: Internet Drafts draft-ietf-sidr-arch-04.txt, November 2008. [OpenSSL] TBA, "OpenSSL", 2009. [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. Nicholas, "Internet X.509 Public Key Infrastructure: Certification Path Building", RFC 4158, September 2005. Authors' Addresses George Michaelson Asia Pacific Network Information Centre Email: ggm@apnic.net URI: http://www.apnic.net Michaelson, et al. Expires August 31, 2009 [Page 16] Internet-Draft Resource Certificate TAs February 2009 Stephen Kent BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA Email: kent@bbn.com Geoff Huston Asia Pacific Network Information Centre Email: gih@apnic.net URI: http://www.apnic.net Michaelson, et al. Expires August 31, 2009 [Page 17]