[cabf_validation] [EXTERNAL]Re: Ballot Proposal: Validation Method in certificatePolicies

Tue Aug 7 16:15:16 MST 2018

I tried to create a test certificate containing a relative OID using
OpenSSL. As best I can tell it's not possible - that ASN.1 type isn't even
defined:

https://github.com/openssl/openssl/blob/master/include/openssl/asn1.h

On Tue, Aug 7, 2018 at 11:02 AM Ryan Sleevi <sleevi at google.com> wrote:

> Tim,
>
> 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.
>
> 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.
>
> 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 (
> https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/
> ), and that may practically amortize to two bytes.
>
> Are two bytes worth the compatibility risk? Why?
>
> On Tue, Aug 7, 2018 at 1:57 PM Tim Hollebeek <tim.hollebeek at digicert.com>
> wrote:
>
>> 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.
>>
>>
>>
>> It doesn’t make sense to me to waste a few bytes in certificates just
>> because browsers have ignored or badly implemented relative OIDs.
>>
>>
>>
>> -Tim
>>
>>
>>
>> *From:* Wayne Thayer <wthayer at mozilla.com>
>> *Sent:* Tuesday, August 7, 2018 12:02 PM
>> *To:* Ryan Sleevi <sleevi at google.com>
>> *Cc:* Tim Hollebeek <tim.hollebeek at digicert.com>; CA/Browser Forum
>> Validation WG List <validation at cabforum.org>
>> *Subject:* Re: [cabf_validation] [EXTERNAL]Re: Ballot Proposal:
>> Validation Method in certificatePolicies
>>
>>
>>
>> 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.
>>
>>
>>
>> On Tue, Aug 7, 2018 at 8:54 AM Ryan Sleevi <sleevi at google.com> wrote:
>>
>> I'm not sure I understand your reply.
>>
>>
>>
>> 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.
>>
>>
>>
>> On Tue, Aug 7, 2018 at 11:34 AM Tim Hollebeek <tim.hollebeek at digicert.com>
>> wrote:
>>
>> 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.
>>
>>
>>
>> -Tim
>>
>>
>>
>> *From:* Ryan Sleevi <sleevi at google.com>
>> *Sent:* Monday, August 6, 2018 11:05 AM
>> *To:* Wayne Thayer <wthayer at mozilla.com>; CA/Browser Forum Validation WG
>> List <validation at cabforum.org>
>> *Cc:* Tim Hollebeek <tim.hollebeek at digicert.com>
>> *Subject:* Re: [cabf_validation] [EXTERNAL]Re: Ballot Proposal:
>> Validation Method in certificatePolicies
>>
>>
>>
>> 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
>>
>>
>>
>> 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.
>>
>>
>>
>> On Fri, Aug 3, 2018 at 2:42 PM Wayne Thayer via Validation <
>> validation at cabforum.org> wrote:
>>
>> On Fri, Aug 3, 2018 at 11:30 AM Tim Hollebeek <tim.hollebeek at digicert.com>
>> wrote:
>>
>> I’ll endorse.
>>
>>
>>
>> >
>>
>> Thanks. Anyone else?
>>
>> >
>>
>> I think you just want:
>>
>>
>>
>> BRValidationMethodSyntax ::= SEQUENCE SIZE (1..MAX) OF
>> DomainOrIpAddressValidationMethodId
>>
>> DomainOrIpAddressValidationMethodId ::= OBJECT IDENTIFIER
>>
>> 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.
>>
>>
>>
>> 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.
>>
>>
>>
>> So maybe something like:
>>
>>
>>
>> “BRValidationMethodSyntax ::= SEQUENCE SIZE (1..MAX) OF
>> DomainOrIpAddressValidationMethodId
>>
>> DomainOrIpAddressValidationMethodId ::= OBJECT IDENTIFIER
>>
>> 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.”
>>
>>
>>
>> >
>>
>> Would it be better to just require the use of relative form? I think so.
>>
>> >
>>
>> -Tim
>>
>>
>>
>> *From:* Validation <validation-bounces at cabforum.org> *On Behalf Of *Wayne
>> Thayer via Validation
>> *Sent:* Thursday, August 2, 2018 8:05 PM
>> *To:* CA/Browser Forum Validation WG List <validation at cabforum.org>
>> *Subject:* Re: [cabf_validation] [EXTERNAL]Re: Ballot Proposal:
>> Validation Method in certificatePolicies
>>
>>
>>
>> I've addressed all the feedback that I have received in the version of
>> the ballot below and at [1].
>>
>>
>>
>> I'm a complete rookie at ABNF and I've almost certainly botched the
>> syntax. Can someone help me get the encoding right?
>>
>>
>>
>> I'm also looking for two endorsers, and of course, any additional
>> feedback.
>>
>>
>>
>> - Wayne
>>
>>
>>
>> ==========================================================
>>
>>
>>
>> Ballot SC#: Validation Method Encoded in Certificates
>>
>> 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.
>>
>> The following motion has been proposed by Wayne Thayer of Mozilla and
>> endorsed by XXX of YYY and XXX of YYY.
>>
>>
>>
>> — MOTION BEGINS –
>> This ballot modifies the “Baseline Requirements for the Issuance and
>> Management of Publicly-Trusted Certificates” as follows, based upon Version
>> 1.5.7:
>>
>> Add the following definitions to section 1.2:
>>
>> {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).
>> {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).
>>
>> Add section 7.1.2.3(g), as follows:
>>
>> This extension MUST be present and SHOULD NOT be marked critical. g.
>> cabf-BRValidationMethod (2.23.140.1.11) (required on or after April 1, 2019)
>>
>> 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.
>>
>> These OIDs representing validation methods SHALL be defined as follows:
>>     * 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,
>>
>>     * 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').
>>
>> OIDs representing validation methods MUST be encoded in this extension as
>> follows:
>>
>> cabf-BRValidationMethod OBJECT IDENTIFIER ::= { 2.23.140.1.11 }
>>
>> BRValidationMethodSyntax ::= SEQUENCE SIZE (1..MAX) OF
>> DomainOrIpAddressValidationMethodId
>>
>> DomainOrIpAddressValidationMethodId ::= OBJECT IDENTIFIER
>>
>>
>> — MOTION ENDS –
>>
>>
>>
>> [1]
>> https://github.com/cabforum/documents/compare/master...wthayer:Ballot226#diff-7f6d14a20e7f3beb696b45e1bf8196f2
>>
>>
>>
>> _______________________________________________
>> Validation mailing list
>> Validation at cabforum.org
>> https://cabforum.org/mailman/listinfo/validation
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180807/69e9eab6/attachment-0001.html>