One document matched: draft-ietf-sidr-rpki-manifests-02.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<rfc category="std" docName="draft-ietf-sidr-rpki-manifests-02.txt" ipr="full3978">
  <front>
    <title abbrev="RPKI Manifests">Manifests for the Resource Public Key Infrastructure</title>

    <author fullname="Rob Austein" initials="R." surname="Austein">
     <organization abbrev="ISC">Internet Systems Consortium</organization>
     <address>
      <postal>
       <street>950 Charter St.</street>
       <city>Redwood City</city>
       <region>CA</region>
       <code>94063</code>
       <country>USA</country>
      </postal>
      <email>sra@isc.org</email>
     </address>
    </author>

    <author fullname="Geoff Huston" initials="G." surname="Huston">
      <organization abbrev="APNIC">Asia Pacific Network Information
      Centre</organization>
      <address>
        <postal>
        <street>33 park Rd.</street>
        <city>Milton</city>
        <region>QLD</region>
        <code>4064</code>
        <country>Australia</country>
        </postal>

        <email>gih@apnic.net</email>

        <uri>http://www.apnic.net</uri>
      </address>
    </author>

    <author fullname="Stephen Kent" initials="S." surname="Kent">
     <organization abbrev="BBN">BBN Technologies</organization>
     <address>
      <postal>
       <street>10 Moulton St.</street>
       <city>Cambridge</city>
       <region>MA</region>
       <code>02138</code>
       <country>USA</country>
      </postal>
      <email>kent@bbn.com</email>
     </address>
    </author>

    <author fullname="Matt Lepinski" initials="M." surname="Lepinski">
     <organization abbrev="BBN">BBN Technologies</organization>
     <address>
      <postal>
       <street>10 Moulton St.</street>
       <city>Cambridge</city>
       <region>MA</region>
       <code>02138</code>
       <country>USA</country>
      </postal>
      <email>mlepinski@bbn.com</email>
     </address>
    </author>


    <date year="2008" />

    <area>Routing Area</area>

    <workgroup>Secure Inter-Domain Routing</workgroup>

    <abstract>
      <t>This document defines a "manifest" for use in the Resource
      Public Key Infrastructure. A "manifest" is a signed object that
      contains a listing of all the signed objects in the repository
      publication point associated with an authority responsible for
      publishing in the repository. For each certificate, or other
      forms of signed objects issued by the authority that are
      published at this repository publication point, the manifest
      contains both the name of the file containing the object, and a
      hash of the file content. Manifests are intended to expose
      potential attacks against relying parties of the RPKI, such as a
      man-in-the middle withholding repository data or replaying stale
      repository data.</t>
    </abstract>
  </front>

  <middle>
   <section title="Introduction">

    <t>The Resource PKI (RPKI) <xref target="ID.SIDR-ARCH" /> makes
    use of a distributed repository system <xref
    target="ID.SIDR-REPOSITORY" /> to make available a variety of
    objects needed by relying parties (RPs) such as Internet service
    providers (ISPs). Because all of the objects stored in the
    repository system are digitally signed by the entities that
    created them, attacks that modify these objects are detectable by
    RPs. However, digital signatures provide no protection against
    attacks that substitute "stale" versions of signed objects (i.e.,
    objects that were valid but have since been superceded) or attacks
    that remove an object that should be present in the repository. To
    assist in the detection of such attacks, the RPKI repository
    system will make use of a new signed object called a
    "manifest."</t>

    <t>A manifest is an object that lists of all of the other signed
    objects issued by the authority responsible for a publication
    point in the repository system.  For each certificate, Certificate
    Revocation List (CRL), or other signed object, such as a Route
    Origination Authority (ROA), issued by the authority, the manifest
    contains both the name of the file containing the object, and a
    hash of the file content.  Manifests allow a RP to obtain
    sufficient information to detect whether the retrieval of objects
    from an RPKI repository has been compromised by unauthorized
    object removal, or by the substitution of "stale" versions of
    objects. Manifests are designed to be used both for Certification
    Authority (CA) publication points in repositories, that contain
    subordinate certificates, CRLs and other signed objects, and End
    Entity (EE) publication points in repositories that contain signed
    objects.</t>

    <t>Manifests are modelled on CRLs, as the issues involved in
    detecting stale manifests, and detection of potential attacks
    using manifest replays, etc are similar to those for CRLs.  The
    syntax of the manifest payload differs from CRLs, since RPKI
    repositories can contain objects not covered by CRLs, such as
    digitally signed objects, such as ROAs.</t>

    <section title="Terminology">

     <t>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" <xref
     target="RFC5280"/>and "X.509 Extensions for IP Addresses and AS
     Identifiers" <xref target="RFC3779"/>.</t>

     <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
     NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     RFC 2119.</t>

    </section>
   </section>
   <section title="Manifest Scope and Syntax">

    <section title="Manifest Scope">

     <t>In the case of a CA's manifest of its associated publication
     repository in the scope of the Resource Certificate PKI (RPKI),
     the manifest contains the current published certificates issued
     by this CA, the most recent CRLs that are associated with the
     CA's non-revoked keypairs, and all objects that are signed using
     a "single-use" EE certificate, where the EE certificate was
     issued by this CA.</t>

     <t>In the case where an EE has a defined publication repository,
     the EE's manifest contains all published objects that have
     been signed by the EE's key pair.</t>

    </section>
    <section title="Manifest Syntax">

     <t>A manifest is a Cryptographic Message Syntax (CMS) <xref
     target="RFC3852" /> signed-data object. The general format of a
     CMS object is:</t>

     <figure>
      <artwork><![CDATA[
   ContentInfo ::= SEQUENCE {
        contentType ContentType,
        content [0] EXPLICIT ANY DEFINED BY contentType }

   ContentType ::= OBJECT IDENTIFIER
   ]]></artwork>
     </figure>

  
   <t>A Manifest is a signed-data object. The ContentType used is the
   signed-data type of id-data, namely the id-signedData OID,
   1.2.840.113549.1.7.2. <xref target="RFC3852" /></t>

   <section title="Signed-Data Content Type">

   <t>According to the CMS specification, signed-data content types
   shall have the ASN.1 type SignedData:</t>

     <figure>
      <artwork><![CDATA[
   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 
   ]]></artwork>
     </figure>

    <section title="version">

    <t>The version is the syntax version number. It MUST be 3,
    corresponding to the signerInfo structure having version number
    3.</t>

     </section>
     <section title="digestAlgorithms">

     <t>The digestAlgorithms set MUST include only SHA-256, the OID
     for which is 2.16.840.1.101.3.4.2.1 <xref target="RFC4055" />. It
     MUST NOT contain any other algorithms.</t>

     </section>
     <section title="encapContentInfo">

     <t>encapContentInfo is the signed content, consisting of a
     content type identifier and the content itself.</t>

        <figure>
          <artwork>
     EncapsulatedContentInfo ::= SEQUENCE { 
       eContentType ContentType, 
       eContent [0] EXPLICIT OCTET STRING OPTIONAL } 
   
     ContentType ::= OBJECT IDENTIFIER 
         </artwork>
        </figure>

     <section title="eContentType">

    <t>The eContentType for a Manifest is defined
    as id-ct-rpkiManifest, and has the numerical value of
    1.2.840.113549.1.9.16.1.26.</t>

        <figure>
          <artwork>
      id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 
                                rsadsi(113549) pkcs(1) pkcs9(9) 16 } 
    
      id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 
    
      id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 
         </artwork>
        </figure>

      </section> 
      <section title="eContent" >
      <t>The content of a Manifest is defined as follows:</t>

     <figure>
      <artwork><![CDATA[
   Manifest ::= SEQUENCE {
        version     [0] INTEGER DEFAULT 0,
        manifestNumber  INTEGER,
        thisUpdate      GeneralizedTime,
        nextUpdate      GeneralizedTime,
        fileHashAlg     OBJECT IDENTIFIER,
        fileList        SEQUENCE OF (SIZE 0..MAX) FileAndHash
    }

    FileAndHash ::=     SEQUENCE {
        file            IA5String
        hash            BIT STRING
    }
   ]]></artwork>
     </figure>

      <section title="Manifest">
      <t>The manifestNumber, thisUpdate, and nextUpdate fields are
      modelled after the corresponding fields in X.509 CRLs (see <xref
      target="RFC5280" />). Analogous to CRLS, a manifest is
      nominally valid until the time specified in nextUpdate or until
      a manifest is issued with a greater manifest number, whichever
      comes first.  The revoked EE certificate for the previous
      manifest's signature will be removed from the CRL when it
      expires.</t>

      <t>To prevent needless growth of CRLs, it is RECOMMENDED that
      the EE certificate used to issue a manifest have an validity
      period that coincides with the interval from thisUpdate to
      nextUpdate.</t>
      <section title="version">
      <t>The version number of the rpkiManifest MUST be 0.</t>
      </section>
      <section title="manifestNumber">
      <t>The manifestNumber field is a sequence number that is
      incremented each time a new manifest is issued for a given
      publication point. This field is used to allow a RP to detect
      gaps in a sequence of published manifest.</t>
      </section>
      <section title="thisUpdate">
      <t>The thisUpdate field contains the time when the manifest was
      created.</t>
      </section>
      <section title="nextUpdate">
      <t>The nextUpdate field contains the time at which the next
      scheduled manifest will be issued. The value of nextUpdate MUST
      be later than the value of thisUpdate. If the authority alters
      any of the items in the repository publication point, then the
      authority MUST issue a new manifest before the nextUpdate
      time. In such a case, when the authority issues the new
      manifest, it MUST also issue a new CRL that includes the EE
      certificate corresponding to the old manifest.</t>
      </section>
      <section title="fileHashAlg">
      <t>The fileHashAlg field contains the OID of the hash algorithm
      used to hash the files that the authority has placed into the
      repository. The mandatory to implement hash algorithm is SHA-256
      and its OID is 2.16.840.1.101.3.4.2.1. <xref target="RFC4055"
      />.</t>
      </section>
      <section title="fileList">
      <t>The fileList field contains a sequence of FileAndHash pairs,
      one for each currently valid signed object that has been issued
      by the authority. Each FileAndHash pair contains the name of the
      file in the repository that contains the object in question, and
      a hash of the file's contents.</t>
      </section>
      </section>
      </section>
      </section>
      <section title="certificates">

      <t>The certificates field MUST be included, and MUST contain the
      RPKI end entity certificate needed to validate this Manifest in
      the context of the RPKI.</t>
      </section>
      <section title="crls">
      <t>This field MUST be omitted.</t>
      </section>
      <section title="signerInfos">
      <t>Signer Infos is defined as a SignerInfo, which is defined under CMS as:</t>

        <figure>
          <artwork>
      SignerInfo ::= SEQUENCE { 
        version CMSVersion, 
        sid SignerIdentifier, 
        digestAlgorithm DigestAlgorithmIdentifier, 
        signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 
        signatureAlgorithm SignatureAlgorithmIdentifier, 
        signature SignatureValue, 
        unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 
         </artwork>
        </figure>

      <section title="version">
      <t>The version number MUST be 3, corresponding with the choice
      of SubjectKeyIdentifier for the sid.</t>
      </section>
      <section title="sid">
      <t>The sid is defined as:</t>
        <figure>
          <artwork>
      SignerIdentifier ::= CHOICE { 
        issuerAndSerialNumber IssuerAndSerialNumber, 
        subjectKeyIdentifier [0] SubjectKeyIdentifier } 
         </artwork>
        </figure>
      <t>For a Manifest, the sid MUST be a SubjectKeyIdentifier.</t>
      </section>
      <section title="digestAlgorithm">
      <t>The digestAlgorithm MUST be SHA-256, the OID for which is 2.16.840.1.101.3.4.2.1. 
      <xref target="RFC4055" /></t>
      </section>
      <section title="signedAttrs">
      <t>The signedAttrs is defined as signedAttributes:</t>
        <figure>
          <artwork>
      SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

      UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute

      Attribute ::= SEQUENCE {
        attrType OBJECT IDENTIFIER,
        attrValues SET OF AttributeValue }

      AttributeValue ::= ANY
         </artwork>
        </figure>

      <t>The signedAttr element MUST be present and MUST include the
      content-type and message-digest attributes. The signer MAY also
      include the signing-time signed attribute, the
      binary-signing-time signed attribute, or both signing-time
      attributes. Other signed attributes that are deemed appropriate
      MAY also be included. The intent is to allow additional signed
      attributes to be included if a future need is identified. This
      does not cause an interoperability concern because unrecognized
      signed attributes are ignored by the relying party.</t>

      <t>The signedAttr MUST include only a single instance of any
      particular attribute. Additionally, even though the syntax
      allows for a SET OF AttributeValue, in a Manifest the attrValues
      MUST consist of only a single AttributeValue.</t>

      <section title="Content-Type Attribute">
      <t>The ContentType attribute MUST be present. The attrType OID
      for the ContentType attribute is 1.2.840.113549.1.9.3.</t>

      <t>The attrValues for the ContentType attribute in a Manifest
      MUST be 1.2.840.113549.1.9.16.1.26, matching the eContentType in
      the EncapsulatedContentInfo.</t>
      </section>
      <section title="Message-Digest Attribute">

      <t>The MessageDigest Attribute MUST be present. The attrType OID
      for the MessageDigest Attribute is 1.2.840.113549.1.9.4.</t>

      <t>The attrValues for the MessageDigest attribute contains the
      output of the digest algorithm applied to the content being
      signed, as specified in Section 11.1 of <xref target="RFC3852"
      />.</t>

      </section>
      <section title="SigningTime Attribute">

       <t>The SigningTime attribute MAY be present. The presence of
       absence of the SigningTime attribute in no way affects the
       validation of the Manifest (as specified in Section 5).</t>

       <t> The attrType OID for the SigningTime attribute is
       1.2.840.113549.1.9.5.</t>

       <t>The attrValues for the SigningTime attribute is defined
       as:</t>

        <figure>
          <artwork>
      id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }

      SigningTime ::= Time

      Time ::= CHOICE {
        utcTime UTCTime,
        generalizedTime GeneralizedTime }
         </artwork>
        </figure>

       <t>The Time element specifies the time, based on the local
       system clock, at which the digital signature was applied to the
       content.</t>

       </section>
       <section title="BinarySigningTime Attribute">

      <t>The signer MAY include a BinarySigningTime attribute,
      specifying the time at which the digital signature was applied
      to the content. If both the BinarySigningTime and SigningTime
      attributes are present, the time that is represented by the
      binary-signing-time attribute MUST represent the same time value
      as the signing-time attribute. The presence or absence of the
      Binary-SigningTime attribute in no way affects the validation of
      the Manifest (as specified in Section 5).</t>

      <t>The binary-signing-time attribute is defined in <xref
      target="RFC4049" /> as:</t>

        <figure>
          <artwork>
      id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1)
          member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
          smime(16) aa(2) 46 }

      BinarySigningTime ::= BinaryTime

      BinaryTime ::= INTEGER (0..MAX)
         </artwork>
        </figure>


      </section>
      </section>
      <section title="signatureAlgorithm">

       <t>The signatureAlgorithm MUST be RSA (rsaEncryption), the OID
       for which is 1.2.840.113549.1.1.1.</t>

      </section>
      <section title="signature">

      <t>The signature value is defined as:</t>

        <figure>
          <artwork>
          SignatureValue ::= OCTET STRING 
         </artwork>
        </figure>

      <t>The signature characteristics are defined by the digest and signature algorithms.</t>

      </section>
       <section title="unsignedAttrs">

      <t>unsignedAttrs MUST be omitted.</t>

      </section>
      </section>
      </section>
      <section title="ASN.1">

      <t>The following is the ASN.1 specification of the CMS-signed
      Manifest.</t>

        <figure>
          <artwork>
      ContentInfo ::= SEQUENCE { 
        contentType ContentType, 
        content [0] EXPLICIT ANY DEFINED BY contentType } 
    
      ContentType ::= OBJECT IDENTIFIER 

      id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 
                                rsadsi(113549) pkcs(1) pkcs9(9) 16 } 
    
      id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 
    
      id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } 

      Manifest ::= SEQUENCE {
           version     [0] INTEGER DEFAULT 0,
           manifestNumber  INTEGER,
           thisUpdate      GeneralizedTime,
           nextUpdate      GeneralizedTime,
           fileHashAlg     OBJECT IDENTIFIER,
           fileList        SEQUENCE OF (SIZE 0..MAX) FileAndHash}

       FileAndHash ::=     SEQUENCE {
           file            IA5String
           hash            BIT STRING}

      id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
                         us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }

      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 

      SignerInfo ::= SEQUENCE { 
        version CMSVersion, 
        sid SignerIdentifier, 
        digestAlgorithm DigestAlgorithmIdentifier, 
        signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 
        signatureAlgorithm SignatureAlgorithmIdentifier, 
        signature SignatureValue, 
        unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 

      SignerIdentifier ::= CHOICE { 
        issuerAndSerialNumber IssuerAndSerialNumber, 
        subjectKeyIdentifier [0] SubjectKeyIdentifier } 

      SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

      UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute

      Attribute ::= SEQUENCE {
        attrType OBJECT IDENTIFIER,
        attrValues SET OF AttributeValue }

      AttributeValue ::= ANY

      SignatureValue ::= OCTET STRING 

      id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }

      ContentType ::= OBJECT IDENTIFIER

      id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }

      MessageDigest ::= OCTET STRING

      id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }

      SigningTime ::= Time

      Time ::= CHOICE {
        utcTime UTCTime,
        generalizedTime GeneralizedTime }

      id-aa-binarySigningTime OBJECT IDENTIFIER ::= { iso(1)
          member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
          smime(16) aa(2) 46 }

      BinarySigningTime ::= BinaryTime

      BinaryTime ::= INTEGER (0..MAX)
         </artwork>
        </figure>


      </section>
      </section>
   </section>
   <section title="Manifest Generation">
    <section title="CA Manifest Generation">

    <t>Each CA in the RPKI publishes the certificates and CRLs it
    issues at a publication point in the RPKI repository system. To
    create a manifest, each CA MUST perform the following
    steps:<vspace blankLines="2" />

     <list style="numbers">

      <t>Generate a key pair.<vspace blankLines="1" /> </t>

      <t>Issue a "single use" EE certificate for this key pair to
      enable relying parties to verify the signature on the
      manifest.<vspace blankLines="1" />

       <list style="symbols">

        <t>This EE certificate has an SIA extension access description
        field with an accessMethod OID value of id-ad-signedobject
        where the associated accessLocation references the publication
        point of the manifest as an object URL.<vspace blankLines="1" /> </t>

        <t>This EE certificate SHOULD describe its IP number resources
        using the "inherit" attribute rather than explicit description
        of a resource set.<vspace blankLines="1" /> </t>

        <t>The validity times of the EE certificate SHOULD exactly
        match the thisUpdate and nextUpdate times of the manifest, and
        MUST encompass the interval from thisUpdate to nextUpdate.
        <vspace blankLines="1" /> </t>
       </list>
      </t>

      <t>The EE certificate SHOULD NOT be published in the authority's
      repository publication point.<vspace blankLines="2" /> </t>

      <t>Construct the Manifest content. Note that the manifest does
      not include a self reference (i.e., its own file name and hash),
      since it would be impossible to compute the hash of the manifest
      itself prior to it being signed.<vspace blankLines="1" /> </t>

      <t>Encapsulate the Manifest content using the CMS SignedData
      content type (as specified in Section 2), sign the manifest
      using the EE certificate, and publish the manifest in repository
      system publication point that is described by the
      manifest.<vspace blankLines="1" /> </t>

      <t>The private key associated with the EE certificate SHOULD
      now be destroyed.<vspace blankLines="1" /> </t>
     </list>
    </t>
    </section>
    <section title="End Entity Manifest Generation">

      <t>EE repository publication points are only used in conjunction
      with "multi-use" EE Certificates. In this case the EE
      Certificate has two accessMethods specified in its SIA
      field. The id-ad-signedObjectRepository accessMethod has an
      associated accessLocation that points to the repository
      publication point of the objects signed by this EE certificate,
      as specified in <xref target="ID.SIDR-CERTPROFILE" />. The
      id-ad-rpkiManifest accessMethod has an associated access
      location that points to the manifest object as an object URL,
      that is associated with this repository publication point. This
      manifest describes all the signed objects that are to be found
      in that publication point that have been signed by this EE
      certificate, and the hash value of each product (excluding the
      manifest itself).</t>

      <t>To create a manifest, each "multi-use" EE MUST perform the following
      steps:.<vspace blankLines="1" />

       <list style="symbols">

      <t>Construct the Manifest content. Note that the manifest does
      not include a self reference (i.e., its own file name and hash),
      since it would be impossible to compute the hash of the manifest
      itself prior to it being signed.<vspace blankLines="1" /> </t>

      <t>Encapsulate the Manifest content using the CMS SignedData
      content type (as specified in Section 2), sign the manifest
      using the EE certificate, and publish the manifest in repository
      system publication point that is described by the
      manifest.<vspace blankLines="1" /> </t>
     </list>
    </t>

    <t>"Single Use" EE certificates do not have repository publication
    points.  The object signed by the "Single Use" EE certificate is
    published in the repository publication point of the CA
    certificate that issued the EE certificate, and is listed in the
    corresponding manifest for this CA certificate.
    </t>
    </section>
    <section title="Common Considerations for Manifest Generation">

    <t>
     <list style="symbols">

    <t>A new manifest MUST be issued on or before the nextUpdate
    time.</t>

    <t>An authority MUST issue a new manifest in conjunction with the
    finalization of changes made to objects in the publication
    point. An authority MAY perform a number of object operations on a
    publication repository within the scope of a repository change
    before issuing a single manifest that covers all the operations
    within the scope of this change. Repository operators SHOULD
    implement some form of synchronization function on the repository
    to ensure that relying parties who are performing retrieval
    operations on the repository are not exposed to intermediate
    states during changes to the repository and the associated
    manifest.</t>

    <t>Since the manifest object URL is included in the SIA of issued
    certificates then a new manifest MUST NOT invalidate the manifest
    object URL of previously issued certificates. This implies that
    the manifest's publication name in the repository, in the form of
    an object URL, is one that is unchanged across manifest generation
    cycles.</t>

    <t>As the manifest scope is all signed objects associated with an
    authority responsible for a publication point, the manifest must
    persist across key rollover events. This implies that this
    persistent repository publication name cannot be derived from the
    authority's current public key value in any way.</t>

    <t>In the case of a CA publication point manifest, when the CA is
    performing a key rollover, the CA will use its new private key to
    sign an EE certificate for a new manifest. The new manifest will
    list all products of the CA that have been signed with the
    new private key. The new manifest will start a new serial number
    sequence. As long as there are published products that have been
    signed with the to-be-retired key, the old CA associated with this
    to-be-retired key will continue to generate manifests that describe
    all published products of the to-be-retired key and associated
    CA certificate. There is no manifest overlap.</t>

    <t>In the case of a EE publication point manifest, when the EE
    certificate is re-keyed, a new publication point is established. A
    new EE certificate for manifest validation will be generated by
    the CA that issues the new EE certificate associated with the new
    publication point. In this case there is no manifest overlap, as
    the new repository publication point will have a distinct
    manifest.</t>
    </list>
    </t>
   </section>
   </section>

   <section title="Processing Certificate Requests">

    <t>When an EE certificate is intended for use in verifying
    multiple objects, the certificate request for the EE certificate
    MUST include in the SIA of the request an access method OID of
    id-ad-signedObjectRepository where the associated access location
    refers to the publication point for objects signed by this EE
    certificate, and MUST include in the SIA of the request an access
    method OID of id-ad-rpkiManifest, where the associated access
    location refers to the publication point of the manifest that is
    associated with published objects that are verified using this EE
    certificate <xref target="ID.SIDR-CERTPROFILE"/>. The issuer SHOULD
    honour these values in the issued certificate or MUST reject the
    Certificate Request.</t>

    <t>When an EE certificate is used to sign a single object, the
    certificate request for the EE certificate MUST include in the SIA
    of the request an access method OID of id-ad-signedObject, where
    the associated access location refers to the publication point of
    the single object that is verified using this EE certificate. The
    certificate request MUST NOT include in the SIA of the request the
    access method OID of id-ad-rpkiManifest. The issuer SHOULD honour
    these values in the issued certificate or MUST reject the
    Certificate Request.</t>

    <t>In accordance with the provisions of <xref
    target="ID.SIDR-CERTPROFILE"/>, all certificate issuance requests
    for a CA certificate SHOULD include in the SIA of the request the
    id-ad-caRepository access method, and also the id-ad-rpkiManifest
    access method that references the intended publication point of
    the manifest in the associated access location in the request. The
    issuer SHOULD honour these values in the issued certificate or MUST
    reject the Certificate Request.</t>

   </section>


   <section title="Manifest Validation">

    <t>To determine whether a manifest is valid, the relying party
    must perform the following checks:<vspace blankLines="1" />

    <list style="numbers">
    <t>Verify that the Manifest complies with this specification. In
    particular, verify the following:<vspace blankLines="1" />

    <list style="letters">

    <t>The contentType of the CMS object is SignedData (OID
    1.2.840.113549.1.7.2)<vspace blankLines="1" /></t>

    <t>The version of the SignedData object is 3.<vspace blankLines="1" /></t>

    <t>The digestAlgorithm in the SignedData object is SHA-256 (OID
    2.16.840.1.101.3.4.2.1).<vspace blankLines="1" /></t>

    <t>The certificates field in the SignedData object is present and
    contains an EE certificate whose Subject Key Identifier (SKI)
    matches the sid field of the SignerInfo object.<vspace
    blankLines="1" /></t>

    <t>The crls field in the SignedData object is omitted.<vspace blankLines="1" /></t>

    <t>The eContentType in the EncapsulatedContentInfo is
    id-ad-rpkiManifest (OID 1.2.840.113549.1.9.16.1.26).<vspace
    blankLines="1" /></t>

    <t>The version of the rpkiManifest is 0.<vspace blankLines="1" /></t>

    <t>In the rpkiManifest, thisUpdate precedes nextUpdate.<vspace blankLines="1" /></t>

    <t>The version of the SignerInfo is 3.<vspace blankLines="1" /></t>

    <t>The digestAlgorithm in the SignerInfo object is SHA-256 (OID
    2.16.840.1.101.3.4.2.1).<vspace blankLines="1" /></t>

    <t>The signatureAlgorithm in the SignerInfo object is RSA (OID
    1.2.840.113549.1.1.1).<vspace blankLines="1" /></t>

    <t>The signedAttrs field in the SignerInfo object is present and
    contains both the ContentType attribute (OID 1.2.840.113549.1.9.3)
    and the MessageDigest attribute (OID 1.2.840.113549.1.9.4).<vspace
    blankLines="1" /></t>

    <t>The unsignedAttrs field in the SignerInfo object is omitted. <vspace blankLines="1" /></t>
    </list>
    <vspace blankLines="1" /></t>

    <t>Use the public key in the EE certificate to verify the
    signature on the Manifest.<vspace blankLines="1" /></t>

    <t>Verify that the EE certificate is a valid end-entity
    certificate in the resource PKI by constructing a valid
    certificate path to a trust anchor. (See [ID.RESCERT] for more
    details.)<vspace blankLines="1" /></t>
    </list>
    </t>

    <t>If the above procedure indicates that the manifest is invalid,
    then the manifest MUST be discarded and treated as though no
    manifest were present.</t>

   </section>

  <section title="Relying Party Use of Manifests">

   <t>The goal of the relying party is to determine which signed
   objects to use for routing-related tasks, (e.g. which ROAs to use
   in the construction of route filters). Ultimately, this is a matter
   of local policy. However, in the following sections, we describe a
   sequence of tests that the relying party should perform to
   determine the manifest state of the given publication point. We
   then discuss the risks associated with using signed objects in the
   publication point, given the manifest state; and provide suitable
   warning text that should placed in a user-accessible log file. It
   is the responsibility of the relying party to weigh these risks
   against the risk of routing failure that could occur if valid data
   is rejected, and construct a suitable local policy. Note that if a
   certificate is deemed unfit for use do to local policy, then any
   descendent object that is validated using this certificate should
   also be deemed unfit for use (regardless of the status of the
   manifest at its own publication point).</t>

   <section title="Tests for Determining Manifest State">

    <t>For a given publication point, the relying party should perform
    the following tests to determine the manifest state of the
    publication point:<vspace blankLines="1" />
    <list style="numbers">

     <t>Select the manifest having highest manifestNumber among all
     valid manifests (where manifest validity is defined in Section
     5).<vspace blankLines="1" />
     <list style="symbols">

      <t>If the publication point does not contain a valid manifest,
      see Section 6.2. (Lacking a valid manifest, the following tests
      cannot be performed).<vspace blankLines="1" /></t>

      </list></t>

     <t>Check that the current time is between thisUpdate and
     nextUpdate.<vspace blankLines="1" />

     <list style="symbols">

      <t>If the current time does not lie in this interval then see
      Section 6.4 (but still continue with the following
      tests).<vspace blankLines="1" /></t>

     </list></t> 

     <t>Check that every file at the publication point appears on the
     manifest, and that every file on the manifest appears at the
     publication point.<vspace blankLines="1" />

     <list style="symbols">

      <t>If there exists files at the publication point that do not
      appear on the manifest, or files on the manifest that do not
      appear at the publication point then see Section 6.5 (but still
      continue with the following test). <vspace blankLines="1" /></t>
     </list></t> 

     <t>Check that the hash of every file listed on the manifest
     matches the value obtained by hashing the file in at the
     publication point.<vspace blankLines="1" />

     <list style="symbols">

      <t>If there exist files at the publication point whose hash does
      not match the hash value listed in the manifest, then see
      Section 6.6.<vspace blankLines="1" /></t>

     </list></t> 
    </list></t>

     <t>For a particular signed object, if (A) the manifest for its
     publication passes all of the above checks; (B) the signed object
     is valid; and (C) the manifests for every certificate on the
     certificate path used to validate the signed object pass all of
     the above checks; then the relying party can conclude that no
     attack against the repository system has compromised the given
     signed object and the signed object MUST be treated as valid.</t>

    </section>
    <section title="Missing Manifests">

     <t>The absence of a valid manifest at a publication could occur
     due to an error by the publisher or due to (malicious or
     accidental) deletion or corruption of all valid manifests.</t>

     <t>When no valid manifest is available, there is no protection
     against attacks that delete signed objects or replay old versions
     of signed objects. All signed objects at the publication point,
     and all descendent objects that are validated using a certificate
     at this publication point should be viewed as somewhat suspect,
     but may be used by the relying party as per local policy.</t>

     <t>The primary risk in using signed objects at this publication
     point is that a deleted CRL causes the relying party to
     improperly treat a revoked certificate as valid. This risk is
     somewhat mitigated if the CRL for this publication point has a
     short time between thisUpdate and nextUpdate (and the current
     time is within this interval). The risk in discarding signed
     objects at this publication point is that the relying party may
     incorrectly discard a large number of valid objects. This gives
     significant power to an adversary that is able to corrupt all
     manifests at the publication point.</t>

     <t>Regardless of whether signed objects from this publication are
     deemed fit for use by the relying party, this situation should
     result in a warning to the effect that: "No manifest is available
     for <pub point name>, and thus there may have been
     undetected deletions from the publication point."</t>

    </section>
    <section title="Invalid Manifests">

     <t>The presence of invalid manifests at a publication point could
     occur due to an error by the publisher or due to (malicious or
     accidental) corruption of a valid manifest. An invalid manifest
     MUST never be used even if the manifestNumber is greater than
     that on valid manifests.</t>

     <t>There are no risks associated with using signed objects at a
     publication point containing an invalid manifest, provided that a
     valid manifest is also present.</t>

     <t>If an invalid manifest is present at a publication point that
     also contains one or more valid manifests, this situation should
     result in a warning to the effect that: "An invalid manifest was
     found at <pub point name>, this indicates an attack against
     the publication point or an error by the publisher. Processing
     for this publication point will continue using the most recent
     valid manifest."</t>

    </section>
    <section title="Stale Manifests">

     <t>A manifest is considered stale if the current time is after
     the nextUpdate time for the manifest. This could be due to
     publisher failure to promptly publish a new manifest, or due to
     (malicious or accidental) corruption of a more recent
     manifest.</t>

     <t>All signed objects at the publication point, and all
     descendent objects that are validated using a certificate at this
     publication point should be viewed as somewhat suspect, but may
     be used by the relying party as per local policy.</t>

     <t>The primary risk in using signed objects at this publication
     point is that a newer manifest exists that, if present, would
     indicate that certain objects are have been removed or
     replaced. (E.g. the new manifest if present might show the
     existence of a newer CRL and the removal of several revoked
     certificates). Thus use of objects on a stale manifest may cause
     the relying party to incorrectly treat several invalid objects as
     valid. The risk is that a stale CRL causes the relying party to improperly
     treat a revoked certificate as valid. This risk is somewhat
     mitigated if the time between the nextUpdate field of the
     manifest and the current time is short. The risk in discarding
     signed objects at this publication point is that the relying
     party may incorrectly discard a large number of valid
     objects. This gives significant power to an adversary that is
     able to prevent the publication of a new manifest at a given
     publication point. </t>

     <t>Regardless of whether signed objects from this publication are
     deemed fit for use by the relying party, this situation should
     result in a warning to the effect that: "The manifest for <pub
     point name> is no longer current. It is possible that
     undetected deletions have occurred at this publication
     point."</t>

     <t>Note that there is also a less common case where the current
     time is before the thisUpdate time for the manifest. This case is
     necessarily due to publisher error and in such a case this
     situation should result in a warning to the effect that: "The
     manifest found at <pub point name> has an incorrect
     thisUpdate field. This is due to publisher error, and processing
     for this publication point will continue using this otherwise
     valid manifest."</t>

    </section>

    <section title="Files Not on Manifests (or Missing from a Publication Point)">

     <t>If there exist otherwise valid signed objects that do not
     appear on any manifest, then provided the manifest is not stale
     (see Section 6.4) it is likely that their omission is an error by
     the publisher. (If the objects were intended to be invalid, then
     they should have been revoked using whatever revocation mechanism
     is appropriate for the signed object in question.) Therefore,
     there is little risk in using such signed objects. If the
     manifest in question is stale, then there is a greater risk that
     the objects in question were revoked with a missing CRL (whose
     absence is undetectable since the manifest is stale). In any
     case, the use of signed objects not present on a manifest (or
     descendent objects that are validated using such signed objects)
     is a matter of local policy.</t>

     <t>Regardless of whether objects not appearing on a manifest are
     deemed fit for use by the relying party, this situation should
     result in a warning to the effect that: "The following files are
     present in the repository at <pub point name>, but are not
     on the manifest <file list>."</t>

     <t>If there exist files listed on the manifest that do not appear
     in the repository, then these objects are likely to have been
     improperly (via malice or accident) deleted from the manifest. A
     primary purpose of manifests is to detect such
     deletions. Therefore, in such a case this situation should result
     in a warning to the effect that: "The following files that should
     have been present in the repository at <pub point name>,
     are missing <file list>.  This indicates an attack against
     this publication point, or the repository, or an error by the
     publisher."</t>

    </section>

    <section title="Hash Values Not Matching Manifests">

     <t>A file appearing on a manifest with an incorrect hash value
     could occur because of publisher error, but it is likely to
     indicate that a serious error has occurred.</t>

     <t>If an object appeared on a previous valid manifest with a
     correct hash value and now appears with an invalid hash value,
     then it is likely that the object has been superceded by a new
     (unavailable) version of the object. If the object is used there
     is a risk that the relying party will be treating a stale object
     as valid. This risk is more significant if the object in question
     is a CRL. Assuming that the object is validated in the RPKI, the
     use of these objects is a matter of local policy.</t>

     <t>If an object appears on a manifest with an invalid hash and
     has never previously appeared on a manifest, then it is unclear
     whether the available version of the object is more or less
     recent than the version whose hash appears in the manifest. If
     the manifest is stale (see Section 6.4) then it becomes more
     likely that the available version is more recent that the version
     indicated on the manifest, but this is never certain. Whether to
     use such objects is a matter of local policy. However, in
     general, it is better to use a possibly outdated version of the
     object, then to discard the object completely.</t>

     <t>Regardless of whether objects with incorrect hashes are deemed
     fit for use by the relying party, this situation should result in
     a warning to the effect that: "The following files at the
     repository <pub point name> appear on a manifest with
     incorrect hash values <file list>. It is likely that these
     objects have been superseded by a more recent version. It is very
     likely that this problem is due to an attack on the publication
     point, although it could be due to a publisher error."</t>

    </section>
   </section>
 
   <section title="Publication Repositories">

    <t>The RPKI publication system model requires that every
    publication point be associated with a CA or an EE, and be
    non-empty. Upon creation of the publication point associated with
    a CA, the CA MUST create and publish a manifest as well as a
    CRL. The manifest will contain at least one entry, the CRL issued
    by the CA upon repository creation.  Upon the creation of the
    publication point associated with an EE, the EE MUST create and
    publish a manifest.  The manifest in an otherwise empty repository
    publication point associated with an EE will contain no entries in
    the manifest's fileList sequence (i.e. a sequence of length
    zero). <xref target="ID.SIDR-REPOSITORY" /></t>

    <t>For signed objects EE certificate used in the verification of
    such objects is either a single-use certificate, used to verify a
    single signed object, or a multiple-use certificate.  In the case
    of a single-use EE certificate, the signed object is published in
    the repository publication point of the CA that issued the single
    use EE certificate, and is listed in the manifest associated with
    that CA certificate. In the case where the EE certificate is used
    to verify multiple objects, signed object is published in the EE
    certificate's repository publication point and listed in the
    manifest associated with the EE certificate.</t>

   </section>

   <section title="Security Considerations">

    <t>Manifests provide an additional level of protection for users
    of the repository system. Manifests can assist the user to
    determine if repository objects have been occluded or other
    removed from view, and to determine if an older version of an
    object has been substituted for the current object.</t>

    <t>Manifests
    cannot repair the effects of such forms of attempted corruption of
    repository retrieval operations, but are capable of allowing the
    user to determine if a locally maintained copy of a repository is
    a complete and up to date copy, even when the repository retrieval
    operation is conduction over an insecure channel. In those cases
    where the manifest and the retrieved repository contents differ,
    the manifest can assist in determining which repository objects
    form the difference set in terms of missing, extraneous or older
    objects.</t>

    <t>The signing structure of a manifest and the use of next update
    times allows the user to determine if the manifest itself is the
    subject of attempted alteration. The requirement for all
    repositories to contain manifests allows the user to determine is
    the manifest itself has been occluded from view. Such attacks
    against the manifest are detectable within the timeframe of the
    regular schedule of manifest updates. Forms of replay attack
    within finer-grained timeframes are not necessarily detectable by
    the manifest structure.</t>

   </section>

   <section title="IANA Considerations">
    <t>[Note to IANA, to be removed prior to publication: there are no IANA
     considerations stated in this version of the document.]</t>
   </section>

   <section title="Acknowledgements">
    <t>The authors would like to acknowledge the contributions from
    George Michaelson and Randy Bush in the preparation of the
    manifest specification. Additionally, the authors would like to
    thank Mark Reynolds and Christopher Small for assistance in
    clarifying manifest validation and relying party behavior.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="ID.SIDR-ARCH">
        <front>
          <title>An Infrastructure to Support Secure Internet Routing</title>

          <author fullname="M. Lepinski" initials="M" surname="Lepinski">
            <organization>BBN Technologies</organization>
          </author>
          <author fullname="S. Kent" initials="S" surname="Kent">
            <organization>BBN Technologies</organization>
          </author>
          <author fullname="R. Barnes" initials="R" surname="Barnes">
            <organization>BBN Technologies</organization>
          </author>

          <date month="February" year="2008" />
        </front>
        <seriesInfo name="Work in progress: Internet Drafts" value="draft-ietf-sidr-arch-03.txt" />
      </reference>

      <reference anchor="ID.SIDR-CERTPROFILE">
        <front>
          <title>A Profile for X.509 PKIX Resource Certificates</title>

          <author fullname="G. Huston" initials="G" surname="Huston">
            <organization>APNIC</organization>
          </author>
          <author fullname="G. Michaelson" initials="G" surname="Michaleson">
            <organization>APNIC</organization>
          </author>
          <author fullname="R. Loomans" initials="R" surname="Loomans">
            <organization>APNIC</organization>
          </author>

          <date month="June" year="2008" />
        </front>

        <seriesInfo name="Work in progress: Internet Drafts" value="draft-ietf-sidr-res-certs-10.txt" />
      </reference>

      <reference anchor="ID.SIDR-REPOSITORY">
        <front>
          <title>A Profile for Resource Certificate Repository Structure</title>

          <author fullname="G. Huston" initials="G" surname="Huston">
            <organization>APNIC</organization>
          </author>
          <author fullname="R. Loomans" initials="R" surname="Loomans">
            <organization>APNIC</organization>
          </author>
          <author fullname="G. Michaelson" initials="G" surname="Michaleson">
            <organization>APNIC</organization>
          </author>

          <date month="June" year="2008" />
        </front>

        <seriesInfo name="Work in progress: Internet Drafts" value="draft-huston-sidr-repos-struct-02.txt" />
      </reference>

      <?rfc include='./rfcs/bibxml/reference.RFC.3779.xml'?>
      <?rfc include='./rfcs/bibxml/reference.RFC.3852.xml'?>
      <?rfc include='./rfcs/bibxml/reference.RFC.4049.xml'?>
      <?rfc include='./rfcs/bibxml/reference.RFC.4055.xml'?>
      <?rfc include='./rfcs/bibxml/reference.RFC.5280.xml'?>
    </references>
  </back>
</rfc>