<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 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
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:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
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;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@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 lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Ryan,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">In this case it wouldn’t be possible to give them the same certificate with only new dates (the current one was issued from a different CA), but we might be able
to re-use the prior CSR. Is re-using the same keys and then GlobalSign specifying the other values for the certificate sufficient? I’m guessing the answer is no because we could collude with this customer on the values.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">We would have no problems doing an audited process where:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">- GlobalSign generates the key pair for the customer (or customer generates it, or we re-use the keys from the prior cert – whatever is best)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">- GlobalSign defines the contents of the certificate following our current vetting practices, documents them (Subject DN and all extensions)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">- Once the keys are generated and the DN content defined, an independent 3<sup>rd</sup> party can specify a value for the OU field to add some randomization which
could not have been predicted by the GlobalSign.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">- Our existing SHA-1 CA would be used to generate the certificate under standard operating procedures (serial number generation, setting the certificate start/end
dates based on the date/time the certificate was requested). We could do this within X minutes of being provided the new OU value to reduce the time available to create collisions prior to signing.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Would something along these lines work where there is an independent 3<sup>rd</sup> party that adds some content just prior to certificate signing?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Doug<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Ryan Sleevi [mailto:sleevi@google.com]
<br>
<b>Sent:</b> Thursday, April 7, 2016 1:55 PM<br>
<b>To:</b> Doug Beattie <doug.beattie@globalsign.com><br>
<b>Cc:</b> Peter Bowen <pzb@amzn.com>; Dean Coclin <Dean_Coclin@symantec.com>; CABFPub <public@cabforum.org><br>
<b>Subject:</b> Re: [cabfpub] SHA1 options for payment processors<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Doug,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I don't think that solution would address our concerns - which is that it doesn't defend against a collaborating or compromised CA. Validity period, serial number, and CA key generation all rely on the CA doing everything exactly right,
and we've seen too much ample evidence of CAs being unable to do that.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The alternative, which is regenerating for exactly the same certificate as a previously issued certificate (while changing the validity period), meaningfully and verifiably addresses these concerns. It's something worth considering. Is
that something that would also work for your case?<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Thu, Apr 7, 2016 at 10:52 AM, Doug Beattie <<a href="mailto:doug.beattie@globalsign.com" target="_blank">doug.beattie@globalsign.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Peter,</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">If we generated the key pair for the customer would that reduce the risks to the point that we could
support issuance of SHA-1 certificates to a specified/predefined set of CommonNames for a specific set of customers? Adding this requirement along with the validity period and serial number entropy sound like solid risk mitigation approach.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Doug</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><a name="m_-5957377857926942324__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span></a><o:p></o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">
<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a> [mailto:<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a>]
<b>On Behalf Of </b>Peter Bowen<br>
<b>Sent:</b> Thursday, April 7, 2016 12:40 PM<br>
<b>To:</b> Dean Coclin <<a href="mailto:Dean_Coclin@symantec.com" target="_blank">Dean_Coclin@symantec.com</a>><br>
<b>Cc:</b> CABFPub <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><br>
<b>Subject:</b> Re: [cabfpub] SHA1 options for payment processors</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Dean,<o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I don't represent a browser, so I may not be the most useful commenter. That being said, I think it is important to understand the risk from weak hashes so proposed mitigations
can be accurately evaluated.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Given that digital certificates share a lot of similarities with physical identity documents (passports, driver's licenses, and such), looking at how fake IDs get created is very
useful.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">There are several kinds of fake IDs that are commonly found in the US: valid IDs issued by untrusted issuers, forged IDs, and tampered IDs are three of the most common.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The first group, valid IDs from untrusted issuers is quite simple: someone comes up with a name, such as "Northampshire University", and creates IDs issued by this non-entity.
The IDs themselves are not forged or tampered, but the process used to validate the data included in the ID is frequently sub-par. For example, it may be up to the applicant for the ID to provide a picture and details for the ID and there no validation done
of the information. The only standard is "nil certificate sine lucre". For digital certificates this is equivalent of self-signed certificates or certificates issued by an untrusted authority.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The second group, forged IDs, are documents where the creator managed to figure out how to make brand new documents that are identical to valid ones. This is also frequently referred
to as counterfeiting. This usually happens when the security elements included in the real ID become easy to duplicate. For example, it used to be that color pictures were considered a good security measure as were embossed seals. However over time technology
got better and it was not nearly so hard to replicate embossed seals and newer technology made getting color photos easy. This meant that someone could create a brand new ID from scratch that was difficult to impossible to tell from an authentic ID. For
digital certificates this is the equivalent of recovering or calculating the private key of the CA. Today this is trivial for RSA public keys that are 512-bits long and considered to be within the real of possibility for RSA public keys that are 1024-bits
long.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The third group are tampered IDs. These are documents which started as authentic documents but have been modified after issuance to contain different information. The classic
example is slicing open an ID, removing the original photograph and inserting a new one. Related attacks are bleaching low value currency (printed on hard to duplicate paper) and using the resulting paper to print higher value notes and removing a holographic
seal from one document and attaching it to a new document. In all these cases the fraudster does not have to forge the security element, she just uses an authentic one. For digital certificates this is a hash collision. One gets a valid certificate or other
signed document, cuts the signature off, and attaches it to their own certificate with different information.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">In late 2008, a team of mathematicians and security researchers executed the third type of attack (<a href="http://www.win.tue.nl/hashclash/rogue-ca/" target="_blank">http://www.win.tue.nl/hashclash/rogue-ca/</a>).
They took a valid RapidSSL certificate from VeriSign (now Symantec), removed the signature, and attached it to their own certificate. By formatting their certificate just right they were able to allow the signature to be valid for both the original certificate
and the fake certificate. You can see the details of both certificates in the diagram they posted:
<a href="http://www.win.tue.nl/hashclash/rogue-ca/downloads/alignment.pdf" target="_blank">
http://www.win.tue.nl/hashclash/rogue-ca/downloads/alignment.pdf</a>. Two details are very important in that diagram: 1) The serial numbers of the two certificates are different and 2) the basic constraints CA field is set differently. The first variation
means that revoking the original certificate has no impact on the fake certificate, as the fake certificate serial number will not be on the revoked list. The second variation means that the risk does not stop at the faked certificate but cascades, as the
fake certificate can be used to issue unlimited new certificates.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Given that anything in the certificate can be faked if you can move a signature from one certificate to another, we need to look at what makes it possible to have a single signature
valid for multiple certificates or signed documents. The signed document case is important as signature for an OCSP response, CRL, CSR, or completely different type of certificate (e.g. S/MIME) from the same issuing CA can be cut off and attached to a server
certificate and used with SSL/TLS. There is currently no known way to take an arbitrary signature and create a new certificate that matches the signature. This is true for MD5, SHA1, SHA2 and SHA3 based signatures. What is known is that one can create two
certificates which both match a given signature if you have full control over both certificates. The amount of data needed to do this varies; see
<a href="http://www.mscs.dal.ca/~selinger/md5collision/" target="_blank">http://www.mscs.dal.ca/~selinger/md5collision/</a> for some examples of short data sequences which both have the same signature. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">So the best solution, other than not using MD5 and SHA1, is to deny the attacker control over the certificate. In both the MD5 Collisions Inc attack and the Flame attack (<a href="https://www.trailofbits.com/resources/flame-md5.pdf" target="_blank">https://www.trailofbits.com/resources/flame-md5.pdf</a>)
the attacker appears to have created specially generated public keys to submit to the CA to be signed. These keys were not random but contained sequences of bytes designed to create the desired collision. These sequences were generated by guessing the bytes
leading up to their control point (the prefix) and then ensuring that there were sufficient bytes under the attackers control to change the state of the hash to one of their choosing. This presents two options for mitigations: make it impossible to guess
the prefix and deny them the bytes to set to their chosen values. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Making the prefix unpredictable can be done by introducing random values into the prefix, for example including them in the certificate serial number. According to RFC 5280, serial
numbers can be up to 20 octets and the top octet must not have a leading 1. This means the serial number can contain up to 159 random bits. This is a good mitigation, but can still be made worthless if the attacker can predict the "random" values used, either
due to poor random value generation by the CA or by secret knowledge of the random value generator. This mitigation is also useless if the CA is a silent partner in the attack -- that is if the CA is willing to accept a chosen value from the attacker as the
serial number.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The other option is denying the attacker sufficient bytes to change the hash state to a collusion state. The can be done by not allowing the attacker to choose the public key in
the certificate and ensuring the subject information does not contain random bytes. There are two paths available here. The first would be for the CA to generate the key pair and provide it to the certificate applicant, thus denying them control of the contents.
This is an option, but does not work in most cases, as legitimate certificate requesters have a reasonable request that their private key be under their control at all times. Alternatively one could require the generation of the key using a trusted algorithm
and only sign keys that were generated using such an algorithm. This is not practical as it requires a level of audit that is unaffordable to most applicants. The other path would be restricting the key to one that was known to exist prior to any known attack
on the hash algorithm. This works under the assumption that a specially constructed key is required to carry out the attack. In this model a CA would only certify keys that existing prior to a date considered "safe".<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">To implement this last option, we can take advantage of Certificate Transparency and the internal audit systems maintained by CAs. The requirement becomes quite simple -- the only
SHA-1 certificates allowed to be issued are those that are simply time extensions of existing SHA-1 certificates. This can be technically implemented by requiring that the Subject, Subject Public Key Information, and Subject Alternative Name of the new certificate
exactly match that of a certificate issued prior to a given date. The changes then become primarily the notAfter date. The downside here is that customers cannot rotate their keys used with SHA-1 certificates, but this seems like a small tradeoff compared
to the risk of allowing a new key. This will make the work of an attacker massively harder; they have to not only find an existing key that works for a collision, they also must prove control of the subject and SANs already associated with that key. Some
details would need to be worked out, such as what other extensions must exist in a new SHA-1 certificate, must the CA also issue a "paired" SHA-26 certificate, when must CAs stop issuing the extension certificates, etc, but I think this is a good start.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Peter<o:p></o:p></p>
</div>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Mar 6, 2016, at 12:51 PM, Dean Coclin <<a href="mailto:Dean_Coclin@symantec.com" target="_blank">Dean_Coclin@symantec.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I’ve been asked by the payment processor ecosystem to explore some options for assisting with the SHA-1 issue. The
scope of this problem is quite large but there may be a few options for dealing with it which need vetting by this community. I’ll outline them below and <u>would appreciate some constructive feedback</u>:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">1. Issue and then immediately revoke a new SHA-1 certificate. </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">>>It turns out some payment terminals don’t check for revocation and this would fix a large percentage of them for
one North American company.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">2. Issue a cert with a poison critical extension</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">>>Some terminals may work with this but we won’t know until it can be tested. This requires issuing a new SHA-1 cert
with this extension. Browsers would see the extension and not allow this certificate to be used. </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">3. Issue a cert from a new, name constrained intermediate</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">>> Same as #2 from a testing perspective. Browsers could blacklist this intermediate.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">It would be interesting to get feedback from not only the community at large but specifically browsers to know what
to expect from a proposed ballot.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Thanks,</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Dean</span><o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">_______________________________________________<br>
Public mailing list<br>
</span><a href="mailto:Public@cabforum.org" target="_blank"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#954F72">Public@cabforum.org</span></a><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><br>
</span><a href="https://cabforum.org/mailman/listinfo/public" target="_blank"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#954F72">https://cabforum.org/mailman/listinfo/public</span></a><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>