[cabfpub] Misissuance of certificates

[Ryan Sleevi]

On Mon, Nov 9, 2015 at 8:52 AM, Doug Beattie <doug.beattie at globalsign.com>
wrote:

> We had been planning to use CT with name redaction to support making all
> certificates publicly available without exposing the exact FQDNs being
> secured.  When CT is mandated for all certificates there will be no choice
> about whether or not to comply, but we hope name redaction is well defined
> and accepted by then.
>

An important, and extremely relevant, point to the discussion of name
redaction is that the only thing it witholds from the certificate is the
DNS name. All other fields and extensions are (rightfully) treated as
public data.

Obviously, there are degrees in which you could disclose information. For
example, I'm sure some CAs would prefer to disclose issuer and serial
number (e.g. what goes in a CRL), with possibly the addition of SPKI, but
there's a whole host of other, relevant fields that appear in a certificate
and that are governed by either root program requirements or by CA/B Forum
documents (for example, policy OIDs being asserted are relevant - are these
EV? DV? OV? IV? So to are basicConstraints - heaven forbid we have a CA
trying to hide a basicConstraints CA=true!).

This goes back to the notion of *misissued* certificates requiring full
disclosure, so that the public and the root programs can independently
evaluate the assertions, scope, and related.

For the customers who care about privacy, my remark to them would be "Well,
make sure your CA isn't going to misissue the certs with your secrets".
Whether or not you can trust your CA to keep your domain names secret only
extends as far as you can trust your CA to implement name redaction
properly (if they're logging to CT) and that they've implemented the BRs /
EVGs / Root Program requirements properly (so that they don't misissue)


> The only other alternative is to set up name constrained CAs for every
> enterprise customer, which is also certainly possible.
>

Note that, even under the current BRs, such CAs unfortunately are
considered in scope of the BRs. I personally find this quite unfortunate,
as I think the 'scope of damage' of a name constrained CA is extremely
limited. Even matters such as cryptographic policies I'm willing to be more
lax on, because those are precisely the things that browsers can enforce
(and, with increasing frequency, are enforcing), and it's the customer's
failing to adhere to industry standards if they choose to ignore. However,
such a customer ignoring it and only affecting 'mysite.example.com' is
vastly different than a CA ignoring it and affecting 10-20% of the secure
Internet,  and I don't think 'mysite.example.com' ignoring it with their
name-constrained CA would be reason for taking action upon the root that
gave out such an intermediate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151109/ce1bb8cf/attachment.html