Subject: Re: [sidr] I-D Action:draft-ietf-sidr-rpki-manifests-07.txt

From: Sean Turner <[email-masked]>
Date: Tue, 28 Sep 2010 22:01:19 -0400

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-masked] 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-masked]
> https://www.ietf.org/mailman/listinfo/sidr