[cabf_validation] [EXTERNAL]Re: Ballot Proposal: Validation Method in certificatePolicies
Wayne Thayer
wthayer at mozilla.com
Thu Oct 4 15:41:09 MST 2018
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> 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> 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/20181004/3a6cb00c/attachment-0001.html>
More information about the Validation
mailing list