[cabf_validation] [EXTERNAL]Re: Ballot Proposal: Validation Method in certificatePolicies
Wayne Thayer
wthayer at mozilla.com
Thu Aug 16 11:46:08 MST 2018
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> 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> 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> 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/816d0083/attachment-0001.html>
More information about the Validation
mailing list