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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
