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

[Ryan Sleevi]

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/36e44baf/attachment.html>