Re: [Acme] Internet-Draft: PQC Algorithm negotiation in ACME

s and is setting up servers is often > different from the part of organization that can change DNS, and they can't > always coordinate their work for reasons that should be familiar to anyone > with the misfortune of ever working for a large company. > > -Tim > >> -Ori

Re: [Acme] Internet-Draft: PQC Algorithm negotiation in ACME

Thinking about KEM PoP in the context of ACME. The subject must provide the KEM subject public key as part of the certificate request. A new challenge could be defined (for example, dns-kem-00) where the token is a KEM ciphertext, and the subject needs to put the corresponding plaintext in to

Re: [Acme] Internet-Draft: PQC Algorithm negotiation in ACME

Mike: Enterprises that do face-to-face enrollment and issue a token that contains a signature certificate and a key management certificate do not need a PoP protocol for the key management private key. Russ > On Aug 8, 2023, at 6:38 PM, Mike Ounsworth > wrote: > > This draft raises an

Re: [Acme] Call for adoption for draft-bweeks-acme-device-attest

I think the ACME WG should adopt this document. I have a couple of comments below. Minor: Section 1: The text talks about permanent-identifier. Please add a reference to RFC 4043 the first time this term is used. Section 1: The text talks about hardware-module identifier. Is this about

Re: [Acme] draft-aaron-acme-ari call for adoption

I have no objection to adoption, but I do think that Appendix A needs more explanatory text to tell what these examples are showing. Russ > On Jul 28, 2022, at 8:12 PM, Deb Cooley wrote: > > At the working group session today, we did a quick count for those who agreed > to adopt this draft.

Re: [Acme] WG Last Call for draft-ietf-acme-integrations-08

I looked at the diff, and the comment that I had on the previous version have been addressed. Russ > On Jul 5, 2022, at 2:08 PM, Deb Cooley wrote: > > Let's do another WGLC, if that's ok. Please respond by 15 July (after the ID > draft cutoff, but hopefully we won't need another version).

Re: [Acme] WG Last Call for draft-ietf-acme-subdomains-03

It looks fine to me. I notice just one nit: Section 2: Please refer to [RFC5280] in the definition of Certification Authority. Russ > On Jun 6, 2022, at 12:36 PM, Deb Cooley wrote: > > A couple of more days for this WGLC and crickets > > For the ACME WG chairs, > DebCooley > > On

Re: [Acme] WG Last Call for draft-ietf-acme-integrations-07

I have a few comments. Only one of them will be difficult to sort out. Section 1, para 1: Please add a cite to [RFC5280] after "X.509 (PKIX) certificate". Section 1, last para: Please reword. Something like: Optionally, ACME for subdomains [I-D.ietf-acme-subdomains] offers a useful

Re: [Acme] 2nd working group call for adoption

I have read the document, and I think that ACME should adopt it. Russ > On Oct 14, 2021, at 8:16 AM, Cooley, Dorothy E > wrote: > > This is the second working group call for adoption of: > draft-friel-acme-subdomains-05. > We have had presentations of this work at the most recent interim >

Re: [Acme] working group call for adoption

I have read this document, and I think the ACME WG should adopt it. Russ > On Aug 31, 2021, at 11:37 AM, Cooley, Dorothy E > wrote: > > This is a working group call for adoption of: > draft-friel-acme-subdomains-05. We have had presentations of this work at > the past couple of IETF meetings

Re: [Acme] AD Review of draft-ietf-acme-dtnnodeid-04

Brian: Is the AD that sponsored that document part of this discussion? If not, I suggest that we loop them in. Russ > On Aug 20, 2021, at 3:10 PM, Brian Sipos wrote: > > Rich, I see your point. I had made my own assumptions that tools would > validate that the SAN URI contained a valid URI

Re: [Acme] AD Review of draft-ietf-acme-dtnnodeid-04

Roman: I think that DTN would conform with RFC 5280 and with RFC 3986 if it used one slash instead of two slashes. Is that a smaller revision than other that have been discussed? Russ > On Aug 13, 2021, at 6:59 PM, Roman Danyliw wrote: > > Hi Ryan! > > > From: Ryan Sleevi

Re: [Acme] Comments on draft-ietf-acme-integrations

>> MAJOR: > >> Sections 3, 4, 5, and 7.2 seem to have a misunderstanding of EST CSR >> Attrs, which were recently explained by Dan Harkins on the LAMPS WG >> mail list: > > In light of this, I agree. > > We will have to figure out how to communicate to the client/pledge the > desired

[Acme] Comments on draft-ietf-acme-integrations

During the IETF 111 session, I agreed to review draft-ietf-acme-integrations. I have a few comments. MAJOR: Sections 3, 4, 5, and 7.2 seem to have a misunderstanding of EST CSR Attrs, which were recently explained by Dan Harkins on the LAMPS WG mail list:

Re: [Acme] WGLC for ACME DTN Node ID

These changes resolve my concerns. Russ > On Apr 9, 2021, at 5:40 PM, Brian Sipos wrote: > > Russ, > Thank you for the review comments. My responses are inline with prefix > "[BS1]". > >> I think that this document is almost ready. I have a few comments. > >> MAJOR: > >> Section 4 points

[Acme] Secdir telechat review of draft-ietf-acme-star-delegation-07

Reviewer: Russ Housley Review result: Ready I reviewed this document as part of the Security Directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security Area Directors. Document authors, document

Re: [Acme] WGLC for ACME DTN Node ID

I think that this document is almost ready. I have a few comments. MAJOR: Section 4 points to Section 4.4.2 of [I-D.ietf-dtn-tcpclv4]; but that profile does not require the certificate to include an EKU of id-kp-bundleSecurity. When this document is used to verify control over the DTN Node

Re: [Acme] Secdir last call review of draft-ietf-acme-star-delegation-06

of the other topics have been sorted out. Russ > On Mar 25, 2021, at 4:02 PM, Thomas Fossati wrote: > > Hi Russ, > > On 25/03/2021, 19:28, "Russ Housley" wrote: >> >> You will see my comments in those issues. > > Thanks very much! > > We hav

Re: [Acme] Secdir last call review of draft-ietf-acme-star-delegation-06

; https://github.com/yaronf/I-D/issues/145 > https://github.com/yaronf/I-D/issues/146 > https://github.com/yaronf/I-D/issues/147 > https://github.com/yaronf/I-D/issues/148 > > Thanks, > Yaron > > > On 3/23/21, 15:26, "Russ Housley" wrote: > >

Re: [Acme] Secdir last call review of draft-ietf-acme-star-delegation-06

of the complexity of navigating the markdown > diffs. > > I have attached the output of rfcdiff, which should give you a more > comfortable view over those changes. > > On 22/03/2021, 19:30, "Russ Housley" wrote: >> https://github.com/yaronf/I-D/issues/142 &

Re: [Acme] Secdir last call review of draft-ietf-acme-star-delegation-06

Yaron and Thomas: Comments below ... >> Abstract: It says: "... party access to a certificate associated with >> said identifier." This is odd wording, and it is incorrect. The >> party needs access to the private key that corresponds to the public >> key in the certificate, and the

[Acme] Secdir last call review of draft-ietf-acme-star-delegation-06

Reviewer: Russ Housley Review result: Not Ready I reviewed this document as part of the Security Directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security Area Directors. Document authors

Re: [Acme] Short WGLC review of draft-ietf-acme-email-smime-13

This makes sense to me. Russ > On Dec 10, 2020, at 1:23 PM, Salz, Rich > wrote: > > In order to address feedback that came up during AD and WGLC review, Alexey > posted a new draft. > This link will show the differences: >

Re: [Acme] Adoption of draft-sipos-acme-dtnnodeid

I read it and posted comments. I think we should adopt the document as a starting point. Russ > On Aug 13, 2020, at 11:27 AM, Salz, Rich > wrote: > > At IETF 108, we discussed > https://datatracker.ietf.org/doc/draft-sipos-acme-dtnnodeid/ >

[Acme] Review of draft-sipos-acme-dtnnodeid-01

Document: draft-sipos-acme-dtnnodeid-01 Reviewer: Russ Housley Date: 2020-08-05 Major Concern: Section 1: I think that this ACME enrollment mechanism is limited to "dtn" and "ipn" URIs. Please say so at the very front of the document. Section 1: the description stops

[Acme] Review of draft-friel-acme-subdomains-02

Document: draft-friel-acme-subdomains-02 Reviewer: Russ Housley Date: 2020-08-04 Major Concern: The TODO markers regarding wildcard domain names, the 200 response code, and the security considerations should be filled in with strawman text before this I-D is adopted by the ACME WG. Minor

Re: [Acme] AD Review of draft-ietf-acme-email-smime-07

> On May 29, 2020, at 12:38 PM, Alexey Melnikov > wrote: > > Hi Roman, > > Thank you for your detailed review. > > On 22/05/2020 15:54, Roman Danyliw wrote: >> Hi! >> >> I completed my AD review of draft-ietf-acme-email-smime-07. Thanks for the >> work on this document. Here is my

Re: [Acme] I-D Action: draft-ietf-acme-tls-alpn-04.txt

Roland: Thanks for the update. In addition to the changes that I requested, you added: The extnValue of the id-pe-acmeIdentifier extension is the ASN.1 DER encoding of the Authorization structure. Authorization is just an OCTET STRING. For clarity, it might be useful to say: The

Re: [Acme] draft-ietf-acme-tls-alpn-03

to the registration to > the SMI numbers registry. > > With that said if there is WG consensus to move to this suggested version I’m > happy to oblige and move forward with it. > > > On Aug 14, 2018, at 12:00 PM, Russ Housley > <mailto:hous...@vigilsec.com>> wr

[Acme] draft-ietf-acme-tls-alpn-03

This document include a particular object identifier, and IANA has not assigned it yet. Please do not assume that you will get the next available number. Someone else could get there before you. This document uses the following syntax for the certificate extension:

Re: [Acme] Do we need/want mandatory-to-implement signature algorithms?

> On May 30, 2018, at 3:54 PM, Salz, Rich > wrote: > > Yes, please ask. If I'm going to tell the IESG that no MTI is needed, I want > to tell them that the WG had consensus. > > This came up in the “AD review” thread that many of you have probably just > seen and skimmed or ignored. :) >

Re: [Acme] AD Review: draft-ietf-acme-acme-12

Eric: > > > > Do you want to specify a set of acceptable signature algorithms here? > > > > I am inclined not to. We have already forbidden "none" and MAC. We > > shouldn't specify "MUST"s here, because CABF sets their own list of > > required algorithms, and we don't want to conflict. I

Re: [Acme] Consensus -- CAA draft to WGLC?

I do not see how the comments from Richard Barnes were handled. Russ > On Jun 30, 2017, at 10:30 AM, Salz, Rich wrote: > > Based on feedback here, Hugo just posted an updated draft, > https://tools.ietf.org/html/draft-ietf-acme-caa-02 > > I would like to advance this to

Re: [Acme] Call for adoption STAR (short-term automatically-renewed) certificates

> On 08/06/2017, 20:56, "Acme on behalf of Russ Housley" <acme-boun...@ietf.org > on behalf of hous...@vigilsec.com> wrote: >> After very quickly looking at the document, I am not clear which >> parts will make up the ACME extensions. I need more clarity to

Re: [Acme] Call for adoption STAR (short-term automatically-renewed) certificates

After very quickly looking at the document, I am not clear which parts will make up the ACME extensions. I need more clarity to offer an opinion. Russ > On Jun 8, 2017, at 12:25 PM, Salz, Rich wrote: > > At the June 2 interim, we had consensus to adopt >

Re: [Acme] Adopt two email-related drafts

> At the interim, we had strong consensus to adopt Alexsey’s draft (was one, is > now two) on ACME challenges and certs for email services and users: > > https://datatracker.ietf.org/doc/draft-melnikov-acme-email-smime/ >

Re: [Acme] Call for adoption; (1) ACME challenge for ATIS/SIP (2) identifiers and challenges for telephone numbers

I think the ACME group should adopt both of these documents. Russ > On Jun 8, 2017, at 11:32 AM, Salz, Rich wrote: > > At the interim we had strong consensus to adopt these two drafts as WG > documents. I am grouping them in a single email because they are related, > and

Re: [Acme] ACME -06: revocation

Yaron: If a party that has access to the private key is telling the CA that the certificate ought to be revoked. I’m thinking that the CA ought to revoke it. Any party that has access to that private key can do far more malicious things. Russ > On May 30, 2017, at 11:48 AM, Richard Barnes

Re: [Acme] ACME interm meeting poll

>> In addition, Alexey is interested in helping with an ACME challenge for >> email certificates. Is anyone else interested in helping to draft drafting? > > Has there been anything about this on the list? Anyway, I’d be happy to help > with that. I’m interested in that as well, especially

Re: [Acme] HPKP in ACME

I am in favor of removing the SHOUL for HPKP. As I said in my WG Last Call comments, I support a SHOULD for OCSP stapling. Russ > On Feb 21, 2017, at 10:04 AM, Daniel McCarney wrote: > > > Does anyone else feel strongly? Can we aim for consensus for > > Monday? > >

Re: [Acme] terms-of-service boolean

> On Feb 19, 2017, at 12:49 PM, Josh Soref wrote: > >> terms-of-service-agreed (optional, boolean): > > This should really be a URL, not a boolean. > >> : Including this field in a new-account request, >> with a value of true, indicates the client's agreement with the terms

Re: [Acme] fulfill

> On Feb 19, 2017, at 12:27 PM, Josh Soref wrote: > >> A client should attempt to fulfill at most one of these challenges, > > fulfill is an odd word. And "attempt" is an odd word in concert. I'm > pretty sure you're trying to say to a client "once you've fulfilled a >

Re: [Acme] Repeated tokens for different challenges in same authorization

> In the WGLC thread, Russ asked: > >> In Section 6.5, should the example use different challenges for "http-01", >> "tls-sni-02", and "dns-01"? > (https://ietf-wg-acme.github.io/acme/#rfc.section.6.5) > > I assume you meant "token" here, and no, I think the token can be the same > across

Re: [Acme] ACME draft is now in WGLC.

Rich asked to me to divide my comments into technical and editorial. This are the same comment that I sent earlier with that categorization. Russ = = = = = = = = TECHNICAL In Section 5.1, I think it is desirable to add a requirement that the ACME server SHOULD OCSP Staple. In Section 5.5,

Re: [Acme] Account Key Loss

On Aug 18, 2016, at 5:45 PM, Roland Bracewell Shoemaker <rol...@letsencrypt.org> wrote: > On 08/18/2016 11:14 AM, Russ Housley wrote: >> In Berlin, I agreed to offer a few words about account key loss. Here >> it my initial suggestion. After the mail list makes imp

Re: [Acme] Issue: Allow ports other than 443

Allowing the Web server to continue running on 443 while validation takes place on another port seems like a straightforward resolution to the issue that is raised. Russ On Nov 21, 2015, at 1:03 PM, Salz, Rich wrote: > Please see here for the background: >

[Acme] Proposed ACME Charter Language

At the end of the ACME BoF, it was suggested that the next step was charter language. I took a stab at some to get the discussion going. I did not consider milestones yet. I think it is easier to get consensus on the charter text and then discuss milestones. Please review and comment. Russ

Re: [Acme] Proposed ACME Charter Language

/04/15 16:57, Russ Housley wrote: Stephen: I did not see the ACME effort as trying to throw everything out. If it is not used, then I don't think we're throwing it out:-) Rather, throw out the parts that have been an impediment to the kind of automation proposed by ACME, but document