[cabfpub] Putting OIDs for the manufacturer of your kitchen sink into certificates

[Ryan Sleevi]

On Tue, May 1, 2018 at 6:33 PM, Tim Hollebeek <tim.hollebeek at digicert.com>
wrote:

> I wouldn't be so quick to throw cold water on additional transparency
> mechanisms.  Some are probably bad ideas, but there are almost certainly
> good
> ideas in there, too.  Blockchain pixie dust does make some things better,
> though it isn't a silver bullet.
>

Transparency is a good idea, but profoundly difficult to build as an
ecosystem. I'm merely encouraging far more caution in thinking that "*
Transparency" is just flipping a few bits and magically an ecosystem
capable of achieving the desired properties and goals pops out :)

> I'm not fully sure I understand your position, then. Based on my
> > understanding, one option is that this problem is a nothingburger if
> there's
> > no compelling use case before a world of 6962-bis (which itself has an
> > indeterminate future). Alternatively, if we believe this is a problem
> for
> > today-or-the-soon to be, then it seems the position is:
> >
> > 1) There's a desire to express additional information (Question: What?)
>
> Let's go with Apple's problem reporting address suggestion for now.  I'm
> not
> kidding about a new one getting suggested every two to three months.
> Sometimes more.
>

So this is a bit of an inconsistent reply. You insist there are many, but
then only elaborate on one. This makes it unreasonably difficult to
actually evaluate the claim or the goals. The "problem reporting" method
can be expressed in the intermediate, and all the problems are suddenly
'solved'.

If that's the example, great, we've solved something in 5 minutes that
could have spent 5 years of unnecessary overarchitecture. Otherwise, we
need a more concrete list.


> > 2) This information is not valuable to express in the certificate itself
> > (Question: Why?)
>
> The information is primarily used by an arbitrarily small subset of
> certificate consumers, and is not part of or necessary for TLS handshakes.
> Some customers like tiny certificates.  I think we produce some of the
> tiniest.
>

Great. So don't use it, and host it on your website.

I've snipped the remainder of the replies, because the point was to
demonstrate the basic problem space to be evaluated for any example, but
that wasn't actually done for the one specific example given.

I don't think this is valuable. If anything, I think it's detrimental, in
that the proposal is a premature attempt to standardize something that's
not well-understood nor demonstrated to be an actual problem. Considering
how much work is left to tighten up the validation methods still, is the
view that such improvements are not a priority, or less of a priority than
this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20180501/8d232ab4/attachment.html>