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

Wed Aug 15 06:24:16 MST 2018

Multiple conflicting concerns is an inherent part of any forum like this.  Thanks for the detailed, objective analysis.  It helps.  I would have expected a sequence of one item to be shorter.

Your point about the fact that the certificate display is going to be rather opaque regardless of which representation we choose is the same point I was trying to make.  I think we should expect that most certificate viewers won’t make much effort to display this information in a pretty format, and it’ll (hopefully, at least) show up as raw ASN.1 or similar.

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 think my preference is for the most efficient representation, which as Ryan shows, for reasonable assumptions, is actually BIT STRING.

-Tim

From: Ryan Sleevi <sleevi at google.com> 
Sent: Tuesday, August 14, 2018 5:04 PM
To: Doug Beattie <doug.beattie at globalsign.com>
Cc: Daymion T. Reynolds <dreynolds at godaddy.com>; CA/Browser Forum Validation WG List <validation at cabforum.org>; 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 4:30 PM Doug Beattie <doug.beattie at globalsign.com <mailto:doug.beattie at globalsign.com> > wrote:

If we take the bigstring approach, we going to need to maintain a mapping table in the BRs that maps the bit position to the domain validation method.  The use of Set and Sequence don’t require this as the value is the section number. 

I'm not sure how that's different. We'd indicate an INTEGER value for any of these methods - and the only distinction is whether that indicates a bit position or a semantic integer.

Also, since most certificates will have one domain validation method (3 bytes for tag, length and value), using Bit string will generally have a longer encoding with: type, length, value  where the value will be one byte for each 7(?) Validation Methods.  This includes all current and all past validation methods, so this will grow over time.

I'm really not sure how this is correct?

No matter the approach - SET, SEQUENCE, or BIT STRING, we're going to minimally need a Tag and Length for the outer coding - that's two bytes.

SET and SEQUENCE are going to be the same - three bytes per method after that (because the INTEGER still needs to be encoded as Tag, Length, and Value)

The BIT STRING will occupy 1 byte (for the number of unused bits), followed by a minimal encoding of the method.

Now let's compare the point of equilibrium, which both you and Tim have raised, but without showing the math.

For a certificate that is only validated with a single method:

- The minimal encoding with both SET or SEQUENCE is going to be five bytes - Tag (SEQUENCE/SET - one byte), Length (one byte), Tag (INTEGER - one byte), Length (one byte), value (one byte for the first 256 methods)

- The initial minimal encoding for a BIT STRING is going to be four bytes - Tag (BIT STRING - one byte), Length (one byte), initial octet for unused bits (one byte), followed by value (1 byte per 8 validation methods). This value is going to be between two and three bytes initially, and if we grow up to 256 methods, could be as much as 8 bytes (total: 11 bytes)

For a certificate that is validated with multiple methods:

- For each additional validation method, there's going to be 3 bytes of overhead.

- For each additional validation method, there will be 0 bytes of overhead in the best case, to (# of validation methods / 8) bytes in the worst.

It took the Forum nearly a decade to go from 10 methods to 12 for DNS. It has taken nearly two years to suggest going from 12 to 14. If we assume the validation working group substantially increases its productivity, and reforms the methods, we can anticipate seeing up to 32 methods in the course of a number of years to follow. That's counting the 'versioning' Tim is referencing.

So our 'worst case' here, of 32 historic methods of validation, can represent 1 to N number of validations, for any number, within 'at most' 7 bytes.

Versus three bytes per INTEGER.

I really don't understand the principles being used by members preferring one or the other. But at least the math shows more than gut - and can be fact checked and corrected if I've made a mistake. I mean, ultimately, we're haggling over a few bytes here. Literally, a few as in "single digits".

As to the question that somehow this makes viewing more complex, or is easier to viewers - every one of the browser viewers, today, does not decode the contents of extensions for display, even if they're flagged as Constructed. In all cases, you're going to see an unrecognized extension, displayed as an OID, and with its raw octet values (whether hex or otherwise), if you even see the extension. So the debate around display is... non-well-grounded.

For CAs that employ multiple validation methods, BIT STRING is more efficient, even at 'two' validations, even at a 'best' projected 4 years down the road.

- Should the Forum become massively more productive, and decide it wants to further split every method into a sub-section, retire all old methods, such that we see a 10X growth in validation methods (say from 14 to 140 methods, all currently accepted), the overhead of BIT STRING for a single method only accounts for 15 bytes for a single method. At two methods, it's 12 bytes.

- Should the Forum decide that there's some sensible floor to validation methods accepted - that is, old methods are retired - at any point, it can bump the extension OID and 'defrag' the existing bitmap space. If we assume a transition period (where both old and new extensions are included), with a transition date, and leaving our expiration policies of 825-days unchanged, that only represents a 5-15 byte overhead (plus the extension SEQUENCE OF { } wrapping of 2 + 6 (OID) + 4 (BITSTRING for extension)).

My vested interest in this space is making sure that CAs are actually informed in the tradeoffs they're debating, and can effectively compare the data. I've heard multiple conflicting concerns, so that's the best I can do, it seems.

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