Subject: [sidr] more repository structure comments

From: Stephen Kent <[email-masked]>
Date: Wed, 26 May 2010 14:49:48 -0400

Geoff,

In re-reading the repository structure document I realized that my 
edits were based on the previous version (03) vs. the current version 
(04), because I started them before the 04 version was posted. Sorry 
'bout that. I will review the 04 version and post comments for 
material contained there that is not present in the 03 version. Using 
the IETF diff tool, it appears that most of the text upon which I 
commented is still present, so most of the comments/edit are still 
applicable.

I think it would be very helpful if the document used the term 
directory, instead of the more generic term "publication point" when 
a directory is intended, and avoid the unwieldy "repository system 
publication point directory" phrase.

I see that the 04 version provides a more thorough discussion of 
Figure 1, but it still does not discuss the CRLDP instances in the 
example.

I like the added text about "locking" a directory during an update, 
so that RPs don't retrieve an inconsistent set of files, but why is 
this a SHOULD vs. a MUST? An RP will have to process the files, 
figure out that they are mismatches, and retry the retrieval if it 
grabs an inconsistent set of files, right?

I also find it a confusing that the document talks about EE 
certificate pub points (in the early part of the document), without 
making a clear distinction between singe-use and multi-use EE 
certificates, in this regard.  My impression is that a single-use EE 
certificate appears only in a corresponding CMS object. This is true 
for ROAs and manifests, and I think it would be an appropriate rule 
for all such certificates, going forward. If so, then these EE 
certificates never appear in a directory, except in CMS objects) and 
that is not clear from the text.

The multi-use EE certificate discussion is also confusing to me. 
Section 2.2 says that all certificates issued under the CA 
certificate appear in the directory for that CA, which means that 
multi-use EE certificates appear in that directory. Section 2.3 talks 
about a (separate?) EE directory, but does not make it clear to me 
when this directory is distinct from that of the CA that issued these 
certificates. 

The revised text in 2.2 add a discussion of "guidelines" for file 
name extensions for different types of RPKI objects (in the broad use 
of this term). I agree that some of the file name derivation 
discussions are just advisory, but the text does not provide enough 
info in every case to ensure that alternative file name generation 
approaches achieve the same goals.  For example, If we want to make 
it easy for an RP to match a CRL and a manifest to a CA certificate, 
then using the CA's public key to derive the name for the 
corresponding files is important. The text should be make it clear 
that this sort of association is important (critical?), and that the 
CA ought not (MUST not) keep old copies of manifests and CRLs in a 
directory. I also I think that the file extensions ought to be MUSTs. 
Otherwise, RPs will have to decode each file and examine the ASN.1 
structures to figure out which files are certificates, CRLs, 
manifests, ROAs, etc. I think this is an undue burden to impose.

It might be helpful to incorporate a table that summarizes repository 
naming conventions. Below is my first cut at such a table.

Object Type		File extension	File name source
CA certificate	.cer			Based on ??
CRL			.crl			hash of CA's public key
Manifest		.mft			hash of CA's public key

Single-use EE		N/A (because it is	N/A (embedded in
certificate		in a CMS object)	signed object)

ROA			.roa			hash of EE public key

Other objects that make use of single-use certificate will have a 
file extension documented in the RFC defining each object and will 
use the hash hash of EE public key to generate the file name??

Multi-use EE cert	.ee (??)		hash of EE public key ??

Other multi-use EE cert signed objects will have have a file 
extension documented in the RFC defining each object and will use ??? 
to generate the file name

Section 4 says that it is important to maintain the same CA directory 
name when reissuing a CA certificate, without a key change. The 
section should be more explicit about the motivation for this, i.e., 
each subordinate certificate contains an AIA extension pointing back 
to that directory. But, it seems that section also should discuss the 
implications of this with regard to certificate reissuance for a CA, 
e.g., the need for multiple CRLs and manifests if the old and new CA 
certificates overlap in time. Also, if a CA rekeys, it can still 
reissue subordinate CA certificates, unilaterally. One presumably 
wants EE certificates under the reissued CA certificates to not have 
to change the AIA back-pointers as well.  Thus this section should 
encompass both reissued (same key) and rekeyed CA certificates, right?

Another issue that I still find a bit confusing is the need to 
generate a new Subject name for a CA whenever the key changes (See 
Section 2.2, before the file name and extension discussion). This is 
not a requirement that PKIs impose in general, so I think it is 
important to explain why the RPKI imposes this constraint. Also, the 
text that discusses this notes that it is OK for the (rekeyed) CA to 
put objects into the same directory. The text does not provide a 
rationale for this, and it does introduce some complexity, e.g., 
multiple instances of CRLs and manifests in the same directory. I'm 
guessing that the motivation here is that using the same directory 
allows the rekeyed CA to (unilaterally) reissue certificates to its 
subordinate CAs and not break the AIA back-pointers in the EE 
certificates under those certificates. If that's the motivation, we 
should say so.

Conversely, the document says (Section 2.2)  that if a CA gets a new 
certificate and does not change its key pair, the new certificate 
replaces the old one (if the file name is derived exclusively from 
the CA's public key.) This implies that a reissued certificate 
triggers immediate replacement, instead of allowing old and new 
certificate to coexist. If this is what we intend, it probably should 
be said explicitly, and motivated, e.g., because this procedure 
avoids ambiguity for RPs. (This may be a lot less desirable for 
algorithm migration, i.e., we may need to allow for overlapping 
validity intervals. I'm still thinking about issues like that.)

Finally, I think it might be helpful to ad a table that concisely 
describes the forward and back pointers used in CA and EE 
certificates, in the form of AIA and SIA extension contents. This 
table should indicate when a URL points to a directory vs. a file, 
and indicate how an RP uses the pointer (why it is needed) in 
constructing certificate paths. (Note that these  extensions are 
non-critical, and not needed for certificate path validation, only 
for discovery). Since Section 5 of the repository structure document 
describes a top-down tree walk for path discovery, it seems 
especially important to motivate the use of back pointers here. I 
realize that there is a discussion of AIA and SIA in the resource 
certificate profile, but I think it would be helpful to have a table 
of this sort here.

When I began work on the algorithm migration I-D, I realized that we 
first needed to document the key rollover process (with no algorithm 
change). There are hints about this in a few places in this document, 
but not a complete discussion of this important topic. Unless the WG 
chairs object, I will include the key rollover discussion as part of 
the I-D that is also going to discuss algorithm migration.  (Maybe 
I'll call it key and algorithm rollover :-).)

Steve

---

From: Geoff Huston <[email-masked]>
Date: Sat, 29 May 2010 08:32:28 +1000

Steve,

> When I began work on the algorithm migration I-D, I realized that we first needed to document the key rollover process (with no algorithm change). There are hints about this in a few places in this document, but not a complete discussion of this important topic. Unless the WG chairs object, I will include the key rollover discussion as part of the I-D that is also going to discuss algorithm migration.  (Maybe I'll call it key and algorithm rollover :-).)

It is my impression that key rollover and algorithm migration are somewhat different in the demands they place on the PKI, and sufficiently so that attempting to describe the two processes in a single document may not be the most appropriate action. Some thoughts on the algorithm migration issue are to be found in draft-ietf-sidr-rpki-algs-01.txt.

Geoff

---

From: Stephen Kent <[email-masked]>
Date: Sun, 30 May 2010 10:38:44 -0400

At 8:32 AM +1000 5/29/10, Geoff Huston wrote:
>Steve,
>
>>  When I began work on the algorithm migration I-D, I realized that 
>>we first needed to document the key rollover process (with no 
>>algorithm change). There are hints about this in a few places in 
>>this document, but not a complete discussion of this important 
>>topic. Unless the WG chairs object, I will include the key rollover 
>>discussion as part of the I-D that is also going to discuss 
>>algorithm migration.  (Maybe I'll call it key and algorithm 
>>rollover :-).)
>
>It is my impression that key rollover and algorithm migration are 
>somewhat different in the demands they place on the PKI, and 
>sufficiently so that attempting to describe the two processes in a 
>single document may not be the most appropriate action. Some 
>thoughts on the algorithm migration issue are to be found in 
>draft-ietf-sidr-rpki-algs-01.txt.
>
>Geoff

Goeff,

I read the brief discussion there.  I believe the two may be more 
closely related, but until we work out all the details ...

Steve