<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body>
<div>One THING I can think of, would be absence of any mechanism where a predefined certificate bit has some sort of end user visibility.</div><div><br></div><div>Thanks,</div><div>M.D.</div><div><br></div><div><br></div><div><br></div><div id="composer_signature"><div style="font-size:88%;color:#364f67" dir="auto">Sent from my Samsung device</div></div><br><br>-------- Original message --------<br>From: Tim Hollebeek via Public <public@cabforum.org> <br>Date: 5/2/18 01:33 (GMT+02:00) <br>To: Ryan Sleevi <sleevi@google.com> <br>Cc: CA/Browser Forum Public Discussion List <public@cabforum.org> <br>Subject: Re: [cabfpub] Putting OIDs for the manufacturer of your kitchen sink into certificates <br><br>I wouldn't be so quick to throw cold water on additional transparency <br>mechanisms. Some are probably bad ideas, but there are almost certainly good <br>ideas in there, too. Blockchain pixie dust does make some things better, <br>though it isn't a silver bullet.<br><br>> I'm not fully sure I understand your position, then. Based on my <br>> understanding, one option is that this problem is a nothingburger if there's <br>> no compelling use case before a world of 6962-bis (which itself has an <br>> indeterminate future). Alternatively, if we believe this is a problem for <br>> today-or-the-soon to be, then it seems the position is:<br>><br>> 1) There's a desire to express additional information (Question: What?)<br><br>Let's go with Apple's problem reporting address suggestion for now. I'm not <br>kidding about a new one getting suggested every two to three months. <br>Sometimes more.<br><br>> 2) This information is not valuable to express in the certificate itself <br>> (Question: Why?)<br><br>The information is primarily used by an arbitrarily small subset of <br>certificate consumers, and is not part of or necessary for TLS handshakes. <br>Some customers like tiny certificates. I think we produce some of the <br>tiniest.<br><br>> 3) This information needs to be expressed before RFC 6962-bis (Question: <br>> When does it need to be expressed, and why?)<br><br>If we're limiting ourselves to concrete discussions, then RFC 6962-bis is out <br>of scope, since we have no idea what it will say, or when. The result of <br>discussions about topics like this may in fact provide some feedback for what <br>RFC 6962-bis should say in this area.<br>It may end up being the solution here. I'm open minded about that. But I'm <br>also open minded about other potential ideas.<br><br>> 4) This information is concrete enough to be expressible via defined <br>> semantics that can be agreed upon (Question: How and where would such <br>> semantics exist?)<br><br>This is simple for some things; harder for others. But I see it more as a <br>detail to be worked out in particular cases rather than a fundamental <br>objection that makes the entire thing a bad idea.<br><br>-Tim<br><br>_______________________________________________<br>Public mailing list<br>Public@cabforum.org<br>https://cabforum.org/mailman/listinfo/public<br></body></html>