<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
On 12/19/2013 02:27 AM, From Ryan Sleevi:
<blockquote
cite="mid:CACvaWvYQ5jZCmLQSh3MZ15ONcBeJJTnJ8mX2+bj1XHSJnWZSpA@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra">It has been repeatedly explained to
you, by multiple parties, that it is not the end users (that
is, to use CA terms, "Relying Parties"), but instead the site
operators, who will be monitoring the CT log.</div>
</div>
</blockquote>
<br>
I don't think it really matters who and how is monitoring this log,
if at all.<br>
<br>
<blockquote
cite="mid:CACvaWvYQ5jZCmLQSh3MZ15ONcBeJJTnJ8mX2+bj1XHSJnWZSpA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div class="im"> <br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>And who do these users yell at when pins
break?</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
There is most likely a reason if that happens, this way
or the other. A knowledgeable users will know the
difference and the others will not pin any certificates
to start with.</div>
</blockquote>
<div><br>
</div>
<div>So protection for nobody. Got it.</div>
</div>
</div>
</div>
</blockquote>
<br>
I thought CT is about detection and not primarily protection?
Detection also provides retroactive protection obviously, there
might be other ways (better, worse) to achieving the same or
similar.<br>
<br>
<blockquote
cite="mid:CACvaWvYQ5jZCmLQSh3MZ15ONcBeJJTnJ8mX2+bj1XHSJnWZSpA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">Eddy, I have tremendous respect for
you and your efforts, but I feel at this time, we've reached
an impasse at being able to fruitfully and productively
discuss CT, its merits, and its risks. </div>
</div>
</div>
</blockquote>
<br>
Probably - at this point we can simply agree that we disagree.<br>
<br>
<blockquote
cite="mid:CACvaWvYQ5jZCmLQSh3MZ15ONcBeJJTnJ8mX2+bj1XHSJnWZSpA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">As has been previously discussed ( <a
moz-do-not-send="true"
href="https://cabforum.org/pipermail/public/2013-September/002233.html">https://cabforum.org/pipermail/public/2013-September/002233.html</a>
), Google Chrome intends to require Certificate Transparency
for all EV certificates issued after a future date. This is,
as has been previously stated, an additional requirement
that Google Chrome is imposing on certificates that it
grants the EV badge to - in addition to, not in replacement
of, the existing auditing requirements according to the
CA/Browser Forum's EV Certificate Guidelines, and as
documented at <a moz-do-not-send="true"
href="http://www.chromium.org/Home/chromium-security/root-ca-policy">http://www.chromium.org/Home/chromium-security/root-ca-policy</a></div>
</div>
</div>
</blockquote>
<br>
I took note about your intentions, funnily that EV is your primary
target which I believe needs it the least.<br>
<br>
Now, regarding your intentions I believe it needs two to tango - we
will make our calculations and will make a decision if we can
support it or not. <u>If compliance would mean a significant change
to the current business model of StartCom and the way we issue
certificates, we will most likely not support it</u>. **<br>
<br>
It could be that other CAs for this or other reasons (maybe privacy,
existing NDAs etc.) will not be able to support it either, than you
might be in a difficult situation too...<br>
<br>
<br>
** Please note that less than half a year ago we had to make
considerable efforts to support a complete change of our OCSP
infrastructure, which involved some difficulties and still does for
us. Unfortunately the only browser that really does something with
that information (Firefox), is the one that suffered the most
because of it. We are willing to make another effort shortly if
Firefox doesn't support OCSP GET requests very soon in order to
improve the situation.<br>
<br>
Other requirements, changes and regulations are coming forth every
here and now by the software vendors (and not through the CAB forum
guidelines necessarily where CAs also have a say) affecting
operation, implementations and business models, whereas I'm not sure
if and when some real actions are warranted by the software vendors
it always happens the way I'd like to see it. Other times the same
browser vendors bent over themselves (and some CAs) for far less
significant changes and far bigger failures (excuse my rambling)...<br>
<br>
In short, this might be a deal-breaker for us which we will consider
carefully at the appropriate time. And now I will shut up in order
not to annoy the audience any further! :-)<br>
<br>
<br>
<div class="moz-signature">
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
<td colspan="2">Regards </td>
</tr>
<tr>
<td colspan="2"> </td>
</tr>
<tr>
<td>Signer: </td>
<td>Eddy Nigg, COO/CTO</td>
</tr>
<tr>
<td> </td>
<td><a href="http://www.startcom.org">StartCom Ltd.</a></td>
</tr>
<tr>
<td>XMPP: </td>
<td><a href="xmpp:startcom@startcom.org">startcom@startcom.org</a></td>
</tr>
<tr>
<td>Blog: </td>
<td><a href="http://blog.startcom.org">Join the Revolution!</a></td>
</tr>
<tr>
<td>Twitter: </td>
<td><a href="http://twitter.com/eddy_nigg">Follow Me</a></td>
</tr>
<tr>
<td colspan="2"> </td>
</tr>
</tbody>
</table>
</div>
<br>
</body>
</html>