Forwarding to the list, per Richard. On Sun, May 27, 2018 at 3:00 PM, Richard Barnes <r...@ipv.sx> wrote:
> Updated PR: > > Responses to comments Github: https://github.com/ietf-wg- > acme/acme/pull/425/commits/710ef835446231ef954b0f6e448718eef04b63fa > Responses to this email: https://github.com/ietf-wg- > acme/acme/pull/425/commits/3dd2a10ee55c13ff87772463374a7c0ab4205d5f > > Trimming points on which we agree... > > On Fri, May 25, 2018 at 12:09 PM Eric Rescorla <e...@rtfm.com> wrote: > >> > > IMPORTANT >> > > S 6.2. >> > > > algorithm in its "alg" field >> > > > >> > > > o The JWS Payload MUST NOT be detached >> > > > o The JWS Protected Header MUST include the following fields: >> > > > >> > > > * "alg" (Algorithm) >> > > >> > > Do you want to specify a set of acceptable signature algorithms here? >> > >> > I am inclined not to. We have already forbidden "none" and MAC. We >> > shouldn't specify "MUST"s here, because CABF sets their own list of >> > required algorithms, and we don't want to conflict. I guess you >> > could specify some MUST NOTs pretty safely, but given that they're >> > already forbidden by CABF, it seems kind of duplicative. >> >> This is about the signatures that ACME accepts, not the signatures >> in certs. Does CABF have a position on what signature algorithms >> that ACME uses? >> > > Good point. As Ryan pointed out, this is not something on which there is > currently CABF guidance. > > Nonetheless, I'm still disinclined to have MUSTs here for other reasons. > If they're positive "MUST support" requirements, then we would need to come > back and revise this document in the event of an algorithm break (though > admittedly, that would be pretty far down on the TODO list). And looking > at the current list of JWS algorithms, I don't see any I would MUST NOT, > except possibly the ones based on SHA-1. > > > >> >> >> > > S 6.3. >> > > > As noted in Section 6.2 above, all ACME request objects carry >> a "url" >> > > > header parameter in their protected header. This header >> parameter >> > > > encodes the URL to which the client is directing the request. >> On >> > > > receiving such an object in an HTTP request, the server MUST >> compare >> > > > the "url" header parameter to the request URL. If the two do >> not >> > > > match, then the server MUST reject the request as unauthorized. >> > > >> > > I think you probably need to provide a clear definition of how you >> > > "compare" them. Is it memcmp? Something else? >> > >> > This is specified further down: >> > >> > """ >> > The server SHOULD perform the corresponding string equality check, >> > configuring each resource with the URL string provided to clients >> > and having the resource check that requests have the same string in >> > their “url” header parameter. >> > """ >> >> Perhaps just a forward reference. >> > > "Further down" here just means "the next paragraph". Over that distance, > I don't think a forward reference is really helpful :) > > > >> >> > > S 7.1.2. >> > > > initiated deactivation. >> > > > >> > > > contact (optional, array of string): An array of URLs that the >> > > > server can use to contact the client for issues related to >> this >> > > > account. For example, the server may wish to notify the >> client >> > > > about server-initiated revocation or certificate expiration. >> > > >> > > How am I supposed to know the semantics of these strings? And if they >> > > are non-mailto URLs, what am I supposed to do with them. >> > >> > To first order, the semantic is defined by the scheme of the URL -- >> > "mailto" says "email me", "sip" or "tel" says "give me a call", etc. >> > We have the "unsupportedContact" error type if the server doesn't >> > know how to leverage a given scheme. >> >> >> > Of course there are URL schemes that don't make sense as a contact >> > point (e.g., "data:"), but trying to enumerate those seems quixotic. >> > Better for the CA to check and reject with the error code we have >> > provided. >> >> Well, http would also be hard to know what to do. >> >> My semantic question, however was: are these all equivalent and >> undifferentiated? >> > > I'm not sure I totally understand the question here, but I think the > answer is "yes". Either the server has code to handle a given contact URL > scheme or it doesn't, in which case unsupportedContact. > > > >> > > S 7.4. >> > > > >> > > > The order object returned by the server represents a promise >> that if >> > > > the client fulfills the server's requirements before the >> "expires" >> > > > time, then the server will be willing to finalize the order >> upon >> > > > request and issue the requested certificate. In the order >> object, >> > > > any authorization referenced in the "authorizations" array >> whose >> > > >> > > What if the CSR contains extensions which are not mentioned here? For >> > > instance, say I request a given EKU that the CA doesn't like? Or the >> > > DelegatedUsage extension from https://tools.ietf.org/html/draft-ietf- >> > > tls-subcerts-00#section-4.1 >> > >> > [[ DISCUSS - 1e9937c ]] >> > >> > This is an unforutunate consequence of not providing the CSR up >> > front. It seems like the right outcome here is for the finalization >> > request to fail. It's unclear to me whether the order should also >> > be invalidated. >> >> > I think my proposal would be to fail the finalization, but leave the >> > order open, and the client can re-try with a CSR that the server >> > might like better. >> >> It seems like the implication of this is that it's not possible to >> demand additional validation procedures at this time, however. I >> guess that's something one could live with.... >> > > I think that's coherent. Validations only apply to identifiers, not > things like EKUs. The identifiers for the certificate should all be listed > in the newOrder, and thus accounted for in the initial list of > authorizations. > > > >> >> > > S 2. >> > > > o In the background, the ACME client contacts the CA and >> requests >> > > > that it issue a certificate for the intended domain name(s). >> > > > >> > > > o The CA verifies that the client controls the requested >> domain >> > > > name(s) by having the ACME client perform some action >> related to >> > > > the domain name(s). >> > > >> > > I know this text is informal but perhaps something sharper is required >> > > here. Receiving email at "j...@example.org" is related to the domain >> > > name. >> > >> > [[ EDIT - f4d421d ]] >> >> I would have personally said "demonstrating that control" rather than >> related, but I agree this is up to the editor. >> > > Oh I see. I agree that that's better; edited. > > > >> >> > > S 3. >> > > > >> > > > 3. Terminology >> > > > >> > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL >> NOT", >> > > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" >> in this >> > > > document are to be interpreted as described in RFC 2119 >> [RFC2119]. >> > > >> > > Regrettably, it is time to cite 8174. >> > >> > Disagree. RFC 8174 is an update, not a replacement. >> >> I can see how you would feel that way, but I can tell you that the >> IESG is now enforcing this, so you might as well do it now. >> > > I have updated this to the recommended text that you sent me 1-1. > > > >> >> > > S 7.3.6. >> > > > "jwk": /* new key */, >> > > > "url": "https://example.com/acme/key-change"; >> > > > }), >> > > > "payload": base64url({ >> > > > "account": "https://example.com/acme/acct/1";, >> > > > "newKey": /* new key */ >> > > >> > > You should explain why the newKey and jwk fields both exist, given >> > > that they have to be identical >> > >> > [[ DISCUSS - 8f50f84 ]] >> > >> > I think this is a legacy of when we switched the order of old/new. >> > It used to be new/old/new, then someone observed that it would be >> > nice to always have the outer signature be with the current account >> > key, so we swapped the outer two and ended up with old/new/new. >> > I'verevised to be old/new/old, with corresponding prose. >> >> This seems like a pretty material change. >> >> Given the complicated logic, perhaps it would be good to state what >> statements we believe each key is attesting to. >> > > Added: > > """ > To change the key associated with an account, the client sends a > request to the server containing signatures by both the old and new > keys. The signature by the new key covers the account URL and the > old key, signifying a request by the new key holder to take over the > account from the old key holder. The signature by the old key > covers this request and its signature, and indicates the old key > holder's assent to the roll-over request. > """ > > > >> > > S 7.4. >> > > > certificates. ACME does not provide a way to reactivate a >> > > > deactivated account. >> > > > >> > > > 7.4. Applying for Certificate Issuance >> > > > >> > > > The client requests certificate issuance by sending a POST >> request to >> > > >> > > This probably could be revised to indicate that it's not actually >> > > requesting issuance immediately, but the server's promise of issuance. >> > >> > I don't think this level of distinction is needed. >> >> I'm not going to fight about it, but I do think these are different. >> > > I'll allow that it's a bit odd that the HTTP response doesn't respond to > the "request" for certificate issuance. > > Revised to: "The client begins the certificate issuance process..." > > > >> > > S 7.4. >> > > > The CSR encodes the client's requests with regard to the >> content of >> > > > the certificate to be issued. The CSR MUST indicate the exact >> same >> > > > set of requested identifiers as the initial new-order request, >> either >> > > > in the commonName portion of the requested subject name, or in >> an >> > > > extensionRequest attribute [RFC2985] requesting a >> subjectAltName >> > > > extension. >> > > >> > > Must it be in the same order? >> > >> > [[ DISCUSS - no change ]] >> > >> > I don't think so, though I'm sympathetic that ordered list comparison >> is easier to get right than set comparison. >> >> I'm not pushing for either direction, just clarity. >> > > Added: "(These identifiers may appear in any order.)" > > >> >> > > S 10.4. >> > > > >> > > > Some server implementations include information from the >> validation >> > > > server's response (in order to facilitate debugging). Such >> > > > implementations enable an attacker to extract this information >> from >> > > > any web server that is accessible to the ACME server, even if >> it is >> > > > not accessible to the ACME client. >> > > >> > > For network topology reasons, primairlY? >> > >> > Network topology, firewalls, etc. Imagine, for example, an enterprise >> ACME CA that could see internal servers and for some reason had a >> publicly-addressable ACME interface. >> >> Might be worth clarifying. >> > > """ > For example, the ACME server might be able to access servers behind > a firewall that would prevent access by the ACME client. > """ > > >> > > S 11.1. >> > > > certificate. ACME clients and servers SHOULD verify that a CSR >> > > > submitted in a finalize request does not contain a public key >> for any >> > > > known account key pair. In particular, when a server receives >> a >> > > > finalize request, it MUST verify that the public key in a CSR >> is not >> > > > the same as the public key of the account key pair used to >> > > > authenticate that request. >> > > >> > > Do you want to mention TLS signing oracles? >> > >> > [[ QUESTION ]] >> > >> > Could you elaborate on this? >> >> As I understand it, part of the reason for this is that TLS 1.2 provides >> a signing oracle, right? >> > > Oh, I see. Proposed: > > """ > This assures that vulnerabilities in the protocols with which the > certificate is used (e.g., signing oracles in TLS [JSS15]) do not result > in > compromise of the ACME account. > """ > > --Richard >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
