At 7:48 AM -0500 11/8/11, Brian Dickson wrote:
...
What I am saying is, there is no reason to require a change to a child's CPS,
and thus its CP, and thus its algorithm suite, simply because the parent CA
is making this change. The whole 'all (non-leaf)' stuff is un-necessary.
this text makes it sound as though there is a per CA CP. The CP for
the RPKI is global. One possibility is that the CP is updated to
refer to two alg suites, and two policy OIDs, supplanting the old CP.
Since the changes would be limited to a vert small part of the CP, it
is not clear that one would want to have multiple CPs in place for
the RPKI at the same time. Also, removing the alg description from
the CP was intended to make the change to a new alg suite more
modular. Still, the difference between two CPs or one is not so
critical to this discussion.
Each CA may operate its CPS independently. Algorithms are explicitly included
via OIDs in every cert. A child CA may need to sign with algorithms
accepted by
the parent CA, but they can issue certs with a different CP, signed according
to the algorithms _of_that_CP_ (their own CP, independent of the choice of
CP used by the parent CA).
Every CA nominally has a CPS, so part of the statement above is
confusing. There are limitations to what a CA can do vs. what algs
its parent supports, e.g., because of PoP.
The choice of algorithm acceptability for a given cert, comes from the CP.
It needs internal consistency. There is no further requirement on
algorithm choice.
not entirely true. each CA MUST perform PoP (3.2.1 of the CP) when
issuing a cert to a subordinate CA. To perform PoP, the issuer must
be prepared to deal with the alg in the subordinate CA's public key
info.
> 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.
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.
Top down is strongly motivated because of the PoP issue, and because of the
repository growth issue. the WG agreed to mandate top down alg
transition last year (July, 2010), after a briefing at IETF 78. See
the proceedings for details.
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.
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.
The very brief description provided above does not contain sufficient
detail to enable it to be compared to the current proposal. it also
fails to address issues such as PoP, repository growth, and the
burden imposed on CAs and RPs to support algs forever, if some small
set of CAs or RPs choose to not transition.
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.
We do not believe that alg suite changes are unilateral decisions by
CAs, for the various reasons cited above.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
