21. 11. 15. 02:35에 Benjamin Kaduk 이(가) 쓴 글:
With apologies for focusing on a different aspect than you are attempting
to focus on...
On Sun, Nov 07, 2021 at 12:00:20AM +0900, Seo Suchan wrote:
After RFC8823 I though it would be trivial to apply its process for TLS
certificate by verify email of various authoized Email address (like
[email protected] or email set by Whois/CAA/TXT etc...) but there is a
problem: it's sending mail when server reply the authorization, even if
I am not sure I fully understand this scenario, but given my current
understanding it seems like a scheme that would not work well in practice.
In an automated issuance environment, we would typically want the thing
being used as a validation challenge to be as analogous to the actual
usage
of the subsequent issued certificate as possible. So, for a TLS
certificate, we should be making a TLS connection sith specific metadata
(e.g., SNI/ALPN), and trying to leverage some other validation challenge
that's quite divorced from the TLS channel in question risks skew between
validation procedure and actual usage. Such skew introduces security risk,
since the "gap" between real usage and validation procedures introduce
either false positives or false negatives.
So maybe you could say a bit more about the scenario(s) you have in mind
and we could think about whether they would actually provide a useful
validation result.
Thanks,
Ben
mailing-to-admin address challenge for TLS certificate was example of
mail reply challenge may used with other kind of challenges. for other
example we may think about we may extend a send-only challenge for
no-reply address that doesn't have inbox for sign only certificate
well the problem I see is RFC8823's mail-reply-00 challenge so it's not
consider other type of challenges for that upper authorization may have,
because
1. sends its challenge email when it's created ("After responding to the
authorization request"), not user triggered the challange
2. if it failed to send challenge email it retry will not succeed
because client won't ever know token-p1, making it invalid- and it being
invalid make the upper auth invalid, kills the order. (If the client
attempts to fulfill a challenge and fails, or if there is an error while
the authorization is still pending, then the authorization transitions
to the "invalid" state. RFC8555 7.1.6)
and other problem is client can't know which challenge incoming mail
triggered for because from address which doesn't required to be unique
per challenge so acme server can reuse sending address (or just fixed it
with static value, because challenge mail only have token-part-1 , which
they don't know about it beforehand so if there is multiple of challenge
mail in inbox, they will have to reply all the challenge email with
expected sender.
(btw does smime certificate for//[email protected] valid for
[email protected]?) allowing smime certificate to be verify
challenge mail imply it is or using same sender for all challenge mails.
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
