Re: [Acme] High level comments on draft-barnes-acme (the GitHub version)

On 25 March 2015 at 17:21, Jacob Hoffman-Andrews j...@eff.org wrote: This seems like a big deal, no? That is, since SNI is one of the few things not protected in the TLS handshake, it does seem spoofable. If there's not something I'm missing, it seems like the proposal should just drop DVSNI

Re: [Acme] Want client-defined callback port

On 22 April 2015 at 19:33, Peter Eckersley p...@eff.org wrote: Perhaps those policies can be stored out of band, or perhaps we can add a separate REST API endpoint where clients ask what ports the server considers acceptable for DV Challenges. Or just pick port 100 (or another that isn't

Re: [Acme] Proposed ACME Charter Language

On 13 May 2015 at 16:39, Salz, Rich rs...@akamai.com wrote: I'd prefer if we just recorded issues there, but discussed them in the mailing list. I'd go further and treat that as a private enterprise. They might help track our issues for us, but until we have an official tracker, it has no

Re: [Acme] Current Charter language

On 15 May 2015 at 11:09, Salz, Rich rs...@akamai.com wrote: Any other obvious edits needed? LGTM Shipping is a feature. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

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

[Acme] PR to implement Ted's suggestion

https://github.com/ietf-wg-acme/acme/pull/2 ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Open issues on GitHub

Others might disagree, but those look largely editorial to my reading. My guess is that the editors are busy and will address your concerns when they are able. If you think that there is a technical deficiency with the specification, definitely bring it here. Opening an issue as well helps with

Re: [Acme] Content-Type and file extensions for HTTP01 challenges

On 12 November 2015 at 16:44, Peter Eckersley wrote: > But is 3 the best answer? Of those presented, I think so. I know that this isn't a great answer (it's bad already, so bad must be OK), but being able to drop things into .well-known opens a raft of other interesting attacks.

Re: [Acme] Adding an Extension to http-01 Answers

At the meeting, we concluded that you would not have to include a specific MIME media type in responses. Serializing the octets of the base64-encoded string would be enough. Does that make your problem easier? On 10 November 2015 at 16:58, Bryan Livingston wrote: >

Re: [Acme] New draft and DANGER

On 28 September 2015 at 13:43, Ted Hardie wrote: > I'm not sure this quite right. If I understand the proposal correctly, when > a client sees http-01 but understands only http-00, the idea that one is > related to the other has no meaning, as the client can only respond to >

Re: [Acme] Support for domains with redundant but not immediately synchronized servers

This seems to be a common problem, so I opened a PR that someone on that project can merge. On 4 December 2015 at 08:08, Salz, Rich wrote: >> Should I open an issue on the protocol draft repository? (Which I assume is >> at [1]) >> [1]:

Re: [Acme] Agreement integrity checksum

Two comments: Echoing an etag would be easier. SHA-512 is overkill. On 9 December 2015 at 10:15, Michael Tandy wrote: > Currently in the new-reg stage, the client POSTs a signed message, which may > contain the URI of a user agreement. If the content of the URL changes, the

Re: [Acme] The path to the "directory" resource should not be "/" and should be specified in draft-ietf-acme-acme-01

On 9 January 2016 at 08:46, Albert ARIBAUD wrote: > Actually, I withdraw this statement: acme-v01.api.letsencrypt.org's > "/directory" is just as compliant as "/acme" or "/". There is no > reason to constrain the path of the directory object to a specific > value. > > In

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

On 23 November 2015 at 10:09, Douglas Calvert wrote: > How does showing control over port 443 convey more information than showing > control over port 22, 80, 487, 1023? Basic information theory: p(control over 443) < p(control over any port under 1024) <

Re: [Acme] Server on >= 1024 port

On 25 November 2015 at 02:13, Paul Millar wrote: > Therefore, there seems no reason to limit ACME to the traditionally secure > port number. I would be OK with having an ACME server validate against any port, but only if it were going to issue a certificate with a

Re: [Acme] Revoking certificates issued by an unknown ACME server

On 15 January 2016 at 17:26, Hugo Landau wrote: > This isn't sanely automatable. Correct. But it doesn't require any work to define. Do you have evidence that suggests this scenario (a certificate issued by an ACME server needs revocation by someone other than the one who

Re: [Acme] tls-sni-01 validation compromise

On 22 January 2016 at 13:38, Jehiah Czebotar wrote: > 1) Change the requirement that the self signed cert have one DNSName, > and require the response to have TWO DNS names. One that matches the > requested hostname, and a second that is secret which proves it can > only be

Re: [Acme] On multiple CAs and contact-based recovery

On 24 March 2016 at 09:33, Karthik Bhargavan wrote: > Emails with clickable links are *BAD*; we should enhance their security by > linking them better with > the ACME account key. FWIW, I think that a clickable link could be possible, it just wouldn't be able to

Re: [Acme] Paging for authorizations and certificates lists

I hope, for everyone's sake, that (assuming we accept this PR, which is a good idea in general) implementations will be setting limits quite low before triggering paging. Otherwise, we will have a feature that is surprising when developers first encounter it. If you set the limit to 1000 entries

Re: [Acme] On the entropy of the nonce

On 12 May 2016 at 04:48, Michele Orrù wrote: > I also gave a look at letsencrypt/boulder[2], and as far as I've > been able to understand there is a in64 counter, and 7 bytes of > randomness that determine the nonce. Am I wrong to say that there > are less than 128 bits of

Re: [Acme] Preconditions

On 9 July 2016 at 08:00, Peter Eckersley wrote: > With a bit of warning I might have been able to put that together for this > deadline. Please don't treat meeting deadlines as anything special. Generate discussion and pull requests at any time. The reason we have the deadline is

Re: [Acme] Post-IETF-96 PRs

On 9 August 2016 at 02:53, Richard Barnes wrote: > Again, I'm not totally convinced that semantic mismatches are that big a > deal. The "url" parameter already scopes the signed object to a specific > resource, so the only risk would be if that specific resource accepts > different

Re: [Acme] Nonces for GETs

On 7 August 2016 at 04:55, Jacob Hoffman-Andrews wrote: > The rationale from the notes is that nonces are not a scarce resource. > However, cachability and idempotence of GETs were not addressed. I think > it's worth not requiring nonces on GETs purely for those reasons. In >

Re: [Acme] Post-IETF-96 PRs

On 8 August 2016 at 12:39, Richard Barnes wrote: > So I'm honestly not that convinced that we need versioning at all here. > Maybe we could get away with just versioning the directory? (As I think the > original issue proposed :) ) I believe that it was PHB who requested this

Re: [Acme] Post-IETF-96 PRs

On 7 August 2016 at 03:46, Jacob Hoffman-Andrews wrote: >> #162 - Add a protocol version >> https://github.com/ietf-wg-acme/acme/pull/162 > > Still thinking about this one. Seems sound at first glance, but I'm thinking > about TLS version intolerance and >

Re: [Acme] Add a special token parameter in ACME registration

On 17 August 2016 at 06:48, Richard Barnes wrote: > a. Infer the certificate type from the CSR. For example, if the Subject in > the CSR has (C, O, CN), infer that the applicant wants EV. > b. Have a field in the new-application request that the client can use to > indicate what

Re: [Acme] UX design by standards

On 18 February 2017 at 00:42, Josh Soref wrote: > > I'm reminded ... there was one specification (i can't remember if it > was Cookie, HTTP, or HTML) which had a UAs must tell users about > something (redirects? cookies?). HTTP did, at one time have such text. I would agree

Re: [Acme] UX design by standards

On 19 February 2017 at 05:40, Jacob Hoffman-Andrews wrote: > Do you have proposed alternate langauge, given the above? Simply state the the description is designed for human consumption. It's not localized, but it might help in more precisely identifying the issue. Then, let the

[Acme] Just the technical comments (was: ACME draft is now in WGLC.)

At Rich's request, here are the technical parts. I assume that the editors will be trawling through the entirety of the original mail (for which I apologize). These are just the headline items, I pulled two forward because I think they are more important. The others are small beans. Of course

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

On 11 February 2017 at 05:56, Salz, Rich wrote: > ACME WGLC It's been a while since I did a review of this, so I spent a few hours on it. This document is in pretty good shape. I have a lot of comments (a LOT), and some of these are serious enough that I'd want to see another

Re: [Acme] Specify account by kid (reg URL) rather than key. #193

I am inclined to think that this is a good change, on the basis that it means that the server is minting the identifiers that the client uses. I think that Jacob is probably understating the potential for bugs here. And key canonicalization is a bad smell. On 27 September 2016 at 14:51, Jacob

Re: [Acme] IETF 97 follow-up PRs

On 29 November 2016 at 13:37, Richard Barnes wrote: > I actually thought you were the one that suggested we keep the "status" > fields :) The minutes not being dispositive, I pulled up the audio > recording of the meeting ([1], around 35:00), and didn't find anything there >

Re: [Acme] Minor fix for JWS signature algorithms

On 30 November 2016 at 15:52, Richard Barnes wrote: > So, dear HTTP editor, which code should we use? No need to be facetious :) I was agreeing with Ted, if that wasn't clear. 400 is your grab bag for "requests you don't like". 403 is generally used for cases where authentication

Re: [Acme] Generating nonces probabilistically in 6.4.1. Replay-Nonce

I agree with Jacob here. MUST seems appropriate, but requiring uniqueness absolutely imposes a constraint on server design that is so onerous that I would see it as impractical. (Also, the document doesn't really identify a scope for this uniqueness, which would probably be necessary if you had

Re: [Acme] Just the technical comments (was: ACME draft is now in WGLC.)

Yes, many of these things were already addressed by Jacob and others. On 7 March 2017 at 05:32, Richard Barnes wrote: >> S6.3.2 >> >>[...] and MUST reflect [the?] value of the >>"external-account-binding" field in the resulting account object >> >> Is this a direct copy of

[Acme] Comments on draft-barnes-acme-service-provider

This document is a key piece of the STIR/SHAKEN infrastructure, as such, I think that this is worth working on and a good basis for that. I have a few questions, some of which might touch on the stir-certificates draft (which I see is in the RFC editor's queue, hmm). STIR certificates define

Re: [Acme] Comments on draft-barnes-acme-service-provider

I just realized that I misunderstood and there is a bearer token being used to resolve the challenge and the service provider is responsible for talking to the STI-PA to get this. I think that this needs to have a bit more detail for it to be understood. On 10 July 2017 at 11:36, Martin Thomson

Re: [Acme] Comments on draft-barnes-acme-service-provider

On 11 July 2017 at 07:29, Mary Barnes wrote: > Hi Martin, > > Thanks for taking the time to review. We're actually working on a revision > right now addressing your comments and agree totally with your point that > more detail is definitely needed in this draft.

Re: [Acme] I-D Action: draft-ietf-acme-ip-00.txt

The biggest concern I have is the text regarding certificate lifetime and the handling of the possibility that IP addresses are dynamically allocated. This seems a little weak and it leaves a lot to the CA to manage. Is there anything that can be done to gain a stronger assertion that the

Re: [Acme] I-D Action: draft-ietf-acme-ip-00.txt

On 19 July 2017 at 03:45, Jacob Hoffman-Andrews <j...@eff.org> wrote: > On 07/17/2017 10:48 PM, Martin Thomson wrote: >> The biggest concern I have is the text regarding certificate lifetime >> and the handling of the possibility that IP addresses are dynamically >> allo

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

On 6 July 2017 at 20:07, Hugo Landau wrote: > Vendor-assigned identifiers could be supported as such: > vnd:example.com/custom-method RFC 6648 explains why vendor-prefixes can be a bad idea. I think that you should do as Yaron suggested and establish a registry. Set the

Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt

On 24 June 2017 at 02:24, Yaron Sheffer wrote: >>> Expires is to ensure that the certificate is not >>> cached beyond the point where a newer certificate will be issued. You >>> should remove this text. >> >> OK > > Is there some other common header to denote that the

Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt

, "Martin Thomson" <martin.thom...@gmail.com> wrote: > A few brief comments on this draft. > > On 16 June 2017 at 22:19, <internet-dra...@ietf.org> wrote: > >This memo proposes an ACME extension to enable the issuance of short- > >term and autom

Re: [Acme] Before entering WGLC ...

Like Russ, I find the statement very difficult to read. Would inverting it be better? > A CA MUST NOT issue authorize issuance if a CAA record is present unless the > "account-uri" parameter identifies the account making a certificate issuance > request. On 19 June 2017 at 00:16, Salz, Rich

Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt

A few brief comments on this draft. On 16 June 2017 at 22:19, wrote: >This memo proposes an ACME extension to enable the issuance of short- >term and automatically renewed certificates. This allows a domain >name owner to delegate the use of certificates

Re: [Acme] v2

I don't see the distinction between what LE deploy and ACME as defined by the IETF being any different to the distinction between whatever any other CA currently deploy and the IETF spec. It's a thing that exists, but I see no reason to accord the LE proprietary protocol any special status other

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

On Fri, Sep 22, 2017 at 4:40 AM, Richard Barnes wrote: > Daniel noted that there might be some issues with GET idempotency here, but > I don't think this actually makes GET non-idempotent. It's still idempotent, because doing the GET twice has the same effect as doing it once. You

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

On Fri, Sep 1, 2017 at 10:47 AM, Adam Roach wrote: > On 8/31/17 19:25, Stephen Farrell wrote: >> >> I really like the idea that the acme WG aims to figure out a way to enable >> people at home to use https with their home n/w routers. ... > There was some musing at the W3C TPAC

Re: [Acme] Returning multiple errors

Is this better cast as "sub" problems, or just "additional" problems? On Tue, Nov 21, 2017 at 10:19 AM, Jacob Hoffman-Andrews wrote: > I've submitted a PR adding this to the spec: > > https://github.com/ietf-wg-acme/acme/pull/354 > > commit a6cc0aedf96067e8b3aaf37662785fcf8b38dd18

Re: [Acme] Returning multiple errors

On Wed, Nov 22, 2017 at 5:55 AM, Jacob Hoffman-Andrews <j...@eff.org> wrote: > On 11/20/2017 08:24 PM, Martin Thomson wrote: >> Is this better cast as "sub" problems, or just "additional" problems? > > I think "additional" is the wrong semantic, b

Re: [Acme] Returning multiple errors

Have you considered json text sequences: https://tools.ietf.org/html/rfc7464 ? I don't know what a random JSON parser would do with your stacked error codes. On Thu, Nov 16, 2017 at 3:54 PM, Jacob Hoffman-Andrews wrote: > On 11/15/2017 07:07 PM, Richard Barnes wrote: >> Following

Re: [Acme] Returning multiple errors

Oh, my bad, my eyes turn out to be a terrible JSON parser. On Thu, Nov 16, 2017 at 4:49 PM, Matthew A. Miller <linuxwolf+i...@outer-planes.net> wrote: > On 17/11/16 16:47, Jacob Hoffman-Andrews wrote: >> On 11/16/2017 12:45 AM, Martin Thomson wrote: >>> I don't know w

Re: [Acme] Fixing the TLS-SNI challenge type

If you are using a new protocol, all of the concerns Peter have come into play. If you are there, why wouldn't you do the challenge validation within the new protocol rather than using the certificate (which is sent in the clear in current TLS versions). That might be easier to implement than

Re: [Acme] Fixing the TLS-SNI challenge type

Rudenberg <jonat...@titanous.com> wrote: > >> On Jan 11, 2018, at 22:26, Martin Thomson <martin.thom...@gmail.com> wrote: >> >> If you are using a new protocol, all of the concerns Peter have come >> into play. If you are there, why wouldn't you do the challeng

Re: [Acme] ALPN based TLS challenge

Now is probably the time to publish in internet-draft form: https://datatracker.ietf.org/submit/ On Fri, Feb 23, 2018 at 12:48 PM, Roland Bracewell Shoemaker wrote: > Hey all, > > After the issues with the SNI based TLS challenges were discovered there was > interest

Re: [Acme] WGLC comments: draft-ietf-acme-tls-alpn-01 (Re: Confirming consensus)

On Thu, Aug 9, 2018 at 12:32 PM Sean Turner wrote: > 5) General: Okay so I’m no cryptographer, but should the hash algorithm used > in the challenge correspond to the hash algorithm used in the PRF/HKDF? I > mean if I’m going to use TLS 1.3 and TLS_AES_256_GCM_SHA384 should I really > use

Re: [Acme] nomenclature: “POST-as-GET”

On Wed, Sep 5, 2018 at 4:33 AM Richard Barnes wrote: >> Alternatively, would it make sense to define a new HTTP verb, e.g., “FETCH”, >> for this? > > I'm inclined not to do this. We definitely shouldn't actually mint a new > HTTP method, since we're not changing the method. One does not

Re: [Acme] Certificate chains including roots

The usage model I think we should aim for is where chains are used as-is. For instance, the chain is fed straight to the HTTPS server. There is reasonably strong advice against sending trust anchor certificates over the wire, and most software simply spools out everything it is given. I thought

Re: [Acme] Certificate chains including roots

On Wed, Mar 14, 2018 at 9:23 PM, Jacob Hoffman-Andrews wrote: > On 03/12/2018 05:25 AM, Hugo Landau wrote: >> 3. Clarify the specification to state that the root certificate must >> not appear in the chain, and that roots must be retrieved using the >> AIA URL inside the

Re: [Acme] Specify which JWS serialization is used

415 is for the case where a client provides bad request content, so yes. See rfc7694 for details. 406 is for failed conneg. Not something you expect to see much here. On 5 Mar. 2018 09:25, "Richard Barnes" wrote: The lengths of the emails in this thread illustrate the complexity

Re: [Acme] Specify which JWS serialization is used

There needs to be a stronger benefit demonstrated than this. As Richard says, implementing flat serialization is near trivial. Rather than add more complexity, settling on precisely one format solves the problem neatly. On 5 Mar. 2018 02:43, "Logan Widick" wrote: How

Re: [Acme] Specify which JWS serialization is used

> How about Accept? It looks like 7694 gives the server a way to specify > encodings, but not the content type. But 7231 says that Accept only replies > to response media types. > > On Sun, Mar 4, 2018 at 5:33 PM, Martin Thomson <martin.thom...@gmail.com> > wrote: >> &

Re: [Acme] Specify which JWS serialization is used

ept if we require the use of the > Flattened JSON serialization. > > https://i.imgflip.com/25r2ui.jpg > > https://github.com/ietf-wg-acme/acme/pull/410 > > On Sun, Mar 4, 2018 at 6:28 PM, Martin Thomson <martin.thom...@gmail.com> > wrote: >> >> That's a bit s

Re: [Acme] Concerning alternative formats …

Sure. Plenty of ways to do that. If your primary concern is issuance, then you don't even need server push, you can just long-poll. In HTTP/1.1, that's gross because it ties up a connection and has some disgusting keep-alive properties. In h2 there is no opportunity cost to worry about, the

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

On Tue, Dec 25, 2018, at 07:32, Eric Rescorla wrote: > IMPORTANT > S 3. > > used to refer to fully qualified domain names. If a ACME server > > wishes to request proof that a user controls a IPv4 or IPv6 address > > it MUST create an authorization with the identifier type "ip".

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

Just read it. Reasonable thing to specify. Not sure why this doesn't talk about delegations of the domain and the effect that might have. That seems relevant. Though control over the parent implies control over delegations, it might be a consideration when setting policy. Not sure why

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

On Fri, Oct 15, 2021, at 18:00, Owen Friel (ofriel) wrote: > Not sure why "domainNamespace" is used as the field when "subdomains" > is shorter and easier to understand. > > > [ofriel] there was early discussion on the mailer about what exactly a > 'subdomain' meant. So we quoted the CA/B

Re: [Acme] Validation methods for alternative services and SVCB/HTTPS targets

On Fri, Oct 28, 2022, at 06:04, Ilari Liusvaara wrote: > It looks like the proposed dns-account-01 method would be very useful > here. The key problem of dns-01 here is that it only allows one > persistent authorization, whereas dns-account-01 allows multiple. So relying on another authorization

[Acme] Artart last call review of draft-ietf-acme-tls-alpn-06

Reviewer: Martin Thomson Review result: Ready with Nits This is a clear description of a simple protocol that addresses a well-defined problem. I didn't find any real issues, though I have some suggestions that might improve the document a little. My view is that publication without these would