Hi Brian, Thanks for your comments. Please see inline.
Roque
(snif)
>
> So the analogous high-level design for agility SHOULD be as follows:
> - new CP documents may be published, with new OIDs
The CP document in section 6.1.5 refers the definition of the Algorithm Suite
to the draft-ietf-sidr-rpki-algs document. There are not OID defined in the CP
document. That is why in our document we refer to an update of this document
instead.
> - 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
>
In section 4.1 we defined:
CA Ready Algorithm B Date - After this date, all (non-leaf) CAs MUST
be ready to process a request from a child CA to issue a
certificate under the Algorithm B suite
If I summarize your comment, you are stating that the definition of "ready" for
a CA should also include an update on its CPS to refer to the new suite. This
was understood but as what each CA will need to do to be ready to process
requests from a child CA is local to that CA, we did not got into the details.
The process that you have described is indeed the proposed algorithm in the
document for the CAs, where we adopted a "top-down" process and we maintain the
two suites independent. The document also includes the transition to the new
suite on the RPs that are distributed globally.
Regards,
Roque
> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
