SIDR G. Michaelson
Internet-Draft APNIC
Intended status: Standards Track S. Kent
Expires: November 9, 2010 BBN
G. Huston
APNIC
May 8, 2010
A Profile for Trust Anchor Material for the Resource Certificate PKI
draft-ietf-sidr-ta-03
Abstract
This document defines a standard profile for the publication of Trust
Anchor material for the Resource Certificate Public Key
Infrastructure.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on November 9, 2010.
Copyright Notice
Copyright (c) 2010 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Michaelson, et al. Expires November 9, 2010 [Page 1]
Internet-Draft Resource Certificate TAs May 2010
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Trust Anchors for Resource Certificates . . . . . . . . . . . 4
2.1. A Compound Trust Anchor Structure . . . . . . . . . . . . 5
3. Publication of Trust Anchor Material . . . . . . . . . . . . . 7
4. Cryptographic Message Syntax Profile for RPKI Trust Anchor
Material . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Signed-Data ContentType . . . . . . . . . . . . . . . . . 9
4.1.1. encapContentInfo . . . . . . . . . . . . . . . . . . . 10
4.1.2. signerInfos . . . . . . . . . . . . . . . . . . . . . 11
4.2. RPKI Trust Anchor Object Validation . . . . . . . . . . . 13
5. Relying Party use of Trust Anchor Material . . . . . . . . . . 15
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 November 9, 2010 [Page 2]
Internet-Draft Resource Certificate TAs May 2010
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 November 9, 2010 [Page 3]
Internet-Draft Resource Certificate TAs May 2010
1.1. Terminology
It is assumed that the reader is familiar with the terms and concepts
described in "An Infrastructure to Support Secure Internet Routing"
[ID.sidr-arch], "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], and .
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 the Internet Assigned
Numbers Authority (IANA), the Regional Internet Registries (RIRs),
Local Internet Registries (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 RP
can verify that that a unique path exists between any RPKI
certificate and a chosen TA.
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 or a LIR that describes all the
resources that are administered by that entity 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, making such certificates poor candidates as trust
anchors, since such changes violate the notion of the TA certificate
as being long-lived and, hence, unchanged.
Michaelson, et al. Expires November 9, 2010 [Page 4]
Internet-Draft Resource Certificate TAs May 2010
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
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 compound trust anchor model can support operational arrangements
of the form of an offline CA for the self-signed TA and an online
subordinate CA.
2.1. A Compound Trust Anchor Structure
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 is referred to here as an
"external TA" (certificate), or ETA. The ETA issues 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 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 here 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.
Michaelson, et al. Expires November 9, 2010 [Page 5]
Internet-Draft Resource Certificate TAs May 2010
The structure of the trust anchor material is shown in the following
diagram.
+------------------------------+
| ETA CA Certificate |
| |
| Issuer: <ETA> |
| Subject: <ETA> |
| SIA: <URI>-------------------|-+
+------------------------------+ |
| Signed: ETA (self-signed) | |
+------------------------------+ |
V
+---------------------------------------------------------+
| ETA Repository Publication Point |
|+--------------------------------+ +--------------+|
|| CMS Signed Object |<-+ +->|ETA CRL ||
||--------------------------------| | | | ||
|| CMS Attributes and Signer Info | | | | Issuer: <ETA>||
|| | | | | <CRL List> ||
||+------------------------------+| | | +--------------+|
||| ETA EE Certificate || | | | Signed: ETA ||
||| || | | +--------------+|
||| Issuer: <ETA> || | | |
||| Subject: <ETA EE> || | | |
||| SIA: <URI>-------------------||--+ | |
||| CRL: <URI>-------------------||----+ |
||+------------------------------+| |
||| Signed: ETA || |
||+------------------------------+| |
||--------------------------------| |
|| CMS Signed Data | |
|| | |
||+------------------------------+| |
||| RTA CA Certificate || |
||| || |
||| Issuer: <RPKI TA> || |
||| Subject: <RPKI TA> || |
||| CRL: <URI>-------------------||------------------------->
||| SIA: <URI>-------------------||------------------------->
||| IP: <IP Addresses> || |
||| AS: <AS Numbers> || |
||+------------------------------+| |
||| Signed: RPKI TA (self-signed)|| |
||+------------------------------+| |
|+--------------------------------+ |
+---------------------------------------------------------+
Michaelson, et al. Expires November 9, 2010 [Page 6]
Internet-Draft Resource Certificate TAs May 2010
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
recommend a specific set of default TAs.
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
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.
Michaelson, et al. Expires November 9, 2010 [Page 7]
Internet-Draft Resource Certificate TAs May 2010
* The entity issues an ETA certificate. 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
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.
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.
Michaelson, et al. Expires November 9, 2010 [Page 8]
Internet-Draft Resource Certificate TAs May 2010
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].
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 is specified in
[ID.sidr-rpki-algs].
encapContentInfo
This element is defined in Section 4.1.1.
Michaelson, et al. Expires November 9, 2010 [Page 9]
Internet-Draft Resource Certificate TAs May 2010
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.
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:
id-ct-RPKITrustAnchor ::= Certificate
The definition of Certificate is taken from [X.509].
Michaelson, et al. Expires November 9, 2010 [Page 10]
Internet-Draft Resource Certificate TAs May 2010
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:
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 is specified in [ID.sidr-rpki-algs].
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
Michaelson, et al. Expires November 9, 2010 [Page 11]
Internet-Draft Resource Certificate TAs May 2010
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, and for each Attribute there MUST only
be one AttributeValue.
The defined signedAttr attributes are:
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,
Michaelson, et al. Expires November 9, 2010 [Page 12]
Internet-Draft Resource Certificate TAs May 2010
generalizedTime GeneralizedTime }
The Time element specifies the time, based on
the local system clock, at which the digital
signature was applied to the content.
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 is specified in [ID.sidr-rpki-algs].
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.
Michaelson, et al. Expires November 9, 2010 [Page 13]
Internet-Draft Resource Certificate TAs May 2010
1. Verify that the RTA Trust Anchor Object syntax complies with
this specification. In particular, verify the following:
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 matches an
algorithm specified in [ID.sidr-rpki-algs].
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 matches the
algorithm specified in [ID.sidr-rpki-algs].
i. The signatureAlgorithm in the SignerInfo object matches
the algorithm specified in [ID.sidr-rpki-algs].
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.
Michaelson, et al. Expires November 9, 2010 [Page 14]
Internet-Draft Resource Certificate TAs May 2010
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:
* 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.]
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-17.txt,
Michaelson, et al. Expires November 9, 2010 [Page 15]
Internet-Draft Resource Certificate TAs May 2010
September 2009.
[ID.sidr-rpki-algs]
Huston, G., "A Profile for Algorithms and Key Sizes for
use in the Resource Public Key Infrastructure", Work in
progress: Internet
Drafts draft-ietf-sidr-rpki-algs-00.txt, August 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.
[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-08.txt, July 2009.
[OpenSSL] The OpenSSL Project, "OpenSSL", 2009,
<http://www.openssl.org>.
[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 November 9, 2010 [Page 16]
Internet-Draft Resource Certificate TAs May 2010
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 November 9, 2010 [Page 17]
