draft-ietf-sidr-signed-object-04.txt   rfc6488.txt 
Secure Inter-Domain Routing M. Lepinski Internet Engineering Task Force (IETF) M. Lepinski
Internet-Draft A. Chi Request for Comments: 6488 A. Chi
Intended status: Standards Track S. Kent Category: Standards Track S. Kent
Expires: November 9, 2011 BBN ISSN: 2070-1721 BBN
May 9, 2011 February 2012
Signed Object Template for the Resource Public Key Infrastructure Signed Object Template for
draft-ietf-sidr-signed-object-04.txt the Resource Public Key Infrastructure (RPKI)
Status of this Memo Abstract
This Internet-Draft is submitted in full conformance with the This document defines a generic profile for signed objects used in
provisions of BCP 78 and BCP 79. the Resource Public Key Infrastructure (RPKI). These RPKI signed
objects make use of Cryptographic Message Syntax (CMS) as a standard
encapsulation format.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
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 This is an Internet Standards Track document.
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 August 16, 2011. This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 5741.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6488.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Abstract
This document defines a generic profile for signed objects used in
the Resource Public Key Infrastructure (RPKI). These RPKI signed
objects make use of Cryptographic Message Syntax (CMS) as a standard
encapsulation format.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology ................................................3
1.2. Note on Algorithms . . . . . . . . . . . . . . . . . . . . 3 1.2. Note on Algorithms .........................................3
2. Signed Object Syntax . . . . . . . . . . . . . . . . . . . . . 4 2. Signed Object Syntax ............................................3
2.1. Signed-Data Content Type . . . . . . . . . . . . . . . . . 4 2.1. Signed-Data Content Type ...................................4
2.1.1. version . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1. version .............................................4
2.1.2. digestAlgorithms . . . . . . . . . . . . . . . . . . . 5 2.1.2. digestAlgorithms ....................................4
2.1.3. encapContentInfo . . . . . . . . . . . . . . . . . . . 5 2.1.3. encapContentInfo ....................................4
2.1.3.1. eContentType . . . . . . . . . . . . . . . . . . . 5 2.1.3.1. eContentType ...............................5
2.1.3.2. eContent . . . . . . . . . . . . . . . . . . . . . 5 2.1.3.2. eContent ...................................5
2.1.4. certificates . . . . . . . . . . . . . . . . . . . . . 5 2.1.4. certificates ........................................5
2.1.5. crls . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.5. crls ................................................5
2.1.6. signerInfos . . . . . . . . . . . . . . . . . . . . . . 6 2.1.6. signerInfos .........................................5
2.1.6.1. version . . . . . . . . . . . . . . . . . . . . . . 6 2.1.6.1. version ....................................6
2.1.6.2. sid . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.6.2. sid ........................................6
2.1.6.3. digestAlgorithm . . . . . . . . . . . . . . . . . . 6 2.1.6.3. digestAlgorithm ............................6
2.1.6.4. signedAttrs . . . . . . . . . . . . . . . . . . . . 6 2.1.6.4. signedAttrs ................................6
2.1.6.4.1. Content-Type Attribute . . . . . . . . . . . . 7 2.1.6.4.1. Content-Type Attribute ..........7
2.1.6.4.2. Message-Digest Attribute . . . . . . . . . . . 7 2.1.6.4.2. Message-Digest Attribute ........7
2.1.6.4.3. SigningTime Attribute . . . . . . . . . . . . . 7 2.1.6.4.3. Signing-Time Attribute ..........7
2.1.6.4.4. BinarySigningTime Attribute . . . . . . . . . . 8 2.1.6.4.4. Binary-Signing-Time Attribute ...8
2.1.6.5. signatureAlgorithm . . . . . . . . . . . . . . . . 8 2.1.6.5. signatureAlgorithm .........................8
2.1.6.6. signature . . . . . . . . . . . . . . . . . . . . . 8 2.1.6.6. signatureValue .............................8
2.1.6.7. unsignedAttrs . . . . . . . . . . . . . . . . . . . 8 2.1.6.7. unsigneAttrs ...............................8
3. Signed Object Validation . . . . . . . . . . . . . . . . . . . 9 3. Signed Object Validation ........................................8
4. Definition of Specific Signed Objects . . . . . . . . . . . . . 10 4. Definition of Specific Signed Objects ..........................10
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations ........................................10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations ............................................11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements ...............................................11
8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 8. Normative References ...........................................11
9. Informative References . . . . . . . . . . . . . . . . . . . . 12 9. Informative References .........................................12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The purpose of the Internet IP Address and Autonomous System (AS) The purpose of the Resource Public Key Infrastructure (RPKI) is to
Number Resource Public Key Infrastructure (RPKI) system is to support support assertions by current resource holders of IP (v4 and v6)
assertions by current resource holders of IP (v4 and v6) address address space and AS numbers, based on the records of organizations
space and AS numbers, based on the records of the organizations that that act as Certification Authorities (CAs). IP address and AS
act as Certification Authorities (CAs). IP address and AS number number resource information is carried in X.509 certificates via RFC
resource information is carried in X.509 certificates via RFC 3779 3779 extensions [RFC6487]. Other information assertions about
extensions [I-D.sidr-res-certs]. Other information assertions about
resources are expressed via digitally signed, non-X.509 data resources are expressed via digitally signed, non-X.509 data
structures that are referred to as "signed objects" in the RPKI structures that are referred to as "signed objects" in the RPKI
context [I-D.sidr-arch]. This document standardizes a template for context [RFC6480]. This document standardizes a template for
specifying signed objects that can be validated using the RPKI. specifying signed objects that can be validated using the RPKI.
RPKI signed objects make use of Cryptographic Message Syntax (CMS) RPKI signed objects make use of Cryptographic Message Syntax (CMS)
[RFC5652] as a standard encapsulation format. CMS was chosen to take [RFC5652] as a standard encapsulation format. CMS was chosen to take
advantage of existing open source software available for processing advantage of existing open source software available for processing
messages in this format. RPKI signed objects adhere to a profile messages in this format. RPKI signed objects adhere to a profile
(specified in Section 2) of the CMS signed-data object. (specified in Section 2) of the CMS signed-data object.
The template defined in this document for RPKI signed objects is not The template defined in this document for RPKI signed objects is not
a complete specification for any particular type of signed object, a complete specification for any particular type of signed object,
and instead includes only the items which are common to all RPKI and instead includes only the items that are common to all RPKI
signed objects. That is, fully specifying a particular type of signed signed objects. That is, fully specifying a particular type of
object requires an additional document that specifies the details signed object requires an additional document that specifies the
which are specific to a particular type of signed object. Such details specific to a particular type of signed object. Such details
details include Abstract Syntax Notation One (ASN.1) [X.208-88] include Abstract Syntax Notation One (ASN.1) [X.208-88] for the
syntax for the object's payload and any additional steps required to object's payload and any additional steps required to validate the
validate the particular type of signed object. Section 4 describes in particular type of signed object. Section 4 describes in more detail
more detail the additional pieces that must be specified in order to the additional pieces that must be specified in order to define a new
define a new type of RPKI signed object that uses this template. type of RPKI signed object that uses this template. Additionally,
Additionally, see [I-D.sidr-roa-format] for an example of a document see [RFC6482] for an example of a document that uses this template to
that uses this template to specify a particular type of signed specify a particular type of signed object, the Route Origination
object, the Route Origination Authorization. Authorization (ROA).
1.1. Terminology 1.1. Terminology
It is assumed that the reader is familiar with the terms and concepts It is assumed that the reader is familiar with the terms and concepts
described in "Internet X.509 Public Key Infrastructure Certificate described in "Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile" [RFC5280] and "X.509 and Certificate Revocation List (CRL) Profile" [RFC5280], "X.509
Extensions for IP Addresses and AS Identifiers" [RFC3779], and Extensions for IP Addresses and AS Identifiers" [RFC3779], and
"Cryptographic Message Syntax (CMS)" [RFC5652]. "Cryptographic Message Syntax (CMS)" [RFC5652].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Note on Algorithms 1.2. Note on Algorithms
Cryptographic Message Syntax is a general format capable of
accommodating a wide variety of signature and digest algorithms. The
algorithms used in the RPKI (and associated key sizes) are specified
in [I-D.sidr-rpki-algs].
2. Signed Object Syntax CMS is a general format capable of accommodating a wide variety of
signature and digest algorithms. The algorithms used in the RPKI
(and associated key sizes) are specified in [RFC6485].
The RPKI signed object is a profile of the Cryptographic Message 2. Signed Object Syntax
Syntax (CMS) [RFC5652] signed-data object, with the restriction that
RPKI signed objects MUST be encoded using the ASN.1 Distinguished The RPKI signed object is a profile of the CMS [RFC5652] signed-data
Encoding Rules (DER) [X.509-88]. object, with the restriction that RPKI signed objects MUST be encoded
using the ASN.1 Distinguished Encoding Rules (DER) [X.509-88].
The general format of a CMS object is: The general format of a CMS object is:
ContentInfo ::= SEQUENCE { ContentInfo ::= SEQUENCE {
contentType ContentType, contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType } content [0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIER ContentType ::= OBJECT IDENTIFIER
The ContentType is the signed-data type of id-data, namely the id- The content-type is the signed-data type of id-data, namely the
signedData OID, 1.2.840.113549.1.7.2. [RFC5652] id-signedData OID [RFC5652], 1.2.840.113549.1.7.2.
2.1. Signed-Data Content Type 2.1. Signed-Data Content Type
According to the CMS standard, the signed-data content type is the According to the CMS standard, the signed-data content type is the
ASN.1 type SignedData: ASN.1 type SignedData:
SignedData ::= SEQUENCE { SignedData ::= SEQUENCE {
version CMSVersion, version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers, digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo, encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL, certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos } signerInfos SignerInfos }
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
SignerInfos ::= SET OF SignerInfo SignerInfos ::= SET OF SignerInfo
Additionally, the SignerInfos set MUST contain only a single Additionally, the SignerInfos set MUST contain only a single
SignerInfo object. SignerInfo object.
2.1.1. version 2.1.1. version
The version is the syntax version number. It MUST be 3, The version is the syntax version number. It MUST be 3,
corresponding to the signerInfo structure having version number 3. corresponding to the signerInfo structure having version number 3.
2.1.2. digestAlgorithms 2.1.2. digestAlgorithms
The digestAlgorithms set contains the OIDs of the digest algorithm(s) The digestAlgorithms set contains the OIDs of the digest algorithm(s)
used in signing the encapsulated content. This set MUST contain used in signing the encapsulated content. This set MUST contain
exactly one digest algorithm OID, and the OID MUST be selected from exactly one digest algorithm OID, and the OID MUST be selected from
those specified in [I-D.sidr-rpki-algs]. those specified in [RFC6485].
2.1.3. encapContentInfo 2.1.3. encapContentInfo
encapContentInfo is the signed content, consisting of a content type encapContentInfo is the signed content, consisting of a content type
identifier and the content itself. The encapContentInfo represents identifier and the content itself. The encapContentInfo represents
the payload of the RPKI signed object. the payload of the RPKI signed object.
EncapsulatedContentInfo ::= SEQUENCE { EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType, eContentType ContentType,
eContent [0] EXPLICIT OCTET STRING OPTIONAL } eContent [0] EXPLICIT OCTET STRING OPTIONAL }
ContentType ::= OBJECT IDENTIFIER ContentType ::= OBJECT IDENTIFIER
2.1.3.1. eContentType 2.1.3.1. eContentType
This field is left undefined by this profile. The eContentType is an This field is left undefined by this profile. The eContentType is an
OID specifying the type of payload in this signed object and MUST be OID specifying the type of payload in this signed object and MUST be
specified by the Internet standards track document that defines the specified by the Internet Standards Track document that defines the
object. object.
2.1.3.2. eContent 2.1.3.2. eContent
This field is left undefined by this profile. The eContent is the This field is left undefined by this profile. The eContent is the
payload of the signed object and MUST be specified by the Internet payload of the signed object and MUST be specified by the Internet
standards track document that defines the RPKI object. Standards Track document that defines the RPKI object.
Note that the signed object profile does not provide version numbers Note that the signed object profile does not provide version numbers
for signed objects. Therefore, in order to facilitate transition to for signed objects. Therefore, in order to facilitate transition to
new versions of the signed objects over time, it is RECOMMENDED that new versions of the signed objects over time, it is RECOMMENDED that
signed objects using this profile include a version number within each type of signed object defined using this profile include a
their eContent. version number within its eContent.
2.1.4. certificates 2.1.4. certificates
The certificates field MUST be included, and MUST contain exactly one The certificates field MUST be included, and MUST contain exactly one
certificate, the RPKI End Entity (EE) certificate needed to validate certificate, the RPKI end-entity (EE) certificate needed to validate
this signed object. this signed object.
2.1.5. crls 2.1.5. crls
The crls field MUST be omitted. The crls field MUST be omitted.
2.1.6. signerInfos 2.1.6. signerInfos
SignerInfo is defined in CMS as: SignerInfo is defined in CMS as:
SignerInfo ::= SEQUENCE { SignerInfo ::= SEQUENCE {
version CMSVersion, version CMSVersion,
sid SignerIdentifier, sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier, digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier, signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue, signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
2.1.6.1. version 2.1.6.1. version
The version number MUST be 3, corresponding with the choice of The version number MUST be 3, corresponding with the choice of
SubjectKeyIdentifier for the sid. SubjectKeyIdentifier for the sid.
2.1.6.2. sid 2.1.6.2. sid
The sid is defined as: The sid is defined as:
SignerIdentifier ::= CHOICE { SignerIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber, issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier } subjectKeyIdentifier [0] SubjectKeyIdentifier }
For RPKI signed objects, the sid MUST be the SubjectKeyIdentifier For RPKI signed objects, the sid MUST be the SubjectKeyIdentifier
that appears in the EE certificate carried in the CMS certificates that appears in the EE certificate carried in the CMS certificates
field. field.
2.1.6.3. digestAlgorithm 2.1.6.3. digestAlgorithm
The digestAlgorithm MUST consist of the OID of a digest algorithm The digestAlgorithm MUST consist of the OID of a digest algorithm
that conforms to the RPKI Algorithms and Key Size Profile that conforms to the RPKI Algorithms and Key Size Profile
specification [I-D.sidr-rpki-algs]. specification [RFC6485].
2.1.6.4. signedAttrs 2.1.6.4. signedAttrs
The signedAttrs is defined as: The signedAttrs is defined as:
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
Attribute ::= SEQUENCE { Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER, attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue } attrValues SET OF AttributeValue }
AttributeValue ::= ANY AttributeValue ::= ANY
The signedAttr element MUST be present and MUST include the content- The signedAttrs element MUST be present and MUST include the content-
type and message-digest attributes [RFC5652]. The signer MAY also type and message-digest attributes [RFC5652]. The signer MAY also
include the signing-time signed attribute [RFC5652], the binary- include the signing-time attribute [RFC5652], the binary-signing-time
signing-time signed attribute [RFC6019], or both signing-time attribute [RFC6019], or both attributes. Other signed attributes
attributes. Other signed attributes MUST NOT be included. MUST NOT be included.
The signedAttr MUST include only a single instance of any particular The signedAttrs element MUST include only a single instance of any
attribute. Additionally, even though the syntax allows for a SET OF particular attribute. Additionally, even though the syntax allows
AttributeValue, in an RPKI signed object the attrValues MUST consist for a SET OF AttributeValue, in an RPKI signed object, the attrValues
of only a single AttributeValue. MUST consist of only a single AttributeValue.
2.1.6.4.1. Content-Type Attribute 2.1.6.4.1. Content-Type Attribute
The ContentType attribute MUST be present. The attrType OID for the The content-type attribute MUST be present. The attrType OID for the
ContentType attribute is 1.2.840.113549.1.9.3. content-type attribute is 1.2.840.113549.1.9.3.
The attrValues for the ContentType attribute MUST match the The attrValues for the content-type attribute MUST match the
eContentType in the EncapsulatedContentInfo. Thus, attrValues MUST eContentType in the EncapsulatedContentInfo. Thus, attrValues MUST
contain the OID that specifies the payload type of the specific RPKI contain the OID that specifies the payload type of the specific RPKI
signed object carried in the CMS signed data structure. signed object carried in the CMS signed data structure.
2.1.6.4.2. Message-Digest Attribute 2.1.6.4.2. Message-Digest Attribute
The MessageDigest Attribute MUST be present. The attrType OID for The message-digest attribute MUST be present. The attrType OID for
the MessageDigest Attribute is 1.2.840.113549.1.9.4. the message-digest attribute is 1.2.840.113549.1.9.4.
The attrValues for the MessageDigest attribute contains the output of The attrValues for the message-digest attribute contains the output
the digest algorithm applied to the content being signed, as of the digest algorithm applied to the content being signed, as
specified in Section 5.4 of [RFC5652]. specified in Section 5.4 of [RFC5652].
2.1.6.4.3. SigningTime Attribute 2.1.6.4.3. Signing-Time Attribute
The SigningTime Attribute MAY be present. Note that the presence or The signing-time attribute MAY be present. Note that the presence or
absence of the SigningTime attribute MUST NOT affect the validity of absence of the signing-time attribute MUST NOT affect the validity of
the signed object (as specified in Section 3). The attrType OID for the signed object (as specified in Section 3). The attrType OID for
the SigningTime attribute is 1.2.840.113549.1.9.5. the signing-time attribute is 1.2.840.113549.1.9.5.
id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }
The attrValues for the SigningTime attribute is defined as: The attrValues for the signing-time attribute is defined as:
SigningTime ::= Time SigningTime ::= Time
Time ::= CHOICE { Time ::= CHOICE {
utcTime UTCTime, utcTime UTCTime,
generalizedTime GeneralizedTime } generalizedTime GeneralizedTime }
The Time element specifies the time, based on the local system clock, The Time element specifies the time, based on the local system clock,
at which the digital signature was applied to the content. at which the digital signature was applied to the content.
The definition of Time matches the one specified in the 1997 version The definition of Time matches the one specified in the 1997 version
of X.509. Additional information regarding the use of UTCTime and of X.509. Additional information regarding the use of UTCTime and
GeneralizedTime can be found in [RFC5652]. GeneralizedTime can be found in [RFC5652].
2.1.6.4.4. BinarySigningTime Attribute 2.1.6.4.4. Binary-Signing-Time Attribute
The BinarySigningTime Attribute MAY be present. Note that the The binary-signing-time attribute MAY be present. Note that the
presence or absence of the BinarySigningTime attribute MUST NOT presence or absence of the binary-signing-time attribute MUST NOT
affect the validity of the signed object (as specified in Section 3). affect the validity of the signed object (as specified in Section 3).
The attrType OID for the BinarySigningTime attribute is The attrType OID for the binary-signing-time attribute is
1.2.840.113549.1.9.16.2.46. 1.2.840.113549.1.9.16.2.46.
id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1) id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) 46 } smime(16) aa(2) 46 }
The attrValues for the signing-time attribute is defined as:
The attrValues for the SigningTime attribute is defined as:
BinarySigningTime ::= BinaryTime BinarySigningTime ::= BinaryTime
BinaryTime ::= INTEGER (0..MAX) BinaryTime ::= INTEGER (0..MAX)
The BinaryTime element specifies the time, based on the local system The BinaryTime element specifies the time, based on the local system
clock, at which the digital signature was applied to the content. The clock, at which the digital signature was applied to the content.
precise definition of the BinaryTime element can be found in The precise definition of the BinaryTime element can be found in
[RFC6019]. [RFC6019].
2.1.6.5. signatureAlgorithm 2.1.6.5. signatureAlgorithm
The signatureAlgorithm MUST conform to the RPKI Algorithms and Key The signatureAlgorithm MUST conform to the RPKI Algorithms and Key
Size Profile specification [I-D.sidr-rpki-algs]. Size Profile specification [RFC6485].
2.1.6.6. signature 2.1.6.6. signature
The signature value is defined as: The signature value is defined as:
SignatureValue ::= OCTET STRING SignatureValue ::= OCTET STRING
The signature characteristics are defined by the digest and signature The signature characteristics are defined by the digest and signature
algorithms. algorithms.
2.1.6.7. unsignedAttrs 2.1.6.7. unsignedAttrs
unsignedAttrs MUST be omitted. unsignedAttrs MUST be omitted.
3. Signed Object Validation 3. Signed Object Validation
Before a relying party can use a signed object, the relying party Before a relying party can use a signed object, the relying party
MUST validate the signed object by verifying that all of the MUST validate the signed object by verifying that all of the
following conditions hold. A relying party may perform these checks following conditions hold. A relying party may perform these checks
in any order. Note that these checks are necessary but not in any order. Note that these checks are necessary, but not
sufficient: in general, further validation MUST be performed based on sufficient. In general, further validation MUST be performed based
the specific type of signed object. on the specific type of signed object.
1. The signed object syntax complies with this specification. In 1. The signed object syntax complies with this specification. In
particular, that each of the following is true: particular, each of the following is true:
a. The contentType of the CMS object is SignedData (OID a. The content-type of the CMS object is SignedData (OID
1.2.840.113549.1.7.2) 1.2.840.113549.1.7.2)
b. The version of the SignedData object is 3. b. The version of the SignedData object is 3.
c. The certificates field in the SignedData object is present c. The certificates field in the SignedData object is present and
and contains one EE certificate, the SubjectKeyIdentifier contains one EE certificate, the SubjectKeyIdentifier field of
field of which matches the sid field of the SignerInfo which matches the sid field of the SignerInfo object.
object.
d. The crls field in the SignedData object is omitted. d. The crls field in the SignedData object is omitted.
e. The version of the SignerInfo is 3. e. The version of the SignerInfo is 3.
f. The signedAttrs field in the SignerInfo object is present and f. The signedAttrs field in the SignerInfo object is present and
contains both the ContentType attribute (OID contains both the content-type attribute (OID
1.2.840.113549.1.9.3) and the MessageDigest attribute (OID 1.2.840.113549.1.9.3) and the message-digest attribute (OID
1.2.840.113549.1.9.4). 1.2.840.113549.1.9.4).
g. The signedAttrs field in the SignerInfo object does not g. The signedAttrs field in the SignerInfo object does not
contain any attributes other than the following four: the contain any attributes other than the following four: the
ContentType attribute (OID 1.2.840.113549.1.9.3), the content-type attribute (OID 1.2.840.113549.1.9.3), the
MessageDigest attribute (OID 1.2.840.113549.1.9.4), the message-digest attribute (OID 1.2.840.113549.1.9.4), the
SigningTime attribute (OID 1.2.840.113549.1.9.5), and the signing-time attribute (OID 1.2.840.113549.1.9.5), and the
BinarySigningTime attribute (OID 1.2.840.113549.1.9.16.2.46). binary-signing-time attribute (OID
Note that the SigningTime and BinarySigningTime attributes 1.2.840.113549.1.9.16.2.46). Note that the signing-time and
MAY be present, but are not required. binary-signing-time attributes MAY be present, but they are
not required.
h. The eContentType in the EncapsulatedContentInfo is an OID h. The eContentType in the EncapsulatedContentInfo is an OID that
that matches the attrValues in the ContentType attribute. matches the attrValues in the content-type attribute.
i. The unsignedAttrs field in the SignerInfo object is omitted. i. The unsignedAttrs field in the SignerInfo object is omitted.
j. The digestAlgorithm in the SignedData and SignerInfo objects j. The digestAlgorithm in the SignedData and SignerInfo objects
conforms to the RPKI Algorithms and Key Size Profile conforms to the RPKI Algorithms and Key Size Profile
specification [I-D.sidr-rpki-algs]. specification [RFC6485].
k. The signatureAlgorithm in the SignerInfo object conforms to k. The signatureAlgorithm in the SignerInfo object conforms to
the RPKI Algorithms and Key Size Profile specification the RPKI Algorithms and Key Size Profile specification
[I-D.sidr-rpki-algs]. [RFC6485].
l. The signed object is DER encoded. l. The signed object is DER encoded.
2. The public key of the EE certificate (contained within the CMS 2. The public key of the EE certificate (contained within the CMS
signed-data object) can be used to successfully verify the signed-data object) can be used to successfully verify the
signature on the signed object. signature on the signed object.
3. The EE certificate (contained within the CMS signed-data object) 3. The EE certificate (contained within the CMS signed-data object)
is a valid EE certificate in the RPKI as specified by [I-D.sidr- is a valid EE certificate in the RPKI as specified by [RFC6487].
res-certs]. In particular, there exists a valid certification In particular, a valid certification path from a trust anchor to
path from a trust anchor to this EE certificate. this EE certificate exists.
If the above procedure indicates that the signed object is invalid, If the above procedure indicates that the signed object is invalid,
then the signed object MUST be discarded and treated as though no then the signed object MUST be discarded and treated as though no
signed object were present. If all of the conditions above are signed object were present. If all of the conditions above are true,
true, then the signed object may be valid. The relying party MUST then the signed object may be valid. The relying party MUST then
then perform any additional validation steps required for the perform any additional validation steps required for the particular
particular type of signed object. type of signed object.
Note that a previously valid signed object will cease to be valid Note that a previously valid signed object will cease to be valid
when the associated EE certificate ceases to be valid (for example, when the associated EE certificate ceases to be valid (for example,
when the end of the certificate's validity period is reached, or when when the end of the certificate's validity period is reached, or when
the certificate is revoked by the authority that issued it). See [I- the certificate is revoked by the authority that issued it). See
D.sidr-res-certs] for a complete specification of resource [RFC6487] for a complete specification of resource certificate
certificate validity. validity.
4. Definition of Specific Signed Objects 4. Definition of Specific Signed Objects
Each RPKI signed object MUST be defined in an Internet standards Each RPKI signed object MUST be defined in an Internet Standards
track document based on this profile, by specifying the following Track document based on this profile, by specifying the following
data elements and validation procedure: data elements and validation procedure:
1. eContentType: A single OID to be used for both the eContentType 1. eContentType: A single OID to be used for both the eContentType
field and the Content-Type attribute. This OID uniquely field and the content-type attribute. This OID uniquely
identifies the type of signed object. identifies the type of signed object.
2. eContent: Define the syntax for the eContent field in 2. eContent: Define the syntax for the eContent field in
encapContentInfo. This is the payload that contains the data encapContentInfo. This is the payload that contains the data
specific to a given type of signed object. specific to a given type of signed object.
3. Additional Validation: Define a set of additional validation 3. Additional Validation: Define a set of additional validation
steps for the specific signed object. Before using this specific steps for the specific signed object. Before using this specific
signed object, a relying party MUST perform both the generic signed object, a relying party MUST perform both the generic
validation steps in Section 3 above, as well as these additional validation steps in Section 3 above, as well as these additional
steps. steps.
5. Security Considerations 5. Security Considerations
There is no assumption of confidentiality for the data in an RPKI
signed object. The integrity and authenticity of each signed
object is based on the verification of a digital signature for
the object, and on the validation of the EE certificate used to
perform that verification. It is anticipated that signed objects
will be stored in repositories that will be publicly accessible.
Since RPKI signed objects make use of CMS as an encapsulation
format, the security considerations for CMS apply [RFC5652].
6. IANA Considerations
IANA is requested to create a registry of signed objects types There is no assumption of confidentiality for the data in an RPKI
that utilize the template defined in this document. This registry signed object. The integrity and authenticity of each signed object
shall contain three fields, an informal name for the signed is based on the verification of the object's digital signature, and
object, the OID for the eContentType of the signed object, and a the validation of the EE certificate used to perform that
specification pointer that references the RFC in which the signed verification. It is anticipated that signed objects will be stored
object is specified. The entries in this registry shall be in repositories that will be publicly accessible.
managed by IETF Standards Action.
The registry shall be initially populated with the following two Since RPKI signed objects make use of CMS as an encapsulation format,
entries. the security considerations for CMS apply [RFC5652].
Name | OID | Specification 6. IANA Considerations
----------------------------------------------------------------
ROA | 1.2.840.113549.1.9.16.1.24 | I-D.sidr-roa-format
Manifest | 1.2.840.113549.1.9.16.1.26 | I-D.sidr-rpki-manifests
Note that when draft-ietf-sidr-roa-format and draft-ietf-sidr- IANA has created a registry of "RPKI Signed Objects" types that
rpki-manifests are published as RFCs, IANA is requested to utilize the template defined in this document. This registry
replace the Internet Draft names in the registry with the RFC contains three fields: an informal name for the signed object, the
numbers of corresponding RFCs. OID for the eContentType of the signed object, and a specification
pointer that references the RFC in which the signed object is
specified. The entries in this registry are managed by IETF
Standards Action.
7. Acknowledgements The registry has been initially populated with the following two
entries.
The authors wish to thank Charles Gardiner, Russ Housley, and Name | OID | Specification
Derek Kong for their help and contributions. Additionally, the ----------------------------------------------------------------
authors would like to thank Rob Austein, Roque Gagliano, Danny ROA | 1.2.840.113549.1.9.16.1.24 | RFC 6482
McPherson, Sean Turner, and Sam Weiler for their careful reviews Manifest | 1.2.840.113549.1.9.16.1.26 | RFC 6486
and helpful comments.
8. Normative References 7. Acknowledgements
[I-D.sidr-res-certs] Huston, G., Michaelson, G., and R. Loomans, "A The authors wish to thank Charles Gardiner, Russ Housley, and Derek
Profile for X.509 PKIX Resource Certificates", Kong for their help and contributions. Additionally, the authors
draft-ietf-sidr-res-certs (work in progress), December would like to thank Rob Austein, Roque Gagliano, Danny McPherson,
2010. Sean Turner, and Sam Weiler for their careful reviews and helpful
comments.
[I-D.sidr-rpki-algs] Huston, G., "A Profile for Algorithms and Key 8. Normative References
Sizes for use in the Resource Public Key Infrastructure",
draft-ietf-sidr-rpki-algs (work in progress), November
2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004. Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
5652, September 2009. RFC 5652, September 2009.
[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for
Use in the Resource Public Key Infrastructure (RPKI)", RFC
6485, February 2012.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487, February
2012.
[X.208-88] CCITT. Recommendation X.208: Specification of Abstract [X.208-88] CCITT. Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1), 1988. Syntax Notation One (ASN.1), 1988.
[X.509-88] CCITT. Recommendation X.509: The Directory Authentication [X.509-88] CCITT. Recommendation X.509: The Directory Authentication
Framework, 1988. Framework, 1988.
9. Informative References 9. Informative References
[I-D.sidr-arch] Lepinski, M. and S. Kent, "An Infrastructure to
Support Secure Internet Routing", draft-ietf-sidr-arch
(work in progress), November 2010.
[I-D.sidr-roa-format] Lepinski, M., Kent, S., and D. Kong, "A Profile
for Route Origin Authorizations (ROAs)",
draft-ietf-sidr-roa-format (work in progress), November
2010.
[RFC6019] Housley, R., "BinaryTime: An Alternate Format for [RFC6019] Housley, R., "BinaryTime: An Alternate Format for
Representing Date and Time in ASN.1", RFC 6019, September Representing Date and Time in ASN.1", RFC 6019, September
2010. 2010.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, February 2012.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482, February 2012.
Authors' Addresses Authors' Addresses
Matt Lepinski Matt Lepinski
BBN Technologies BBN Technologies
10 Moulton Street 10 Moulton Street
Cambridge MA 02138 Cambridge MA 02138
Email: mlepinski@bbn.com EMail: mlepinski@bbn.com
Andrew Chi Andrew Chi
BBN Technologies BBN Technologies
10 Moulton Street 10 Moulton Street
Cambridge MA 02138 Cambridge MA 02138
Email: achi@bbn.com EMail: achi@bbn.com
Stephen Kent Stephen Kent
BBN Technologies BBN Technologies
10 Moulton Street 10 Moulton Street
Cambridge MA 02138 Cambridge MA 02138
Email: kent@bbn.com EMail: kent@bbn.com
 End of changes. 102 change blocks. 
264 lines changed or deleted 248 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/