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
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
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
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
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
https://github.com/ietf-wg-acme/acme/pull/2
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
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
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.
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:
>
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
>
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]:
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
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
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) <
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
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
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
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
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
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
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
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
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
>
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
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
>
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
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
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
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
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
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
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
>
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
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
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
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
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
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.
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
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
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
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
, "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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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:
>>
&
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
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
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".
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
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
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
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
69 matches
Mail list logo