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

Thu Aug 16 09:03:15 MST 2018

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/3aa4cf43/attachment.html>