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

Tim Hollebeek 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. 
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 

> 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...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/public/attachments/20180501/70c89482/attachment.p7s>

More information about the Public mailing list