[cabfpub] Ballot 167 - Baseline Requirements Corrections

Ryan Sleevi sleevi at google.com
Thu Apr 7 00:24:47 UTC 2016


On Wed, Apr 6, 2016 at 4:40 PM, Peter Bowen <pzb at amzn.com> wrote:

>
> This change is to address https://bugzilla.cabforum.org/show_bug.cgi?id=31,
> which is one of the bugs Gerv listed in the prior thread.
>
> 7.1.4.3 is already "Subject Information – Subordinate CA Certificates”, so
> I was following the same heading format.
>
> 7.1.4.2 says the subject alternative name extension is required and the
> "extension MUST contain at least one entry. Each entry MUST be either a
> dNSName containing the Fully‐Qualified Domain Name or an iPAddress
> containing the IP address of a server”.  Clearly this is incorrect for CA
> certificates.
>
> 7.1.2.1/7.1.2.2 call out the requirement for validation of
> organizationName for CA certificates.  I admit that BR structure here is a
> little weird — very similar requirements are applied to different types of
> certificates in 7.1.2 and 7.1.4. It would probably be better to call out
> validation requirements in one place.  However that is starting to feel
> like its own ballot as it is going to take some careful thought on how to
> make it work correctly.
>
> Would you prefer we drop the change to the heading on 7.1.4.2?
>

Right, my main concern with the change was the asymmetry between
7.1.2.1/7.1.2.2 and 7.1.4.2.

I agree, 7.1.4.2 is structured weird right now. There are elements that
clearly only apply to subscriber certificates, so in that context, I think
your change makes logical sense with that argument, as 7.1.2.1/7.1.2.2
cover what MUST appear for CA certificates. The downside is that the change
leaves ambiguity as to how data in the name types currently listed in
7.1.4.2, but not in 7.1.2.1/7.1.2.2 (meaning they're *optional* for CA
certificates) would be validated, because this change would suggest "no
validation needed".

I think you're absolutely correct that the spirit of the change to 7.1.4.2
is meant to be uncontroversial, and the understanding of how it generally
means is accepted, I just wouldn't want there to be an argument that, say,
that the subject:postalCode can be any arbitrary value (because 7.1.4.2(f)
covers exactly how those field contents are validated), simply because
7.1.4.3 allowed the CA to say "We'll put whatever we want in there"

My concrete suggestions, which I hope would be uncontroversial, but sound
like would benefit from a separate cleanup-ballot because it's more work,
and I wouldn't want to delay the other cleanups in this ballot, are:

- Remove the change from 7.1.4.2's heading
- Let's work up a ballot that:
  - Moves the remarks about "required/optional" for subject names (which is
only relevant to subscriber certificates) into a new 7.1.2.3 (g) [thus
mirroring 7.1.2.1 [e] and 7.1.2.2 [h])
  - Moves the remarks about "required/optional" for subjectAltNames to a
new 7.1.2.3 [h]
  - Ensures that 7.1.4.2.2 consistently describes a policy which is "If
this name is present, here's how the contents must be validated" (for
any/all certificate types)
    - The two differences here are that 7.1.4.2.2(b) allows for a natural
person Subject's name (is this OK or not for CA certificates) and
7.1.4.2.2(g) allows for non-assigned country code (which seems like that
should be permitted for CA certificates too, for the same reasons)

There's also the question as to whether the prohibitions against domain
names/IP addresses (from 7.1.4.2) should be merged with 7.1.4.3, but IF
these are meant to be distinct (that is, it's OK for a sub-CA to say
"organizationalUnitName:Issued by www.example.com" and that's desirable to
support via the BRs), then we'd need to deconflict 7.1.4.3 and 7.1.4.2. One
way to do that would be to swap(ish) the text from the first pargraphs of
each, such that 7.1.4.2 read as "Subject Information - Subscriber
Certificates", and acted as a more-specific restriction over the general
(all certificate) policies from 7.1.4.2

Since that's a lot of editorial work, it doesn't feel fair or right to ask
you to do, and I also agree that we should deconflict these sections, AND I
hope none of what I said above would be controversial, because it (mostly)
aligns with practice. I just wouldn't want to accidentally introduce a
loophole, which I think the change-as-proposed would.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160406/7105283f/attachment-0003.html>


More information about the Public mailing list