Howdy folks! This WGLC ended up being a bit more of a long discussion than I anticipated... I think since this WGLC there have been 2 document updates to catch comments/concerns/etc and I think deal with them properly.
I don't see anymore chatter for this document after 9/2/2016, so I think we should move this document forward to IESG.. I'll be sending along a pub request today. -chris On Tue, Jul 19, 2016 at 10:00 AM, Stephen Kent <k...@bbn.com> wrote: > Tim, > > > > Thanks for taking the time to read and comment on the document. > > > > I will change CA certificate analysis to be section 2.1, and make the CRL > section b 2.3, as per your request. The Manifest section will remain 2.2, > ROAs will become 2.4, GB will become 2.5, and Router Certificates will > remain 2.6. This will require a lot of changes to the pointers within and > between sections, but we aim to please :-). > > > > A-5.4.1: I agree that reducing the set of resources in a CA certificate > may be done for legitimate reasons, even if the INR holder does not agree > with the reduction. Nonetheless, this is an adverse action from the > perspective of the INR holder. It’s important to note that there are cases > when this reduction is the result of an attack against or an error by the > parent CA. Thus I believe it is important to retain this action in the > list. > > > > > > A-5.4.2: I’ll delete this action. > > > > A-5.4.5: I agree that this may be hard to distinguish from a legitimate > key rollover, except that a key rollover would have both old and new CA > keys present simultaneously. I’ll add a note to this effect. > > > > I disagree with your suggestion that we remove the modification, > revocation, and injection actions for Manifests, ROAs, and Router > Certificates. First, remember that adverse actions include errors by CAs, > and transient attacks against CAs. In the former case the private key is > clearly available and the CA may also control the repository. In the latter > case note that an attacker need not need learn the private key’s value; > he/she needs only the ability to cause an HSM to use the key. Also, an > attacker need not control the repository to effect these actions; an RP > might be misdirected to a different set of files via a routing system > attack (ironic?) or a DNS attack. > > > > Recall that the goal of this document is to document, as best we can, a > wide range of actions that are adverse, irrespective of whether we can > prevent or detect such actions. Your message noted that RRDP may make it > easier for RPs to detect some of these actions; I suggest you add > references to the relevant sections of this document as further motivation > for transitioning to RRDP. > > > > Finally, when we revised an earlier version of the document we decided to > include every action in the same order in each section (except for GB > records, where it would be trivial), to make it easier for a reader to see > that we were addressing the same issues for each object. > > Steve > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > >
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
