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

[Ryan Sleevi]

On Tue, Aug 14, 2018 at 4:30 PM Doug Beattie <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/20180814/6e3c0351/attachment-0001.html>