Here's another PR with further feedback: https://github.com/ietf-wg-acme/acme/pull/453
Replies in-line below. > Perhaps dropping the "to clients" would remove the reading that > there is nonce/client tracking without losing any significant information, > but this seems to fall under editorial discretion, so it's all yours. I think that's a reasonable change if it will reduce confusion. Done. > How about "It is also used, with some media types, from certificate > resources [...]"? Works for me. Done. > And my intent was to suggest that there is a new paragraph for "alternate", > maybe: >> The "alternate" link relation is used when a CA can provide multiple >> distinct certification chains (e.g., chaining to different root CA >> certificates) for a provided certificate. I don't think this is needed. Section 7.4.2 "Downloading the Certificate" says almost the same thing when describing the "alternate" relation. I think this is the location in-document where the information is most relevant. > Ah. This table is slightly cramped, so it may not be worth a change, but > even "order's certificate" (and the matching "order's authorizations") > might help. Ok, changed to the possessive forms. > Mostly I just want the document to be clear and consistent about whether > exactly one successful challenge suffices to authorize, and exactly one > unsuccessful challenge suffices to fail authorization Ok. I think this has been made clear in #447. One authorization is sufficient to authorize. One failed challenge fails the authorization/order. > I was expecting something like '''a stub account object optionally containing the > "contact", "termsOfServiceAgreed", "onlyReturnExisting", and > "externalAccountBinding" fields.''' I understand now, thanks! Updated to say "and optionally the "onlyReturnExisting" and "externalAccountBinding" fields". I think that will cover this. > If "termsOfService" is present in the directory, is the client required to > agree to the terms before service is provided? The text, to me, seems to > allow a server to use this field to provide some optional additional > documentation without requiring clients to agree to it. I don't think the text suggests that. Section 7.3 "Account Creation" says: > If the server wishes to present the client with terms under which the > ACME service is to be used, it MUST indicate the URL where such terms > can be accessed in the "termsOfService" subfield of the "meta" field > in the directory object, and the server MUST reject new-account > requests that do not have the "termsOfServiceAgreed" field set to > "true". So if termsOfService is present you MUST send termsOfServiceAgreed to be able to create an account. I don't think there is a reading of that text that would allow the server to provide additional documentation without requiring client agreement. > I think it would help to say '''MUST ignore any updates to [...], the > "status" field (except as allowed by Section 7.3.7), or any other [...]''' Good suggestion. Done. > It seems that they would then be removed from the listing on page 46 (of > the -14)? I think the best fix here is to remove "valid" from "After a valid request to finalize has been issued". I've made this change. > This would be ยง 4.4.2 of RFC 8446 Thanks. Added a ref to RFC 8446. > Well now I'm really confused. If I look at the example exchanges for the HTTP challenge. Apologies. I forgot that the HTTP-01 challenge type does send the token in the request by way of the request path. I removed the language that says it "expresses a domain holder's authorization". > In particular, right now I think that the text about "participating in the > creation" is inaccurate. Rephrased to say that the entropy requirement only prevents guessing the token and removed text about "participating in the creation". Thanks. On Sun, Sep 16, 2018 at 6:29 PM Benjamin Kaduk <ka...@mit.edu> wrote: > On Sun, Sep 16, 2018 at 10:42:26PM +0200, Felix Fontein wrote: > > 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/<foo> with <foo>.<key > > > > > > > > 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 <foo> 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 <foo>? > > > > > > > > > > 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/<hash-of-token> > > > instead of > > > GET /.well-known/acme-challenge/<token> > > > > > > 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. > > Whether or not it should be disallowed is probably a function of the > severity of the XSS risk (which I don't have a good picture of right now) > -- as I attempted to note in my ballot text, the token is only created by > virtue of the account key holder's explicit request, which could itself be > seen as an authorizing action. The echoing of the token by the HTTP server > serves to confirm possession of the domain name, more than the specific > authorization, in that worldview. > > > 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. > > Agreed that the text could be more clear. In particular, right now I think > that the text about "participating in the creation" is inaccurate. > > -Benjamin > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
