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

[Moudrick M. Dadashov]

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>