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]
