[cabf_validation] Onion Proposal

[Wayne Thayer]

Thanks Jacob and Roland. I've attempted to address your comments:
https://github.com/wthayer/documents/commit/6e590309cca47737454790f452369769bf7281eb

As I believe you are suggesting, I removed the requirement defining how to
communicate the nonce only to the Applicant.

I also made a few other changes to the draft:
* Add random value expiration:
https://github.com/cabforum/documents/commit/14235f2e21df5cc75fbd151f91cba277af2df762
* Anticipate changes to domain validation method #6:
https://github.com/cabforum/documents/commit/4945ebd94fe70e3762600f39746e30d266d15aaf

Thanks,

Wayne

On Thu, Dec 19, 2019 at 2:18 PM Jacob Hoffman-Andrews <jsha at letsencrypt.org>
wrote:

> Thanks for moving this forward.
>
> My colleague Roland Shoemaker pointed out that this proposal introduces
> the term "Verified Method of Communication," which is only defined in the
> EVGLs, not the BRs. There's a similar definition in the BRs:
>
> Reliable Method of Communication: A method of communication, such as a
> postal/courier delivery address, telephone number, or email address, that
> was verified using a source other than the Applicant Representative.
>
> However, this is only used in the context of establishing Subject Identity
> Information to be included in the certificate. For certificates without
> Subject Identity Information, this is probably not necessary; that is,
> proof of control of the private key corresponding to the Onion address is
> sufficient on its own, so communication could be established, e.g. through
> an API account created by the Applicant Representative.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20191223/aebc7f8f/attachment.html>