<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:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 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;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.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 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">I have specifically encountered non-browser use cases where the 64 character limit caused it to be difficult or impossible to uniquely or accurately identify
the subject or organization, because there were values that were longer than 64 characters. So this isn’t a theoretical problem.<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">It would be a good thing to bring up once we have a forum for non-browser use cases.<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">-Tim<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>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> public-bounces@cabforum.org [mailto:public-bounces@cabforum.org]
<b>On Behalf Of </b>Jeremy Rowley<br>
<b>Sent:</b> Wednesday, February 24, 2016 2:17 PM<br>
<b>To:</b> Ryan Sleevi<br>
<b>Cc:</b> CABFPub<br>
<b>Subject:</b> Re: [cabfpub] RFC5280<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks Ryan. I wouldn’t say these are proposals. Mostly questions about why things are set the way they are. I figured it’d be faster to ask here than do a
lot of digging.<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">#1 - Since we are only talking about browsers in the CAB Forum (as the browsers have made absolutely clear many times), does the forum care if it breaks non-browser
software? Seems irrelevant at the current CAB Forum level.<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">#2 – There’s a lot of CAs still using keyAgreement. Would you like to see the CAB forum officially deprecate it?</span></a><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">#3 – I haven’t looked at notBefore dates to see whether all CAs have moved to a true 2048-bit cert, but there are definitely still 2047-bit certs out there.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">#4 – I don’t have strong opinions on teletext, but would really prefer UTF8 over printableString for international support.
<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"><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 [<a href="mailto:sleevi@google.com">mailto:sleevi@google.com</a>]
<br>
<b>Sent:</b> Wednesday, February 24, 2016 12:08 PM<br>
<b>To:</b> Jeremy Rowley<br>
<b>Cc:</b> CABFPub<br>
<b>Subject:</b> Re: [cabfpub] RFC5280<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p><br>
On Feb 24, 2016 10:56 AM, "Jeremy Rowley" <<a href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>> wrote:<br>
><br>
> I’ve been playing around with Peter Bowen’s certlint (an excellent tool) and, looking at the cert universe as a whole, there are some noticeable issues with the BRs and RFC 5280 that I though merited a public CAB Forum discussion. Some of this is likely
me not knowing the entire history of 5280, so I appreciated any explanation. If there’s exceptions we would like to make to RFC5280, we should probably also push a bis with IETF at the same time.<br>
><br>
> <br>
><br>
> Here’s what I’m noticing are common issues:<br>
><br>
> 1) Org names, common names, and address fields are limited to 64 characters. Very few international companies can comply with this restriction. It’s even worse if you are converting an IDN to a printable string. I don’t think any browsers limit this
to 64 characters? Is there a strong objection to permitting longer strings in these fields?<o:p></o:p></p>
<p>Yes. Plenty of tools rely on the schema as defined by 5280 - and as such, ignoring it causes real compatibility issues.<o:p></o:p></p>
<p>> 2) keyAgreement isn’t specifically prohibited in the BRs or 5280. However, keyAgreement should no longer be used in ECC certs because of security issues as explained by Ryan Sleevi in previous emails . We should update the BRs to prohibit keyAgreement.<br>
><br>
> 3) Years ago, we discussed that 2047 bit certs were equivalent to 2048 bit certs (although the discussion may have occurred solely on the Mozilla mailing list). We should codify this exception.<o:p></o:p></p>
<p>IMO, this is a giant hack that browsers did because CAs have trouble counting (see also: serial numbers), which itself is a statement that the underlying libraries played a very liberal definition.<o:p></o:p></p>
<p>I would prefer not.<o:p></o:p></p>
<p>><br>
> 4) Why is teletext string not permissible on a lot of these fields? I also don’t understand the weird requirement to use printablestring over UTRF8 for some fields. Specifically, requiring a printable string for subject:serialNumber could cause issues
with the EV Guidelines if a country uses an IDN as part of their registration number. <o:p></o:p></p>
<p>TeletexString is the worst string - good luck trying to find a single parser that properly understands it, or a single version of the spec that is unambiguous.<o:p></o:p></p>
<p>It would be different if you are talking UTF-8 string, but certainly any new appearances of TeletexString should be forbidden.<o:p></o:p></p>
<p>We have zero desire to support this string, and if CAs followed RFC5280, that would not really be an issue.<o:p></o:p></p>
<p>Overall, your proposals 1/4 will explicitly fragment the market and the specs - and that's something that should not be supported or encouraged. 2 is basic operational sanity, and 3 is one of those gross things that would ideally be deprecated rather than
codified.<o:p></o:p></p>
</div>
<br>
<hr>
<font face="Arial" color="Gray" size="1"><br>
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information
contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.<br>
</font>
</body>
</html>