draft-ietf-sidr-signed-object-01.txt   draft-ietf-sidr-signed-object-02.txt 
Secure Inter-Domain Routing M. Lepinski Secure Inter-Domain Routing M. Lepinski
Internet-Draft A. Chi Internet-Draft A. Chi
Intended status: Standards Track S. Kent Intended status: Standards Track S. Kent
Expires: April 7, 2011 BBN Expires: June 31, 2011 BBN
October 4, 2010 December 31, 2010
Signed Object Template for the Resource Public Key Infrastructure Signed Object Template for the Resource Public Key Infrastructure
draft-ietf-sidr-signed-object-01.txt draft-ietf-sidr-signed-object-02.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 7, 2011. This Internet-Draft will expire on June 19, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . 5
2.1.3. encapContentInfo . . . . . . . . . . . . . . . . . . . 5 2.1.3. encapContentInfo . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.5. crls . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.6. signerInfos . . . . . . . . . . . . . . . . . . . . . 6 2.1.6. signerInfos . . . . . . . . . . . . . . . . . . . . . 6
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. SigningTime Attribute . . . . . . . . . . . 7
2.1.6.4.4. BinarySigningTime Attribute . . . . . . . . 8 2.1.6.4.4. BinarySigningTime Attribute . . . . . . . . 8
2.1.6.5. signatureAlgorithm . . . . . . . . . . . . . . . 8 2.1.6.5. signatureAlgorithm . . . . . . . . . . . . . . . 8
2.1.6.6. signature . . . . . . . . . . . . . . . . . . . . 8 2.1.6.6. signature . . . . . . . . . . . . . . . . . . . . 8
2.1.6.7. unsignedAttrs . . . . . . . . . . . . . . . . . . 9 2.1.6.7. unsignedAttrs . . . . . . . . . . . . . . . . . . 8
3. Signed Object Validation . . . . . . . . . . . . . . . . . . . . 9 3. Signed Object Validation . . . . . . . . . . . . . . . . . . . . 9
4. Definition of Specific Signed Objects . . . . . . . . . . . . 10 4. Definition of Specific Signed Objects . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
skipping to change at page 3, line 36 skipping to change at page 3, line 36
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 which 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 signed
object requires an additional document that specifies the details object requires an additional document that specifies the details
which are specific to a particular type of signed object. Such which are specific to a particular type of signed object. Such
details include Abstract Syntax Notation One (ASN.1) [X.208-88] details include Abstract Syntax Notation One (ASN.1) [X.208-88]
syntax for the object's payload and any additional steps required to syntax for the object's payload and any additional steps required to
validate the particular type of signed object. Section 4 describes in validate the particular type of signed object. Section 4 describes in
more detail the additional pieces that must be specified in order to more detail the additional pieces that must be specified in order to
define a new type of RPKI signed object that uses this template. define a new type of RPKI signed object that uses this template.
Additionally, see [draft-ietf-sidr-roa-format] for an example of a Additionally, see [I-D.sidr-roa-format] for an example of a document
document that uses this template to specify a particular type of that uses this template to specify a particular type of signed
signed object, the Route Origination Authorization. object, the Route Origination Authorization.
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] and "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",
skipping to change at page 5, line 33 skipping to change at page 5, line 33
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 partially undefined by this profile. The eContent This field is left undefined by this profile. The eContent is the
is the payload of the signed object and MUST be specified by the payload of the signed object and MUST be specified by the Internet
Internet standards track document that defines the RPKI object. standards track document that defines the RPKI object.
At the outermost level, the eContent field MUST be an ASN.1 SEQUENCE.
The first element of the SEQUENCE MUST be the version number, in
order to enable transition to new versions of signed objects over
time.
ContentTemplate ::= SEQUENCE {
version [0] INTEGER DEFAULT 0,
... }
The Internet standards track document that defines the specific RPKI Note that the signed object profile does not provide version numbers
object MUST specify the remaining fields, represented as ellipses for signed objects. Therefore, in order to facilitate transition to
(...). new versions of the signed objects over time, it is RECOMMENDED that
signed objects using this profile include a version number within
their 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.
skipping to change at page 10, line 46 skipping to change at page 10, line 40
the certificate is revoked by the authority that issued it). See [I- the certificate is revoked by the authority that issued it). See [I-
D.sidr-res-certs] for a complete specification of resource D.sidr-res-certs] for a complete specification of resource
certificate validity. certificate 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: Obtain an OID to be used for the eContentType 1. eContentType: A single OID to be used for both the eContentType
field in encapContentInfo. This OID uniquely identifies the type field and the Content-Type attribute. This OID uniquely
of signed object. identifies the type of signed object.
2. eContent: Define an ASN.1 syntax for the eContent field in
encapContentInfo. The syntax MUST consist of an ASN.1 SEQUENCE
whose first element is "version" expressed as an ASN.1 INTEGER.
3. Content-Type Attribute: The mandatory Content-Type Attribute 2. eContent: Define the syntax for the eContent field in
MUST have its attrValues field set to the same OID as encapContentInfo. This is the payload that contains the data
eContentType in item 1. specific to a given type of signed object.
4. 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 There is no assumption of confidentiality for the data in an RPKI
signed object. The integrity and authenticity of each signed signed object. The integrity and authenticity of each signed
object is based on the verification of a digital signature for object is based on the verification of a digital signature for
skipping to change at page 11, line 43 skipping to change at page 11, line 33
The authors wish to thank Charles Gardiner, Russ Housley, and The authors wish to thank Charles Gardiner, Russ Housley, and
Derek Kong for their help and contributions. Additionally, the Derek Kong for their help and contributions. Additionally, the
authors would like to thank Rob Austein, Roque Gagliano, Danny authors would like to thank Rob Austein, Roque Gagliano, Danny
McPherson, Sean Turner, and Sam Weiler for their careful reviews McPherson, Sean Turner, and Sam Weiler for their careful reviews
and helpful comments. and helpful comments.
8. Normative References 8. Normative References
[I-D.sidr-res-certs] Huston, G., Michaelson, G., and R. Loomans, "A [I-D.sidr-res-certs] Huston, G., Michaelson, G., and R. Loomans, "A
Profile for X.509 PKIX Resource Certificates", Profile for X.509 PKIX Resource Certificates",
draft-ietf-sidr-res-certs-18.txt (work in progress), May draft-ietf-sidr-res-certs (work in progress), December
2010. 2010.
[I-D.sidr-rpki-algs] Huston, G., "A Profile for Algorithms and Key [I-D.sidr-rpki-algs] Huston, G., "A Profile for Algorithms and Key
Sizes for use in the Resource Public Key Infrastructure", Sizes for use in the Resource Public Key Infrastructure",
draft-huston-sidr-rpki-algs-00.txt (work in progress), draft-ietf-sidr-rpki-algs (work in progress), November
July 2009. 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
skipping to change at page 12, line 25 skipping to change at page 12, line 15
[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 [I-D.sidr-arch] Lepinski, M. and S. Kent, "An Infrastructure to
Support Secure Internet Routing", Support Secure Internet Routing", draft-ietf-sidr-arch
draft-ietf-sidr-arch-11.txt (work in progress), September (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. 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.
Authors' Addresses Authors' Addresses
Matt Lepinski Matt Lepinski
BBN Technologies BBN Technologies
 End of changes. 14 change blocks. 
40 lines changed or deleted 33 lines changed or added

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