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

[Ryan Sleevi]

I'm not sure why it would follow that there needs to be two BIT STRINGs vs
one. You can use a single set for the validation methods - for example,
bits 1 - 10 could be DNS validation methods, bit 11-15 could be IP, and
then as we add a new validation method, a new bit is allocated - for
example, bit 16 could be a new DNS method, bits 17 and 18 two new IP
address methods, etc.

There's no need to semantically distinguish them, AFAICT

On Tue, Aug 14, 2018 at 12:52 PM Doug Beattie <doug.beattie at globalsign.com>
wrote:

> Ryan,
>
>
>
> If there are lots of examples for poor implementations of SET, then using
> sequence would certainly be preferred.  I was just commenting that since
> the order is irrelevant that SET might be better.
>
>
>
> Enforcement of using Bitstring is an interesting option, but it seems
> there are also pitfalls with that approach.  In addition, we’d need to
> encode 2 bitstrings, one for dNSName  and for iPAddress (which might
> actually be good).
>
>
>
>
>
>
>
> *From:* Ryan Sleevi <sleevi at google.com>
> *Sent:* Tuesday, August 14, 2018 10:37 AM
> *To:* Doug Beattie <doug.beattie at globalsign.com>; CA/Browser Forum
> Validation WG List <validation at cabforum.org>
> *Cc:* Wayne Thayer <wthayer at mozilla.com>; Tim Hollebeek <
> tim.hollebeek at digicert.com>
> *Subject:* Re: [cabf_validation] [EXTERNAL]Re: Ballot Proposal:
> Validation Method in certificatePolicies
>
>
>
>
>
> On Tue, Aug 14, 2018 at 7:29 AM Doug Beattie via Validation <
> validation at cabforum.org> wrote:
>
> 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.
>
>
>
> We've seen CAs botch the SET ordering for DER badly in the past (example:
> equivalent subject AttributeValues), so it also seems less risk to order by
> SEQUENCE, which gives it nice predictability. I've certainly seen encoding
> libraries have troubles with SET OF vs SEQUENCE OF. I agree that
> semantically, we're not approaching special value to the ordering.
>
>
>
> 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
>
>
>
> I'm not really sure that supports the point you're making though. That's
> just talking about assumptions people make that aren't supported by the
> text (e.g. X.680 E.2.10 for SEQUENCE/SEQUENCE OF, E.2.11 for SET/SET OF)
>
>
>
> If the goal here is to guarantee that one-and-only-one instance appears,
> and to minimize the size, the alternative encoding is using a BITSTRING
> (c.f. X.680 E.2.5.3  Use a bit string type to model the values of a bit
> map, an ordered collection of logical variables indicating whether a
> particular condition holds for each of a correspondingly ordered collection
> of objects.). Note that if using a named bitlist, you have to make sure
> you're observing the DER rule (of no additional trailing zeroes), which is
> another thing some CA impls have botched, but seems... slightly better?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180814/2dd50c9e/attachment-0001.html>