[cabfpub] Putting OIDs for the manufacturer of your kitchen sink into certificates
tim.hollebeek at digicert.com
Tue May 1 15:33:16 MST 2018
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.
> 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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4940 bytes
Desc: not available
More information about the Public