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

Tue Aug 14 04:29:04 MST 2018

Hi Wayne,

I have a couple of comments/suggestions:

Did we agree to change the effective date to a bit later than April?

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?

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.

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.

https://stackoverflow.com/questions/31442003/asn1-sequence-vs-set

Doug

From: Validation <validation-bounces at cabforum.org> On Behalf Of Wayne Thayer via Validation
Sent: Monday, August 13, 2018 7:06 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com>
Cc: CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: Re: [cabf_validation] [EXTERNAL]Re: Ballot Proposal: Validation Method in certificatePolicies

Here's an updated proposal using numbers instead of OIDs to represent the validation methods:

https://github.com/cabforum/documents/compare/master...wthayer:Ballot226#diff-7f6d14a20e7f3beb696b45e1bf8196f2

Please review and comment.

- Wayne

On Fri, Aug 10, 2018 at 8:10 PM Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> > wrote:

I think this might be the best of both worlds, and I thank Wayne for proposing it.

-Tim

From: Wayne Thayer <wthayer at mozilla.com <mailto:wthayer at mozilla.com> > 
Sent: Thursday, August 9, 2018 1:54 PM
To: Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> >; CA/Browser Forum Validation WG List <validation at cabforum.org <mailto:validation at cabforum.org> >
Cc: Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> >
Subject: Re: [cabf_validation] [EXTERNAL]Re: Ballot Proposal: Validation Method in certificatePolicies

Redirecting this discussion back to my proposal...

I understand Tim's position to be that CAs should have the choice of encoding this data as relative OIDs, even if it is difficult for the CA to do that and causes all sorts of compatibility issues in client software. For certificate consumers that value size above all else, the benefits may outweigh the risks.

I think this approach builds a footgun into the BRs because the odds are high that some CAs will get it wrong (encode relative OID as OID --> misissuance) and some clients will fail to parse data that is properly encoded as a relative OID.

What are the objections to encoding the validation method number(s) as a sequence of integers? This at least results in a smaller certificate that is unlikely to cause compatibility problems. I would, of course, propose a mechanism for expressing IP Address validation methods uniquely.

On Thu, Aug 9, 2018 at 11:10 AM Ryan Sleevi via Validation <validation at cabforum.org <mailto:validation at cabforum.org> > wrote:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180814/87911eaa/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5736 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20180814/87911eaa/attachment-0001.p7s>