[Acme] draft-ietf-acme-onion

Hi all, First of all apologies for not being able to show up at IETF119, as I'm sure you'll understand, presenting from the hospital isn't really an option. This is just a reminder to please share your comments/thoughts/criticisms of draft-ietf-acme-onion so we can progress the draft! Thanks in

Re: [Acme] draft-ietf-acme-client-05 and key attestations

--- > > *From:* Acme on behalf of Carl Wallace < > c...@redhoundsoftware.com> > > *Sent:* Friday, April 8, 2022 5:00:27 PM

Re: [Acme] draft-ietf-acme-subdomains and public suffixes

On Mon, May 16, 2022 at 7:47 AM Peter Thomassen wrote: > FWIW, the notion is already codified in RFC 7489 (Section 3.2) and RFC > 9091 (in the title, albeit experimental). Yes, doubly unfortunate, as the DBOUND WG can attest ;) Sure. However, if the relevant part of the DNS space is, at the

Re: [Acme] draft-ietf-acme-subdomains and public suffixes

Ryan, On 4/7/22 20:26, Ryan Sleevi wrote: Given that public suffices are an unfortunate fiction invented by browsers, it'd be doubly unfortunate to codify it in an IETF doc. FWIW, the notion is already codified in RFC 7489 (Section 3.2) and RFC 9091 (in the title, albeit experimental).

Re: [Acme] draft-ietf-acme-client-05 and key attestations

of Carl Wallace *Sent:* Friday, April 8, 2022 5:00:27 PM *To:* acme@ietf.org *Subject:* [Acme] draft-ietf-acme-client-05 and key attestations Given draft-ietf-acme-client-05 addresses provisioning device certificates and client

Re: [Acme] draft-ietf-acme-client-05 and key attestations

I agree that this would be an extremely useful addition! From: Acme on behalf of Carl Wallace Sent: Friday, April 8, 2022 5:00:27 PM To: acme@ietf.org Subject: [Acme] draft-ietf-acme-client-05 and key attestations Given draft-ietf-acme-client-05 addresses

[Acme] draft-ietf-acme-client-05 and key attestations

Given draft-ietf-acme-client-05 addresses provisioning device certificates and client certificates and both may be issued for keys that reside on mobile devices that support key attestation, would it make sense to include means of conveying key attestations to this draft? This wouldn’t align

Re: [Acme] draft-ietf-acme-subdomains and public suffixes

On Thu, Apr 7, 2022 at 10:36 AM Peter Thomassen wrote: > Now, should it be possible for the DNS admin of eu.org to request a > certificate for example.de.eu.org (or subdomains thereof) through the > mechanism described in the draft, although there is a public suffix in > between? (I don't think

[Acme] draft-ietf-acme-subdomains and public suffixes

Hi, Perhaps the following has been discussed before (although I wasn't able to find it, then); in that case, please let me know, and we can close the thread. I read the draft and think it is a good idea and well done. However, I was wondering: What if there is a public suffix between the

Re: [Acme] draft-ietf-acme-client: Was: Basic ACME question/Open Banking

Hi Kathleen & Co, I have now actually used ACME as well :) Anyway, I see a slight disconnect between ACME and how Open Banking CAs work today. That is, open banking application developers typically create an account using a Web application provided by the bank (or external CA). From this

Re: [Acme] draft-ietf-acme-dtnnodeid-07 issue

All, It appears that there is a logical issue in the current Node ID Validation draft [1]; I had incorrectly assumed that the current three inputs of the Key Authorization (token-chal, token-bundle, client account key thumbprint) provide proof of access to both the validated BP channel and the

Re: [Acme] draft-ietf-acme-client: Was: Basic ACME question/Open Banking

Hi Anders, On Tue, Oct 19, 2021 at 2:08 PM Anders Rundgren < anders.rundgren@gmail.com> wrote: > On 2021-10-19 19:00, Kathleen Moriarty wrote: > > Hello Anders, > > > > The draft extends ACME to add client challenge methods that might be > helpful. This could be for several use cases

Re: [Acme] draft-ietf-acme-client: Was: Basic ACME question/Open Banking

On 2021-10-19 19:00, Kathleen Moriarty wrote: Hello Anders, The draft extends ACME to add client challenge methods that might be helpful. This could be for several use cases including code signing automation or client certificate management.  Does the draft contain what you need? The use case

Re: [Acme] draft-ietf-acme-client: Was: Basic ACME question/Open Banking

Hello Anders, The draft extends ACME to add client challenge methods that might be helpful. This could be for several use cases including code signing automation or client certificate management. Does the draft contain what you need? The use case from your message is not clear to me. Thank you,

[Acme] draft-ietf-acme-client: Was: Basic ACME question/Open Banking

After some research I found https://datatracker.ietf.org/doc/draft-ietf-acme-client/ which almost fills the bill. What would the preferred procedure be, including challenge? Attestations like offered by FIDO is not a part of ACME, right? thanx, Anders On 2021-10-11 9:03, Anders Rundgren

Re: [Acme] draft-ietf-acme-star

On 13/09/2019, 13:41, "Thomas Fossati" wrote: > It seems to me that this might still be possible modulo > recurrent-certificate-adjust (rcp) being upper bounded by > recurrent-cert-validity (rcv), i.e., slightly changing the calculations > in 3.5 like this: > > notBefore = nrd[i] - predating

Re: [Acme] draft-ietf-acme-star

Thanks Richard for raising this and Ryan for taking the time to explain. On 11/09/2019, 17:52, "Ryan Sleevi" wrote: > I'm not Richard, but with respect to publicly trusted certificates, > issuing a certificate with a notBefore set prior to that certificate > was issued is seen as, minimally,

Re: [Acme] draft-ietf-acme-star

Hi! > -Original Message- > From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Thomas Fossati > Sent: Thursday, September 12, 2019 7:38 AM > To: Salz, Rich ; Richard Barnes > Cc: IETF ACME ; Thomas Fossati > > Subject: Re: [Acme] draft-ietf-acme-star > >

Re: [Acme] draft-ietf-acme-star

On 11/09/2019, 18:40, "Salz, Rich" wrote: > > the protocol is still correct/consistent. But, let's be bold as > > it's probably worth taking the risk :-) > > We can ask that the IESG/IETF do a simultaneous re-review period of > something like two weeks. Sounds good, thank you. IMPORTANT

Re: [Acme] draft-ietf-acme-star

>the protocol is still correct/consistent. But, let's be bold as it's probably worth taking the risk :-) We can ask that the IESG/IETF do a simultaneous re-review period of something like two weeks. Thanks. ___ Acme mailing list

Re: [Acme] draft-ietf-acme-star

On Wed, Sep 11, 2019 at 12:09 PM Thomas Fossati wrote: > 2 The pre-dating that the ACME server MUST do on cert rotation to > prevent the client to fetch a not-yet-valid credential (i.e., the > overlap you mention). > > IIUC, you are suggesting to drop the former, i.e., removing the ability >

Re: [Acme] draft-ietf-acme-star

Hi Rich, Richard, (Merging both your emails into one reply.) On 09/09/2019, 23:57, "Salz, Rich" wrote: > I don't care about the STAR acronym not bring known by those who don't > know :) but I think Richard's comments – most of which are, really, > wordsmithing nits of message-field names –

Re: [Acme] draft-ietf-acme-star

: Richard Barnes Date: Monday, September 9, 2019 at 6:44 PM To: Thomas Fossati Cc: "acme@ietf.org" Subject: Re: [Acme] draft-ietf-acme-star On Mon, Sep 9, 2019 at 4:15 AM Thomas Fossati mailto:thomas.foss...@arm.com>> wrote: Hi Richard, Thank you for the detailed review. As y

Re: [Acme] draft-ietf-acme-star

On Mon, Sep 9, 2019 at 4:15 AM Thomas Fossati wrote: > Hi Richard, > > Thank you for the detailed review. As you note yourself, this is quite > late in the document life-cycle (the draft completed IETF LC over a > month ago), which is unfortunate, given that every one of your comments > is an

Re: [Acme] draft-ietf-acme-star

Hi Richard, Thank you for the detailed review. As you note yourself, this is quite late in the document life-cycle (the draft completed IETF LC over a month ago), which is unfortunate, given that every one of your comments is an actual protocol change. As far as we understand, none of them can be

[Acme] draft-ietf-acme-star

I had a chance to take a look at this draft as a result of being a designated expert on the registries. I approved the registrations, but independently, I have several major concerns about the draft. In no particular order - The use of the "STAR" acronym is not helpful. This is not an acronym

Re: [Acme] draft-ietf-acme-ip-05

Hey Kathleen, I'm not clear on what you're after here. Do you see something in here forbidding use for client certificates that needs to be removed? Do you think there needs to be some explanation of how to put the right EKU in the CSR? It might help if you could submit a PR. --Richard On

[Acme] draft-ietf-acme-ip-05

Hello, In the ACME meeting, I had asked if this draft could have text added to address how client certificates could be generated since this was written specific to server certificates, but could easily be extended as the difference in most cases would just be in the CSR. Could this text be

[Acme] draft-ietf-acme-email-smime-03 - comments

Hi Alexey, Overall, this seems to be workable and useful. * In Sec. 3, definition of the format of the email address should refer to RFC 5322 (specifically, Sec. 3.4.1) and not 5321. * I've never seen "*" used to denote wildcards in the context of

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

One additional point. The same IANA process would be used to get object identifiers for subsequent versions. The difference is which table the value comes from. Russ > On Aug 15, 2018, at 11:10 AM, Richard Barnes wrote: > > I don't really think it matters much who's going to make a new

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

I don't really think it matters much who's going to make a new version. The only difference here is whether you go back to IANA to get a new code point. Given that the IANA process is not onerous, it seems like the extra couple of octets are not really adding anything here. So I'm inclined to do

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

The decision to format the OID this way was an early one that I’m not completely attached to. That said the existing solution does still feel cleaner to me than doing the versioning directly under id-pe. Given it’s unlikely that the version with be incremented by anything other than a document

[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] draft-ietf-acme-ip and draft-ietf-acme-caa

Ah, my bad on draft-ietf-acme-ip, I have a new version to submit but am still making a few changes, I thought the expiry notice was for my individual submission not the WG doc. I’ll submit the new version this afternoon. > On Apr 21, 2018, at 8:59 AM, Paul Hoffman wrote:

[Acme] draft-ietf-acme-ip and draft-ietf-acme-caa

Greetings. These two WG drafts are both expired, despite having been discussed at IETF 101 in London and draft-ietf-acme-ip being actively discussed on the list since then. What is the actual status of these two documents is? Have they been dropped from the WG? --Paul Hoffman

Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain

>I would rather sidestep the issue of what format to put the certificate >response in, by putting the certificates directly into the JSON ACME order >object. I have not seen any arguments against that premise (except for “size”) >and several arguments in favor of it. The "so-called PEM format"

Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain

> On Apr 26, 2017, at 9:55 PM, Jacob Hoffman-Andrews wrote: > > On 03/30/2017 09:04 AM, Sean Leonard wrote: >> IN PARTICULAR: both Apache and Ngnix may be subject to a private key >> substitution attack with naive passing of the ACME response to the web >> server! See: >>

Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain

Based on Jacob's research, I'm pretty well convinced that this is not an issue. Nonetheless, I have posted a PR to add some text about this risk. https://github.com/ietf-wg-acme/acme/pull/306 On Thu, Apr 27, 2017 at 12:55 AM, Jacob Hoffman-Andrews wrote: > On 03/30/2017 09:04

Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain

On 03/30/2017 09:04 AM, Sean Leonard wrote: > IN PARTICULAR: both Apache and Ngnix may be subject to a private key > substitution attack with naive passing of the ACME response to the web > server! See: > http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate >

Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain

> On Mar 30, 2017, at 10:47 AM, Jacob Hoffman-Andrews wrote: > >> Therefore the “receiver” is the ACME client, which also is the web/TLS > server that incorporates the chain into its operations. > > Note that in common deployment today, the ACME client is separate from > the web

Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain

> Therefore the “receiver” is the ACME client, which also is the web/TLS server that incorporates the chain into its operations. Note that in common deployment today, the ACME client is separate from the web server. On 03/30/2017 08:27 AM, Sean Leonard wrote: > Contents: DER-encoded

Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain

On 03/29/2017 01:48 PM, Sean Leonard wrote: > If you are saying that the receiver is only expected to handle TLS > 1.2-ordered certificates: “Each following certificate MUST directly > certify the one preceding it” (MUST, not SHOULD) then we have a > different situation and PKCS #7/CMS certs-only

Re: [Acme] draft-ietf-acme-acme-06: Don't call it PEM Certificate Chain

> On Mar 29, 2017, at 2:54 PM, Ilari Liusvaara wrote: > > On Wed, Mar 29, 2017 at 02:32:17PM -0500, Sean Leonard wrote: >> Hello, >> >> Second of all, I see negative value in transmitting certificates in >> the proposed “PEM Certificate Chain” format (Section 7.4.2.,

Re: [Acme] draft-ietf-acme-acme-04 and "PEM" problem (issue #194)

On 11/15/2016 09:29 PM, Sean Leonard wrote: > Since it says “should” I suppose this is normative language. However, > although it might be nice to put the certificates in order for stylistic > reasons, it should be a normative requirement. Is your client really going to > fail if the

[Acme] draft-ietf-acme-acme-04 and "PEM" problem (issue #194)

Hello: I noticed that issue #194 defaults to PEM with chain for certificates. However, the text in Section 6.4.2 is not correct. [RFC7468] is the correct reference but it should be called “PKIX textual encoding” or simply “textual encoding”, not “PEM”. Furthermore, application/x-pem-file is

Re: [Acme] draft-ietf-acme-caa-00 - security considerations

> In the security considerations, specifically 5.6, we omit the trivial but > most pertinent risk: the CAA record type must be implemented by all CAs in > order to be fully effective. Any CA that does not honor CAA can potentially > (mis-)issue a rogue cert for the domain in question. > > I

[Acme] draft-ietf-acme-caa-00 - security considerations

Hi, In the security considerations, specifically 5.6, we omit the trivial but most pertinent risk: the CAA record type must be implemented by all CAs in order to be fully effective. Any CA that does not honor CAA can potentially (mis-)issue a rogue cert for the domain in question. I suspect

Re: [Acme] draft-ietf-acme-acme-02 authorization

> It seems what we'd really want for that is the ability to query for all current authorisations and to be able to revoke them even if you aren't in possession of the account key that obtained them (but are in possession of the key which most recently performed authz). Another way to achieve

Re: [Acme] draft-ietf-acme-acme-02 authorization

It's worth pointing out that the latest draft of the domain validation ballot[1] written by the CA/B Forum Validation WG set the authorization lifetime at 39 months: > Completed confirmations of Applicant authority may be valid for the > issuance of multiple certificates over time. In all cases,

[Acme] draft-ietf-acme-acme-02 authorization

Hi, Reading the ACME 02 draft, I have a concern regarding the identifier authorization life time. Given a compromised TLS server, the attacker can solve an ACME challenge and be authorized for the hosts's name. This authorization can then be used to obtain valid certificates, even after the

[Acme] draft-ietf-acme

Howdy, At the meeting in Prague, the room felt that adopting draft-barnes-acme as a working group draft was appropriate (this is also in the charter). Richard is touching up the editing buffer for that now, but if you have a contrary opinion, now would be the time to let us know. thanks, Ted

Re: [Acme] draft-ietf-acme

On Wed, Aug 12, 2015 at 11:44 AM, Ted Hardie ted.i...@gmail.com wrote: ​So, this is a common misconception. Adopting a draft doesn't mean you think it is done or even that it has no known issues; it's a statement by the working group that this is a starting point. ​Think of it like picking

Re: [Acme] draft-ietf-acme

I think the duplicate-signature key selection attack Andrew Ayer discovered here really needs to be addressed (unless it already was): https://mailarchive.ietf.org/arch/msg/acme/F71iz6qq1o_QPVhJCV4dqWf-4Yc On Wed, Aug 12, 2015 at 10:46 AM, Ted Hardie ted.i...@gmail.com wrote: Howdy, At the

Re: [Acme] draft-ietf-acme

On Wed 2015-08-12 14:18:54 -0400, Tony Arcieri wrote: On Wed, Aug 12, 2015 at 11:03 AM, Martin Thomson martin.thom...@gmail.com wrote: I don't see that as reason enough to block adoption. It represents a conceptual misuse of digital signatures, and seems to me like a very fundamental

Re: [Acme] draft-ietf-acme

On Wed, Aug 12, 2015 at 11:03 AM, Martin Thomson martin.thom...@gmail.com wrote: I don't see that as reason enough to block adoption. It represents a conceptual misuse of digital signatures, and seems to me like a very fundamental design flaw which is easily addressed. I'm confused why you

Re: [Acme] draft-ietf-acme

On 12 August 2015 at 11:18, Tony Arcieri basc...@gmail.com wrote: It represents a conceptual misuse of digital signatures, and seems to me like a very fundamental design flaw which is easily addressed. I'm confused why you don't want to address it before adopting the draft. If we set a