Subject: Re: [sidr] WG LC on draft-ietf-sidr-rpki-manifests-02.txt

From: Stephen Kent <[email-masked]>
Date: Mon, 13 Oct 2008 16:33:08 -0400

Geoff & Rob,

First, my recollection is that we decided that the cert for a 
manifest appears only in the manifest data structure, which still 
seems like a useful simplification.

So, I suggest that this EE cert  appear only in this location, and 
this not have its own publication point.  That does require that the 
cert be used ONLY for manifest validation. In the terminology Geoff 
crafted for the manifest I-D, this makes the EE cert for a manifest a 
single-use cert, (optionally a sequential use cert) even if it is not 
a one-time-use cert.

Geoff's message emphasized reuse of the private key, but Rob's 
message emphasized the desire to not have to put the manifest EE cert 
on a CRL if a manifest is reissued one or more times before its next 
scheduled issuance time.
There was no mention of the validity interval is for this cert in 
either Geoff's or Rob's messages.

For a one-time-use cert, the manifest I-D suggests that the EE cert 
lifetime match that of the manifest. That will cause each new EE to 
be on the CRL until the matching manifest expires, when a manifest is 
issued before the nextUpdate time. Presumably this is what triggered 
Rob's concern. The manifest I-D does not provide (useful) guidance 
for the validity period for a sequential-use EE cert associated with 
a manifest. Presumably the validity period will be longer than that 
anticipated for the manifest, else it makes no sense to view this as 
a sequential-use cert. So, it appears to me that a sequential-use, 
single-use cert satisfies Rob's concern about CRL growth.

The primary security rationale for revoking the EE cert for a 
manifest when a new manifest is issued is to alert RPs of the 
manifest change. The argument is that the revoked EE cert for the 
manifest will appear on the CRL, and RPs will thus know not to accept 
the old manifest. This argument presumes that RPs will acquire the 
new CRL in orders to perform this check. However, if an attacker 
replaces the new manifest and new CRL with the older, not yet expired 
versions, RPs will not be able to tell the difference, so the cited 
rationale is not a good one.

This suggests that a sequential-use EE cert for the manifest is just 
as secure as a one-time-use cert, relative to the unscheduled 
manifest change case.

Given this observation, I suggest that we mandate that the manifest 
nextUpdate value and the nextUpdate value in the CRL that covers the 
EE cert used to verify the manifest be the same. Otherwise, if the 
CRL is scheduled to be reissued before the manifest, the manifest 
will have to be reissued at that time, so that it contains the 
current CRL hash value, and we'll create a preventable stale manifest 
problem. (I also suggest that this analysis be included in the 
manifest I-D.) If CRL and manifest issuance are synchronized, as 
suggested above, then a sequential-use EE cert for a manifest can 
safely have a lifetime that spans multiple manifests. The primary 
argument for one-time-use EE certs for manifests, is the same as for 
ROAs, i.e., the underlying private key can be forgotten after use, 
making the system somewhat safer as a result.

As for terminology, a CA is an entity, a CA cert is not. We can talk 
about the current CRL issued by a CA and verified using the CA's 
cert, but a manifest is issued by a CA (through an EE representing 
the CA), nit by a CA cert.

Finaly, the document has LOTS of instances where is refers to objects 
signed by a given cert. This has to be fixed, as certs are not used 
to sign objects; they are used to verify signed objects.

I'l, send Geoff a marked up version of the manifest I-D with some of 
the edits based on my comments above.

Steve
_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr