<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.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle18
{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 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'>“</span>I used RFCs 5280, 6818, 3279, 5480, and 5758. Several of these specify what key usages are acceptable with which public key types. Are you suggesting that the other PKIX RFCs are not what CAs should be following?”<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>No – I’m saying 5280 is the only one included in the BRs specifically. The auditors are working on audit criteria for 5280 compliance. There won’t be the same audit criteria for 6818, 3279, 5480, and 5758. The question is whether we codify certain policies from these RFCS, although adoption of the RFC as a BR requirement could work as well (as it will then add the RFC to the audit framework).<o:p></o:p></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><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'> Peter Bowen [mailto:pzb@amzn.com] <br><b>Sent:</b> Wednesday, February 24, 2016 12:22 PM<br><b>To:</b> Jeremy Rowley<br><b>Cc:</b> public@cabforum.org<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><o:p> </o:p></p><div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal>On Feb 24, 2016, at 10:56 AM, Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>> wrote:<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>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.<span class=apple-converted-space> </span><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Here’s what I’m noticing are common issues:<o:p></o:p></span></p></div><div style='margin-left:.5in'><p class=MsoNormal style='text-indent:-.25in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>1)</span><span style='font-size:7.0pt'> <span class=apple-converted-space> </span></span><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>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></span></p></div><div style='margin-left:.5in'><p class=MsoNormal style='text-indent:-.25in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>2)</span><span style='font-size:7.0pt'> <span class=apple-converted-space> </span></span><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>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.<o:p></o:p></span></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I used RFCs 5280, 6818, 3279, 5480, and 5758. Several of these specify what key usages are acceptable with which public key types. Are you suggesting that the other PKIX RFCs are not what CAs should be following?<o:p></o:p></p></div><p class=MsoNormal><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div style='margin-left:.5in'><p class=MsoNormal style='text-indent:-.25in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>3)</span><span style='font-size:7.0pt'> <span class=apple-converted-space> </span></span><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>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.<span class=apple-converted-space> </span><o:p></o:p></span></p></div><div style='margin-left:.5in'><p class=MsoNormal style='text-indent:-.25in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>4)</span><span style='font-size:7.0pt'> <span class=apple-converted-space> </span></span><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>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></span></p></div></blockquote><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>TeletexString (along with its friends VideotexString, GraphicString, and GeneralString) are almost impossible to get right. They all allow ISO/IEC 2022 escape sequences and require escape sequences to use characters outside the default character. TeletexString specifically defines the default graphics (G0) character set as T.61-7bit (102) rather than ASCII (6), which leads to interesting surprises. For example {, }, and ^ are not allowed.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Thanks,<o:p></o:p></p></div><div><p class=MsoNormal>Peter<o:p></o:p></p></div></div></body></html>