[cabf_validation] [EXTERNAL]Re: Ballot Proposal: Validation Method in certificatePolicies
Wayne Thayer
wthayer at mozilla.com
Thu Aug 16 10:54:33 MST 2018
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> 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>
> 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>
>> *Sent:* Thursday, August 16, 2018 10:03 AM
>> *To:* Ben Wilson <ben.wilson at digicert.com>
>> *Cc:* Tim Hollebeek <tim.hollebeek at digicert.com>; CA/Browser Forum
>> Validation WG List <validation at cabforum.org>; Corey Bonnell <
>> CBonnell at trustwave.com>; Wayne Thayer <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>
>> 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> *On Behalf Of *Tim
>> Hollebeek via Validation
>> *Sent:* Wednesday, August 15, 2018 11:40 AM
>> *To:* Corey Bonnell <CBonnell at trustwave.com>; Wayne Thayer <
>> wthayer at mozilla.com>; CA/Browser Forum Validation WG List <
>> 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>
>> *Sent:* Wednesday, August 15, 2018 12:48 PM
>> *To:* Wayne Thayer <wthayer at mozilla.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
>>
>>
>>
>> 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
>> https://www.trustwave.com <http://www.trustwave.com/>
>>
>>
>>
>> *From: *Validation <validation-bounces at cabforum.org> on behalf of Wayne
>> Thayer via Validation <validation at cabforum.org>
>> *Reply-To: *Wayne Thayer <wthayer at mozilla.com>, CA/Browser Forum
>> Validation WG List <validation at cabforum.org>
>> *Date: *Wednesday, August 15, 2018 at 12:34 PM
>> *To: *Tim Hollebeek <tim.hollebeek at digicert.com>, CA/Browser Forum
>> Validation WG List <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> 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>
>> *Sent:* Wednesday, August 15, 2018 11:32 AM
>> *To:* Tim Hollebeek <tim.hollebeek at digicert.com>
>> *Cc:* Doug Beattie <doug.beattie at globalsign.com>; Daymion T. Reynolds <
>> dreynolds at godaddy.com>; CA/Browser Forum Validation WG List <
>> 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>
>> 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
>> 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/20180816/cd6d05fc/attachment-0001.html>
More information about the Validation
mailing list