W dniu 26.01.2015 o 11:33, Richard Barnes pisze:
> Hey Mateusz,
>
> Thanks a lot for suggesting this. This sounds like a great idea to me.
> Please
> feel free to file an issue on the Github spec -- or send a pull request!
>
> The only exception that occurs to me is the recoveryToken / recoveryContact
> challenge types. The recoveryToken challenge is done in-band to ACME, so it's
> already signed with the account key pair. For recoveryChallenge, I guess you
> could bind in the key pair, but given that it's intended to be more
> human-facing, that seems counterproductive.
>
> --Richard
>
I have been thinking about this a bit and have some more crazy ideas:
- why don't we simply demand that a new key is signed with the old one? It's
AFAIK quite standard with key management.
It could be more robust then the current proofOfPossession validation method
(and is very secure even without HTTPS).
- at first use of ACME, the server could validate another key, that would be
only used in the proofOfPossesion method. It wouldn't be deployed on the HTTPS
server and therefore it would be more difficult for an attacker to get it (e.g.
through some recent bug in OpenSSL). In case of that key, longer key lengths
could be used, e.g. 4096 bits could be required.
It may make more sense when the keys are exchanged e.g. once a month or even
every several days (I've seen such proposals as a replacement to key rev lists,
which are currently not very reliable). An attacker that gets access to the
private key will have only a small amount of time to use it.
- the client could send his IP address to the server (possibly as some
validation challenge response) to verify that the client's and server's ideas of
it are the same (and some DNS hijacking isn't going on).
- would it make sense to support the client specifying more stringent
requirements for future key renewals - such as blocking some challenge
combinations that it considers insecure?
- it may be helpful in the future when new, more secure validation
challenges
will be specified and some older clients will not support and the ACME server
will not require them therefore (or some challenges may be specified that will
be more secure but problematic in use),
- it can be probably easily added in the future, when need arises so I
do not
think that it should be added now in order not to overcomplicate the protocol,
- would it make sense to add to the challengeRequest message some information
about the certificate type that is requested, for example an "extended
validation" certificate?
Greetings,
Mateusz
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
