Re: [lamps] New draft: rfc6844bis

[Ryan Sleevi <[e-mail]>]

On Tue, Jun 5, 2018 at 10:45 AM, Quirin Scheitle <[e-mail]>
wrote:

>
> > 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]
>

Yeah, the CA/Browser Forum requires that CAs support organizations listing
who their certificate approvers are, so if you've limited to CAs X & Y, you
can instruct CAs X & Y to restrict that issuance, and it's a violation if
they don't. Subtle but it exists :)