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

[Ryan Sleevi]

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

>
> > To make sure I understand: Are you proposing an explicit prohibition
> against
> > including any other extension or metadata within a Certificate
>
> Wow, no, certainly nothing so extreme.  There is certainly some metadata
> that
> is necessary and appropriate within the certificate itself.  Certainly
> anything that a browser uses or wants to use for trust decisions should be
> in
> the certificate itself.  I just think that not ALL such metadata belongs
> in
> certificates ...
>

Do you have an example?


>
> > If not, I'm not sure what you're proposing here - CAs that want to
> include
> > information will be able to, just as they are today.
>
> Sure, DigiCert can put kitchen sinks into certificates today, and we
> totally
> will, when it's appropriate.  I just think there is some value in
> standardizing across the industry what information is available where,
> instead
> of having all CAs make independent decisions.
>

Much like I was (and am) opposed to proposals to introduce Yet Another Way
to request revocation, I'm equally inclined to be skeptical-to-opposed to
premature standardization. I'd much rather facilitate and encourage open
discussion, but see no reason to presume a solution (such as "Metadata
Transparency") in the absence of a concrete problem.

Further, I'm deeply skeptical of any claims for more "Transparency Log"
types solutions (e.g. Revocation Transparency, DNSSEC transparency) without
a succinct and firm definition of the concrete set of problems that are
both in scope and out of scope. Transparency is a hugely complex system
that involves thinking about ecosystem incentives and alignment. That it's
taken CT 6 years to get to that point for DV, and we're still working
through a host of fun and interesting challenges anticipated back then
should hopefully demonstrate that CT is not blockchain pixie dust we get to
sprinkle on :)


>
> > While I agree that there are all sorts of terrible ideas for things to
> stuff
> > into certificates (if only because those proposing may not be aware of
> the
> > technical constraints or the alternatives that exist), there's also
> plenty
> > of good ideas.
>
> Agreed.  Which is why I'm hoping this will be a useful discussion that
> will
> provide some good guidance going forward on what is and is not a good idea.
>

I'm very skeptical that it will or can, without concrete examples to
facilitate discussion, which I may have missed or misunderstood.


> > Regarding your dislike of the poison extension, how does that square
> with
> > RFC 6962-bis? Are you saying that you don't believe 6962-bis already
> > accommodates the system you're describing, or that you don't want to
> wait
> > for 6962-bis to be deployed to be able to take advantage of this? If the
> > latter, do you have specific, concrete examples that might demonstrate
> why
> > it's more valuable sooner than later?
>
> I think RFC 6962-bis is a perfectly reasonable solution to the poison
> extension problem, and am in no particular hurry to solve that problem,
> since
> all it does is annoy my preferences about architectural cleanliness, and
> there
> are plenty of other things that annoy me along those lines that can
> distract
> me from this particular annoyance.
>
> I just don't want people creating any ADDITIONAL divergences between CT
> logged
> certificates and real certificates.
>

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?)
2) This information is not valuable to express in the certificate itself
(Question: Why?)
3) This information needs to be expressed before RFC 6962-bis (Question:
When does it need to be expressed, and why?)
4) This information is concrete enough to be expressible via defined
semantics that can be agreed upon (Question: How and where would such
semantics exist?)

I'm not sure I agree with any or all of those, so I must be
misunderstanding the problem you're trying to solve. Concrete, real-world
(that is, those that can be tied to specific customers and problem spaces)
examples would be tremendously useful in this regard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180501/ae05aae3/attachment-0003.html>