<div dir="ltr">Tim,<div><br></div><div>It's not just browsers that are affected. I would hope you are concerned about the wide variety of consuming products, which, to date, have not needed to implement relative OIDs, and which, as a distinct universal tag, can and will and do treat such certificates as invalid.</div><div><br></div><div>It might help if you could articulate, concretely, the benefits of relative OIDs, given the risk you're asking CAs to accept with having their certificates not respected by a large body of existing software - of which browsers are but one part.</div><div><br></div><div>When you say "waste bytes", it's equally useful if you indicate the context. Are you concerned about TLS handshakes? Something else? By my math, the difference we're speaking of would be approximately 26 bytes uncompressed. However, the IETF is actively working on certificate compression ( <a href="https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/">https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/</a> ), and that may practically amortize to two bytes.</div><div><br></div><div>Are two bytes worth the compatibility risk? Why?</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 7, 2018 at 1:57 PM Tim Hollebeek <<a href="mailto:tim.hollebeek@digicert.com">tim.hollebeek@digicert.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-4114599688738690387WordSection1"><p class="MsoNormal">Then browsers should fix their code.  I thought the benefit of rapid update cycles for browsers was we didn’t have to have workarounds for dodgy browser code?  There should be plenty of time to make sure relative OIDs work correctly before the compliance deadline next year.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">It doesn’t make sense to me to waste a few bytes in certificates just because browsers have ignored or badly implemented relative OIDs.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">-Tim<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></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> Wayne Thayer <<a href="mailto:wthayer@mozilla.com" target="_blank">wthayer@mozilla.com</a>> <br><b>Sent:</b> Tuesday, August 7, 2018 12:02 PM<br><b>To:</b> Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>><br><b>Cc:</b> Tim Hollebeek <<a href="mailto:tim.hollebeek@digicert.com" target="_blank">tim.hollebeek@digicert.com</a>>; CA/Browser Forum Validation WG List <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>><br><b>Subject:</b> Re: [cabf_validation] [EXTERNAL]Re: Ballot Proposal: Validation Method in certificatePolicies<u></u><u></u></p></div></div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">I believe Ryan is stating that - even if we do require the relative form - it could cause compatibility issues with clients. The ASN.1 encoding of relative OIDs is a unique an apparently poorly supported type - even NSS doesn't recognize it. So either allowing or requiring the use of relative OIDs is risky and probably not worth the bytes saved.<u></u><u></u></p></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">On Tue, Aug 7, 2018 at 8:54 AM Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>> wrote:<u></u><u></u></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 I understand your reply.<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">The complexity I mention is precisely because of requiring the relative OID. I'm afraid you may have taken the opposite meaning of my message.<u></u><u></u></p></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">On Tue, Aug 7, 2018 at 11:34 AM Tim Hollebeek <<a href="mailto:tim.hollebeek@digicert.com" target="_blank">tim.hollebeek@digicert.com</a>> wrote:<u></u><u></u></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">I agree with Wayne, I think it might make sense to just require the use of the relative OID, to avoid the complexity you mention.<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">-Tim<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></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 <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>> <br><b>Sent:</b> Monday, August 6, 2018 11:05 AM<br><b>To:</b> Wayne Thayer <<a href="mailto:wthayer@mozilla.com" target="_blank">wthayer@mozilla.com</a>>; CA/Browser Forum Validation WG List <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>><br><b>Cc:</b> 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<u></u><u></u></p></div></div><p class="MsoNormal"> <u></u><u></u></p><div><p class="MsoNormal">It would be clearer, and easier, to use the absolute form. The relative form is a nightmare to deal with in client software - because it's not used in any widely used X.509 extension (AFAICT). Certainly, NSS does not support decoding that type <u></u><u></u></p><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">Further, in ASN.1, "RELATIVE OID" is a distinct type and tag than OBJECT IDENTIFIER (0x06 vs 0x0D). Thus the proposed language "MAY" requires a separate ASN.1 syntax (such as a CHOICE OF) to support the optionality, and will require updates to client software to support. This may be easier with implicit tagging rather than explicit, to avoid parsing issues on the unhandled relative OIDs, but... it's better to just not bother with it.<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><div><div><p class="MsoNormal">On Fri, Aug 3, 2018 at 2:42 PM Wayne Thayer via Validation <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>> wrote:<u></u><u></u></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><p class="MsoNormal">On Fri, Aug 3, 2018 at 11:30 AM Tim Hollebeek <<a href="mailto:tim.hollebeek@digicert.com" target="_blank">tim.hollebeek@digicert.com</a>> wrote:<u></u><u></u></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">I’ll endorse.<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p></div></div></blockquote><div><p class="MsoNormal">> <u></u><u></u></p></div><div><p class="MsoNormal">Thanks. Anyone else?<u></u><u></u></p></div><div><p class="MsoNormal">> <u></u><u></u></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">I think you just want:<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal" style="margin-bottom:12.0pt">BRValidationMethodSyntax ::= SEQUENCE SIZE (1..MAX) OF DomainOrIpAddressValidationMethodId<br><br>DomainOrIpAddressValidationMethodId ::= OBJECT IDENTIFIER<u></u><u></u></p><p class="MsoNormal">I think there’s a way to express the concept that DomainOrIpAddressValidationMethodId MUST be a child of { 2.23.140.1.11 } via ASN.1 constraints, but I can’t do it.  It might be better anyway just to be handle that constraint outside of the ASN.1.<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">The ballot should make explicit that relative OIDs are allowed in addition to absolute OIDs, and if relative forms of OIDs are used, the forms MUST be relative to the prefix { 2.23.140.1.2 }.  That’ll make the encoding much smaller.<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">So maybe something like:<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal" style="margin-bottom:12.0pt">“BRValidationMethodSyntax ::= SEQUENCE SIZE (1..MAX) OF DomainOrIpAddressValidationMethodId<br><br>DomainOrIpAddressValidationMethodId ::= OBJECT IDENTIFIER<u></u><u></u></p><p class="MsoNormal">DomainOrIpAddressValidationMethodId OIDs MUST be a child of 2.23.140.1.2.4 or 2.23.140.1.2.5, and MAY appear in relative form, relative to 2.23.140.1.2.”<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p></div></div></blockquote><div><p class="MsoNormal">> <u></u><u></u></p></div><div><p class="MsoNormal">Would it be better to just require the use of relative form? I think so.<u></u><u></u></p></div><div><p class="MsoNormal">> <u></u><u></u></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">-Tim<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></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> Validation <<a href="mailto:validation-bounces@cabforum.org" target="_blank">validation-bounces@cabforum.org</a>> <b>On Behalf Of </b>Wayne Thayer via Validation<br><b>Sent:</b> Thursday, August 2, 2018 8:05 PM<br><b>To:</b> CA/Browser Forum Validation WG List <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>><br><b>Subject:</b> Re: [cabf_validation] [EXTERNAL]Re: Ballot Proposal: Validation Method in certificatePolicies<u></u><u></u></p></div></div><p class="MsoNormal"> <u></u><u></u></p><div><div><p class="MsoNormal">I've addressed all the feedback that I have received in the version of the ballot below and at [1].<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">I'm a complete rookie at ABNF and I've almost certainly botched the syntax. Can someone help me get the encoding right?<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">I'm also looking for two endorsers, and of course, any additional feedback.<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">- Wayne<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">==========================================================<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><div><p class="MsoNormal">Ballot SC#: Validation Method Encoded in Certificates<br> <br>Purpose of Ballot: The methods defined in BR section 3.2.2.4 and 3.2.2.5 to confirm control or ownership of each domain name or IP address placed in a TLS certificate have varying security properties. This ballot proposes a standard format for expressing the method(s) the CA used to validate domain control or ownership of the Authorization Domain Name(s) placed in a certificate, and requires conforming CAs to include this information in certificates issued on or after July 1, 2019. This information is useful for quantification and analysis when vulnerabilities in specific methods are identified, and disclosing it will benefit the PKI ecosystem. As specified, this information is not useful or intended for making trust decisions in user agents.<br> <br>The following motion has been proposed by Wayne Thayer of Mozilla and endorsed by XXX of YYY and XXX of YYY.<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">— MOTION BEGINS –<br>This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” as follows, based upon Version 1.5.7:<br><br>Add the following definitions to section 1.2:<br><br>{joint‐iso‐itu‐t(2) international‐organizations(23) ca‐browser‐forum(140) certificate‐policies(1) baseline‐ requirements(2) domain-validation-methods(4)} (2.23.140.1.2.4). <br>{joint‐iso‐itu‐t(2) international‐organizations(23) ca‐browser‐forum(140) certificate‐policies(1) baseline‐ requirements(2) IP-address-validation-methods(5)} (2.23.140.1.2.5). <br><br>Add section 7.1.2.3(g), as follows:<br><br>This extension MUST be present and SHOULD NOT be marked critical.<span style="font-family:"Tahoma",sans-serif">
</span>g.   cabf-BRValidationMethod (2.23.140.1.11) (required on or after April 1, 2019)<br><br>This extension contains a list of one or more OIDs that assert every distinct method performed by the CA to validate domain control or ownership of each FQDN contained in the certificate's subjectAlternativeName. If an FQDN has been validated using multiple methods, the CA MAY assert more than one of the methods. This extension SHOULD NOT be marked critical.<br><br>These OIDs representing validation methods SHALL be defined as follows:<br>    * 2.23.140.1.2.4. concatenated with the subsection number of section 3.2.2.4 corresponding to the domain validation method that was used to validate one or more subjectAlternativeNames in this certificate (e.g. 2.23.140.1.2.4.2'); or,<br>    <br>    * 2.23.140.1.2.5 concatenated with the subsection number of section 3.2.2.5 corresponding to the IP address validation method that was used to validate one or more subjectAlternativeNames in the certificate (e.g. '2.23.140.1.2.5.1').<br><br>OIDs representing validation methods MUST be encoded in this extension as follows:<br><br>cabf-BRValidationMethod OBJECT IDENTIFIER ::= { 2.23.140.1.11 }<br><br>BRValidationMethodSyntax ::= SEQUENCE SIZE (1..MAX) OF DomainOrIpAddressValidationMethodId<br><br>DomainOrIpAddressValidationMethodId ::= OBJECT IDENTIFIER<br><br><br>— MOTION ENDS –<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">[1] <a href="https://github.com/cabforum/documents/compare/master...wthayer:Ballot226#diff-7f6d14a20e7f3beb696b45e1bf8196f2" target="_blank">https://github.com/cabforum/documents/compare/master...wthayer:Ballot226#diff-7f6d14a20e7f3beb696b45e1bf8196f2</a><u></u><u></u></p></div></div><p class="MsoNormal"> <u></u><u></u></p></div></div></div></div></blockquote></div></div><p class="MsoNormal">_______________________________________________<br>Validation mailing list<br><a href="mailto:Validation@cabforum.org" target="_blank">Validation@cabforum.org</a><br><a href="https://cabforum.org/mailman/listinfo/validation" target="_blank">https://cabforum.org/mailman/listinfo/validation</a><u></u><u></u></p></blockquote></div></div></div></div></div></div></blockquote></div></div></blockquote></div></div></div></div></blockquote></div>