draft-ietf-sidr-signed-object-03.txt   draft-ietf-sidr-signed-object-04.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: August 16, 2011 BBN Expires: November 9, 2011 BBN
February 16, 2011 May 9, 2011
Signed Object Template for the Resource Public Key Infrastructure Signed Object Template for the Resource Public Key Infrastructure
draft-ietf-sidr-signed-object-03.txt draft-ietf-sidr-signed-object-04.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/.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Abstract Abstract
This document defines a generic profile for signed objects used in This document defines a generic profile for signed objects used in
the Resource Public Key Infrastructure (RPKI). These RPKI signed the Resource Public Key Infrastructure (RPKI). These RPKI signed
objects make use of Cryptographic Message Syntax (CMS) as a standard objects make use of Cryptographic Message Syntax (CMS) as a standard
encapsulation format. encapsulation format.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . 8 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
The purpose of the Internet IP Address and Autonomous System (AS) The purpose of the Internet IP Address and Autonomous System (AS)
Number Resource Public Key Infrastructure (RPKI) system is to support Number Resource Public Key Infrastructure (RPKI) system is to support
assertions by current resource holders of IP (v4 and v6) address assertions by current resource holders of IP (v4 and v6) address
space and AS numbers, based on the records of the organizations that space and AS numbers, based on the records of the organizations that
act as Certification Authorities (CAs). IP address and AS number act as Certification Authorities (CAs). IP address and AS number
resource information is carried in X.509 certificates via RFC 3779 resource information is carried in X.509 certificates via RFC 3779
extensions [I-D.sidr-res-certs]. Other information assertions about extensions [I-D.sidr-res-certs]. Other information assertions about
skipping to change at page 10, line 22 skipping to change at page 10, line 22
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 [I-D.sidr-
res-certs]. In particular, there exists a valid certification res-certs]. In particular, there exists a valid certification
path from a trust anchor to this EE certificate. path from a trust anchor to this EE certificate.
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 the all of the conditions above are signed object were present. If all of the conditions above are
true, then the signed object may be valid. The relying party MUST true, then the signed object may be valid. The relying party MUST
then perform any additional validation steps required for the then perform any additional validation steps required for the
particular type of signed object. particular 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 [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.
skipping to change at page 11, line 19 skipping to change at page 11, line 19
object is based on the verification of a digital signature for object is based on the verification of a digital signature for
the object, and on the validation of the EE certificate used to the object, and on the validation of the EE certificate used to
perform that verification. It is anticipated that signed objects perform that verification. It is anticipated that signed objects
will be stored in repositories that will be publicly accessible. will be stored in repositories that will be publicly accessible.
Since RPKI signed objects make use of CMS as an encapsulation Since RPKI signed objects make use of CMS as an encapsulation
format, the security considerations for CMS apply [RFC5652]. format, the security considerations for CMS apply [RFC5652].
6. IANA Considerations 6. IANA Considerations
None. IANA is requested to create a registry of signed objects types
that utilize the template defined in this document. This registry
shall contain three fields, an informal name for the signed
object, the 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 shall be
managed by IETF Standards Action.
The registry shall be initially populated with the following two
entries.
Name | OID | Specification
----------------------------------------------------------------
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-
rpki-manifests are published as RFCs, IANA is requested to
replace the Internet Draft names in the registry with the RFC
numbers of corresponding RFCs.
7. Acknowledgements 7. Acknowledgements
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
 End of changes. 5 change blocks. 
37 lines changed or deleted 56 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/