Update to reflect recent discussions #39
Conversation
|
OK, so since this is an uber-PR, combining many different changes (hooray for separate commits), I'll go comment on individual commits. Ideally, we'll be able to rebase-and-merge at the end, unless you'd like to use branch-and-PR for the individual commits. |
There was a problem hiding this comment.
Thanks for doing this!
I'm not sure how well these comments will carry over, because they're on individual commits. We could try breaking them out into individual PRs (I believe if you git branch each commit, and then set their appropriate upstream, GitHub is supposed to be smart enough), but happy to continue iterating through this.
You may want to rebase -i to squash some of the fixups (like the dangling reference) into their appropriate section.
I notice you included a Python file for renumbering sections. That should be a separate commit and PR, don't you think?
| * [Section 7.1.2.4 - Technically-Constrained Precertificate Signing CA Certificate Profile](7124-technically-constrained-precertificate-signing-ca-certificate-profile) | ||
| * [Section 7.1.2.5 - Technically-Constrained TLS Subordinate CA Certificate Profile](#7125-technically-constrained-tls-subordinate-ca-certificate-profile) | ||
| * [Section 7.1.2.6 - TLS Subordinate CA Certificate Profile](#7126-tls-subordinate-ca-certificate-profile) | ||
| * [Section 7.1.2.7 - Subscriber (End-Entity) Certificate Profile](#7127-subscriber-server-certificate-profile) |
There was a problem hiding this comment.
I'm having trouble finding the discussion around this, but I don't think we can make this change.
The entire point of profiles is to make sure we've clearly defined everything in-scope. The issuance of a non-TLS CA is, from past discussions, in-scope of the BRs, as the non-TLS certificate still needs to conform to the applicable policies.
The only reference I could find is https://lists.cabforum.org/pipermail/validation/2021-December/001738.html - is there something I overlooked?
There was a problem hiding this comment.
@sleevi - check out the F2F minutes
There was a problem hiding this comment.
Thanks. It looks like some of the participants may have been confused, based on the disussion.
The requirements here are the synthesis of the existing BRs, combined with the RFC 5280 rules, in trying to capture the "minimal acceptable well-formedness" criteria.
Based on the minutes, it did look like there was consensus for "requirements for acceptable criteria for these non-TLS ICA", which is the case. There was some pushback about existing BR requirements, but that sounds like that pushback should be a separate ballot - i.e. this just tries to transcribe the existing RFC 5280 rules, synthesized with the existing BR 7.1.2.2 rules (some discussion previously on the list )
I understand that the proposal for expediency is constantly to remove things, but I'm wondering: were there concrete issues with the requirements expressed here? i.e. was something seen as not part of the existing BRs or RFC 5280? I thought we fixed the one typo (re: policy OIDs), which was the only one previously addressed.
The reason this is somewhat important is that if the outcome of profiles is to say "Anything that meets this profile is in scope, anything that doesn't is out of scope" (which is logically the consequence of excluding non-TLS), then it doesn't get to the "Default Deny" state that motivates profiles in the first place. That is, the whole goal was to be able to look at any cert issued under a root and ask if it meets one of these profiles / if the chain meets the profiles. If there are things not listed, then this ends up making the BRs more permissive than they are today, and more risk of misissuance.
@CBonnell I wasn't sure if you had a more detailed analysis?
| | `rfc822Name` | SHOULD NOT | The CA MAY constrain to a mailbox, a particular host, or any address within a domain, as specified within [RFC 5280, Section 4.2.1.10](https://tools.ietf.org/html/rfc5280#section-4.2.1.10). For each host, domain, or Domain portion of a Mailbox (as specified within [RFC 5280, Section 4.2.1.6](https://tools.ietf.org/html/rfc5280#section-4.2.1.6)), the CA MUST confirm that the Applicant has registered the domain or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `rfc822Name` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more mailboxes, hosts, or domains to be excluded. | If no `rfc822Name` instance is present in the `permittedSubtrees`, then the CA MAY include a zero-length `rfc822Name` to indicate no mailboxes are permitted. | | ||
| | `otherName` | SHOULD NOT | See following table. | See following table. | See following table. | | ||
| | `rfc822Name` | MAY | The CA MAY constrain to a mailbox, a particular host, or any address within a domain, as specified within [RFC 5280, Section 4.2.1.10](https://tools.ietf.org/html/rfc5280#section-4.2.1.10). For each host, domain, or Domain portion of a Mailbox (as specified within [RFC 5280, Section 4.2.1.6](https://tools.ietf.org/html/rfc5280#section-4.2.1.6)), the CA MUST confirm that the Applicant has registered the domain or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `rfc822Name` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more mailboxes, hosts, or domains to be excluded. | If no `rfc822Name` instance is present in the `permittedSubtrees`, then the CA MAY include a zero-length `rfc822Name` to indicate no mailboxes are permitted. | | ||
| | `otherName` | MAY | - | - | |
There was a problem hiding this comment.
Both of these remain SHOULD NOT, not MAY, under the existing restrictions of the BRs today (7.1.2.4)
| All other `otherName` `type-id`s other than those listed above: | ||
| 1. MUST apply in the context of the public Internet, unless: | ||
| a. the extension OID falls within an OID arc for which the Applicant demonstrates ownership, or, | ||
| b. the Applicant can otherwise demonstrate the right to assert the data in a public context. | ||
| 2. MUST NOT include semantics that will mislead the Relying Party about certificate information verified by the CA. | ||
| 3. MUST be DER encoded according to the relevant ASN.1 module defining the `otherName` `type-id` and `value`. | ||
|
|
||
| CAs SHALL NOT include additional names unless the CA is aware of a reason for including the data in the Certificate. |
There was a problem hiding this comment.
This can't be removed, especially with the (I believe incorrect) changes to MAY. We still need to specify the conditions on what it means to be present.
| @@ -1811,7 +1811,7 @@ If the CA asserts compliance with these Baseline Requirements, all certificates | |||
|
|
|||
| | __Extension__ | __Presence__ | __Critical__ | __Description__ | | |||
| | ---- | - | - | ----- | | |||
| | `authorityKeyIdentifier` | SHOULD | N | See [Section 7.1.2.1.2](#71212-authority-key-identifier) | | |||
| | `authorityKeyIdentifier` | MAY | N | See [Section 7.1.2.1.2](#71212-authority-key-identifier) | | |||
There was a problem hiding this comment.
I believe our recent call concluded this change was correct as-is.
Did you take a different conclusion?
| @@ -1786,7 +1786,7 @@ If the CA asserts compliance with these Baseline Requirements, all certificates | |||
| | --- | ------ | | |||
| | `tbsCertificate` | | | |||
| | \ \ \ \ `version` | MUST be v3(2) | | |||
| | \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) containing at least 64 bits of output from a CSPRNG. | | |||
| | \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159 containing at least 64 bits of output from a CSPRNG. | | |||
There was a problem hiding this comment.
This seems fine, but it likely needs to be supplementary documented that the reason for 2^159 is to ensure it encodes in 20 bytes or fewer
| @@ -2917,7 +2917,7 @@ This section details encoding rules that apply to all Certificates issued by a C | |||
|
|
|||
| In addition, the following requirements apply to all Subject Attributes (i.e. those attributes within the `subject` field of a `tbsCertificate`): | |||
| * Subject Attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. | |||
| * Subject Attributes MUST NOT include a Domain Name or IP Address, except as specified in [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) or [Section 3.2.2.5](#3225-authentication-for-an-ip-address) | |||
| * Subject `commonName` Attributes MUST NOT include a Domain Name or IP Address, except as specified in [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) or [Section 3.2.2.5](#3225-authentication-for-an-ip-address). | |||
There was a problem hiding this comment.
This change isn't correct.
I understand DigiCert has some disagreement, based on https://lists.cabforum.org/pipermail/validation/2021-November/001728.html , but the existing BR requirement in 7.1.4.2 is clear and unambiguous:
By issuing the Certificate, the CA represents that it followed the procedure set forth in
its Certificate Policy and/or Certification Practice Statement to verify that, as of the
Certificate’s issuance date, all of the Subject Information was accurate. CAs SHALL NOT
include a Domain Name or IP Address in a Subject attribute except as specified in
Section 3.2.2.4 or Section 3.2.2.5.
If the goal is to just scope this to Subscriber certs, we can do that, but this blanket change removes an existing BR requirement, so doesn't seem correct.
| @@ -2104,7 +2104,7 @@ CAs SHALL NOT include additional names unless the CA is aware of a reason for in | |||
| | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | |||
| | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | | |||
| | \ \ \ \ `validity` | | | |||
| | \ \ \ \ \ \ \ \ `notBefore` | __**TBD**__ | | |||
| | \ \ \ \ \ \ \ \ `notBefore` | A value within 48 hours of the certificate signing operation. | | |||
There was a problem hiding this comment.
I realize this was from https://lists.cabforum.org/pipermail/validation/2021-November/001728.html but I didn't see any explanation/rationale?
Unlike CA signing, there's no need to backdate here, and this seems to violate the existing BRs' 9.6.1
Was the only concern to resolve the precertificate question? Just making sure I can try to address this correctly / offer suggestions here.
| | `certificatePolicies` | - | - | - | | ||
| | \ \ \ \ _Prior to 2022-04-01_ | SHOULD NOT | N | See [Section 7.1.2.7.7](#71277-certificate-policies) | | ||
| | \ \ \ \ _Effective 2022-04-01_ | MUST NOT | - | - | | ||
| | `certificatePolicies` | MAY | N | See [Section 7.1.2.7.7](#71277-certificate-policies) | |
There was a problem hiding this comment.
This was discussed in https://lists.cabforum.org/pipermail/validation/2021-November/001728.html
I'm all game for updating the timelines (to 6 months out), but the discussion makes it clear there wasn't strong support for removing, and there is compelling technical reason to leave this prohibition in. In particular, it does not seem appropriate to have OCSP responders indicating validation types for subscriber certificates, as both misleading (9.6.1) and technically incorrect.
| | `subjectKeyIdentifier` | SHOULD NOT | N | See [Section 7.1.2.10.4](#712104-subject-key-identifier) | | ||
| | Any other extension | SHOULD NOT | - | See [Section 7.1.2.10.5](#712105-other-extensions) | | ||
| | `subjectKeyIdentifier` | MAY | N | See [Section 7.1.2.10.4](#712104-subject-key-identifier) | | ||
| | Any other extension | MAY | - | See [Section 7.1.2.10.5](#712105-other-extensions) | |
There was a problem hiding this comment.
This doesn't do what the commit message says.
SKI is still allowed (it's a SHOULD NOT, not a MUST NOT), and equally, changes the any other extension in a way that's inconsistent with the existing BRs' 7.1.2.4
I understand the discussion to be "Our auditors interpret a SHOULD NOT as a MUST NOT", but that's an obviously incorrect interpretation of the auditors that can be clarified. However, to the extent "Our auditors require us to justify every violation of a SHOULD NOT", that's the existing BR language (in that the CA needs to demonstrate how each non-explicitly-enumerated field satisifies the 7.1.2.4 test), and is WAI.
| @@ -2771,7 +2771,7 @@ Each `SignedCertificateTimestamp` included within the `SignedCertificateTimestam | |||
|
|
|||
| ##### 7.1.2.10.4 Subject Key Identifier | |||
|
|
|||
| If present, the `subjectKeyIdentifier` MUST be set as defined within [RFC 5280, Section 4.2.1.2](https://tools.ietf.org/html/rfc5280#section-4.2.1.2). CAs MUST generate a unique `subjectKeyIdentifier` for each unique public key (the `subjectPublicKeyInfo` field of the `tbsCertificate`). For example, CAs MAY generate the subject key identifier using an algorithm derived from the public key, or MAY generate a unique number, such by using a CSPRNG. | |||
| If present, the `subjectKeyIdentifier` MUST be set as defined within [RFC 5280, Section 4.2.1.2](https://tools.ietf.org/html/rfc5280#section-4.2.1.2). The CA MUST generate a `subjectKeyIdentifier` that is unique within in the scope of the Issuing CA for each certified public key (the `subjectPublicKeyInfo` field of the `tbsCertificate`). For example, CAs may generate the subject key identifier using an algorithm derived from the public key, or MAY generate a unique number, such by using a CSPRNG. | |||
There was a problem hiding this comment.
This isn't quite what we discussed, right? Namely, "Issuing CA" here refers to the immediate parent certificate, but I believe the discussion concluded within the context of the CA organization?
However, Tim's proposal had been to define/mandate the explicit algorithm, AIUI - that is, pulling forward the requirements from RFC 5280 4.2.1.2 and going SHOULD -> MUST. Is there a reason that didn't work?
|
@CBonnell Thanks for this. I've updated #36 with new commits related to this
|
|
(Closing this out, with hopefully everything addressed that was planned) |
Incorporate conclusions reached during November and December validation-sc meetings:
It was agreed (https://lists.cabforum.org/pipermail/validation/2021-November/001728.html) that the requirement to make the CABF policy OID the first policyIdentifier should be moved to another ballot. Given the drastic changes in formatting adjusting the current language would create, I haven't proposed concrete language for that yet.