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

[Brian Dickson <[e-mail]>]

Sorry for the late reply.

I have been following the discussion, and reviewing all the related
items (normative/informative).

I will note that the compartmentalized design of the ROA elements of
SIDR mean it is possible to update pieces easily.
However, on the mere mortal reviewer of component IDs, it puts a
larger burden. It is well worth the cost, IMHO.

I hope my comments aren't too late. Given the number of other items in
the WG that had informally extended periods, I would appreciate
leniency here.

My main comment is as follows:
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, especially with respect to
timelines imposed by the IETF, or even IESG or IAB, whether directly
in BCP or RFC, or indirectly via ICANN or IANA.

More to the point - I am not sure if I understand the relationship
between some of the elements involved, but I believe there is no
strict requirement for all members of a CA hierarchy to maintain
identical algorithms.

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.
- 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.)
- Each CPS specifies the OID of the corresponding CP
- Each CP refers to the corresponding policy for algorithms
- Algorithms themselves have OIDs and are referenced as such in certs
- Every cert also specifies the OID of the CP itself (which embodies
the rules for allowed algorithms)

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.

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.

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_.

So the analogous high-level design for agility SHOULD be as follows:
- new CP documents may be published, with new OIDs
- ONLY when a CA with a given CPS decides to change CP does that CA
need to execute a locally-significant key+alg roll
- The CA would issue new certs with the new CP which itself lists
additional algorithms
- 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

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.

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.

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.

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?

Modulo the interaction between parents/children, and requiring old
algorithms to be retired, and having a set timeline, and  having all
global CAs on the same timetable, the general methodology for handling
the phases seems pretty solid.

IMHO.

Brian