[cabfpub] Putting OIDs for the manufacturer of your kitchen sink into certificates
Moudrick M. Dadashov
md at ssc.lt
Tue May 1 23:16:52 UTC 2018
One THING I can think of, would be absence of any mechanism where a predefined certificate bit has some sort of end user visibility.
Thanks,M.D.
Sent from my Samsung device
-------- Original message --------
From: Tim Hollebeek via Public <public at cabforum.org>
Date: 5/2/18 01:33 (GMT+02:00)
To: Ryan Sleevi <sleevi at google.com>
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org>
Subject: Re: [cabfpub] Putting OIDs for the manufacturer of your kitchen sink into certificates
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.
> 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.
> 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.
> 3) This information needs to be expressed before RFC 6962-bis (Question:
> When does it need to be expressed, and why?)
If we're limiting ourselves to concrete discussions, then RFC 6962-bis is out
of scope, since we have no idea what it will say, or when. The result of
discussions about topics like this may in fact provide some feedback for what
RFC 6962-bis should say in this area.
It may end up being the solution here. I'm open minded about that. But I'm
also open minded about other potential ideas.
> 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?)
This is simple for some things; harder for others. But I see it more as a
detail to be worked out in particular cases rather than a fundamental
objection that makes the entire thing a bad idea.
-Tim
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180502/84479a53/attachment-0003.html>
More information about the Public
mailing list