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]