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

[Roque Gagliano <[e-mail]>]

Hi Brian,

Lets focus on this part:

> That's the part I disagree with entirely - there is no "top-down"
> required at all.
> There is no "globally". There is only the requirement operationally
> that any newly
> published CP with new OID be supported by RPs.
> 
> The publishing the new CP with new OIDs with sufficient time for RPs
> to implement
> those changes is the only timeline issue. It is a "sunrise" issue - a
> minimum time
> after publication before ANY CA begins to issue certs using the new OID.

This is fine in a model where every CA lives in its own island (think on the identity case) but not in our case. A CA needs to issue a certificate-signing-request to its parent CA.

The WG decided to not allow "mixed" CA certificates. Consequently, you need your parent to be "ready" before been able to issue the CSR. This is the reason for the "top-down" requirement. So for "any" CA to issue certs using the new OID it needs that it parent has migrated first.

The rest of your reasoning seams to go around the same concept.

Roque.



> After that date, any CA may choose to use the new CP, without
> requiring any change
> to either the CA's parent, or the CA's children, except as relates to
> the algorithms
> used on new certs, which the child needs to discover. This has no bearing on the
> CP _used_ by the child CA in issuing certs to grand-child CAs - that
> is under the
> local policy of the child CA.
> Every CA is free to choose the CP it uses from among the published CPs, modulo
> the issue date plus delay required (6 months in the initial CP document).
> 
> Issuing a second (or third, or fourth) CP does _not_require_ANY_ CA to change
> algorithm suite.
> 
> Perhaps a separate BCP can recommend, or even require, use of some subset
> of CP documents, or at some point an old CP could be moved to historic or
> depracated status.
> 
> However, that should _not_ be part of the alg-agility document.
> Agility should limit
> itself to the mechanism by which a _single_ CA changes algorithm
> suite, including
> the possibility that the new suite still include all the algorithm(s)
> from the previous
> suite, the possibility that multiple algorithms are part of the new
> suite, as well as
> case of (but not a requirement that) _an_ older algorithm is dropped
> from the suite.
> 
>> Regards,
>> Roque
> 
> Sincerely,
> Brian