[cabf_validation] Subject DN attributes in ICA certificates

[Ryan Sleevi]

On Wed, Jun 10, 2020 at 8:38 AM Doug Beattie <doug.beattie at globalsign.com>
wrote:

> Ryan, Tim and group,
>
>
>
> I was looking at the CA Certificate Profile page yesterday and had a
> couple of questions.
>
>
>
>    1. For ICAs, the BR lists 3 subject DN attributes and remains silent
>    on the remaining.  We see lots of CAs including other attributes
>    (State/Prov, Locality, etc.) and it’s not clear if this is a violation of
>    the BRs or not (default deny discussion…).  Even after a long thread [1],
>    we didn’t come to a consensus.   I don’t want to open that can of worms
>    here, but the question is, as we update this section with the intent of not
>    making material changes, what DN fields do we say are permitted?  Currently
>    the page says Optional in the optional/required column but says prohibited
>    further to the right (along with a reference to the DN tab for validation
>    rules which implies it’s permitted).  Does this update intend to clarify
>    what’s permitted and the associated validation rules?  Do we need a ballot
>    prior to this Profile ballot to define permitted attributes and to specify
>    the validation rules?
>
> Yes, we need a ballot to resolve this.


>
>    1.
>    2. Related to this, the definition of Org is currently: “This field
>    MUST be present and the contents MUST contain either the Subject CA’s name
>    or DBA as verified under Section 3.2.2.2”.  I could not find a definition
>    of “Subject CA’s Name” to know what exactly that means.  A number of CAs,
>    GlobalSign included, issue “Vanity” CAs.  Those are CA certificates in the
>    name of a 3rd party and run by the CA identified in the Certificate
>    Policy CPS link.  As we clarify the validation rules for fields in CA
>    certificates, we should be clear on what we mean by “Subject CA’s name” and
>    how these attributes are validated.  This was discussed in 2017 as part of
>    Ballot 199. Gerv said it was permitted [2], and Ben said [3] this was part
>    of the Policy WG discussion about “CA” and “CA Operator”, which I don’t
>    think was ever reflected in the BRs.
>
> That seems to be confusing CN with O name. You seem to be discussing a
different field than Gerv, have I confused anything?


>
>    1.
>
> We should come to conclusion on both of these as part of clarifying the
> certificate profiles and attribute validation rules.  Do we need a ballot
> on these before we can finalize the certificate profiles?
>
>
>
> Ryan – I believe you created a list of all subject Attributes you found in
> CAs at some point.  Is that the starting point we wanted to use as the
> “whitelist” of attributes as we clarify what is permitted?
>

Yes, and I circulated it multiple times for feedback. It was the process of
preparing a Ballot that revealed the systemic issues that we're now
discussing with profiles, in order to resolve matters like how you
highlight. I just didn't expect we'd be spending so long on profiles.


>
>
> [1]
> https://lists.cabforum.org/pipermail/servercert-wg/2019-October/001154.html
>
> [2] https://lists.cabforum.org/pipermail/public/2017-May/010928.html
>
> [3] https://lists.cabforum.org/pipermail/public/2017-May/010936.html
>
>
>
>
>
> Doug
>
>
>
> *From:* Validation <validation-bounces at cabforum.org> *On Behalf Of *Ryan
> Sleevi via Validation
> *Sent:* Thursday, June 4, 2020 5:50 PM
> *To:* CA/Browser Forum Validation WG List <validation at cabforum.org>
> *Subject:* Re: [cabf_validation] Sub-CAs and CP policy OIDs
>
>
>
>
>
>
>
> On Tue, May 12, 2020 at 4:09 PM Ryan Sleevi <sleevi at google.com> wrote:
>
> I had an issue flagged by a CA and went and filed
> https://github.com/cabforum/documents/issues/179 to try to capture the
> issue
>
>
>
> The TL:DR: is how to handle a sub-CA that wishes to use the CABF OIDs
> within their end-entity certificates, but is not Affiliated with the Root.
>
>
>
> Bumping this, and hoping to get some feedback from other root programs as
> to whether or not they see it as an issue with the BRs, and whether the
> attempted solution ( https://github.com/sleevi/cabforum-docs/pull/21 ) is
> aligning in the right direction. As it is, it raises questions about
> whether some Sub-CAs are in compliance, and creates challenges for issuing
> new Sub-CAs, so I want to make sure we're moving in the right direction and
> giving CAs the clarity they need from Root Programs.
>
>
>
> Separate from that more immediate issue, I'm also starting to wonder
> whether, longer-term, we should restructure how we handle these policy
> OIDs, to make it easier for Relying Party software to use
> certificatePolicies for verification, rather than the (implemented by
> Google/Mozilla/Microsoft) EKU chaining behaviour. This would likely help
> resolve some of the issues around separate trust frameworks, by more
> clearly asserting the trust framework (or frameworks) a certificate belongs
> to. That's not something we need to immediately tackle, as we can still
> smoothly transition later, but the way our current requirements are
> structured, which this PR tries to preserve, prevents that.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20200610/7a92ccb1/attachment-0001.html>