All, I think the CABForum is indeed the right mechanism to alert both CAs and root programs to such a change, and then the root programs can include it in their periodic notices to their included CAs -- which will then cover all bases.
I would be happy to introduce the information to the CABForum's server certificate mailing list, and indicate its origin of course. Alternatively, anyone can email it to the CABForum Public List <pub...@cabforum.org> directly and then the appropriate CABF Working Group Chair would be responsible for forwarding it onward suitably. (Note: I'm a member of that public list's recipients, so I could confirm it wasn't lost.) I think either would be fine -- but if you'd like me to do the introducing, I'd appreciate it if you could synthesize me a quick rundown of what CAs need to know. Cheers! J.C. On Tue, Dec 3, 2019 at 10:24 PM Adam Roach <a...@nostrum.com> wrote: > [JC -- note for you at the very bottom] > > On 12/3/19 4:27 PM, Dave Lawrence wrote: > > Thank you very much for your review, Adam. I have incorporated your > > feedback into the document (which is not yet pushed to datatracker). > > > > Here's the diff: > > > > > https://github.com/vttale/serve-stale/commit/3ae0f4e5f79e0b326608beaa77b74a1efe62663c > > > > Adam Roach via Datatracker writes: > >> The addition of what I must presume is intended to be RFC 2119 > >> language to a document that doesn't cite RFC 2119 seems > >> questionable. I would suggest either explicitly adding RFC 2119 > >> boilerplate to RFC 1035 as part of this update, or using plain > >> English language to convey the same concepts as are intended. > > I definitely agree it is questionable, and if something needs to be > > done to resolve this then your first suggestion is the one that is > > more agreeable to me personally, but I can also see how that too is > > questionable and might get some pushback. It's a bit of a weird > > situation. > > > > It is perhaps worth noting that several other RFCs that have updated > > 1035, starting with 3658, have already used 2119 normative keywords. > > So in spirit it's already there, just not with an explicit remark in > > any of the that formally puts the boilerplate on 1035 itself. (And, > > in the end, that means 1035 is a weird hodge-podge of old world and new.) > > > That would be all the more reason to formally update RFC 1035 to > incorporate RFC 2119 terminology. I'll note that this document does go > well beyond the simple task explained in its title to do some general > unrelated housecleaning (cf. the high-order bit of the TTL), so it seems > to have taken exactly this kind of broad document maintenance under its > remit. > > > >>> A proposed mitigation is that certificate authorities > >>> should fully look up each name starting at the DNS root for every > >>> name lookup. Alternatively, CAs should use a resolver that is not > >>> serving stale data. > >> This seems like a perfectly good solution, although I wonder how > >> many CAs are likely to read this document. If I were the type to > >> engage in wagering, I'd put all of my money on "zero." I'm not sure > >> specific action is called for prior to publication of this document > >> as an RFC, but it seems that additional publicity of this issue and > >> the way that serve-stale interacts with it -- e.g., to CAB Forum and > >> its members -- is warranted. > > Completely agree, except to the point that if it were known that there > > was money riding on it then someone at a CA would read it just to take > > your money. :) That said, anyone have thoughts on how best to bring > > it to their attention? > > > > I'm copying JC Jones on this mail to seek his advice on this point. > > /a > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
