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

[Daymion T. Reynolds]

I agree, this looks like an ideal case for exposing the data with a bitmask + validation version. It also be easy to add additional validation methods using this mechanism. -Daymion

From: Validation <validation-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Validation
Sent: Tuesday, August 14, 2018 12:31 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


On Tue, Aug 14, 2018 at 2:49 PM Tim Hollebeek <tim.hollebeek at digicert.com<mailto:tim.hollebeek at digicert.com>> wrote:
Ok, so the speculation about my motivations are completely ridiculous and I’m not going to address them.  Suffice it to say neither of your speculations is even remotely close to correct.

I'm sorry you feel I was speculating about your motives. Can you highlight where I did, and where I was wrong? I'm providing and citing the arguments and concerns you've raised, and solely discussing that. I think, to the extent anything in the Forum can be productive, understanding your base set of concerns is going to be key to finding a solution that works for you. If you believe my understanding of your concerns is incorrect, I hope you can highlight it.

I will say, thinking about it more, I think BIT STRING is optimizing for the wrong case.  I think large numbers of validation methods in a particular certificate will be vanishingly rare, so I think in the long term, just a sequence of integers is probably both easier to use, and more compact, since the number of elements will be strongly peaked at one.

I'm not sure I understand this concern. The stated argument for BIT STRING is because it ensures no ambiguity with the "one and exactly one instance of a validation method" being present - that is, the issue Doug raised with SET and SEQUENCE. Further, it addresses the concerns you raised previously with RELATIVE OID (which appeared to be a deal breaker for you, given you stated DigiCert would vote against other approaches), namely, the size concern. This is clearly the most compact form of representing the information, in which additional methods cost only a single bit of information, rather than the three bytes that would be needed for an INTEGER (tag, length, and value).

As I said, the inability to understand your set of concerns, and the seemingly shifting and incompatible nature of them, is making it hard to find a solution that you find acceptable, which is very much my goal - both now and going forward.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180814/269ff486/attachment.html>