Re: [lamps] New draft: rfc6844bis

[Quirin Scheitle <[e-mail]>]

> On 5. Jun 2018, at 12:02, Ryan Sleevi <[e-mail]> wrote:
> 
> 
> 
> On Tue, Jun 5, 2018 at 3:49 AM, Quirin Scheitle <[e-mail]> wrote:
> 3) Validation Type   ######################
> 
> We suggest a tag (i.e., not a parameter) to permit domain-level control of permitted/restricted validation methods. E.g., an entry such as 
> 
>   tum.de 0 CAA 128 dcv "dns-cname"
>   tum.de 0 CAA 128 dcv "domain-contact-postal"
> 
> would permit dns-cname and domain-contact-postal methods. An entry such as 
> 
>   tum.de 0 CAA 128 nodcv "tls-sni”
> 
> would restrict the tls-sni method, but permit all others. 
> A mapping of BR/ACME defined methods to usable names would have to be conceived. 
> This could have helped in the TLS-SNI problem a couple of months ago.  
> 
> 4) Validation Level    ######################
> 
> We suggest a tag to define a minimum validation level. E.g., 
>         tum.de 0 CAA 128 vlevel "ov"
> In this example, the validation level tag vlevel would specify
> that for tum.de, only OV or EV certificates may be issued.
> This could, e.g. be used by domain name holders that exclusively
> obtain EV certificates, such as financial institutions,
> to proactively close the attack surface of DV methods.

Hi Ryan,

thank you for your reply! 

> 
> I am not supportive of either of these as part of 6844-bis.
> 
> Both of these concepts are specific to a particular industry and set of policies (namely, the commercial Web PKI and the CA/Browser Forum documents), and as such, do not have normative references and are not standards themselves that can be referenced.

That sounds convincing to me. Happy to move that part (#3 and #4) over to CABF VWG.

> 
> I am supportive of the former, to be defined in the CA/Browser Forum. While this document might countenance syntax of such an expression, the semantics of such an expression is inherently tied to the CA/Browser Forum's validation requirements, and thus exclusively should be viewed in that lens.
> 
> I am not supportive of the latter, even in the CA/Browser Forum, as they're unnecessary expressions of syntax for what can already be achieved via policy. That is, by restricting the set of CAs that can issue, one can already restrict the type and nature of certificates issued. For nominal views of 'high' security, this is the only defensible position - as shown by the ample OV and EV misissuance of CAs.

The way I understand your answer, you imply it would be bad if “vlevel” would be used *instead* of issue/issuewild tags. I full agree to that.
I meant “vlevel” to be an addition to issue/issuewild:
If I am an institution only using EV, and permit only CAs X and Y, attackers could still obtain DV certificates from CAs X or Y. 
With vlevel “ev”, attacks only using DV level would fail. 
[This part of the discussion can also be continued at the VWG, I guess]

Kind regards
Quirin