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