Re: [Acme] Changes in ACME WG leadership team
Roman Danyliw wrote: > Rich: This achievement is due to your time, commitment and leadership. > A profound thank you! From me as well! > I'm excited to announce that Deb Cooley has graciously agreed to serve > as the co-chair with Yoav. Deb brings top-sight of the security area > having worked in a number WGs, and a deep understanding of certificate > technologies and associated ecosystems. Awesome choice! It should be fun. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] AD review of draft-ietf-acme-authority-token-05
Hi! Checking in again on addressing the AD review feedback from October 2020 (~9 months ago). If we can't determine the disposition of this document on list, let's carve out agenda time on the IETF 111 to decide how to proceed -- coordinate with STIR on still needing it? appoint additional authors? drop the document? Regards, Roman > -Original Message- > From: Acme On Behalf Of Roman Danyliw > Sent: Wednesday, May 12, 2021 10:41 AM > To: acme@ietf.org > Subject: Re: [Acme] AD review of draft-ietf-acme-authority-token-05 > > Hi! > > I wanted to check-in with the WG on the next steps for draft-ietf-acme- > authority-token. I performed an AD review on it in October-2020 (~7 months) > and haven't heard back. Rich and I asked again in January 2021 and April 2021 > but got no response. Is this document something the WG still wants to > advance? > > Regards, > Roman > > > > -Original Message- > > From: Acme On Behalf Of Roman Danyliw > > Sent: Thursday, April 15, 2021 4:01 PM > > To: Salz, Rich ; Chris Wendt > > ; Mary Barnes ; > > Peterson, Jon ; davidhancock.i...@gmail.com > > Cc: acme@ietf.org > > Subject: Re: [Acme] AD review of draft-ietf-acme-authority-token-05 > > > > Hi! > > > > I'm checking in on status of this document. I'd like to batch it with > > draft-ietf- acme-authority-token-tnauthlist when they go to the IESG. > > > > Thanks, > > Roman > > > > > -Original Message- > > > From: Salz, Rich > > > Sent: Wednesday, January 13, 2021 3:16 PM > > > To: Roman Danyliw ; Chris Wendt > > > ; Mary Barnes > > > ; Peterson, Jon > > > ; davidhancock.i...@gmail.com > > > Cc: acme@ietf.org > > > Subject: Re: [Acme] AD review of draft-ietf-acme-authority-token-05 > > > > > > Authors, > > > > > > Have these been addressed? Soon? > > > > > > On 10/14/20, 1:00 PM, "Roman Danyliw" wrote: > > > > > > Hi! > > > > > > I performed an AD review of draft-ietf-acme-authority-token. > > > Thanks for writing this document in an extensible way (for > > > additional token types). Below is my detailed feedback. > > > > > > ** What is the intended status of this document? The document > > > says Informational; the datatracker and the shepherd's report says > > > Proposed Standard. TnAuthlist is PS. These four places need to be > consistent. > > > > > > ** Are there implementations of this document? The rough > > > history in ACME seems to have been PS should have implementation > experience. > > > Is the link to STIR decisive here (to make it PS)? > > > > > > ** ID-Nits reported the following issues with references being > > > listed but not > > > used: > > > == Unused Reference: 'I-D.ietf-acme-service-provider' is defined on > > > line > > > 455, but no explicit reference was found in the text > > > > > > == Unused Reference: 'I-D.ietf-acme-star' is defined on line 460, > > > but no > > > explicit reference was found in the text > > > > > > == Unused Reference: 'RFC7340' is defined on line 477, but no > > > explicit > > > reference was found in the text > > > > > > == Unused Reference: 'RFC8224' is defined on line 494, but no > > > explicit > > > reference was found in the text > > > > > > == Unused Reference: 'RFC8225' is defined on line 500, but no > > > explicit > > > reference was found in the text > > > > > > ** Additionally, on the topic of references, why are > > > [I-D.ietf-acme-authority- token-tnauthlist] , [RFC7340] and > > > [RFC8226] > > normative? > > > > > > -- Section 1. [I-D.ietf-acme-telephone] is an expired draft that > > > doesn't appear to be actively advanced. Given that it primarily to > > > show an example use case, it should likely be an informative, not > > > normative, > > reference. > > > > > > ** In the introductory materials (abstract and/or Section 1), I > > > would have benefited from an upfront statement that this document is > > > describing an architecture for Authority Tokens, a particular token > > > format, a new protocol for retrieving the token, and integration of > > > this token into an ACME challenge. In particular the existence of > > > the new protocol (between the TA and the client) was not clear. > > > > > > ** The tkauth-type="atc" type doesn't seem to describe all of > > > the required information described by Section 3.1 - 3.3 and Section > > > 9 (Security > > > Considerations) as being needed for a token format. Specifically: > > > > > > (a) Section 3.1. Per "Definitions of a tkauth-type MUST specify > > > how they manage the freshness of authority assignments", how is > > > freshness of authority assignment handled in tkauth-type="atc"? > > > > > > (b) Section 3.2 suggests that tokens need to convey scope. > > > This scope seems to be identifier specific conveyed through the tkvalue. > > > However, the values of tkvalue is out of scope of this document. > > > > > > (c) Section 3.3. suggests "To
Re: [Acme] Changes in ACME WG leadership team
Thanks! I’m looking forward to contributing. Many thanks to Rich Salz for many years of hard work! Deb Cooley > On Jul 9, 2021, at 2:57 PM, Yoav Nir wrote: > > Welcome aboard, Deb! > > > >> On 9 Jul 2021, at 19:26, Roman Danyliw wrote: >> >> Hi! >> >> To follow up on the announcement during IETF 109, after 6 years of leading >> the ACME WG from the very first BoF, Rich will be stepping down as co-chair. >> Under his stewardship, a working group was formed, the core specifications >> were completed, and most importantly, they saw adoption. The underlying >> ACME technology, and the services using it, have profoundly lowered the >> barrier to secure communication over the Internet. >> >> Rich: This achievement is due to your time, commitment and leadership. A >> profound thank you! >> >> I'm excited to announce that Deb Cooley has graciously agreed to serve as >> the co-chair with Yoav. Deb brings top-sight of the security area having >> worked in a number WGs, and a deep understanding of certificate technologies >> and associated ecosystems. >> >> Please join me in thanking Rich for his years of service in the WG, and >> welcoming Deb to the new role. >> >> Regards, >> Roman >> >> ___ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Changes in ACME WG leadership team
Welcome aboard, Deb! > On 9 Jul 2021, at 19:26, Roman Danyliw wrote: > > Hi! > > To follow up on the announcement during IETF 109, after 6 years of leading > the ACME WG from the very first BoF, Rich will be stepping down as co-chair. > Under his stewardship, a working group was formed, the core specifications > were completed, and most importantly, they saw adoption. The underlying ACME > technology, and the services using it, have profoundly lowered the barrier to > secure communication over the Internet. > > Rich: This achievement is due to your time, commitment and leadership. A > profound thank you! > > I'm excited to announce that Deb Cooley has graciously agreed to serve as the > co-chair with Yoav. Deb brings top-sight of the security area having worked > in a number WGs, and a deep understanding of certificate technologies and > associated ecosystems. > > Please join me in thanking Rich for his years of service in the WG, and > welcoming Deb to the new role. > > Regards, > Roman > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] Changes in ACME WG leadership team
Hi! To follow up on the announcement during IETF 109, after 6 years of leading the ACME WG from the very first BoF, Rich will be stepping down as co-chair. Under his stewardship, a working group was formed, the core specifications were completed, and most importantly, they saw adoption. The underlying ACME technology, and the services using it, have profoundly lowered the barrier to secure communication over the Internet. Rich: This achievement is due to your time, commitment and leadership. A profound thank you! I'm excited to announce that Deb Cooley has graciously agreed to serve as the co-chair with Yoav. Deb brings top-sight of the security area having worked in a number WGs, and a deep understanding of certificate technologies and associated ecosystems. Please join me in thanking Rich for his years of service in the WG, and welcoming Deb to the new role. Regards, Roman ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] comments on: draft-ietf-acme-integrations-03.txt
Sorry, I've been pulled in too many different directions. That message flow would work, I think. Getting a CSR, properly constructed, signed, etc. from the pledge is key. The CA can make changes before issuing a certificate, but the RA cannot. The two step process is the only way I can see to automate what we do manually today. Michael Richardson's 'civil serpents' made me laugh. Although most of those 'serpents' are military or contractors. In the end, the easier we can make it for them to do the 'right' thing, the better off we will be. Deb Cooley On Tue, Jun 15, 2021 at 2:50 AM Owen Friel (ofriel) wrote: > Deb in your govt PKI world then, would the flow be something like: > > > > > > There is no CSR Attributes exchange that allows the RA to tell the Pledge > to use a particular CN/SAN. > > > > Pledge sends CSR with, say, SAN=serialnumberx > > > > RA sends newOrder with identifier= serialnumberx > > > > ACME CA decides that the identity should be “ > serialnumberx.devices.some-gov-dept.example.org” (e.g. based on the RA > identity) > > > > ACME returns an authorization challenge for “serialnumberx.devices. > some-gov-dept.example.org” to the RA. > > > > The RA must then prove ownership of that DNS domain before the ACME CA > will issue the cert. > > > > > > > > > > This is how we envisaged the enterprise/civilian workflow: > > > > RA owns the domain e.g. devices.ra.example.org > > > > Pledge connects to RA using its IDevID and sends CSR Attributes request > > > > RA extracts serial#=abc123 (or whatever) from IDevID and appends domain to > it > > > > RA tells pledge in CSR Attributes response to include e.g. SAN= > abc123.devices.ra.example.org in CSR > > > > Pledge sends CSR with SAN= abc123.devices.ra.example.org > > > > RA sends newOrder with identifier= abc123.devices.ra.example.org > > > > ACME returns an authorization challenge for abc123.devices.ra.example.org > > > > RA proves ownership of abc123.devices.ra.example.org and ACME issues cert. > > > > (or using acme-subdomains, proves ownership of devices.ra.example.org) > > > > > > > > > > *From:* Deb Cooley > *Sent:* 10 June 2021 17:52 > *To:* Michael Richardson > *Cc:* Owen Friel (ofriel) ; acme@ietf.org; Cooley, > Dorothy E > *Subject:* Re: [Acme] comments on: draft-ietf-acme-integrations-03.txt > > > > Michael, > > > > In my world (government PKI systems), the RA doesn't get to do that. > Either the CSR is accepted or it is rejected. The CA has a profile it > follows, if the CSR is missing things, the CA adds them before the > certificate is signed. The RA can do none of that. In our case, most RAs > are actually people, so there can be a back channel to the requestor which > can be used to sort it all out. > > > > How this all happens in the case of 'little things', I don't know. We do > have a 'portal' for devices, but it would probably be quite 'heavy' for > your use cases. > > > > > > > > > > On Tue, Jun 8, 2021 at 4:15 PM Michael Richardson > wrote: > > > Owen Friel \(ofriel\) wrote: > deb> Again architecture: If the EST Server sits in front of a large > deb> organization, then domain validation is more interesting, and the > deb> Get /csrattrs may or may not be able to recommend a SAN, right? I > deb> can see that policy oids could be provided, if that is a thing in > deb> these systems. [we use policy oids in US DOD, but that is > possibly > deb> uncommon elsewhere.] > > ofriel> That is also a fair point, for complex deployments its not > clear > ofriel> what policy the EST server may want to apply before assigning a > ofriel> SAN. The text in section 3 currently states: > > “EST servers could use this mechanism to tell the client what fields > to > include in the CSR Subject and Subject Alternative Name fields” > > ofriel> We could beef up that statement and explicitly state that the > ofriel> policy by which the EST determines the SAN to specify is > ofriel> explicitly out of scope. And also note that policy OIDs could > be > ofriel> provided. > > I would love to hear from operators and designers of CAs about how a > RA can communicate to the CA about things it doesn't like, or wishes to > add, > to a certificate request. > > The CSR is immutable, being signed by the EE requesting. > ACME doesn't provide any out-of-CSR mechanism, nor does CMC or CMP (correct > me if I'm wrong here!)... Max and I talked a lot about this when design > RFC8995, > and we had to conclude that it was simply non-standard. > > In the case of ACP (RFC8994) use of BRSKI, like the Ford Model-T, the CSR > may > contain anything the Pledge wants to put in, it will get an otherName > containing the encoded ACP IPv6 ULA. > > In implementing, I also realized that the GET /csrattrs is > pseudo-idempotent. > When first called, it needs to allocate an IPv6 ULA for that node, and it > needs to store it, such that whenever the same IDevID does the GET, it gets > the same answer. It's
