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]
