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 >
Hmm... Common practice in security protocols is to specify MTI algorithms. Why is this different? > > > 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 :) > OK. > >> >> > > 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. > > This doesn't seem entirely clear: 1. What do I send to the HTTP URI, if anything? What method do I use? 2. If there is >1 URI, are they all semantically equivalent. >> > > 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. > Well, I could certainly imagine that you would need some extra level of something (whether you call it validation or not) to get a certificate with certain EKUs. > > > 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. > "" > OK > > > 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. > """ > OK > >> > > 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. > OK -Ekr """ > > --Richard >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
