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

Tim Hollebeek tim.hollebeek at digicert.com
Mon Oct 8 09:56:45 MST 2018


Might want to use underscores to make it clear where the method number starts.

 

E.g. “method3224_1” through “method3224_12”.

 

-Tim

 

From: Wayne Thayer <wthayer at mozilla.com> 
Sent: Thursday, October 4, 2018 6:41 PM
To: Ryan Sleevi <sleevi at google.com>
Cc: Ben Wilson <ben.wilson at digicert.com>; Tim Hollebeek <tim.hollebeek at digicert.com>; CA/Browser Forum Validation WG List <validation at cabforum.org>; CBonnell at trustwave.com
Subject: Re: [cabf_validation] [EXTERNAL]Re: Ballot Proposal: Validation Method in certificatePolicies

 

Reviving this discussion on the proposal to encode validation methods in certificates - here is an update that I believe addresses Ryan's concerns with the ASN.1 syntax:

 

https://github.com/cabforum/documents/compare/master...wthayer:Ballot226

 

Are there any remaining concerns? Is this ready to be converted into a ballot and sent to the SCWG list?

 

Thanks,

 

Wayne

 

On Thu, Aug 16, 2018 at 11:46 AM Wayne Thayer <wthayer at mozilla.com <mailto:wthayer at mozilla.com> > wrote:

Not sure I'm following. Are you arguing that "DNSValidationMethods ::= BIT STRING" is better than the informative but syntactically flawed enumeration in my latest draft simply because you can cut & paste it into code?

 

On Thu, Aug 16, 2018 at 11:03 AM Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> > wrote:

Ideally, we'd keep the syntax something that CAs and RPs can just paste in to their ASN.1 modules. To that end, both the ellipses and periods in the named bitmask names (method3.2.2.4.1) would be ideal to avoid. Whether we give them semantic identifiers (domainAuthorizationDocument (5)) or not I don't have any strong feelings about, I'd just love to make sure we've got clean syntax that is valid :)

On Thu, Aug 16, 2018 at 1:54 PM Wayne Thayer <wthayer at mozilla.com <mailto:wthayer at mozilla.com> > wrote:

Here some new language that attempts to incorporate everyone's feedback:

 

https://github.com/wthayer/documents/commit/73bece3c6c506e0fdd50b86fee42ac769a016fe5

 

My use of ellipses ("...") in the enumerations is surely a syntax violation, but I think it helps to clarify the layout of the BIT STRINGs without adding a maintenance burden to the document.

 

On Thu, Aug 16, 2018 at 9:23 AM Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> > wrote:

If we assume the concerns are:

1) Simplicity of implementation for CAs

2) Maximum compatibility with clients

3) Minimal size encoding in the average and best cases

4) Ease in maintenance overhead for the Forum

 

Then we end up with something like (using some of the RFC 5912 class templates)

 

-- Option 1: This just uses them as bit strings without enumerating the reasons, and

-- prose would be attached to describe which bit to set, using the terminology from

-- X.680 regarding 'leading' bit (e.g. X.680 21.2 / 21.4)

DNSValidationMethods ::= BIT STRING

IPValidationMethods ::= BIT STRING

 

-- Option 2: This provides an enumeration for semantic names for the bits. New bits can be added at any time

DNSValidationMethods ::= BIT STRING {

  unused (0),

  -- This is also optional, and just means we're skipping the leading bit so that the textual

  -- '1' can align with the named '1' bit.

  -- It does mean one bit is 'reserved', to the extent that matters to folks, for want of a bit.

  method1 (1),

  method2 (2),

  method3 (3)

}

IPValidationMethods ::= BIT STRING {

  method1 (0),

  -- This demonstrates the other approach

  method2 (1),

  method3 (2)

}

 

id-cabf-dnsValidation OBJECT IDENTIFIER ::= { /*TBD */ }

id-cabf-ipValidation OBJECT IDENTIFIER ::= { /* TBD */ }

ext-cabf-dnsValidation EXTENSION ::= { SYNTAX DNSValidationMethods IDENTIFIED BY id-cabf-dnsValidation }

ext-cabf-ipValidation EXTENSION ::= { SYNTAX IPValidationMethods IDENTIFIED BY id-cabf-ipValidation }

 

 

On Thu, Aug 16, 2018 at 12:06 PM Ben Wilson <ben.wilson at digicert.com <mailto:ben.wilson at digicert.com> > wrote:

Never mind, then.  I was just responding to the confusion I felt there was on the validation WG call this morning about how this was going to be done.  Has anyone circulated an example of how this will be encoded in ASN1?

 

From: Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> > 
Sent: Thursday, August 16, 2018 10:03 AM
To: Ben Wilson <ben.wilson at digicert.com <mailto:ben.wilson at digicert.com> >
Cc: Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> >; CA/Browser Forum Validation WG List <validation at cabforum.org <mailto:validation at cabforum.org> >; Corey Bonnell <CBonnell at trustwave.com <mailto:CBonnell at trustwave.com> >; Wayne Thayer <wthayer at mozilla.com <mailto:wthayer at mozilla.com> >
Subject: Re: [cabf_validation] [EXTERNAL]Re: Ballot Proposal: Validation Method in certificatePolicies

 

Ben,

 

Could you explain why you prefer that method? It would be the most expensive in terms of size proposed yet, and be second only to relative OID in complexity for implementations. It also doesn't align with the X.680 guidance. Could you indicate what the factors you were considering in that solution?

 

On Thu, Aug 16, 2018 at 11:58 AM Ben Wilson <ben.wilson at digicert.com <mailto:ben.wilson at digicert.com> > wrote:

I think we should have one OID extension and then a sequence and then context-specific strings that map to each validation method used – similar to what is done for SANs under RFC 5280.  Similar to the SAN approach, you would identify what context-specific type of SAN (domain name or IP  address) we are talking about.  (I’m not suggesting that CAs would be required to have a matching method for each SAN in a certificate, they could still have just one, however they could if they wanted, or they could include multiple lines, without one-to-one mapping.)

 

To illustrate, here is a clip from RFC 5280

 

SubjectAltName ::= GeneralNames

 

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

 

GeneralName ::= CHOICE {

     otherName                 [0]  AnotherName,

     rfc822Name                [1]  IA5String,

     dNSName                   [2]  IA5String,

     x400Address               [3]  ORAddress,

     directoryName             [4]  Name,

     ediPartyName              [5]  EDIPartyName,

     uniformResourceIdentifier [6]  IA5String,

     iPAddress                 [7]  OCTET STRING,

     registeredID              [8]  OBJECT IDENTIFIER }

 

I’m also not suggesting that this numbering from RFC 5280 be used.

 

Ben 

 

From: Validation <validation-bounces at cabforum.org <mailto:validation-bounces at cabforum.org> > On Behalf Of Tim Hollebeek via Validation
Sent: Wednesday, August 15, 2018 11:40 AM
To: Corey Bonnell <CBonnell at trustwave.com <mailto:CBonnell at trustwave.com> >; Wayne Thayer <wthayer at mozilla.com <mailto:wthayer at mozilla.com> >; CA/Browser Forum Validation WG List <validation at cabforum.org <mailto:validation at cabforum.org> >
Subject: Re: [cabf_validation] [EXTERNAL]Re: Ballot Proposal: Validation Method in certificatePolicies

 

I also like the separate extension because IP validated certificates are pretty rare.  I think it’d be nicer not to muck up the 3.2.2.4 list with attempts to accommodate them.

 

-Tim

 

From: Corey Bonnell <CBonnell at trustwave.com <mailto:CBonnell at trustwave.com> > 
Sent: Wednesday, August 15, 2018 12:48 PM
To: Wayne Thayer <wthayer at mozilla.com <mailto:wthayer at mozilla.com> >; CA/Browser Forum Validation WG List <validation at cabforum.org <mailto:validation at cabforum.org> >; Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> >
Subject: Re: [cabf_validation] [EXTERNAL]Re: Ballot Proposal: Validation Method in certificatePolicies

 

Hi Wayne,

Perhaps create another extension/OID to contain the BIT STRING of validation methods for IP addresses? Doing so would remove the need to have a special numbering scheme for IP address validation method numbers and would be straightforward to process.

 

Additionally, if a certificate contains only iPAddress SANs, it could omit the dNSName-specific extension entirely (likewise for a certificate that contains only dNSNames). Certificates that contain both dNSNames and iPAddress SANs are rare in practice, so there is no additional space overhead in the common case.

 

Thanks,
Corey

 

 

Corey Bonnell

Senior Software Engineer

 

Trustwave | SMART SECURITY ON DEMAND <http://www.trustwave.com/> 
https://www.trustwave.com

 

From: Validation <validation-bounces at cabforum.org <mailto:validation-bounces at cabforum.org> > on behalf of Wayne Thayer via Validation <validation at cabforum.org <mailto:validation at cabforum.org> >
Reply-To: Wayne Thayer <wthayer at mozilla.com <mailto:wthayer at mozilla.com> >, CA/Browser Forum Validation WG List <validation at cabforum.org <mailto:validation at cabforum.org> >
Date: Wednesday, August 15, 2018 at 12:34 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> >, CA/Browser Forum Validation WG List <validation at cabforum.org <mailto:validation at cabforum.org> >
Subject: Re: [cabf_validation] [EXTERNAL]Re: Ballot Proposal: Validation Method in certificatePolicies

 

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 <mailto: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 <mailto:sleevi at google.com> > 
Sent: Wednesday, August 15, 2018 11:32 AM
To: Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> >
Cc: Doug Beattie <doug.beattie at globalsign.com <mailto:doug.beattie at globalsign.com> >; Daymion T. Reynolds <dreynolds at godaddy.com <mailto:dreynolds at godaddy.com> >; CA/Browser Forum Validation WG List <validation at cabforum.org <mailto: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 <mailto: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 <mailto:Validation at cabforum.org> 
https://cabforum.org/mailman/listinfo/validation <https://scanmail.trustwave.com/?c=4062&d=hdb021QJj1WGk3oW4iuneFftb6mTa86AK485jQ3E5A&s=5&u=https%3a%2f%2fcabforum%2eorg%2fmailman%2flistinfo%2fvalidation> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20181008/93dd5c21/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/20181008/93dd5c21/attachment-0001.p7s>


More information about the Validation mailing list