<HTML><HEAD></HEAD>
<BODY dir=ltr>
<DIV dir=ltr>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: 'Calibri'; COLOR: #000000">
<DIV>That depends what the alternatives are. Any new proposal has to be able to
meet all the functional use cases of the old. So if the only alternative you
leave to leaving out the subject key is to publish a constrained intermediary
instead then you are forcing people to use a large hole rather than a smaller
one.</DIV>
<DIV> </DIV>
<DIV>There are two separate compelled issue cases</DIV>
<DIV> </DIV>
<DIV>Case 1: CA X is authorized to issue, CA Y is compelled to issue a
cert.</DIV>
<DIV>Case 2: CA X is authorized to issue and is compelled to issue an additional
certificate.</DIV>
<DIV> </DIV>
<DIV>The compelled issue scenario that has been raised most frequently is (1).
That is the hard one because any CA can potentially be coerced.</DIV>
<DIV> </DIV>
<DIV>If I am going to be putting the service out on the Amazon cloud then why
would I accept a major operational constraint to prevent coercion of my US CA by
the US government if the US government can pick up the same information by
coercing my US cloud host?</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV
style="BORDER-TOP-COLOR: #000000; BORDER-BOTTOM-COLOR: #000000; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 4px solid; BORDER-RIGHT-COLOR: #000000">
<DIV
style="FONT-SIZE: small; FONT-FAMILY: 'Calibri'; FONT-WEIGHT: normal; COLOR: #000000; FONT-STYLE: normal; TEXT-DECORATION: none; DISPLAY: inline">
<DIV style="FONT: 10pt tahoma">
<DIV style="font-color: black"><B>From:</B> <A title=sleevi@google.com
href="mailto:sleevi@google.com">Ryan Sleevi</A> </DIV>
<DIV><B>Sent:</B> Friday, December 20, 2013 4:05 PM</DIV>
<DIV><B>To:</B> <A title=philliph@comodo.com
href="mailto:philliph@comodo.com">Phillip Hallam-Baker</A> </DIV>
<DIV><B>Cc:</B> <A title=rob.stradling@comodo.com
href="mailto:rob.stradling@comodo.com">Rob Stradling</A> ; <A
title=public@cabforum.org href="mailto:public@cabforum.org">CABFPub</A> </DIV>
<DIV><B>Subject:</B> Re: [cabfpub] CT Precertificates and the
BRs</DIV></DIV></DIV></DIV>
<DIV
style="BORDER-TOP-COLOR: #000000; BORDER-BOTTOM-COLOR: #000000; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 4px solid; BORDER-RIGHT-COLOR: #000000">
<DIV
style="FONT-SIZE: small; FONT-FAMILY: 'Calibri'; FONT-WEIGHT: normal; COLOR: #000000; FONT-STYLE: normal; TEXT-DECORATION: none; DISPLAY: inline">
<DIV dir=ltr>
<DIV>Phil,</DIV>
<DIV> </DIV>
<DIV>I fail to see how omitting the subject key can be argued as meeting the
security requirements of public auditability. Indeed, nothing would prevent a CA
from being compromised and issuing a new certificate - based on an existing
certificate - that contains an attacker controlled key. This may be due to
compromise or due to legal compulsion, and would be undetectable by the
public.</DIV>
<DIV> </DIV>
<DIV>Surely you're not arguing that supporting compelled certificate issuance
would be a "feature"?<BR>
<DIV class=gmail_extra><BR><BR>
<DIV class=gmail_quote>On Fri, Dec 20, 2013 at 12:56 PM, Phillip Hallam-Baker
<SPAN dir=ltr><<A href="mailto:philliph@comodo.com"
target=_blank>philliph@comodo.com</A>></SPAN> wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<DIV dir=ltr>
<DIV dir=ltr>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: 'Calibri'">
<DIV>An Experimental RFC is certainly not a bar to major protocol changes.
</DIV>
<DIV> </DIV>
<DIV>Since any change would only impact verification, DigiCert would be
unaffected. And we are told repeatedly that Chrome can be updated at will. So
I don’t see you making a persuasive argument that it is too late to make
changes.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>The parts of the cert that you cite as important are the parts that I
agreed the CT entry needs to cover. The parts that I am dubious about are the
serial number and the subject key. </DIV>
<DIV> </DIV>
<DIV>I don’t see you making an argument against excluding the parts of the
certificate I suggested leaving out. You instead set up a straw man and argued
against that.</DIV>
<DIV> </DIV>
<DIV>What I am proposing has far greater control than certifying an
intermediate precisely because the EKU and other extensions can be included.
It is actually strengthening the scheme over allowances already
conceded.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV
style="BORDER-TOP-COLOR: #000000; BORDER-BOTTOM-COLOR: #000000; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 4px solid; BORDER-RIGHT-COLOR: #000000">
<DIV
style="FONT-SIZE: small; FONT-FAMILY: 'Calibri'; FONT-WEIGHT: normal; FONT-STYLE: normal; TEXT-DECORATION: none; DISPLAY: inline">
<DIV style="FONT: 10pt tahoma">
<DIV><B>From:</B> <A title=sleevi@google.com href="mailto:sleevi@google.com"
target=_blank>Ryan Sleevi</A> </DIV>
<DIV><B>Sent:</B> Friday, December 20, 2013 3:19 PM</DIV>
<DIV><B>To:</B> <A title=philliph@comodo.com href="mailto:philliph@comodo.com"
target=_blank>Phillip Hallam-Baker</A> </DIV>
<DIV><B>Cc:</B> <A title=rob.stradling@comodo.com
href="mailto:rob.stradling@comodo.com" target=_blank>Rob Stradling</A> ; <A
title=public@cabforum.org href="mailto:public@cabforum.org"
target=_blank>public@cabforum.org</A> </DIV>
<DIV class=im>
<DIV><B>Subject:</B> Re: [cabfpub] CT Precertificates and the
BRs</DIV></DIV></DIV></DIV></DIV>
<DIV
style="BORDER-TOP-COLOR: #000000; BORDER-BOTTOM-COLOR: #000000; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 4px solid; BORDER-RIGHT-COLOR: #000000">
<DIV
style="FONT-SIZE: small; FONT-FAMILY: 'Calibri'; FONT-WEIGHT: normal; FONT-STYLE: normal; TEXT-DECORATION: none; DISPLAY: inline">
<DIV dir=ltr>
<DIV> </DIV>
<DIV class=gmail_extra>
<DIV> </DIV>
<DIV>
<DIV class=h5>
<DIV> </DIV>
<DIV class=gmail_quote>On Fri, Dec 20, 2013 at 6:40 AM, Phillip Hallam-Baker
<SPAN dir=ltr><<A href="mailto:philliph@comodo.com"
target=_blank>philliph@comodo.com</A>></SPAN> wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">We
seem to be getting a lot of confusion here, lets start from first
principles.<BR><BR>1) Is there a deployed base for CT? NO<BR><BR>Therefore
the CT code is completely changeable. We are not restricted by the current
formats or solutions. If there is an incompatibility with deployed
infrastructure we can do that.<BR></BLOCKQUOTE>
<DIV> </DIV>
<DIV>As Jeremy has already pointed out, there is a deployed base of CT -
Google and Digicert ( <A
href="http://www.digicert.com/news/2013-09-24-certificate-transparency.htm"
target=_blank>http://www.digicert.com/news/2013-09-24-certificate-transparency.htm</A>
), among others. There are people already examining the CT logs (using tools
like <A href="https://github.com/agl/certificatetransparency"
target=_blank>https://github.com/agl/certificatetransparency</A> ). There are
clients validating SCTs (eg: <A
href="https://twitter.com/reschly/status/410990449952698369"
target=_blank>https://twitter.com/reschly/status/410990449952698369</A>
)</DIV>
<DIV> </DIV>
<DIV>Finally, there is an IETF RFC assigned, the result of a very active
discussion within the IETF.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><BR> </DIV>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR><BR>2)
Is there a need for any CT record to bind to the certificate serial number
data?<BR><BR>I can’t see one. The transparency criteria is for issue of
certificates that are signed by a particular CA that bind to particular
names under specific policies.<BR><BR>The less information that the CT binds
to, the more coverage a CT record gets. For example, a cloud service has
1000 certificates with separate keys for each, do they really need to have
an independent CT block for each one? For example, a service refreshes its
certificate every hour with a very short expiry period to avoid the need for
revocation processing, does it really need to get a new CT authorization per
certificate issue?</BLOCKQUOTE>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR><BR>Including
the certificate serial number and the subject key in the CT record should
both be optional. Including them does not seem to reduce the attack surface
in a meaningful way but it certainly constrains the operation of the End
Entity device.</BLOCKQUOTE>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR><BR>In
a cloud computing environment the service can be moving from machine to
machine on a very short cycle. I am old fashioned, I don’t think private
keys for signature or exchange should ever be used on more than one machine.
So I would like to see a scheme where the certificates and keys flow into
the machine where they will be used along with the VM image and expire
within a day.<BR><BR>Binding CT records to the subject keys and the serial
numbers in the public transparency records seems like a bad move to me. It
would provide a huge amount of information to an attacker on the internal
workings of cloud providers and big infrastructure players like Akamai (and
Google).<BR><BR><BR>If there was a customer that really wanted to have fine
grain control over cert issue then the appropriate way to handle that
requirement would be for the CA to issue them a sub CA with name constraints
and give them partial control over the signing key through a multiparty
signature scheme. But I am not sure which (if any) HSMs would support the
capabilities needed and it would be a huge engineering investment.<BR>
<DIV>
<DIV></DIV></DIV></BLOCKQUOTE></DIV></DIV></DIV></DIV>
<DIV>
<DIV class=h5>
<DIV class=gmail_extra> </DIV>
<DIV class=gmail_extra> </DIV>
<DIV class=gmail_extra>While an interesting idea, it seems to fail to grasp
some of the key benefits to CT.</DIV>
<DIV class=gmail_extra> </DIV>
<DIV class=gmail_extra>Such a proposal - to only bind precerts to certain
elements of the cert, whether it be things like "just" the subjectAltNames -
fails to consider the fact that CT represents a publicly-auditable record of
issuance.</DIV>
<DIV class=gmail_extra> </DIV>
<DIV class=gmail_extra>We have seen repeatedly over the past several years -
both in high-profile incidents like Trustwave, Diginotar, and Turktrust, and
in smaller cases such as GoDaddy - where the stated CP/CPS (eg: as linked to
within the certificate) is not adhered to. Whether this is intentional - such
as a different interpretation of "issuance", as in the case of GoDaddy - the
result of compromise, such as DigiNotar, or accident, such as TurkTrust, it
remains a consistent problem.</DIV>
<DIV class=gmail_extra> </DIV>
<DIV class=gmail_extra>Google has, through our basic crawls that certainly
fails to discover *all* certificates issued, continued to see this misissuance
- RSA key sizes, validity periods, subject names, etc.</DIV>
<DIV class=gmail_extra> </DIV>
<DIV class=gmail_extra>If CT is meant to be a meaningful augmentation to the
demonstrably inadequate WebTrust audits, then we really do need to cover all
parts of the certificate that are governed by the BRs or the EVGs. And, as it
turns out, that is the entire certificate - including extensions.</DIV>
<DIV class=gmail_extra> </DIV>
<DIV class=gmail_extra>Trying to chop up the cert into bits and pieces simply
fails to accomplish that goal of providing a reasonable, publicly auditable
trail of issuance and adherence. And, given the continued failure of audits to
provide reasonable assurances, that is exactly what is needed at this
time.</DIV></DIV></DIV></DIV></DIV></DIV></DIV></DIV></DIV></BLOCKQUOTE></DIV>
<DIV> </DIV></DIV></DIV></DIV></DIV></DIV></DIV></DIV></BODY></HTML>