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

> client has no intend to use those kind of challenge. while this could be 
> used as a warning mail for someone try to validate your domain, this is 
> not a expected result. and even in S/Mime context if we ever made some 
> other type of challenge while server still support email-reply-00, it 
> will send two mail for both type of challenge message to mailing address.
> 
> I think there is two way to 'arming' a challenge with a side effect:
> 
>  1.      Make challenge that doesn't boot up until client respond to
>     challenge first time. it will obviously fail because client doesn't
>     get needed info to validate, but let challenge retry mechanism to
>     handle that
>  2.      same with 1, but use some custom payload like 'run' or
>     something. we can do that when we make a new challenge protocol
> 
> _______________________________________________
> Acme mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/acme

_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme

Reply via email to