9, 2020 13:25
*To:* Brian Sipos; acme@ietf.org
*Cc:* alexey.melni...@isode.com
*Subject:* SV: [Acme] ACME email validation
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 can’t be spoofed, because ACME i
the split
token.
Originalmeddelande Från: Brian Sipos
Datum: 2020-06-20 00:09 (GMT+01:00) Till: Sebastian Nielsen
, acme@ietf.org Kopia: alexey.melni...@isode.com Ämne: Re:
[Acme] ACME email validation
Sebastian,
Thank you very much for this clarification. This would apply
Nielsen
Sent: Friday, June 19, 2020 13:25
To: Brian Sipos; acme@ietf.org
Cc: alexey.melni...@isode.com
Subject: SV: [Acme] ACME email validation
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 can’t
2020 00:13
Till: acme@ietf.org
Kopia: alexey.melni...@isode.com
Ämne: [Acme] ACME email validation
All,
In a recent draft I created for using ACME for non-web-PKI verification [1]
I see that there are many similarities with an earlier draft for email
verification [2]. In that email protocol
All,
In a recent draft I created for using ACME for non-web-PKI verification [1] I
see that there are many similarities with an earlier draft for email
verification [2]. In that email protocol, the challenge token is split into two
parts which arrive at the email validation agent through two
