Individual Submission R. Austein
Internet-Draft ISC
Intended status: Standards Track G. Huston
Expires: July 5, 2008 APNIC
S. Kent
M. Lepinski
BBN
January 2, 2008
Manifests for the Resource Public Key Infrastructure
draft-ietf-sidr-rpki-manifests-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 5, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
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
Austein, et al. Expires July 5, 2008 [Page 1]
Internet-Draft RPKI Manifests January 2008
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 threats to relying parties of the
results of a man-in-the middle withholding attack on repository
retrieval operations.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Manifests . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Manifest Syntax . . . . . . . . . . . . . . . . . . . . . 4
3. Manifest Signing and Verification . . . . . . . . . . . . . . 6
4. Using CMS SignedData to protect a Manifest . . . . . . . . . . 7
5. Manifest Generation . . . . . . . . . . . . . . . . . . . . . 7
6. Certificate Requests . . . . . . . . . . . . . . . . . . . . . 10
7. Publication Repositories . . . . . . . . . . . . . . . . . . . 11
8. Relying Parties . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Manifest Processing . . . . . . . . . . . . . . . . . . . 13
8.1.1. Warning List . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
12. Normative References . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Austein, et al. Expires July 5, 2008 [Page 2]
Internet-Draft RPKI Manifests January 2008
1. Introduction
The Resource PKI (RPKI) [ID.SIDR-ARCH] makes use of a distributed
repository system [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, attacks that substitute "stale" versions of signed objects
(i.e., objects that were valid but have since been superceded) are
not automatically detected just by validation of digital signatures.
Attacks that remove an object also are not detectable by verification
of digital signatures, unless an RP is able to predict that the
object should be present. To help address these vulnerabilities, the
RPKI repository system will make use of a new data structure call a
"manifest."
A manifest is a signed object listing of all of the signed objects
issued by an 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 are intended to allow an RP to obtain sufficient
information so as to be able to detect if the retrieval of objects
from an RPKI repository has been compromised by unauthorized removal,
or by substitution of "stale" versions of objects. Manifests are
designed to be used for Certification Authority (CA) publication
points in repositories, points that contain subordinate certificates,
CRLs and other signed objects, and End Entity (EE) publication points
in repositories (that contain signed objects).
[Note 1. This text assumes that CRLs are included in manifests.
As a signed product of an issuing authority that is published in
the authority's publication repository this would be consistent
with the definition of manifests in the text. However, if
manifests are intended to list all objects in a publication
repository that relying parties would otherwise not know to exist,
then is not logically necessary to include CRLs in a manifest, as
the CRL is already a requrement for CAs to publish. It is an
option to strike CRLs from the list of objects to inlude in a
manifest. This may reduce to some extent the amount of manifest
activity in a repository for an otherse largely static CA. On the
other hand listing the CRL in the manifest has some utility in
being able to detect some forms of substitution of a "stale" but
otherwise valid CRL. A later note highlights a similar issue over
inclusion of the manifest-signing EE certificate in the manifest.
Austein, et al. Expires July 5, 2008 [Page 3]
Internet-Draft RPKI Manifests January 2008
It is suggested that the text be left as is and that CRLs be
included in manifests.]
[Note 2. This draft assumes that it is possible for an EE to sign
and publish multiple objects and, accordingly, a manifest for the
signed object publication repository is necessary. Accordingly,
the document implicitly refers to both CA and EE manifests. An
alternate option is to apply a restriction in the RPKI that an EE
can sign a single object, in which case the signed object can be
referenced directly in the SIA of the AA and no manifest of EE-
signed objects is necessary. It is suggested that the text be
left as is, leaving the option for CA and EE manifests to be
permitted within this specification.]
1.1. Terminology
It is assumed that the reader is familiar with the terms and concepts
described in "Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile" [RFC3280]and "X.509
Extensions for IP Addresses and AS Identifiers" [RFC3779].
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.
2. Manifests
Manifests are modeled 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, e.g. digitally signed objects,
such as ROAs. The Cryptographic Message Syntax (CMS) [RFC3852]
signature format is employed to encapsulate the manifest payload. It
also provides a vehicle to carry the EE certificate needed to verify
a manifest.
The scope of a manifest is the entire collection objects in a
publication point in a repository, where each object has been signed
by the same CA or EE that is the authority for this repository
publication point.
2.1. Manifest Syntax
A manifest is a CMS signed-data object whose content is defined as
follows:
Austein, et al. Expires July 5, 2008 [Page 4]
Internet-Draft RPKI Manifests January 2008
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
}
The version of this Manifest format is 1, and the value of this field
is therefore 0.
The manifestNumber field is a sequence number that is incremented
each time a new manifest is issued for the repository. This field is
used to allow a RP to detect gaps in a sequence of published
manifest.
The thisUpdate field contains the time when the manifest was created
and 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 nextUpdate. 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.
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.
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. [RFC4055].
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.
Austein, et al. Expires July 5, 2008 [Page 5]
Internet-Draft RPKI Manifests January 2008
3. Manifest Signing and Verification
A manifest for a CA's repository publication point is signed by a
private key, for which the corresponding public key appears in an EE
certificate signed by the CA in question.
A manifest for a EE's repository publication point is signed by a
private key, for which the corresponding public key appears in an EE
certificate signed by the same CA that signed the public key of the
publishing EE. This, for an EE-managed publication point, exactly
one level of indirection is allowed in validation of the manifest
certificate.
Validation of a manifest's CMS digital signature is performed in the
context of the RPKI, and is validated using the algorithm described
in [ID.SIDR-CERTPROFILE].
[Note 3. This draft assumes that each EE uses a unique repository
publication point. This is not an explicit constraint of the
Resource PKI. For the sake of the efficiency of the relying
parties' repository synchronization operations it is possible that
a CA may choose to place all signed objects that are verified
using EE certificates that are subordinates to this CA in a common
single repository publication point. In this case the above
manifest signature description still holds, namely that the
manifest of this common repository publication point is a single
manifest that is signed by a private key, for which the
corresponding public key appears in an EE certificate signed by
this CA. It is suggested that the text note that this validation
method allows both the model that each EE uses a dedicated
repository publication point, or that all subordinate EEs of a
single CA share a common repository publication point, and note
that it CAs may elect to use a dedicated per-EE repository, or a
single shared EE repository.]
[Note 4. In the (possibly degenerate) case of a multi-signed
object it would appear that the simplest case is to apply a
restriction that the EE certificates used in this context be one-
off use EE certificates and each EE certificate reference the
common multi-signed object's repository publication point. The
collection of CAs that generated EE certificates to sign this
object would also need to agree on a common repository publication
point in this case. As the issue of a multi-signed object is
still unresolved for this RPKI no resolution is suggested here
(see draft-ietf-smime-multisig-03.txt for a multi-signing
approach).]
Austein, et al. Expires July 5, 2008 [Page 6]
Internet-Draft RPKI Manifests January 2008
Two models for managing the EE certificates used to verify manifests
are permitted. A publication point authority may create an EE
certificate for manifest verification and use the corresponding
private key to sign a series of manifests over tiome. Alternatively,
an EE certificate may be used to verify a single instance of a
manifest and the private key corresponding to the certificate may be
deleted after it is used to sign that manifest instance. To avoid
needless CRL growth, the EE certificate used to validate a manifest
in this second case SHOULD expire at the same time that the manifest
expires, i.e., the notAfter value in the EE certificate should be the
same as the nextUpdate value in the manifest. In contrast, when an
EE certificate is used to verify a series of manifests, the validity
of that certificate has to encompass the validity intervals for all
corresponding manifests.
4. Using CMS SignedData to protect a Manifest
It is intended that the manifest will be processed by an RP in the
context of assembling a local copy of the entire RPKI repository.
Thus, the certificates and CRLs required to validate the certificate
path for the EE certificate used to varify the manifest's signature
will be at hand for the RP. AS a result, this specification
recommends that only the EE certificate needed to verify the
signature on the manifest be included in the CMS DignedData. CA
certificates and CRLs SHOULD NOT be included in the CMS SignedData.
The CMS timestamp field SHOULD NOT be included in the CMS Signed
Data.
[Note 5. This section needs to be expanded to precisely specify
which optional CMS fields MUST be present, which ones MUST be
omitted and which (if any) MAY be present at the discretion of
themanifest signed. It is also suggested that the default
algorithms to be used also be specified here.]
5. Manifest Generation
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:
1. Generate a key pair.
Austein, et al. Expires July 5, 2008 [Page 7]
Internet-Draft RPKI Manifests January 2008
2. Issue an EE certificate for this key pair to enable relying
parties to verify the signature on the manifest.
* 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.
* This EE certificate SHOULD describe its IP number resources
using the "inherit" attribute rather than explicit description
of a resource set.
* The validity times of the EE certificate MUST either exactly
match the thisUpdate and nextUpdate times of the manifest, or
encompass the validity intervals for the series of manifests
that are expected to be verified using the EE certificate.
3. Publish this certificate in the authority's repository
publication point.
[Note 6. This assumes that the EE certificate used to sign
manifests is published in the CA's repository publication
point in the same manner as all other subordinate certificates
issued by this CA. It is potentially an option to omit the
publication step on the basis that the EE certificate is also
contained in the CMS SignedData field of the manifest. It is
suggested that these EE certificates by treated in the same
manner as all other certificates in the RPKI and be published
in the appropriate repository as well as being reproduced in
the CMS SignedData section of the manifest, leaving the above
text as is.]
4. The manifest is then constructed. 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.
5. The manifest is encapsulated using the CMS SignedData content
type and published in the publication point in the repository
system that is described by the manifest.
6. If a single use EE certificate is associated with a single use
key pair the private key may now be destroyed.
An authority MUST issue a new manifest on or before the nextUpdate
Austein, et al. Expires July 5, 2008 [Page 8]
Internet-Draft RPKI Manifests January 2008
time.
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 replying
parties who are performing retrieval operations on the repository are
not exposed to intermediate states during changes to the repository
and the associated manifest.
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.
As the manifest scope is all signed objects associated with an
authority responsible for a pubnlication 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.
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. It will sign the manifest
and publish it at the point in the key rollover sequence following
the publication of the new CA certificate by the superior CA (i.e.
the point at which objects signed with the new key may be validated
by relying parties). The previous EE certificate used to sign
manifests will be revoked by the CRL that is associated with the
retiring private key (as the scope of CRLs in the RPKI is that of CA
plus private key value). The new instance of the manifest, and
successive manifests, will describe all the files in the CA
publication point that were signed with both the retiring key and the
new key. The manifest number will continue to be incremented and
MUST NOT be reset.
In the case of a EE publication point manifest, when the EE
certificate is rekeyed, 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 assocaited with the new
publication point. In this case there is no manifest overlap, as the
new repository publication point will have a distinct manifest.
Austein, et al. Expires July 5, 2008 [Page 9]
Internet-Draft RPKI Manifests January 2008
In the case of a common publication point for all subordinate EE
authorities of a CA the same still holds, and each batched update
operation on the shared repository would entail a new generation of
the manifest being produced.
6. Certificate Requests
A request for a CA certificate MUST include in the SIA of the request
an accessMethod OID of id-ad-rpkiManifest, where the associated
accessLocation refers to the subject's published manifest object as
an object URL.
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-rpkiManifest,
where the associated access location refers to the publication point
of the objects that are verified using this EE certificate.
[Note 7. This draft assumes that it is possible for an EE to sign
and publish multiple objects as noted earlier. The above
constraint me be removed if this is not the case. It is suggested
that the multiple object provision be left in the text.]
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.
In accordance with the provisions of [ID.SIDR-CERTPROFILE], all
certificate issuance requests for a CA certificate SHOULD include 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 honor these values in the issued certificate or MUST
reject the Certificate Request.
Similarly, a request for an EE certificate SHOULD include either the
id-ad-signedObjectRepository and the id-ad-rpkiManifest access
method, or, in the case of single-use EE certificates, include the
id-ad-signedObject access method and omit the id-ad-rpkiManifest
access method.
Austein, et al. Expires July 5, 2008 [Page 10]
Internet-Draft RPKI Manifests January 2008
7. Publication Repositories
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 two entries, the CRL issued by the CA upon
repository creation and the EE certificate used to sign the manifest.
Upon the creation of the publication point associated with an AA, the
EE MUST create and puiblish 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 0
length).
[Note 8. This description of the initial state of a CA's
repository publication point assumes that the EE certificate used
to sign manifests is published in the CA's repository publication
point in the same manner as all other subordinate certificates
issued by this CA, as noted in a previous comment. It is
suggested that this remain the case and that this text be
retained.]
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 id-ad-signedObject SIA access method
is to refer to the signed object itself, and the signed object is not
covered by a manifest. In the case where the EE certificate is used
to verify multiple objects, the id-ad-signedObjectRepository SIA
access method points to the repository publication point where signed
objects that are verified using this EE certificate are published and
the id-ad-rpkiManifest SIA access methos points to the manifest for
this repository publication point. A CA MAY use a common repository
publication point for the collection of signed objects that are
verified using any of the CA's subordinate EE certificates.
8. Relying Parties
All RPKI repository publication points SHOULD should contain a valid
manifest.
A valid manifest is one where:
Austein, et al. Expires July 5, 2008 [Page 11]
Internet-Draft RPKI Manifests January 2008
o the manifest conforms to the defined syntax for manifests
o the digital signature can be verified by using the public key
specified in the attached EE certificate
o the current time is no earlier than the thisUpdate time of the
manifest and no later than the nextUpdate time of the manifest
o the EE certificate conforms to the profile as specified in
[ID.SIDR-CERTPROFILE]
o the EE certificate has not been revoked
o the EE certificate has not expired
o the EE certificate can be validated according to the procedure
described in section 7 of [ID.SIDR-CERTPROFILE]
The absence of a manifest from a RPKI repository publication point
may indicate a possible attack on the repository retrieval function,
and this situation should generate some form of operational warning.
If the relying party has retained one or more previously retrieved
manifests then the relying party should use most recent (highest
manifestNumber value) verified manifest for the publication point in
question. If no prior manifest for this publication point is
available, there is no basis for detecting missing files, so the
relying party should just process the repository contents in any
case. All objects retrieved from a repository whose manifest is in
this state are still potentially useable by relying parties, and
validated objects should be regarded with the same level of trust
that is used for validated objects that have been retrieved from
repositories with valid manifests.
If the signature on a manifest cannot be verified, or the manifest
cannot be parsed according to the manifest syntax specification, it
must be disregarded by a relying party. Since this case entailed
retrieval of what purports to be a manifest, a warning SHOULD be
issued, but the RP should proceed with processing the publication
point objects.
Where a manifest is present, and the signature can be verified using
the attached EE certificate, but the EE certificate itself cannot be
validated, then it is possible that the manifest is bogus. In this
case the manifest should be disregarded by the RP and a warning
SHOULD be issued, but the RP should proceed with processing the
publication point objects as if no manifest had been provided.
Austein, et al. Expires July 5, 2008 [Page 12]
Internet-Draft RPKI Manifests January 2008
Where a manifest is present, and the signature can be verified using
the attached EE certificate, but the EE certificate itself has been
revoked, then it is possible that the manifest is a replay. In this
case the manifest should be disregarded by the RP and a warning
SHOULD be issued, but the RP should proceed with processing the
publication point objects as if no manifest had been provided.
When processing a valid manifest, if an RP encounters a signed object
that is not listed in the manifest, or that has a different hash
value from the one specified in the manifest, then the object SHOULD
be ignored and a warning SHOULD be issued. The object should not be
trusted as it may be part of a replay attack.
[Note 9. An alternative approach is that such objects that are
not in the manifest or fail to match the hash algorithm but still
validate in the RPKI should still be used because they do indeed
validate within the scope of the RPKI. The issue here appears to
be one of judgment about what form of replay attack is occurring
in such a situation, assuming that the authority's manifest
generation process was correct and the discrepancy has arisen
during the repository synchronization operation. The default
approach, or ignoring everything not in the manifest and ignoring
everything that fails to match the manifest's hash value assumes
that the attack is one of replay of the object. The alternative
is that the replay attack is a replay of the manifest, in which
case the relying party has been forced to discard valid objects
because of the manifest replay. This requires further
consideration as to which scenario presents the lesser risk to
relying parties. No suggestion is made here, and further advice
is sought on this topic.]
If a valid manifest lists files that are not visible in the
publication point, then the RP should assume that these objects have
been deleted, potentially without authorization, and a warning SHOULD
be issued.
A semi-formal description of the recommended relying party manifest
processing algorithm follows.
8.1. Manifest Processing
The error-free case is:
A manifest is present in the repository, is current (i.e., the
current time is bounded by the manifest validity interval), and
its signature can be verified using a valid certificate
Austein, et al. Expires July 5, 2008 [Page 13]
Internet-Draft RPKI Manifests January 2008
[ID.SIDR-CERTPROFILE]. All files found in the publication point
are listed in the manifest, all files listed in the manifest are
found in the publication point, and the hashes match.
The cases that SHOULD generate various manifest validation warnings
are:
1. No manifest is found in the repository at the publication point.
In this case, the relying party cannot use the manifest in
question.
A. If the relying party has a prior manifest for this
publication point, then the relying party should use most
recent, verified manifest for the publication point in
question and generate warning A.
B. If no prior manifest for this publication point is available
to the relying party, there is no basis for detecting missing
files, so just process certificate, CRL, and other signed
object files and generate warning B.
2. The signature on manifest fetched from the repository cannot be
verified (or the format of the manifest is bad). In this case,
the relying party cannot use the manifest in question.
A. If the relying party has a prior manifest for this
publication point, then the relying party should use most
recent, verified manifest for the publication point in
question and generate warning A.
B. If no prior manifest for this publication point is available
to the relying party, there is no basis for detecting missing
files, so just process certificate, CRL, and other signed
object files and generate warning B.
3. The manifest is present and current and its signature can be
verified using the CMS enclosed EE certificate.
A. If the EE certificate is valid (current and not revoked) and
all files in the repository are listed in the manifest, and
all files listed in the manifest are found in the repository,
and the hashes match, then the relying party should use the
manifest, as this is the validated case.
B. If the EE certificate is valid and one or more files listed
in the manifest have hashes that do not match the files in
the repository with the indicates names, then the
corresponding files are likely to be old and intended to be
Austein, et al. Expires July 5, 2008 [Page 14]
Internet-Draft RPKI Manifests January 2008
replaced, and thus SHOULD NOT be used. The relying party
should generate Warning C.
C. If the EE certificate is valid and one or more files listed
in the manifest are missing, the relying party should
Generate Warning D.
D. If the EE certificate is expired, an indication that the EE
certificate valid times and the manifest times are not
aligned, then the relying party should generate warning E,
but proceed with processing.
E. If the EE certificate is revoked but not expired, then the
manifest SHOULD be ignored. The relying party should
generate warning F and proceed with processing as if no
manifest is available, as the CA has explicitly revoked the
certificate for the manifest.
4. The manifest is present but expired. If the signature cannot be
verified, then treat this in the same manner as case 1 or 2. If
the manifest signature can be verified using a matching EE
certificate:
A. If the EE certificate is valid (current and not revoked),
then generate warning A and proceed.
B. If the EE certificate is expired, then generate warning G and
proceed.
C. If EE certificate is revoked but not expired, the manifest
SHOULD be ignored. Generate warning F and proceed with
processing as if no manifest is available (since the CA
explicitly revoked the certificate for the manifest.)
8.1.1. Warning List
Warning A: A current manifest is not available for <pub point name>.
An older manifest for this publication point will be used, but
there may be undetected deletions from the publication point.
Warning B: No manifest is available for <pub point name>, and thus
there may have been undetected deletions from the publication
point.
Austein, et al. Expires July 5, 2008 [Page 15]
Internet-Draft RPKI Manifests January 2008
Warning C: The following files at <pub point nam> appear to be
superceded and are NOT being processed.
Warning D: 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.
Warning E: EE certificate for manifest verification for <pub point
name> is expired. This indicates an error by the publisher, but
processing for this publication point will proceed using the
current manifest.
Warning F: The EE certificate for <pub point name> has been revoked.
The manifest will be ignored and all files found at this
publication point will be processed.
Warning G: EE certificate for manifest verification for <pub point
name> is expired. This indicates an error by the publisher, but
processing for this publication point will proceed using the the
most recent (but expired) manifest.
9. Security Considerations
[To be defined]
10. IANA Considerations
[Note to IANA, to be removed prior to publication: there are no IANA
considerations stated in this version of the document.]
11. Acknowledgements
The authors would like to acknowledge the contributions from George
Michaelson and Randy Bush in the preparation of the manifest
specification.
12. Normative References
[ID.SIDR-ARCH]
Lepinski, M., Kent, S., and R. Barnes, "An Infrastructure
to Support Secure Internet Routing", Work in progress:
Internet Drafts draft-ietf-sidr-arch-02.txt,
Austein, et al. Expires July 5, 2008 [Page 16]
Internet-Draft RPKI Manifests January 2008
November 2007.
[ID.SIDR-CERTPROFILE]
Huston, G., Michaleson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", Work in progress:
Internet Drafts draft-ietf-sidr-res-certs-09.txt,
November 2007.
[ID.SIDR-REPOSITORY]
Huston, G. and G. Michaleson, "A Distributed Repository
System for the Resource PKI", Work in progress: Internet
Drafts draft-ietf-sidr-repository-00.txt, November 2007.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, July 2004.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in
the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC 4055,
June 2005.
Authors' Addresses
Rob Austein
Internet Systems Consortium
950 Charter St.
Redwood City, CA 94063
USA
Email: sra@isc.org
Austein, et al. Expires July 5, 2008 [Page 17]
Internet-Draft RPKI Manifests January 2008
Geoff Huston
Asia Pacific Network Information Centre
33 park Rd.
Milton, QLD 4064
Australia
Email: gih@apnic.net
URI: http://www.apnic.net
Stephen Kent
BBN Technologies
10 Moulton St.
Cambridge, MA 02138
USA
Email: kent@bbn.com
Matt Lepinski
BBN Technologies
10 Moulton St.
Cambridge, MA 02138
USA
Email: mlepinski@bbn.com
Austein, et al. Expires July 5, 2008 [Page 18]
Internet-Draft RPKI Manifests January 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Austein, et al. Expires July 5, 2008 [Page 19]
