One document matched: draft-ietf-sidr-rpki-manifests-03.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-03.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 Resource Public
      Key Infrastructure, such as a man-in-the middle attack of
      withholding repository data from relying party access, or
      replaying stale repository data to a relying party's access
      request.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The Resource Public Key Infrastructure (RPKI) <xref
      target="ID.SIDR-ARCH"></xref> makes use of a distributed
      repository system <xref target="ID.SIDR-REPOSITORY"></xref> 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"></xref>and "X.509 Extensions for IP Addresses and AS
        Identifiers" <xref target="RFC3779"></xref>.</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">
      <t>In the case of a CA's manifest of its associated publication
      repository, the manifest contains the current published certificates
      issued by this CA, the most recent CRL issued by this CA, and all
      objects that are signed using a "single-use" EE certificate ((i.e., the
      SIA extension of the EE certificate has an accessMethod OID of
      id-ad-signedObject), where the EE certificate was issued by this CA.</t>

      <t>In the case where multiple CAs share a common publication point, as
      may be the case when an entity performs a staged key-rollover operation,
      the respository publication will contain multiple manifests. Each
      manifest describes only the collection of products of its associated
      CA.</t>

      <t>In the case of a "multi-use" EE certificate, where an EE has a
      defined publication repository (i.e., the SIA extension of the EE
      certificate has an accessMethod OID of id-ad-signedObjectRepository),
      the EE's manifest contains all published objects that have been signed
      by the EE's key pair, and the accessMethod id-as-rpkiManifest points to
      the publication point of the EE's manifest.</t>
    </section>

    <section title="Manifest Signing">
      <t>A CA's manifest is signed using an EE certificate that is designated
      in <xref target="ID.SIDR-CERTPROFILE"></xref> as a "single-use" EE
      certificate. The SIA field of the "single-use" EE certificate contains
      the access method OID of id-ad-signedObject.</t>

      <t>The CA MAY chose to sign only one manifest with the EE certificate,
      and generate a new EE certificate for each new version of the manifest.
      This form of use of a "single-use" EE certificate is termed a
      "one-time-use" EE certificate.</t>

      <t>Alternatively the CA MAY chose to use the same EE certificate to sign
      a sequence of manifests. Because only a single manifest is current at
      any point in time, the EE certificate is only ever used to sign a single
      object at a time. As long as the sequence of objects signed by this EE
      certificate are published as the same named object, so that the SIA
      accessMethod id-ad-signedObject value can refer to the current instance
      of the sequence of such objects, then this sequential multiple use of
      this "single-use" EE certificate is also valid. This form of use of a
      "single-use" EE certificate is termed a "sequential-use" EE
      certificate.</t>

      <t>A "multi-use" EE's manifest of it's publication repository MUST be
      signed by the EE certificate itself.</t>
    </section>

    <section anchor="syntax" title="Manifest Syntax">
      <t>A manifest is a Cryptographic Message Syntax (CMS) <xref
      target="RFC3852"></xref> 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"></xref></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"></xref>. 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><![CDATA[
     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><![CDATA[
      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"></xref>). 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>In the case of "one-time-use" EE certificates being used to
              sign a manifest, it is RECOMMENDED that the EE certificate have
              an validity period that coincides with the interval from
              thisUpdate to nextUpdate, to prevent needless growth of the CA's
              CRL.</t>

              <t>In the case of "sequential-use EE certificates to sign a
              manifest the EE certificate's validity period should reflect the
              CA's key management policies.</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, and when "one-time-use" EE certificates are
                being used to sign the manifest, the CA 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"></xref>.</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 EE 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><![CDATA[
      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><![CDATA[
      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"></xref></t>
          </section>

          <section title="signedAttrs">
            <t>The signedAttrs is defined as signedAttributes:</t>

            <figure>
              <artwork><![CDATA[
      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"></xref>.</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 <xref target="validation" />).</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><![CDATA[
      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 <xref target="validation" />).</t>

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

              <figure>
                <artwork><![CDATA[
      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><![CDATA[
          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><![CDATA[
      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 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>If no key pair exists, or if using a "one-time-use" EE
            certificate with a new key pair, then generate a key pair.<vspace
            blankLines="1" /></t>

            <t>If using a "one-time-use" EE certificate, or if a key pair was
            generated in step 1, 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 MUST describe its IP number resources
                using the "inherit" attribute, rather than explicit
                description of a resource set.<vspace blankLines="1" /></t>

                <t>In the case of a "one-time-use" EE certificate, 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>

                <t>In the case of a "sequential-use" EE certificate the
                validity times of the EE certificate MUST encompass the time
                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 <xref target="syntax" />), 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>In the case of a key pair that is to be used only once, in
            conjunction with a "one-time-use" EE certificate, the private key
            associated with this key pair 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"></xref>. 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 <xref target="syntax" />), 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 (EE certificates with an SIA
        accessMethod OID of id-as-signedObject) 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.<vspace blankLines="1" /></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.<vspace blankLines="1" /></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.<vspace blankLines="1" /></t>

            <t>In the case of a CA publication point manifest, when the entity
            is performing a key rollover the entity MAY chose to have multiple
            CAs publishing at the same publication point. In this case there
            will be one manifest associated with each active CA that is
            publishing into the common repository publication point.<vspace
            blankLines="1" /></t>

            <t>In the case of an EE publication point the manifest is
            associated all published objects signed by that EE certificate.
            Multiple EEs may share a common repository publication point, in
            which case there will be one manifest associated with each active
            EE that is publishing into the common repository publication
            point.</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"></xref>.</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.</t>

      <t>In accordance with the provisions of <xref
      target="ID.SIDR-CERTPROFILE"></xref>, 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.</t>

      <t>The issuer MUST either honor these values in the issued certificate
      or reject the request entirely.</t>
    </section>

    <section anchor="validation" 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="format %c.">
              <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
            <xref target="validation" />).<vspace blankLines="1" /> <list style="symbols">
                <t>If the publication point does not contain a valid manifest,
                see Section <xref target="missing" />. 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 <xref target="StaleManifests" />, 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 <xref target="mismatch" /> 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 <xref target="NonMatchingManifests" />.<vspace blankLines="1" /></t>
              </list></t>
          </list></t>

        <t>For a particular signed object, if all of the following
        conditions hold:<list style="symbols"><t>the manifest for its
        publication passes all of the above checks;</t><t>the signed
        object is valid; and</t><t>the manifests for every certificate
        on the certificate path used to validate the signed object
        pass all of the above checks;</t></list> 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 anchor="missing" 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 or
        replay substitutions from the publication point."</t>
      </section>

      <section anchor="invalid" 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 covering the signed objects 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 anchor="StaleManifests" 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 could be due
        to publisher error, or a local clock 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 could be due to publisher error, or a local clock error, and
        processing for this publication point will continue using this
        otherwise valid manifest."</t>
      </section>

      <section anchor="mismatch" title="Mismatch between Manifest and 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
        <xref target="StaleManifests"></xref>) 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 anchor="NonMatchingManifests"
               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 <xref target="StaleManifests"></xref>) 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 than to
        discard the object completely.</t>

        <t>While it is a matter of local policy, in the case of CRLs a relying
        party should endeavour to use the most recently issued valid CRL even
        where the hash value in the manifest matches an older CRL, or does not
        match any CRL hand. The ThisUpdate field of the CRL can be used to
        establish the most recent CRL in the case where a relying party has
        more than one valid CRL at hand.</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 possible 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 also 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"></xref></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>