doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc6488.txt b/doc/rfc/rfc6488.txt
new file mode 100644
index 0000000..addd38c
--- /dev/null
+++ b/doc/rfc/rfc6488.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       M. Lepinski
+Request for Comments: 6488                                        A. Chi
+Category: Standards Track                                        S. Kent
+ISSN: 2070-1721                                                      BBN
+                                                           February 2012
+
+
+                       Signed Object Template for
+             the Resource Public Key Infrastructure (RPKI)
+
+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.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   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 (c) 2012 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
+   described in the Simplified BSD License.
+
+
+
+
+
+Lepinski, et al.             Standards Track                    [Page 1]
+
+RFC 6488               RPKI Signed Object Template         February 2012
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Terminology ................................................3
+      1.2. Note on Algorithms .........................................3
+   2. Signed Object Syntax ............................................3
+      2.1. Signed-Data Content Type ...................................4
+           2.1.1. version .............................................4
+           2.1.2. digestAlgorithms ....................................4
+           2.1.3. encapContentInfo ....................................4
+                  2.1.3.1. eContentType ...............................5
+                  2.1.3.2. eContent ...................................5
+           2.1.4. certificates ........................................5
+           2.1.5. crls ................................................5
+           2.1.6. signerInfos .........................................5
+                  2.1.6.1. version ....................................6
+                  2.1.6.2. sid ........................................6
+                  2.1.6.3. digestAlgorithm ............................6
+                  2.1.6.4. signedAttrs ................................6
+                           2.1.6.4.1. Content-Type Attribute ..........7
+                           2.1.6.4.2. Message-Digest Attribute ........7
+                           2.1.6.4.3. Signing-Time Attribute ..........7
+                           2.1.6.4.4. Binary-Signing-Time Attribute ...8
+                  2.1.6.5. signatureAlgorithm .........................8
+                  2.1.6.6. signatureValue .............................8
+                  2.1.6.7. unsigneAttrs ...............................8
+   3. Signed Object Validation ........................................8
+   4. Definition of Specific Signed Objects ..........................10
+   5. Security Considerations ........................................10
+   6. IANA Considerations ............................................11
+   7. Acknowledgements ...............................................11
+   8. Normative References ...........................................11
+   9. Informative References .........................................12
+
+1.  Introduction
+
+   The purpose of the Resource Public Key Infrastructure (RPKI) is to
+   support assertions by current resource holders of IP (v4 and v6)
+   address space and AS numbers, based on the records of organizations
+   that act as Certification Authorities (CAs).  IP address and AS
+   number resource information is carried in X.509 certificates via RFC
+   3779 extensions [RFC6487].  Other information assertions about
+   resources are expressed via digitally signed, non-X.509 data
+   structures that are referred to as "signed objects" in the RPKI
+   context [RFC6480].  This document standardizes a template for
+   specifying signed objects that can be validated using the RPKI.
+
+
+
+
+
+Lepinski, et al.             Standards Track                    [Page 2]
+
+RFC 6488               RPKI Signed Object Template         February 2012
+
+
+   RPKI signed objects make use of Cryptographic Message Syntax (CMS)
+   [RFC5652] as a standard encapsulation format.  CMS was chosen to take
+   advantage of existing open source software available for processing
+   messages in this format.  RPKI signed objects adhere to a profile
+   (specified in Section 2) of the CMS signed-data object.
+
+   The template defined in this document for RPKI signed objects is not
+   a complete specification for any particular type of signed object,
+   and instead includes only the items that are common to all RPKI
+   signed objects.  That is, fully specifying a particular type of
+   signed object requires an additional document that specifies the
+   details specific to a particular type of signed object.  Such details
+   include Abstract Syntax Notation One (ASN.1) [X.208-88] for the
+   object's payload and any additional steps required to validate the
+   particular type of signed object.  Section 4 describes in more detail
+   the additional pieces that must be specified in order to define a new
+   type of RPKI signed object that uses this template.  Additionally,
+   see [RFC6482] for an example of a document that uses this template to
+   specify a particular type of signed object, the Route Origination
+   Authorization (ROA).
+
+1.1.  Terminology
+
+   It is assumed that the reader is familiar with the terms and concepts
+   described in "Internet X.509 Public Key Infrastructure Certificate
+   and Certificate Revocation List (CRL) Profile" [RFC5280], "X.509
+   Extensions for IP Addresses and AS Identifiers" [RFC3779], and
+   "Cryptographic Message Syntax (CMS)" [RFC5652].
+
+   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 [RFC2119].
+
+1.2.  Note on Algorithms
+
+   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].
+
+2.  Signed Object Syntax
+
+   The RPKI signed object is a profile of the CMS [RFC5652] signed-data
+   object, with the restriction that RPKI signed objects MUST be encoded
+   using the ASN.1 Distinguished Encoding Rules (DER) [X.509-88].
+
+
+
+
+
+
+
+Lepinski, et al.             Standards Track                    [Page 3]
+
+RFC 6488               RPKI Signed Object Template         February 2012
+
+
+   The general format of a CMS object is:
+
+      ContentInfo ::= SEQUENCE {
+        contentType ContentType,
+        content [0] EXPLICIT ANY DEFINED BY contentType }
+
+      ContentType ::= OBJECT IDENTIFIER
+
+   The content-type is the signed-data type of id-data, namely the
+   id-signedData OID [RFC5652], 1.2.840.113549.1.7.2.
+
+2.1.  Signed-Data Content Type
+
+   According to the CMS standard, the signed-data content type is the
+   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
+
+   Additionally, the SignerInfos set MUST contain only a single
+   SignerInfo object.
+
+2.1.1.  version
+
+   The version is the syntax version number.  It MUST be 3,
+   corresponding to the signerInfo structure having version number 3.
+
+2.1.2.  digestAlgorithms
+
+   The digestAlgorithms set contains the OIDs of the digest algorithm(s)
+   used in signing the encapsulated content.  This set MUST contain
+   exactly one digest algorithm OID, and the OID MUST be selected from
+   those specified in [RFC6485].
+
+2.1.3.  encapContentInfo
+
+   encapContentInfo is the signed content, consisting of a content type
+   identifier and the content itself.  The encapContentInfo represents
+   the payload of the RPKI signed object.
+
+
+
+Lepinski, et al.             Standards Track                    [Page 4]
+
+RFC 6488               RPKI Signed Object Template         February 2012
+
+
+        EncapsulatedContentInfo ::= SEQUENCE {
+          eContentType ContentType,
+          eContent [0] EXPLICIT OCTET STRING OPTIONAL }
+
+        ContentType ::= OBJECT IDENTIFIER
+
+2.1.3.1.  eContentType
+
+   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
+   specified by the Internet Standards Track document that defines the
+   object.
+
+2.1.3.2.  eContent
+
+   This field is left undefined by this profile.  The eContent is the
+   payload of the signed object and MUST be specified by the Internet
+   Standards Track document that defines the RPKI object.
+
+   Note that the signed object profile does not provide version numbers
+   for signed objects.  Therefore, in order to facilitate transition to
+   new versions of the signed objects over time, it is RECOMMENDED that
+   each type of signed object defined using this profile include a
+   version number within its eContent.
+
+2.1.4.  certificates
+
+   The certificates field MUST be included, and MUST contain exactly one
+   certificate, the RPKI end-entity (EE) certificate needed to validate
+   this signed object.
+
+2.1.5.  crls
+
+   The crls field MUST be omitted.
+
+2.1.6.  signerInfos
+
+   SignerInfo is defined in CMS as:
+
+         SignerInfo ::= SEQUENCE {
+           version CMSVersion,
+           sid SignerIdentifier,
+           digestAlgorithm DigestAlgorithmIdentifier,
+           signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
+           signatureAlgorithm SignatureAlgorithmIdentifier,
+           signature SignatureValue,
+           unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
+
+
+
+
+Lepinski, et al.             Standards Track                    [Page 5]
+
+RFC 6488               RPKI Signed Object Template         February 2012
+
+
+2.1.6.1.  version
+
+   The version number MUST be 3, corresponding with the choice of
+   SubjectKeyIdentifier for the sid.
+
+2.1.6.2.  sid
+
+   The sid is defined as:
+
+         SignerIdentifier ::= CHOICE {
+           issuerAndSerialNumber IssuerAndSerialNumber,
+           subjectKeyIdentifier [0] SubjectKeyIdentifier }
+
+   For RPKI signed objects, the sid MUST be the SubjectKeyIdentifier
+   that appears in the EE certificate carried in the CMS certificates
+   field.
+
+2.1.6.3.  digestAlgorithm
+
+   The digestAlgorithm MUST consist of the OID of a digest algorithm
+   that conforms to the RPKI Algorithms and Key Size Profile
+   specification [RFC6485].
+
+2.1.6.4.  signedAttrs
+
+   The signedAttrs is defined as:
+
+         SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
+
+         Attribute ::= SEQUENCE {
+           attrType OBJECT IDENTIFIER,
+           attrValues SET OF AttributeValue }
+
+         AttributeValue ::= ANY
+
+   The signedAttrs element MUST be present and MUST include the content-
+   type and message-digest attributes [RFC5652].  The signer MAY also
+   include the signing-time attribute [RFC5652], the binary-signing-time
+   attribute [RFC6019], or both attributes.  Other signed attributes
+   MUST NOT be included.
+
+   The signedAttrs element MUST include only a single instance of any
+   particular attribute.  Additionally, even though the syntax allows
+   for a SET OF AttributeValue, in an RPKI signed object, the attrValues
+   MUST consist of only a single AttributeValue.
+
+
+
+
+
+
+Lepinski, et al.             Standards Track                    [Page 6]
+
+RFC 6488               RPKI Signed Object Template         February 2012
+
+
+2.1.6.4.1.  Content-Type Attribute
+
+   The content-type attribute MUST be present.  The attrType OID for the
+   content-type attribute is 1.2.840.113549.1.9.3.
+
+   The attrValues for the content-type attribute MUST match the
+   eContentType in the EncapsulatedContentInfo.  Thus, attrValues MUST
+   contain the OID that specifies the payload type of the specific RPKI
+   signed object carried in the CMS signed data structure.
+
+2.1.6.4.2.  Message-Digest Attribute
+
+   The message-digest attribute MUST be present.  The attrType OID for
+   the message-digest attribute is 1.2.840.113549.1.9.4.
+
+   The attrValues for the message-digest attribute contains the output
+   of the digest algorithm applied to the content being signed, as
+   specified in Section 5.4 of [RFC5652].
+
+2.1.6.4.3.  Signing-Time Attribute
+
+   The signing-time attribute MAY be present.  Note that the presence or
+   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 signing-time attribute is 1.2.840.113549.1.9.5.
+
+         id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
+             us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }
+
+   The attrValues for the signing-time attribute is defined as:
+
+         SigningTime ::= Time
+
+         Time ::= CHOICE {
+           utcTime UTCTime,
+           generalizedTime GeneralizedTime }
+
+   The Time element specifies the time, based on the local system clock,
+   at which the digital signature was applied to the content.
+
+   The definition of Time matches the one specified in the 1997 version
+   of X.509.  Additional information regarding the use of UTCTime and
+   GeneralizedTime can be found in [RFC5652].
+
+
+
+
+
+
+
+
+Lepinski, et al.             Standards Track                    [Page 7]
+
+RFC 6488               RPKI Signed Object Template         February 2012
+
+
+2.1.6.4.4.  Binary-Signing-Time Attribute
+
+   The binary-signing-time attribute MAY be present.  Note that the
+   presence or absence of the binary-signing-time attribute MUST NOT
+   affect the validity of the signed object (as specified in Section 3).
+   The attrType OID for the binary-signing-time attribute is
+   1.2.840.113549.1.9.16.2.46.
+
+         id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1)
+             member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
+             smime(16) aa(2) 46 }
+   The attrValues for the signing-time 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.
+   The precise definition of the BinaryTime element can be found in
+   [RFC6019].
+
+2.1.6.5.  signatureAlgorithm
+
+   The signatureAlgorithm MUST conform to the RPKI Algorithms and Key
+   Size Profile specification [RFC6485].
+
+2.1.6.6.  signature
+
+   The signature value is defined as:
+
+         SignatureValue ::= OCTET STRING
+
+   The signature characteristics are defined by the digest and signature
+   algorithms.
+
+2.1.6.7.  unsignedAttrs
+
+   unsignedAttrs MUST be omitted.
+
+3.  Signed Object Validation
+
+   Before a relying party can use a signed object, the relying party
+   MUST validate the signed object by verifying that all of the
+   following conditions hold.  A relying party may perform these checks
+   in any order.  Note that these checks are necessary, but not
+   sufficient.  In general, further validation MUST be performed based
+   on the specific type of signed object.
+
+
+
+Lepinski, et al.             Standards Track                    [Page 8]
+
+RFC 6488               RPKI Signed Object Template         February 2012
+
+
+   1.  The signed object syntax complies with this specification.  In
+       particular, each of the following is true:
+
+      a.  The content-type 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 certificates field in the SignedData object is present and
+          contains one EE certificate, the SubjectKeyIdentifier field of
+          which matches the sid field of the SignerInfo object.
+
+      d.  The crls field in the SignedData object is omitted.
+
+      e.  The version of the SignerInfo is 3.
+
+      f.  The signedAttrs field in the SignerInfo object is present and
+          contains both the content-type attribute (OID
+          1.2.840.113549.1.9.3) and the message-digest attribute (OID
+          1.2.840.113549.1.9.4).
+
+      g.  The signedAttrs field in the SignerInfo object does not
+          contain any attributes other than the following four: the
+          content-type attribute (OID 1.2.840.113549.1.9.3), the
+          message-digest attribute (OID 1.2.840.113549.1.9.4), the
+          signing-time attribute (OID 1.2.840.113549.1.9.5), and the
+          binary-signing-time attribute (OID
+          1.2.840.113549.1.9.16.2.46).  Note that the signing-time and
+          binary-signing-time attributes MAY be present, but they are
+          not required.
+
+      h.  The eContentType in the EncapsulatedContentInfo is an OID that
+          matches the attrValues in the content-type attribute.
+
+      i.  The unsignedAttrs field in the SignerInfo object is omitted.
+
+      j.  The digestAlgorithm in the SignedData and SignerInfo objects
+          conforms to the RPKI Algorithms and Key Size Profile
+          specification [RFC6485].
+
+      k.  The signatureAlgorithm in the SignerInfo object conforms to
+          the RPKI Algorithms and Key Size Profile specification
+          [RFC6485].
+
+      l.  The signed object is DER encoded.
+
+
+
+
+
+
+Lepinski, et al.             Standards Track                    [Page 9]
+
+RFC 6488               RPKI Signed Object Template         February 2012
+
+
+   2.  The public key of the EE certificate (contained within the CMS
+       signed-data object) can be used to successfully verify the
+       signature on the signed object.
+
+   3.  The EE certificate (contained within the CMS signed-data object)
+       is a valid EE certificate in the RPKI as specified by [RFC6487].
+       In particular, a valid certification path from a trust anchor to
+       this EE certificate exists.
+
+   If the above procedure indicates that the signed object is invalid,
+   then the signed object MUST be discarded and treated as though no
+   signed object were present.  If all of the conditions above are true,
+   then the signed object may be valid.  The relying party MUST then
+   perform any additional validation steps required for the particular
+   type of signed object.
+
+   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 end of the certificate's validity period is reached, or when
+   the certificate is revoked by the authority that issued it).  See
+   [RFC6487] for a complete specification of resource certificate
+   validity.
+
+4.  Definition of Specific Signed Objects
+
+   Each RPKI signed object MUST be defined in an Internet Standards
+   Track document based on this profile, by specifying the following
+   data elements and validation procedure:
+
+   1.  eContentType:  A single OID to be used for both the eContentType
+       field and the content-type attribute.  This OID uniquely
+       identifies the type of signed object.
+
+   2.  eContent:  Define the syntax for the eContent field in
+       encapContentInfo.  This is the payload that contains the data
+       specific to a given type of signed object.
+
+   3.  Additional Validation:  Define a set of additional validation
+       steps for the specific signed object.  Before using this specific
+       signed object, a relying party MUST perform both the generic
+       validation steps in Section 3 above, as well as these additional
+       steps.
+
+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 the object's digital signature, and
+
+
+
+Lepinski, et al.             Standards Track                   [Page 10]
+
+RFC 6488               RPKI Signed Object Template         February 2012
+
+
+   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 has created a registry of "RPKI Signed Objects" types that
+   utilize the template defined in this document.  This registry
+   contains 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 are managed by IETF
+   Standards Action.
+
+   The registry has been initially populated with the following two
+   entries.
+
+   Name      |    OID                      | Specification
+   ----------------------------------------------------------------
+   ROA       | 1.2.840.113549.1.9.16.1.24  | RFC 6482
+   Manifest  | 1.2.840.113549.1.9.16.1.26  | RFC 6486
+
+7.  Acknowledgements
+
+   The authors wish to thank Charles Gardiner, Russ Housley, and Derek
+   Kong for their help and contributions.  Additionally, the authors
+   would like to thank Rob Austein, Roque Gagliano, Danny McPherson,
+   Sean Turner, and Sam Weiler for their careful reviews and helpful
+   comments.
+
+8.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3779]  Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
+              Addresses and AS Identifiers", RFC 3779, June 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.
+
+   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
+              RFC 5652, September 2009.
+
+
+
+Lepinski, et al.             Standards Track                   [Page 11]
+
+RFC 6488               RPKI Signed Object Template         February 2012
+
+
+   [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
+              Syntax Notation One (ASN.1), 1988.
+
+   [X.509-88] CCITT.  Recommendation X.509: The Directory Authentication
+              Framework, 1988.
+
+9.  Informative References
+
+   [RFC6019]  Housley, R., "BinaryTime: An Alternate Format for
+              Representing Date and Time in ASN.1", RFC 6019, September
+              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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lepinski, et al.             Standards Track                   [Page 12]
+
+RFC 6488               RPKI Signed Object Template         February 2012
+
+
+Authors' Addresses
+
+   Matt Lepinski
+   BBN Technologies
+   10 Moulton Street
+   Cambridge MA 02138
+
+   EMail: mlepinski@bbn.com
+
+
+   Andrew Chi
+   BBN Technologies
+   10 Moulton Street
+   Cambridge MA 02138
+
+   EMail: achi@bbn.com
+
+
+   Stephen Kent
+   BBN Technologies
+   10 Moulton Street
+   Cambridge MA 02138
+
+   EMail: kent@bbn.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lepinski, et al.             Standards Track                   [Page 13]
+