Thanks Deb! On Thu, Sep 4, 2025 at 11:51 AM Deb Cooley <[email protected]> wrote:
> 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]
