<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:"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:11.0pt;
        font-family:"Calibri",sans-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.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.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>While in theory it should be ample time, experience has shown that certificate viewers evolve glacially.  And, as we discussed in London, there are good reasons for that.  The target audience is extremely small, and it doesn’t surprise me that improvements there often get deprioritized.  There are things that were added to the BRs many years ago that many certificate viewers still don’t understand.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I’m kind of torn on BIT STRING vs SEQUENCE.  There are strong arguments that can be made both ways.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>-Tim<o:p></o:p></p><p class=MsoNormal><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><b>From:</b> Ryan Sleevi <sleevi@google.com> <br><b>Sent:</b> Tuesday, August 14, 2018 1:19 PM<br><b>To:</b> Wayne Thayer <wthayer@mozilla.com><br><b>Cc:</b> Doug Beattie <doug.beattie@globalsign.com>; CA/Browser Forum Validation WG List <validation@cabforum.org>; Tim Hollebeek <tim.hollebeek@digicert.com><br><b>Subject:</b> Re: [cabf_validation] [EXTERNAL]Re: Ballot Proposal: Validation Method in certificatePolicies<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Wayne,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Could you expand on what you mean by "difficult to interpret when viewing the cert"?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>With an effective date so far back as to be July 1, 2019, that seems ample time to update certificate viewers as we do for other bitstring fields (e.g. CRL reasons or keyUsages) to display their semantic value - or even just their numerical bit position, which would have the same "viewer" effect as an integer.<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Tue, Aug 14, 2018 at 1:07 PM Wayne Thayer <<a href="mailto:wthayer@mozilla.com">wthayer@mozilla.com</a>> wrote:<o:p></o:p></p></div><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>Doug - thanks for the comments! Let's discuss this on Thursday's call.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I don't like the BIT STRING idea because it will be difficult to interpret when viewing the cert.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I'm open to changing the language to account for the current structure of 3.2.2.5, or perhaps it's just time to get the IP 'any other method' ballot cranked out.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I chose to start the IP numbering at 501 because the section number is 3.2.2.5. I'm happy to change that if it's not a helpful cue. We could also get creative and make it 322501.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I do intend to move the effective date to July 1, 2019 as we discussed on the last call.<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Tue, Aug 14, 2018 at 10:02 AM Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><p class=MsoNormal>I'm not sure why it would follow that there needs to be two BIT STRINGs vs one. You can use a single set for the validation methods - for example, bits 1 - 10 could be DNS validation methods, bit 11-15 could be IP, and then as we add a new validation method, a new bit is allocated - for example, bit 16 could be a new DNS method, bits 17 and 18 two new IP address methods, etc.<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>There's no need to semantically distinguish them, AFAICT<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Tue, Aug 14, 2018 at 12:52 PM Doug Beattie <<a href="mailto:doug.beattie@globalsign.com" target="_blank">doug.beattie@globalsign.com</a>> wrote:<o:p></o:p></p></div><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='color:#1F497D'>Ryan,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>If there are lots of examples for poor implementations of SET, then using sequence would certainly be preferred.  I was just commenting that since the order is irrelevant that SET might be better.  </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>Enforcement of using Bitstring is an interesting option, but it seems there are also pitfalls with that approach.  In addition, we’d need to encode 2 bitstrings, one for dNSName  and for iPAddress (which might actually be good).</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><a name="m_-8555149639561394065_m_-20065925981723"><span style='color:#1F497D'> </span></a><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>From:</b> Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>> <br><b>Sent:</b> Tuesday, August 14, 2018 10:37 AM<br><b>To:</b> Doug Beattie <<a href="mailto:doug.beattie@globalsign.com" target="_blank">doug.beattie@globalsign.com</a>>; CA/Browser Forum Validation WG List <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>><br><b>Cc:</b> Wayne Thayer <<a href="mailto:wthayer@mozilla.com" target="_blank">wthayer@mozilla.com</a>>; Tim Hollebeek <<a href="mailto:tim.hollebeek@digicert.com" target="_blank">tim.hollebeek@digicert.com</a>><br><b>Subject:</b> Re: [cabf_validation] [EXTERNAL]Re: Ballot Proposal: Validation Method in certificatePolicies<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'> <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Tue, Aug 14, 2018 at 7:29 AM Doug Beattie via Validation <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>Hi Wayne,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>I have a couple of comments/suggestions:</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>Did we agree to change the effective date to a bit later than April?</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>On the numbering scheme, certainly 500 is high enough that we won’t see a collision any time soon, but it might be easier to mentally map the IP address numbers if they started at 1000 (just a minor suggestion).   Also we’ll need to be sure we update IP address validation section before this ballot goes into effect – do we need to point out this dependency?</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>You used the construct Sequence vs. Set, so there is an implied meaning to the order of the integers, but I think they are randomly “sequenced”.  Maybe Set is better in this case unless we want them ordered for some reason?  It’s not a big deal because RFC 5280 uses sequence for things like EKU where the order isn’t important also.</span><o:p></o:p></p></div></div></blockquote><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'>We've seen CAs botch the SET ordering for DER badly in the past (example: equivalent subject AttributeValues), so it also seems less risk to order by SEQUENCE, which gives it nice predictability. I've certainly seen encoding libraries have troubles with SET OF vs SEQUENCE OF. I agree that semantically, we're not approaching special value to the ordering.<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><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>Neither Set nor Sequence precludes duplicate values, so the statement “..assert every distinct method” isn’t enforced via the ASN structure.  I don’t think there is an easy way (nor necessarily a strong requirement) to enforce this at the encoding level – just pointing it out in case someone has an idea or opinion about that.  However, this random article says that “the entries of a set usually are assumed to be unique, no two identical entries in a set, while a sequence may contain many identical entries”, which further suggests we should use set for our purposes.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'><a href="https://stackoverflow.com/questions/31442003/asn1-sequence-vs-set" target="_blank">https://stackoverflow.com/questions/31442003/asn1-sequence-vs-set</a></span><o:p></o:p></p></div></div></blockquote><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'm not really sure that supports the point you're making though. That's just talking about assumptions people make that aren't supported by the text (e.g. X.680 E.2.10 for SEQUENCE/SEQUENCE OF, E.2.11 for SET/SET OF)<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'>If the goal here is to guarantee that one-and-only-one instance appears, and to minimize the size, the alternative encoding is using a BITSTRING (c.f. X.680 E.2.5.3  Use a bit string type to model the values of a bit map, an ordered collection of logical variables indicating whether a particular condition holds for each of a correspondingly ordered collection of objects.). Note that if using a named bitlist, you have to make sure you're observing the DER rule (of no additional trailing zeroes), which is another thing some CA impls have botched, but seems... slightly better?<o:p></o:p></p></div></div></div></div></div></blockquote></div></blockquote></div></blockquote></div></div></div></body></html>