I'm assuming that this draft will get modified to point to the
-signed-objects draft so I'm going to skip commenting on the CMS
paragraphs. Here are my comments on the rest of the draft:
1) One thing I noted about this draft (and the -roa draft) is that
it's going to need an ASN.1 module (well it will be needed before the
proto write-up is accepted). The OID for the module should probably
come from the same arc as the content type but it's not necessary.
Below is a suggested module (not sure whether you want an IMPLICIT or
an EXPLICIT module).
There are two changes that needs to be made in Section 4.1.3.2 (1.a
and 1.b) and one optional change (1.c):
1.a) The constraints comes between the SEQUENCE and the OF and the
bounds need to be brackets.
OLD:
fileList SEQUENCE OF (SIZE 0..MAX) FileAndHash
NEW:
fileList SEQUENCE SIZE (0..MAX) OF FileAndHash
1.b) Need comma on "file" line.
OLD:
FileAndHash ::= SEQUENCE {
file IA5String
hash BIT STRING
}
NEW:
FileAndHash ::= SEQUENCE {
file IA5String,
hash BIT STRING
}
1.c) If number is similar to CRLNumber should we add a constraint like
CRLNumber has:
OLD:
manifestNumber INTEGER,
NEW:
manifestNumber INTEGER (0..MAX),
1.d) Here's module (incorporates 1.a and 1.c) that could go in an
Appendix:
------------------------------------------------------
RPKIManifest { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) smime(7)
mod(0) TBD }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
-- IMPORTS NOTHING --
-- Manifest Content Type: OID
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 Content Type: eContent
Manifest ::= SEQUENCE {
version [0] INTEGER DEFAULT 0,
manifestNumber INTEGER (0..MAX),
thisUpdate GeneralizedTime,
nextUpdate GeneralizedTime,
fileHashAlg OBJECT IDENTIFIER,
fileList SEQUENCE SIZE (0..MAX) OF FileAndHash
}
FileAndHash ::= SEQUENCE {
file IA5String,
hash BIT STRING
}
END
------------------------------------------------------
2) Abstract:
r/Resource Public Key Infrastructure/Resource Public Key
Infrastructure (RPKI)
r/CRL/Certificate Revocation List (CRL)
3) Sec 1: r/CRLs/Certificate Revocation Lists (CRLs)
4) Sec 1.1: r/ [RFC5280]>/[RFC5280]
5) Sec 1.1: Add that familiarity with -signed-objects and -res-certs
is assumed.
6) Sec 1.1 & 13: Add normative reference to 2119.
And, r/RFC 2119/RFC-2119 [RFC2119].
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7) Sec 2: Add reference to res-certs for single-use/multi-use (I know
it's in the next section, but the reference should appear the 1st time
these terms are used)
8) Sec 2:
r/SIA/Subject Information Access (SIA)
r/OID/Object Identifier (OID)
9) Sec 2: r/EE's key/EE's private key
10) Sec 3: If we're going to retain the "one-time-use" and
"sequential-use" concepts they should be discussed in the -res-certs
draft and probably also in the -arch drafts?
11) No comments on 4 modulo 4.1.3.2.*
12) Sec 4.1.3.2.1: r/CRLS/CRLs
13) Sec 4.1.3.2.1: r/"sequential-use EE/"sequential-use" EE
14) Sec 4.1.3.2.1.1: r/The version number of this version of the
manifest specification is 0. /The version number of the Manifest MUST
be 0.
15) Sec 4.1.3.2.1.2: If this field is analogous to CRLNumber I think
you need to say something about how big the integer can be. I suggest
tweaking the text from RFC 5280:
Manifest numbers can be expected to contain long integers. Manifest
verifiers MUST be able to handle number values up to 20 octets.
Conforming Manifest issuers MUST NOT use number values longer than 20
octets.
16) Sec 4.1.3.2.1.3/4: Need to say something about the format for the
date. Just point or copy the text from 5280:
GeneralizedTime values MUST be expressed in Greenwich Mean Time (Zulu)
and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even where
the number of seconds is zero. GeneralizedTime values MUST NOT
include fractional seconds.
17) Sec 4.1.3.2.1.4: r/the nextUpdate field of the manifest MUST match
that of the CRL,/the nextUpdate field of the manifest MUST match the
CRL's nextUpdate field,
18) Sec 4.1.3.2.1.6: Should there be an upper bound on the length of
the IA5String? You're probably also going to need to say something
about why IA5String is okay (i.e., why aren't you supporting
internationalized file names).
19) Sec 6: I have to ask why Sec 6 is in this document and not in the
res-cert document?
20) Sec 7: List only the additional checks that aren't in -signed-objects
21) Sec 8:
r/should placed/SHOULD be placed
r/should/SHOULD
22) Sec 8.1: r/relying party should/relying party SHOULD
23) Sec 8.2-.6: r/this situation should/this situation SHOULD X7
24) Sec 8.6: Indicates that thisUpdate can be used if there's more
than one valid CRL. Shouldn't we be using the CRLNumber extension?
It's required and that is what it's for.
25) Sec 9: t might be worth noting that the first CRL issued by the CA
is goign to be an empty CRL (i.e., one that has no entries).
26) Sec 10: Add that the security considerations of -signed-objects apply.
27) Sec 10: r/structure ./structure.
28) Sec 13: Refer to 6019 instead of 4049.
29) Sec 13 & 1: Probably need to add a reference to ASN.1 [X.208-88].
Maybe put in the intro that "This document defines the Abstract
Syntax Notation One (ASN.1) [X.208-88] for the Manifest object."
30) We should probably say something about the required encoding
scheme (BER or DER) for the content and add a reference to [X.209-88].
I like DER, but I'd understand using BER if these are going to get
really large. Have folks already generated these - which did they use?
31) It would be awesome if there were example encodings (hex dumps)
provided in an Appendix. If the res-certs profile had CA and EE cert
examples, you could use them in the example. It would tie it all up
nicely. It would also make it feel more "real" because you actually
got an implementation to generate this thingie (or you got somebody
smart who can hand code ASN.1 ;).
NOTE: Comments 29, 30, and 31 also apply to the -roa draft.
Cheers,
spt
[email protected] wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Inter-Domain Routing Working Group of
the IETF.
Title : Manifests for the Resource Public Key Infrastructure
Author(s) : R. Austein, et al.
Filename : draft-ietf-sidr-rpki-manifests-07.txt
Pages : 27
Date : 2010-05-12
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, CRL, or other type 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 enable a Relying Party to detect certain forms of attacks
against a repository. Specifically, if a Relying Party checks a
manifest's contents against the signed objects retrieved from a
repository publication point, then the Relying Party can detect
"stale" (valid) data and deletion of signed objects.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-manifests-07.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
------------------------------------------------------------------------
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
