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

[Ryan Sleevi]

Correct.

The ID is 13, which the following don't support: OpenSSL
<https://github.com/openssl/openssl/blob/master/include/openssl/asn1.h>,
BoringSSL
<https://boringssl.googlesource.com/boringssl/+/master/include/openssl/bytestring.h#143>,
LibreSSL
<https://github.com/libressl/libressl/blob/ba04546060b835e279c0e8a26261e73a1964927c/src/crypto/asn1/asn1.h#L96>,
NSS <https://dxr.mozilla.org/nss/source/nss/lib/util/quickder.c#728>, Apache
Harmony
<https://harmony.apache.org/subcomponents/classlibrary/asn1_framework.html#ASN1Oid>,
Microsoft Windows
<https://docs.microsoft.com/en-us/windows/desktop/SecCrypto/constants-for-cryptencodeobject-and-cryptdecodeobject>,
and perhaps most importantly for a number of members, EJBCA
<https://www.ejbca.org/docs/Custom_Certificate_Extensions.html> and
BouncyCastle
<https://github.com/bcgit/bc-java/blob/master/core/src/main/java/org/bouncycastle/asn1/ASN1InputStream.java#L424>
.

As I said, it's not well-supported. For generating or parsing.

On Tue, Aug 7, 2018 at 7:15 PM Wayne Thayer <wthayer at mozilla.com> wrote:

> 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/bc1c35ad/attachment-0001.html>