[Acme] stray Accept: application/pkix headers
Hi, I've noticed that there are two stray "Accept: application/pkix" headers in examples where they don't make sense (as the answer is application/json): - Section 7.5 (Identifier Authorization), top of page 50 - Section 7.5.1 (Responding to Challenges), top of page 53 I think they have been accidentally copied there; they were inserted in the first commit of https://github.com/ietf-wg-acme/acme/pull/445 Best regards, Felix ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] malformedRequest vs. malformed in draft-ietf-acme-acme-15
Hi, while looking at POST-as-GET support for account URLs, I noticed that draft-ietf-acme-acme-15 mentions an error called "malformedRequest" in two places (w.r.t. POST-as-GET), while the error is simply called "malformed" in the list in Section 6.7. I think this is an oversight and they should be the same, i.e. either "malformed" (as until now) or "malformedRequest" (which would be a breaking change). Best regards, Felix ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)
Hi, > > > > > >[...] Secondly, the entropy requirement > > > > > >prevents ACME clients from implementing a "naive" > > > > > > validation server that automatically replies to challenges > > > > > > without participating in the creation of the initial > > > > > > authorization request. > > > > > > > > > > > > IMPORTANT: I'm not sure I see how this applies to the HTTP > > > > > > mechanism -- couldn't you write a script to reply > > > > > > to .well-known/acme-challenge/ with . > > > > > thumbprint> for a fixed key thumbprint? The validation > > > > > > thumbprint> server would ned to > > > > > > know about the ACME account in question, but not about any > > > > > > individual authorization request. > > > > > > > > > > It would also need to know the value, which is not > > > > > provided in the validation request specifically to avoid > > > > > this. > > > > > > > > As I said above, "[w]ell now I'm really confused." In the > > > > example HTTP challenge exchange (duplicated here): > > > > > > > > GET > > > > /.well-known/acme-challenge/LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0 > > > > Host: example.org > > > > > > > > HTTP/1.1 200 OK > > > > Content-Type: application/octet-stream > > > > > > > > LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0.9jg46WB3rR_AHD-EBXdN7cBkH1WOu0tA3M9fm21mqTI > > > > > > > > Doesn't the path in the GET include the ? > > > > > > Yes, and some people are already using this to add a generic > > > authorization replier (which needs the thumbprint of the account > > > key). For example, the acme.sh client supports this "stateless > > > mode" (as it is called there): > > > https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode > > > > Okay, that matches up with my understanding and maybe un-confuses > > me. > > > > But does this state of affairs nullify the text in the -14 about: > > > >[...] the entropy requirement > >prevents ACME clients from implementing a "naive" validation > > server that automatically replies to challenges without > > participating in the creation of the initial authorization request. > > > > ? > > Also, if we wanted to prevent this sort of dumb script, it seems like > we could have the ACME server do a > GET /.well-known/acme-challenge/ > instead of > GET /.well-known/acme-challenge/ > > and expect the un-hashed token in the response body. (Witih obvious > questions about explicit hash agility vs. hardcoding a hash per > challenge type.) That would work. However, I'm not sure whether this should really be disallowed. I also understand the text from draft-14 as you do, but I since this incorporates the account key hash, it doesn't validate for challenges coming from other ACME accounts. Also, there has been a proposal (https://github.com/ietf-wg-acme/acme/issues/393) to allow something similar for DNS validation (as dns-02), which explicitly mentions this automation. Since nobody responded that such an automation is unwanted, my assumption is that this automation is a feature and not a bug. It would be nice if this would be more clear from the text, though. Cheers, Felix ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)
Hi, > > >[...] Secondly, the entropy requirement > > >prevents ACME clients from implementing a "naive" validation > > > server that automatically replies to challenges without > > > participating in the creation of the initial authorization > > > request. > > > > > > IMPORTANT: I'm not sure I see how this applies to the HTTP > > > mechanism -- couldn't you write a script to reply > > > to .well-known/acme-challenge/ with . > > > for a fixed key thumbprint? The validation server would ned to > > > know about the ACME account in question, but not about any > > > individual authorization request. > > > > It would also need to know the value, which is not provided > > in the validation request specifically to avoid this. > > As I said above, "[w]ell now I'm really confused." In the example > HTTP challenge exchange (duplicated here): > > GET /.well-known/acme-challenge/LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0 > Host: example.org > > HTTP/1.1 200 OK > Content-Type: application/octet-stream > > LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0.9jg46WB3rR_AHD-EBXdN7cBkH1WOu0tA3M9fm21mqTI > > Doesn't the path in the GET include the ? Yes, and some people are already using this to add a generic authorization replier (which needs the thumbprint of the account key). For example, the acme.sh client supports this "stateless mode" (as it is called there): https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode (There currently is also a discussion in the Let's Encrypt community forum about this, see https://community.letsencrypt.org/t/xss-via-acme-implementations/72295; this is because some implementations do not restrict the allowed input and thus allow XSS attacks, as described here: https://labs.detectify.com/2018/09/04/xss-using-quirky-implementations-of-acme-http-01/) Cheers, Felix ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ACME breaking change: Most GETs become POSTs
Hi Richard, > I was able upgrade the lego client in a pretty short patch (5 files > changed, 26 insertions(+), 16 deletions(-)) [0]. It interoperates > with Daniel's branch of pebble. you were faster :) I've adjusted Ansible's acme_certificate module to also work with Daniel's branch in https://github.com/ansible/ansible/pull/44988 Most of the changes are general refactoring to make use of a single URL fetch method which has access to the ACME account data; the main part related to POST-as-GET is only a few lines. Cheers, Felix > > --Richard > > [1] https://github.com/bifurcation/lego/pull/1 > > > > On Fri, Aug 31, 2018 at 2:56 PM Daniel McCarney > wrote: > > > I think its an anti-pattern to standardize protocol features that > > haven't been implemented by anyone so here's a PR[0] for the Pebble > > ACME server that implements Richard's proposal[1] to establish > > viability. The proposal seems OK to me given the > > trade-offs/alternatives on the table. > > > > I would encourage other ACME client/server developers to try their > > hand at implementing the changes from [1] as well. I've tested my > > PR with hand-rolled requests but not as part of an automated > > issuance process with a "real" ACME client. Speak now or forever > > hold your bugs. > > > > [0] - https://github.com/letsencrypt/pebble/pull/162 > > [1] - https://github.com/ietf-wg-acme/acme/pull/445/files > > > > On Fri, Aug 31, 2018 at 1:21 PM, Richard Barnes wrote: > > > >> No, if a server receives a GET request for a resource other than > >> those specified, then it MUST return 405. But please check out > >> the PR and see if it's clear there. > >> > >> On Fri, Aug 31, 2018 at 1:14 PM Salz, Rich > >> wrote: > >>> > >>>- * Servers MUST return a 405 if they get a GET for a resource > >>> other than directory/newNonce/certificate. > >>> > >>> > >>> > >>> They means client? Or there’s a word missing, and “they get a” is > >>> “they do not support” ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)
Hello,
> On 8/30/18 7:55 AM, Richard Barnes wrote:
> > Focusing on DISCUSS comment for now, will pick up COMMENTs later.
> >
> > On your DISCUSS, I think you're off on a couple of small things
>
>
> Yeah, I woke up with the sudden realization that I'd had the wrong
> model in my head when I talked through the cert endpoint. All that's
> there is a signed public cert rather than a public/private pair, so
> it's not sensitive.
what happens if the cert URL is not
https://example.com/acme/cert/somerandomlookingidentifier, but
https://example.com/acme/acct/2/order/1/cert? Then someone can still do
identification correlation when the certificate can be downloaded
without authentication.
Cheers,
Felix
> > , but right on the underlying point that the document doesn't
> > really provide any guidance as to which resources a server should
> > consider sensitive. I agree that it would be good to say more, and
> > I've started up a PR for this.
> >
> > https://github.com/ietf-wg-acme/acme/pull/443
>
>
> Thanks -- that fixes the text I cite.
>
>
> >
> > I don't agree that sensitivity entails a need for non-guessable
> > URLs. If accessing the URL requires authentication, then it doesn't
> > matter if someone can guess it; unauthorized people can't access it
> > even if they can guess it. I guess you could argue that if you
> > made a random URL and only distributed it in authenticated
> > channels, then you could allow GETs to it, using the URL itself as
> > an authenticator. But that seems super brittle; I would rather
> > just have all the authentication be based on signing. So at best,
> > random URLs are a backstop against a CA making the wrong decision
> > about GETs.
>
>
> Yup, that seems better.
>
>
> >
> > You're also correct to note that some resources might be sensitive
> > that we now instruct clients to poll with GETs. For example, the
> > client is supposed to poll an authorization resource to see when it
> > validates, but if the authz has a TN in it and so is considered
> > sensitive, you won't be able to do a GET. I think the right answer
> > here is to have the server return 405 Method Not Allowed if it gets
> > a GET and have the client fall back to an authenticated "POST {}",
> > which should be equivalent to a GET in all cases.
>
>
> That seems like a good clarification. The one remaining issue is the
> table at the bottom of §7.1, which shows GETs for resources that the
> new text says CAs might consider sensitive. I catch the "might" in
> that sentence, but it seems that identification correlation is a
> pretty powerful privacy leak, and would strongly suggest that the
> table be revised to show POSTs for retrieval of order resources.
> Whether you take this suggestion is up to you -- I'll clear my
> DISCUSS either way.
>
> /a
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
[Acme] optional MIME parameter for application/pem-certificate-chain
Hello,
this came up in the discussion of
https://github.com/ietf-wg-acme/acme/issues/435 ("An optional MIME
parameter for application/pem-certificate-chain?"). I'm interested in
a reliable way to retrieve the root certificate, resp. the complete
certificate chain including a root certificate. This is sometimes
needed, for example for setting up an AWS ELB load balancer, or for
configuring OCSP verification in nginx, and also to simply verify the
validity of the returned chain down to the root.
During the discussion in the Github issue, Logan Widick suggested a
boolean MIME parameter (with suggested name "includeroot") for
application/pem-certificate-chain.
Since the issue (originally about another MIME parameter) is now
closed, I want to bring this suggestion up on the mailing list. My
suggestion would be that this parameter is optional (with no explicit
default value, i.e. the default is to do what the ACME server already
did before), and a formulation which suggests the server SHOULD respect
this parameter. I think the name "includeroot" is fine, but it could
also be "include-root" or something different.
Are there any opinions on this?
Thanks and best regards,
Felix Fontein
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
[Acme] More specific error codes for certificate revocation, at least for some cases?
Hi, while implementing certificate revocation in an ACME client, I noticed that the current ACME draft is very vague about errors to return when revocation fails. The draft says "If the revocation fails, the server returns an error." (https://tools.ietf.org/html/draft-ietf-acme-acme-12#section-7.6), which is followed by an example which returns urn:ietf:params:acme:error:unauthorized with detail "No authorization provided for name example.net". When trying this out with Boulder (Let's Encrypt staging), I noticed that Boulder returns urn:ietf:params:acme:error:malformed with detail "Certificate already revoked" if the certificate has already been revoked. On the other hand, the Pebble testing server simply returns a 404 error. I think it would make sense to define more specific error codes the server could return for certificate revocation. In particular, there should be an error code for "certificate has already been revoked" (maybe urn:ietf:params:acme:error:alreadyRevoked?). This would make it easier for clients to detect this specific situations. The rationale behind this is that it allows the client to distinguish between errors which require no user interventions (if the certificate has already been revoked, the action the user wanted to perform did fail, but everything is fine since there is no need to still revoke the certificate), and errors which require user intervention (if the certificate was not revoked, and the user has to do something to make sure it is really revoked, like providing the correct account key / private key). Without a well-defined error, a client author has to guess (or simply assume that every server behaves as Boulder and sends the same error detail). Thank you for your considerations, Felix ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
