<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Cambria;
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin-top:0in;
margin-right:0in;
margin-bottom:10.0pt;
margin-left:0in;
line-height:115%;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:10.0pt;
margin-left:.5in;
line-height:115%;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:black;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=white lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:12.0pt;line-height:115%;font-family:"Times New Roman","serif"'>First of all I don't believe that there can be a robust mechanism to issue certificates with such a frequency where the CA does its pre and post issuance diligence. I'd consider such issuance more risky than a controlled and supervised manner (assuming that CAs did implement some due diligence for issuing certificates in the post Diginotar aera). This is my main objection and critical in my opinion.</span><span style='font-size:12.0pt;line-height:115%;font-family:"Times New Roman","serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:115%;font-family:"Times New Roman","serif";color:#1F497D'>[JR] Depends on the CA. Obviously, some CAs have better post and pre issuance diligence practices than others. I think a correctly operating CA issuing short lived certificates can have just as good of post issuance and pre issuance diligence as one that issues longer lived certs. In fact, better practices since they don’t have to worry about OCSP up-time, CRL availability, and the timely processing of revocation requests. Plus, you don’t have revocation-for-business reasons cluttering the CRL and OCSP responses. I believe it’s much less risky since there is a lot less that can go wrong.<o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:12.0pt;line-height:normal'><span style='font-size:12.0pt;font-family:"Times New Roman","serif"'>Second, for an attacker 3 - 7 days is a long time to achieve their goals most of the time, by repeating same attack which would go undetected due to the above mentioned missing diligence, this could go on for a while.</span><span style='color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:12.0pt;line-height:normal'><span style='color:#1F497D'>[JR] That argument is bogus. Because of the BR 7/10 update requirement, any attacker has between 7-10 days to make their attack. The post issuance obligations remain the same. You discover a breach, you report the breach to the browsers and turn off related issuance. If you are arguing for a shorter time under the BRs, I’d support that and update my proposal for short-lived certs accordingly.<o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:12.0pt;line-height:normal'><span style='font-size:12.0pt;font-family:"Times New Roman","serif"'>Third, most software (browsers and other clients) check revocation usually on a higher frequency then possible nextUpdate fields in OCSP and CRLs, specially when relying on OCSP. Removing revocation status DPs will allow an attacker to complete his attack happily even if the CA has become aware of it. Software updates wouldn't be fast enough either.</span><span style='font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:12.0pt;line-height:normal'><span style='font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F497D'>[JR] Not accurate. As someone pointed out a while ago, Microsoft caches responses for 80% of the OCSP next update. Under the BRs this is 8 days. Software updates can be rolled out much faster than this (based on the actions taken by the major browsers in response to the events of a few years ago). Again, sounds like you are arguing for a change in the BR’s requirements on OCSP and CRL rather than directly against short-lived certificates.<o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:12.0pt;line-height:normal'><span style='font-size:12.0pt;font-family:"Times New Roman","serif"'>Forth, browsers don't check revocation status all at the same time, making attacks more difficult when revocation status DPs are defined (system restarts, first access, access after 24 hours depending on software trigger a revocation status check). This will make an attack less reliable and also detectable by the client (if configured correctly).<br><br></span><span style='font-size:12.0pt;font-family:"Cambria","serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:12.0pt;line-height:normal'><span style='font-size:12.0pt;font-family:"Cambria","serif";color:#1F497D'>[JR] Correct. Some browsers don’t check revocation at all. </span><span style='font-size:12.0pt;font-family:"Cambria","serif";color:#1F497D'>I hardly think that is an argument against a guaranteed method of revocation checking like short lived certs provides. Also, if the client can’t access the revocation information (say in the case of a government sponsored attack), you’re basically screwed using traditional revocation. You simply can’t revoke the certificate, whereas with short lived certificates you have assurance that those certificates will at least cease functioning after a certain time.</span><span style='font-size:12.0pt;font-family:"Cambria","serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Would it alleviate concerns if short-lived certs are issued from a different intermediate than other certs? The intermediate still contains revocation information. If something goes horribly wrong, you can always shut off the intermediate.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Jeremy<o:p></o:p></span></p></div></body></html>