It looks good. I've cleared my discuss. TYVM Deb
On Wed, Sep 3, 2025 at 6:53 PM Rifaat Shekh-Yusef <[email protected]> wrote: > 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]
