> That seems like a great way to simplify the protocol. On the other > hand, Jacob's /.well-known/certificate/acme-account-keys.json idea is > also quite nice.
This is only tangentially on-topic, but since the idea's been reinforced, just a note that some deployment setups will find it challenging to deploy and maintain special content at HTTP URIs that aren't part of the app's business logic. I'm thinking of platform-as-a-service hosts like Heroku or Cloud Foundry, which map hostnames entirely to "apps" (often with a code repository as the sole content source for URIs). Right now, /.well-known is only used for the Simple HTTP validation mechanism, where the ability to put special metadata at HTTP URIs within the validated hostname is already a prerequisite. Making that ability a requirement for the overall ACME protocol would add friction for a class of users. -- Eric On Thu, Aug 13, 2015 at 1:21 AM, Richard Barnes <[email protected]> wrote: > On Wed, Aug 12, 2015 at 4:04 PM, Andrew Ayer <[email protected]> wrote: > > On Tue, 11 Aug 2015 22:52:05 -0700 > > Richard Barnes <[email protected]> wrote: > > > >> I'm not 100% sure I agree that there are non-trivial cases where RSA > >> allows one to find a key that will verify a given (message, signature) > >> pair. (I would note, however, that you don't even need to find the > >> modular inverse d of e -- you just need n and e such that s^e == m mod > >> n.) It's even less clear for ECDSA. I'm not sure we even need to get > >> a clear answer to that question, though. There are protocol ways to > >> hack around it, as you suggest. > > > > Thanks to Trevor Perrin, I now know that this attack is called > > "duplicate-signature key selection," and found a paper which presents > > a general way to construct a non-trivial RSA key (pages 4-5): > > > > http://eprint.iacr.org/2011/343 > > > > It also presents an attack with ECDSA, though it depends on the > > attacker picking their own base point, and I believe that the > > commonly-used curves (P-256, P-384, and so on) specify a fixed base > > point. > > Nice find! (Thanks, Trevor!) > > I would note, though that in practice, e=65537 pretty much always, and > the attack would almost never produce that value. So this could still > be prevented by checks on account public keys. > > Still doesn't change the conclusion, though :) > > --Richard > > > > > >> I think you're on the right track that we really should just not use > >> signatures here. I had added those in response to concerns about a > >> CDNs in front of the ACME server, but in retrospect, they're solving > >> the wrong problem. The risk posed by a CDN is that it swaps the keys > >> out, much like this situation. So it's enough for the statement by > >> the domain owner (i.e., the validation object) to include an > >> indication of which account key he intends to authorize. > >> > >> This actually adds some symmetry to the challenges. I had thought > >> that proofOfPossession seemed like the odd one out, since the account > >> key was being signed instead of doing the signing. Your observation > >> that the domain holder needs to assert the key basically says that the > >> other challenges should follow the proofOfPossession model and have > >> the domian owner make a statement about the account key. It's just > >> that in the other cases, the authenticity of the statement won't be > >> shown with a signature, but with its being provisioned in a particular > >> place. > > > > Exactly. > > > >> We will probably want to bind some more stuff into the validation > >> object besides the public key, though, in order to bound replay > >> opportunities. At the very least, there needs to be a token that the > >> CA can use to associate the validation object with things like which > >> identifier is being authorized, and what type of challenge it goes > >> with (to prevent replay for different domains, or in different > >> channels). > > > > I may be overlooking something, but I'm skeptical of the value of > > including extra information. If an attacker can replay a validation > > object for another domain or in the context of a different challenge, > > that means the attacker effectively controls that domain/validation > > channel, and can just contact the ACME server, start a new challenge, > > and complete it "normally" without any need for replays. > > > >> In light of the above, ISTM that the right tactical move is probably > >> to define a standard validation object that many challenges can use. > >> Then the proofOfPossession challenge can sign the validation object, > >> and the "put it here" challenges can provision a digest of the > >> validation object. > > > > That seems like a great way to simplify the protocol. On the other > > hand, Jacob's /.well-known/certificate/acme-account-keys.json idea is > > also quite nice. > > > > Regards, > > Andrew > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme > -- konklone.com | @konklone <https://twitter.com/konklone>
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
