No, all validation types where the client or subject sends back or submits the
validation result.If the client or subject makes the validation result
available, and ACME server have to search for the data in such a way the
location of the result itself validate control, then you don't need the
Sebastian,
Thank you very much for this clarification. This would apply to all message
exchange validation types then (including the one I'm looking into).
I notice that the email validation draft does not mention multiple attempts
from different sources, which RFC8555 does discuss briefly [1].
What he talking about, is to make it possible, to get a "revocation blob"
from the ACME client, for a specific client or certificate.
This can then be locked securely inside a safe, or published with a
dead-mans-switch.
IF anything happens to the certificate, you just take out the securely
stored
The reason is to prevent email spoofing.
In the case of .well-known or DNS validation, or ALPN, you publish a record
where ACME fetches. That cant be spoofed, because ACME itself searches for
the record, you cant send ACME a record and have it accept.
In the email case, you instead send ACME
>That's true if you want to revoke a certificate, but how do you deactivate
an account without access to the private key?
I don't think ACME should handle this.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
