At 1:27 AM -0500 11/8/11, Brian Dickson wrote:
...
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,
so, this is a Verisign critique, provided by you, Eric, and Danny?
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.
yes, essentially every actor in the RPKI is both a CA and an RP.
- 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.)
small ISPs and orgs that have address space probably will not bother
with a CPS, which is why it is a SHOULD, not a MUST. In a typical PKI
context, a CPS primarily benefits the subjects to whom certs are
issued; RPs also are potential CPS consumers. In the RPKI, a "keaf"
CA issues certs to itself, so a CPS is not of much interest for the
first class of consumers. In the RPLI one does not get to shop around
to choose a CA, so RPs don't need much from a CPS.
- Each CPS specifies the OID of the corresponding CP
there is just one CP. not clear form your statement if thatr ws clear.
- Each CP refers to the corresponding policy for algorithms
there is only one policy (CP) for the RPKI, and it specifies algs via
a reference to an alg spec. so, I am not sure what you have in mind
here.
- Algorithms themselves have OIDs and are referenced as such in certs
yes.
- Every cert also specifies the OID of the CP itself (which embodies
the rules for allowed algorithms)
yes.
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.
yes.
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.
there is only one CP.
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_.
yes, this is by design, but is irrelevant to the the alg transition
design, which has global impact (on all RPs).
So the analogous high-level design for agility SHOULD be as follows:
- new CP documents may be published, with new OIDs
as I mentioned above, there is one CP for the RPKI. When you suggest multile
CPs, are you thinking of them on a per CA basis, or RPKI-wide?
- ONLY when a CA with a given CPS decides to change CP does that CA
need to execute a locally-significant key+alg roll
see question above. also, unlike key roll, an alg roll affects ALL RPs,
which is why the analogy between the two procedures is bad. Also, note my
'reply to Brian re the top-dowen deployment model that the Wg adopted, to avoid
exponential growth in the repository system.
- The CA would issue new certs with the new CP which itself lists
additional algorithms
ibid.
- 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
ibid.
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.
not graceful re repository growth, and impact on RPs.
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.
there needs to be one alg that ALL RPs can deal with at all times. Also,
unlike key roll, when a CA wants to have a new cert with a public key
using a new alg, its parent MUST be able to support that alg, because of
the PoP requirement.
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.
I do not agree.
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?
This text suggests that you believe there is on CP per CA, vs. a
system-wide CP. The architecture is the latter. Also, while I respect
Goeff, why is your question directed to him? I am a co-author of the CP,
the arch, and the key roll and the alg roll docs :-).
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
