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

Doug Beattie doug.beattie at globalsign.com
Tue Aug 14 13:30:34 MST 2018


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.  

 

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’d prefer to stick with Set based on the discussion so far.

 

Doug

 

From: Validation <validation-bounces at cabforum.org> On Behalf Of Daymion T. Reynolds via Validation
Sent: Tuesday, August 14, 2018 4:10 PM
To: Ryan Sleevi <sleevi at google.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

 

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/17379a0c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5736 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20180814/17379a0c/attachment-0001.p7s>


More information about the Validation mailing list