Re: [Acme] URI-based CAA account binding

[Yaron Sheffer <[e-mail]>]

> From: Hugo Landau <[e-mail]>
> To: Richard Barnes <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Acme] URI-based CAA account binding
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset=iso-8859-1
>
>>    Thanks for the draft, Hugo.? In general, the idea of making CAA more
>>    precise seems like a good vein to explore, and to the dimensions of
>>    precision overlap with ACME semantics, it makes sense to do it here.
>>
>>    The other case (besides account URI) that I've heard folks talk about is
>>    allowing the domain holder to restrict what validation methods the CA
>>    should be allowed to use.? For example, you might allow DNS validation and
>>    forbid HTTP validation.? Between ACME and the new, stricter Baseline
>>    Requirements, it seems like we should be able to come up with a pretty
>>    comprehensive list of validation methods.? Is this something that would
>>    make sense to fold into this document?
>
> Alright, so here's some ideas:
>
> -  An ACME-specific 'acme-methods' parameter taking a comma-separated
>    list of methods (e.g. "acme-methods=dns-01,http-01").
>
> -  A generic "method-uri" parameter which accepts a URI representing a
>    method. For ACME this would be urn:ietf:acme:method:METHOD-NAME.
>    Multiple methods would probably be specified via multiple CAA
>    records; this would be slightly more obtuse for implementations
>    to process than the above, but nothing unreasonable.
>
> There's also the question of whether this should be in the same I-D or a
> separate one. I'm fine with putting it in, but if anyone thinks it
> should be a separate I-D, let me know.
>

I support this idea for the reasons listed here: 
https://tools.ietf.org/html/draft-sheffer-lurk-cert-delegation-00#section-4.3.

I think the first option (ACME-specific parameter) is preferred, because 
it is much better defined. I would suggest to include it in the current 
document, and with strict semantics: an ACME implementation that 
supports CAA MUST understand this parameter and MUST NOT use any method 
not listed here.

Thanks,
	Yaron