Hi Deb, Are you happy with the latest version? https://datatracker.ietf.org/doc/draft-ietf-anima-brski-cloud/
Is there anything else that we need to do for you to clear your DISCUSS on this document? Regards, Rifaat On Wed, Aug 27, 2025 at 7:07 PM Deb Cooley <[email protected]> wrote: > It is much clearer and simpler. I like it better. Thanks. > > Deb > > On Wed, Aug 27, 2025 at 4:58 PM Owen Friel (ofriel) <[email protected]> > wrote: > >> Hi Deb – what do you think of this PR? It completely refactors and >> greatly simplifies section 8.2: >> >> >> >> https://github.com/anima-wg/brski-cloud/pull/257/files >> >> >> >> >> >> *From:* Deb Cooley <[email protected]> >> *Sent:* Tuesday 26 August 2025 21:00 >> *To:* Michael Richardson <[email protected]> >> *Cc:* The IESG <[email protected]>; [email protected]; >> [email protected]; [email protected]; [email protected] >> *Subject:* Re: Deb Cooley's Discuss on draft-ietf-anima-brski-cloud-16: >> (with DISCUSS and COMMENT) >> >> >> >> w/ [DC] below. >> >> >> >> On Tue, Aug 26, 2025 at 3:27 PM Michael Richardson <[email protected]> >> wrote: >> >> Deb Cooley <[email protected]> wrote: >> > 1. Section 8.2: I'm still struggling with finding the point here. >> I'd >> > like to be a bit more cohesive. State the issues/recommendations up >> > front (i.e tell a story). It looks like you are claiming that the >> end >> > customer 'has to' run a private PKI, the manufacturer 'could' run a >> > private PKI for the whole thing, or the manufacturer 'could' use >> some >> > subset of Web PKI Trust Anchors (which you call something else). >> I've >> > tried to do the 'use the public WebPKI' part below. >> >> RFC8995 (BRSKI) is for end customers that want to enroll a device into >> their >> private PKI (in a zero-touch way). >> So I really don't understand what you are complaining about here. >> There are options. >> >> >> >> [DC] Outline the options in a clear and logical fashion. Preferably >> without jumping around too much. >> >> >> 8.2 is about the tussle between being inclusive and reducing attack >> surface. >> >> Manufacturers that want to install IDevID into the devices (which BRSKI >> requires), already MUST have a private PKI for that. The conflicting >> lifetime >> requirements prevent using a "Web PKI Trust Anchor". >> (There is also a SAN contents struggle, but there are workarounds for >> that) >> >> Is "Web PKI Trust Anchor" (set) even a well-defined term? >> It's not a single set, as much as people would like to think it is. >> >> >> >> [DC] that is absolutely correct. Google, Apple, Mozilla, Microsoft, and >> many more (Adobe, Oracle, etc) all run Trust Anchor lists. So saying that >> one can just use it (like there is only one) is odd, at best. >> >> >> AFAIK, CABFORUM does not define it, web browser and OS vendors decide on a >> case-by-case basis (based upon criteria established by CABFORUM), if they >> will >> accept any specific anchor into their trusted set. >> >> >> >> [DC] Right, the owners of the trust anchor lists may listen to CA/B >> Forum, but they aren't beholden to them. They add the roots that they >> 'trust' when the rules that they set are satisfied. This is why you don't >> want to go down this rabbit hole. >> >> >> > 2. Section 8.2, last three paras: These are actually just three >> > sentences. Let's see if we can make a paragraph out of them. Put >> the >> > last sentence first, and second sentence second, and first sentence >> > last. Something like: "It is recommended for Manufacturers to work >> > with their VARs to determine if there is a subset of publicly >> trusted >> > (Web) PKI Trust Anchors that would satisfy all their VARs, and to >> ship >> > only that subset. Manufacturers need to include enough trust >> anchors >> > in their devices (the Pledges) so that all expected Cloud >> Registrar's >> > can be validated. While there is no requirement that Cloud >> Registrar's >> > certificates are part of the public (WebPKI) Trust Anchors, it is >> > likely simpler and cheaper for most such systems to use these easily >> > obtained certificates." >> >> okay, I'll see wehat we can do. >> >> > Nits: 8.1, para 2: 'device.is sheltered'/'device is sheltered . >> 8.2, >> > para 3: 'operate enough of a private PKI'/'operate a private PKI' >> >> okay. >> >> -- >> ] Never tell me the odds! | ipv6 mesh >> networks [ >> ] Michael Richardson, Sandelman Software Works | IoT >> architect [ >> ] [email protected] http://www.sandelman.ca/ | ruby on >> rails [ >> >>
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
