On Fri, Jan 19, 2018 at 05:24:01PM +0000, Tim Hollebeek wrote:
> 
> > > I'm less worried about this constraint.  If there's consensus for a
> > > change, changes can be made to the BRs much more quickly than an RFC can
> > be issued.
> > 
> > Oh yeah, the minimum process latency for changing BRs is ~7 weeks.
> > 
> > However, that would take well-fleshed proposal to do it even close to that
> > quick. Take note that "10 methods" took years.
> 
> Years is a bit of an exaggeration.  One and change, I think it was.  And
> that
> was to get agreement on all ten methods and to work out exactly how the
> forum's IPR policy applied to validation methods (which was about 2/3
> of the timeline ...).
> 
> I think a well-written proposal to add or improve an existing validation
> method could easily get passed in close to the minimum timeline.
> 
> As the Validation WG chair, I'm even willing to help get secure, 
> well-analyzed and well-specified proposals through the voting process.

Just as an example of what the new method could be (I am assuming
back-transport via extension, because if it was via certificate, one
could claim method 10 as-is):


challenge: Random string of at least 128 bits of entropy.


Define new server_name NameType: network_address. The payload is IP
address of endpoint (4 bytes for IPv4, 16  bytes for IPv6).


Then define extension domain_validation:

Validator sends challenge_hash. This is 32 octet SHA-256 hash of the
challenge. server_name extension MUST be sent and set to the identifier
being validated (this is the reason for adding network_address, in
order to support validating IP addresses).


Server replies (in ServerHello or EncryptedExtensions) with its own
hash (using strong hash specified by the CA) over:

opaque challenge<1..2^16-1>;
opaque identifier<1..2^16-1>;
opaque applicant_id<1..2^16-1>;


The validation passes if:

- Response hash matches what CA computed, AND
- Server Finished MAC matches what CA computed, AND
- The exchange signature validates with the key from the certificate
  message.



In general, I would expect the BRs to refer to the TLS extension,
instead of specifying framework it fits into. This allows much more
precise security analysis, and much more compact BR text.


-Ilari

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

Reply via email to