about 2) I want to mention in pqc world there are there are movement to
use long term dh-like keys for tls handshake: as those can't sign
anything at all means csr can't selfsigned we'll need something new form
of finalize order.
https://datatracker.ietf.org/doc/draft-celi-wiggers-tls-authkem/
2024-11-26 오후 11:54에 Aaron Gable 이(가) 쓴 글:
Hi all,
I agree that it would be beneficial for the ACME protocol to have a
pubKey identifier type, and to have challenges which can be used to
prove control over the corresponding private key. However, it seems
that I believe this would be useful for entirely different reasons
than the authors here, and I am currently unconvinced by the
motivations presented here.
I believe that a pubKey identifier type is useful for two reasons:
1) it allows the CSR to be removed from the finalize request, as it
will no longer be carrying any information that is not already found
in other parts of the ACME protocol; and
2) proof-of-possession allows the ACME server to respect keyCompromise
revocation requests which are signed by the Subscriber key instead of
only accepting those which are signed by the certificate key.
It seems that this draft is arguing for the inclusion of a pubKey type
and corresponding challenges from a security perspective: that an
adversary might replace the CSR in the finalize request and thereby
get issuance of a certificate containing a malicious key. I must admit
I do not understand this threat model.
If the adversary is simply a network adversary between the legitimate
Client and Server, then they cannot replace the CSR: the finalize
request is signed by the ACME client key and cannot be tampered with
without invalidating that signature. If the adversary is on the ACME
client host, and has access to the ACME client key, then the game is
already lost -- that adversary *is* the Subscriber for all intents and
purposes, and has significant latitude: they can change the ACME
client key to one the victim doesn't control, they can (generally,
based on the architecture of most clients) complete HTTP-01 and DNS-01
challenges, and they can prove possession of any private key they like.
So I think that this document needs to be overhauled in two ways:
- more clearly motivating the threat model: what exactly is the
security issue being solved, and why is it import that it be solved; and
- more clearly motivating the solution space: how do
proof-of-possession challenges mitigate the threat, and why are this
particular set of proposed challenges the best way to do so.
Aaron
_______________________________________________
Acme mailing list -- acme@ietf.org
To unsubscribe send an email to acme-le...@ietf.org
_______________________________________________
Acme mailing list -- acme@ietf.org
To unsubscribe send an email to acme-le...@ietf.org
