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

[Ryan Sleevi]

Just checking if I understand:

Are you suggesting folding the document into a single section (that is,
combining 3.2.2.4 and 3.2.2.5)? Could you explain what the concerns would
be for the alternative solution, which is just, within each section, e.g.
3.2.2.4.1

This ID of this validation method is 1.

That is, I'd like to try to understand a bit more the desire for a need for
a separate mapping table, and how the existence or absence of alignment
between the document and the identifiers helps or hinders the use cases you
envisage for this.

On Wed, Aug 15, 2018 at 12:34 PM Wayne Thayer <wthayer at mozilla.com> wrote:

> To make the BIT STRING encoding work in a single extension, we should
> discuss how best to collapse domain and IP address validation methods into
> a single "namespace". It might be best to add explicit and unique numbering
> to all the domain + IP address methods as part of the ballot to remove the
> IP address "any other method". I'd like to avoid the need for a separate
> mapping table (e.g. bit position 17 signifies method 3.2.2.5.3).
>
> On Wed, Aug 15, 2018 at 9:22 AM Tim Hollebeek via Validation <
> validation at cabforum.org> wrote:
>
>> Yeah, lots of people are going to make the same mistake I did if Method 6
>> is represented by bit 5 (not 6!  I like my bit numbers to be zero based, so
>> you can just do the power thing).  Off by one errors are so much fun …
>>
>>
>>
>> But again, I don’t think it’s a huge problem.  Only technical people are
>> staring at this stuff, and they’ll quickly learn which values correspond to
>> which methods.
>>
>>
>>
>> -Tim
>>
>>
>>
>> *From:* Ryan Sleevi <sleevi at google.com>
>> *Sent:* Wednesday, August 15, 2018 11:32 AM
>> *To:* Tim Hollebeek <tim.hollebeek at digicert.com>
>> *Cc:* Doug Beattie <doug.beattie at globalsign.com>; Daymion T. Reynolds <
>> dreynolds at godaddy.com>; CA/Browser Forum Validation WG List <
>> validation at cabforum.org>
>> *Subject:* Re: [cabf_validation] [EXTERNAL]Re: Ballot Proposal:
>> Validation Method in certificatePolicies
>>
>>
>>
>>
>>
>> On Wed, Aug 15, 2018 at 9:24 AM Tim Hollebeek <tim.hollebeek at digicert.com>
>> wrote:
>>
>> Given that the number of 1 bits is likely low, I don’t think BIT STRING
>> is that hard to read.  It just means that you’re going to have to memorize
>> that Method 6 is “64” instead of 6.  It’s slightly tougher, but if you’re
>> the sort of person who is capable of staring at raw ASN.1, I think you can
>> cope.
>>
>>
>>
>> I'm not sure I understand your point about knowing that "Method 6 is 64".
>>
>>
>>
>> Method 6 is Bit 6.
>>
>> Method 7 is Bit 7.
>>
>> Method 139 is Bit 139.
>>
>>
>>
>> A certificate viewer that does not dive into constructed extensions would
>> display the extension as its full hex (e.g. with the outer Tag and Length
>> octets).
>>
>> A certificate viewer that does dive into constructed extensions would
>> display the inner value, typically in either base2 or base16 notation. In
>> Base2 notation, it's 'easy' to count which bits are set. In Base16
>> notation, you can easily convert to Base2.
>>
>> A certificate viewer that explicitly knows about this extension can:
>>
>>   - Used named values for methods it recognizes - e.g. as a lookup table,
>> same as OIDs)
>>
>>   - Alternatively, note the integer position itself for which bit was set
>> - e.g. bit 1 = method 1, bit 2 = method 2 etc. - and display that as such
>>
>>
>>
>> But regardless, you shouldn't expect to see "Method 6 is 64". You'd
>> expect 32, at best, but more realistically, 0x20. :)
>>
>>
>> _______________________________________________
>> 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/20180815/86ca1c74/attachment.html>