Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03

[Stephen Kent <[e-mail]>]

At 1:27 AM -0500 11/8/11, Brian Dickson wrote:
>...

>I do not support adoption of this document in its current form.
>
>The main reasons have to do with fundamental aspects which at a high
>level have been addressed by my colleagues,

so, this is a Verisign critique, provided by you, Eric, and Danny?

>Here's why:
>- everybody is a CA. Both the "root" of the INR tree (ICANN/IANA),
>plus the RIRs, etc., down to the publishers of EE certs.

yes, essentially every actor in the RPKI is both a CA and an RP.

>- each CA publishes its policy via a CPS (it's a SHOULD, but
>functionally a MUST for RPs to be able to understand what a CA
>publishes.)

small ISPs and orgs that have address space probably will not bother 
with a CPS, which is why it is a SHOULD, not a MUST. In a typical PKI 
context, a CPS primarily benefits the subjects to whom certs are 
issued; RPs also are potential CPS consumers.  In the RPKI, a "keaf" 
CA issues certs to itself, so a CPS is not of much interest for the 
first class of consumers. In the RPLI one does not get to shop around 
to choose a CA, so RPs don't need much from a CPS.

>- Each CPS specifies the OID of the corresponding CP

there is just one CP. not clear form your statement if thatr ws clear.

>- Each CP refers to the corresponding policy for algorithms

there is only one policy (CP) for the RPKI, and it specifies algs via 
a reference to an alg spec. so, I am not sure what you have in mind 
here.

>- Algorithms themselves have OIDs and are referenced as such in certs

yes.

>- Every cert also specifies the OID of the CP itself (which embodies
>the rules for allowed algorithms)

yes.

>So while the first revision of the CP insists on only one algorithm
>for pub/private keys, and one algorithm for hashes, it explicitly
>calls out that these are expected to change.

yes.

>In changing allowed algorithms, it can reasonably be inferred that CPs
>could be issued which increase the _number_ of allowed algoriths of
>both types beyond one.

there is only one CP.

>And similarly, the methodology demonstrated by key rollover has local
>scope. There is no requirement that children do anything at all when a
>parent executes a key roll. _This is by design_.

yes, this is by design, but is irrelevant to the the alg transition 
design, which has global impact (on all RPs).

>
>So the analogous high-level design for agility SHOULD be as follows:
>- new CP documents may be published, with new OIDs

as I mentioned above, there is one CP for the RPKI. When you suggest multile
CPs, are you thinking of them on a per CA basis, or RPKI-wide?

>- ONLY when a CA with a given CPS decides to change CP does that CA
>need to execute a locally-significant key+alg roll

see question above. also, unlike key roll, an alg roll affects ALL RPs,
which is why the analogy between the two procedures is bad. Also, note my
'reply to Brian re the top-dowen deployment model that the Wg adopted, to avoid
exponential growth in the repository system.

>- The CA would issue new certs with the new CP which itself lists
>additional algorithms

ibid.

>- The same procedure would be executed in multiple phases - issue new
>child certs published under the old main cert; move them to the new
>cert, rewriting/overwriting in the same location

ibid.

>This could be handled gracefully by having two CPs - one CP having the
>additional algorithm(s), and subsequently another CP with the new but
>minus the old.

not graceful re repository growth, and impact on RPs.

>This mechanism could be used to introduce new algorithms without
>requiring retiring specific old algorithms. The two actions - adding
>and removing - are in fact independent, beyond the requirement that
>there be at least one algorithm (which goes without saying, really).
>The only other requirement is that the issued certs have algorithms
>consistent with the specified CP (OID) attached to the cert.

there needs to be one alg that ALL RPs can deal with at all times.  Also,
unlike key roll, when a CA wants to have a new cert with a public key
using a new alg, its parent MUST be able to support that alg, because of
the PoP requirement.

>I may be completely off the mark, but this would seem to be much more
>in line with the whole manner in which algorithms, policies, resource
>objects, etc., have been separated out and linked by normative
>reference.

I do not agree.

>Perhaps we could get Geoff Huston to comment on my interpretation of
>the CP/CPS/alg interaction and explicit/implicit rules?
>Is it intended that CAs have a uniform hierarchy using exactly one
>algorithm set, or is it intended that each CA be able to specify (via
>CPS + CP)  the set of algorithms it supports, with the initial CP
>document being the minimum acceptable algorithm set?

This text suggests that you believe there is on CP per CA, vs. a
system-wide CP. The architecture is the latter.  Also, while I respect
Goeff, why is your question directed to him? I am a co-author of the CP,
the arch, and the key roll and the alg roll docs :-).

Steve