[we should probably choose either dnsop or dnsext for this, and stop posting to both, sorry for starting that trend]
On 2011-01-31, at 16:44, John Bashinski wrote: > On 2011-01-31 14:32, Joe Abley wrote: > >> Individual trust anchors are also packaged as X.509 identity >> certificates, signed by various Certificate Authorities (CAs). > > How firmly are you attached to your approach? Would you be prepared to > consider supporting alternatives, if consensus could be gathered behind > them? Publishing the trust anchor as a CSR and subsequently signing that to produce a certificate is part of the existing workflow for KSK ceremonies, and changing it will not happen quickly. Change is certainly possible, however. My hope with this document was to present it in Prague, and suggest that the (a) working group adopt it. I think the general subject area needs work, and I think a working group is likely to do a better job than a pair of individuals. I don't think anybody is married to any particular approach. > Prodedural details > ================== > I assume you *are* saying that the > > http://data.iana.org/root-anchors/root-anchors.xml > > URL is guaranteed good for a long time? It's specified in the KSK manager's DNSSEC Practice Statement, and the IANA people at ICANN are happy to support it for as long as we manage the key. > I'm not sure what procedure we're meant to use to get the validated CSRs > to create the X.509 certificates for new KSKs. Can you say anything > about that? We (IANA, again) expect to find a workflow that suits the CA in question. If that means that IANA staff provide attestations and a copy of the CSR in a tamper-evident bag with corresponding documentation for a chain of custody, we can do that. > I assume that the "ultimate" way to do it is to send some people to a > key ceremony. To be honest, I'm not sure that I could convince > management (or even myself) that that gave enough extra assurance to be > worth it. I suspect what we'd end up doing, absent other guidance, > would be just grabbing the CSR from wherever, and looking at the root > KSK in use on our own internal systems to see if it was right... then > signing it. The participants who attended the first ceremony were able to witness the generation of the key and the corresponding hash on a screen connected directly to the ceremony laptop. Subsequent ceremonies have principally been concerned with processing the set of key material supplied by VeriSign for the next quarter, and have not involved key generation. > Some comments on the draft itself: > > Finding CAs > =========== > You say: > >> URLs >> to allow those certificates to be retrieved are included as optional >> elements in the XML document. > > I don't actually see any CA URLs in the XML at the moment. Right, this is something that occurred to me as we were discussing the bootstrap problem. I have a rev to the trust anchor document ready to go that includes those optional elements. > Obviously you can't just grab a root cert from such a URL and trust > it, anyway... you have to have either a wired-in copy of the cert > itself, or at least a wired-in copy of its public key. So I'm > not sure I see what having the URLs in the XML would do for anybody. The certificates you pull from those URLs would be of the form http://data.iana.org/root-anchors/Kxxxxxx.crt (the current name for the certificate produced using the IANA CA) http://data.iana.org/root-anchors/Kxxxxxx.crt.cisco (if that's the kind of thing cisco decided to do) http://data.iana.org/root-anchors/Kxxxxxx.crt.some-commercial-CA (and so on) The idea of inserting optional elements into the XML schema was to allow a device parsing root-anchors.xml to enumerate a list of URLs for candidate certificates. Whether or not you decided to trust that certificate would depend on whether you had shipped with an appropriate CA trust anchor (e.g. the IANA one, or a cisco one, or the some-commercial-CA one). >> alternatively a vendor may instantiate its own CA and make >> arrangements with the root zone KSK manager to have the corresponding >> identity certificate locations published in root-anchors.xml. > > Our devices already have copies of our own CA's root cert for other > reasons, so we'd just let them rely on that. I'd assume others would > do similarly. Then perhaps this scheme is not as unwieldy for cisco as it might first have seemed -- if that cisco CA key can be exercised to process the CSR containing the root zone KSK public key, and we can publish that in a reasonable place, the extra process involved might be fairly small. > Time > ==== > >> 3.1 Initial State >> [...] >> A validator must confirm that its local clock is sufficiently >> accurate before trust anchors can be established, and before >> processing of DNSSEC signatures can proceed. Discussion of timing >> considerations can be found in Section 4. > > How? Good question. The fact that the answer is not obvious doesn't eliminate the requirement to set the local clock, though. > Trust > ===== > I'm not sure I understand the phrase "trust anchor" the same way you > do. > >> 5.1 Retrieval of Trust Anchors from Local Sources >> >> A trust anchor which is packaged with validator software can never be >> trusted, [...] >> >> Validators should never use local trust anchors for bootstrapping. > > I think that by "trust anchor" here, you really mean "DNSSEC root > KSK", because below you say: Yes, I mean a copy of the root zone KSK public key, or a hash of it. > Either way, it's a local trust anchor... and I don't see why X.509 > keys are any less compromisable than DNS keys... The difference is that X.509 keys, as deployed by CAs, have expected lifetimes measured in decades. Right now we don't know what the expected lifetime of the root zone KSK is. Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
