[cabf_validation] [EXTERNAL] Section 7.1.2.10.5 CA Certificate Certificate Policies for cross signing certificates

Wed Sep 11 15:25:40 UTC 2024

Hi Clint, Ben,

(Sharing here for visibility in addition to GitHub)

We can update the policyIdentifier contents in the "No Policy Restrictions (Affiliated CA)" table under sections 7.1.2.2.6 and 7.1.2.10.5 with Ben's suggested text:

When the Issuing CA wishes to express that there are no policy restrictions, and if the Subordinate CA is an Affiliate of the Issuing CA, then the Issuing CA MAY use the `anyPolicy` Policy Identifier, which MUST be the only `PolicyInformation` value.

and add the following sentence at the end of the paragraph after the table in section 7.1.2.2.6:

If the Certificate issued under this Certificate Profile is authorized to issue Subscriber certificates, it MUST contain exactly one Reserved Certificate Policy Identifier.

Do these changes address your concerns?

See also: https://github.com/cabforum/servercert/pull/544

Paul

________________________________
From: Clint Wilson
Sent: Saturday, September 07, 2024 01:03
To: Bruce Morton
Cc: CA/Browser Forum Validation SC List; Paul van Brouwershaven
Subject: Re: [EXTERNAL] [cabf_validation] Section 7.1.2.10.5 CA Certificate Certificate Policies for cross signing certificates

Hi Bruce,

I agree, but don’t see anything conceptualized in the current TBRs which would represent this. I’m not sure how to fully capture this simply. For part of the prerequisites we’re describing — though I’m pretty sure it’s not a good idea —  we could possibly add this into the hypothetical clarifying language to-be-added to the new Section 7.1.2.2.6 with something along the lines of “the CA Certificate whose Subject Name and Subject Public Key Information are being signed as a Cross-Certified Subordinate CA MUST contain a basicConstraints:pathLenConstraint and the value of the pathLenConstraint MUST NOT be `0`”.

However, that kind of requirement doesn’t prohibit such a CA Certificate from issuing Subscriber Certificates and I don’t know of a technical means of representing that a CA Certificate doesn’t issue end-entity certificates and so should not be used by relying parties in chain validation as the issuing CA of a leaf. Limiting it to Root CA Certificates was the best I could come up with that doesn’t scope creep this change substantially, but hopefully someone else sees something I don’t. If nothing else, we could probably add that language into this same new Section as a “If a Cross-Certified Subordinate CA contains more than one Reserved Certificate Policy Identifier, it MUST NOT sign Subscriber Certificates” sort of caveat/condition.

Thanks,
-Clint

On Sep 6, 2024, at 1:18 PM, Bruce Morton <Bruce.Morton at entrust.com> wrote:

Hi Clint,

I think the requirement should apply to a certificate to a CA, which can issue CA certificates. I’m not sure of the right terminology, but I categorize this as a Root-to-Root CA or a Root-to-Intermediate CA Certificate. It would not apply to a CA certificate where the CA issues Subscriber certificates.

Bruce.

From: Validation <validation-bounces at cabforum.org> On Behalf Of Clint Wilson via Validation
Sent: Friday, September 6, 2024 2:45 PM
To: Paul van Brouwershaven <Paul.vanBrouwershaven at entrust.com>; CA/Browser Forum Validation SC List <validation at cabforum.org>
Subject: [EXTERNAL] Re: [cabf_validation] Section 7.1.2.10.5 CA Certificate Certificate Policies for cross signing certificates

Hi Paul,

One concern I have with this change is its impact on the cross-certification of subordinate CAs which directly issue end-entity TLS certificates. That is, I think it appropriate to maintain the requirement/limitation that only one Reserved Certificate Policy Identifier be included in the Cross-Certified Subordinate CA Certificate where the CA Certificate being signed/certified is a Subordinate CA Certificate as opposed to a Root CA Certificate.

Since the introduction to this Profile in Section 7.1.2.2 states that the Profile is the same regardless of whether the “source” CA Certificate is a Root CA Certificate or a Subordinate CA Certificate, I think this newly added Section 7.1.2.2.6 would need to indicate clearly its scope of applicability against Cross-Certified Subordinate CA Certificate which are the result of issuing a CA Certificate using the same Subject Name and Subject Public Key Information as an existing Root CA Certificate.

It also seems like it may be helpful to clarify that the Certificate Policies extension defined in this newly added Section 7.1.2.2.6 needs to be compatible between the Cross-Certified Subordinate CA and its Issuing CA (though, perhaps, obvious, this would also help ensure that the separation of pre- and post-SC-062 CA Certificates is maintained, at least in the cases where the `anyPolicy` Policy Identifier is not used). I’m not entirely sure this is necessary, as I suspect it’s required elsewhere within Section 7, but I couldn’t find it in a quick search so thought I’d mention it.

Thanks!
-Clint

On Sep 6, 2024, at 6:21 AM, Paul van Brouwershaven via Validation <validation at cabforum.org<mailto:validation at cabforum.org>> wrote:

Following yesterday's discussion in the validation subcommittee teleconference, we are now seeking two members to endorse the ballot. Feedback is also welcome, either here or on the pull request.

### Purpose of the Ballot

This ballot duplicates the content of section 7.1.2.10.5 (CA Certificate Certificate Policies) into section 7.1.2.2 (Cross-Certified Subordinate CA Certificate Profile) as section 7.1.2.2.6 (Cross-Certified Subordinate CA Certificate Certificate Policies), modifying the requirement from "MUST contain exactly one Reserved Certificate Policy Identifier" to "MUST include at least one Reserved Certificate Policy Identifier" to allow the inclusion of multiple Reserved Certificate Policy Identifiers in a Cross-Certified Subordinate CA Certificate.

The following motion has been proposed by Paul van Brouwershaven (Entrust) and endorsed by XXX (XXX) and XXX (XXX).

GitHub pull request for this ballot: https://github.com/cabforum/servercert/pull/544

### Motion begins

MODIFY the "Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates" ("TLS Baseline Requirements") based on Version 2.0.6 as specified in the following redline:

https://github.com/cabforum/servercert/compare/929d9b4a1ed1f13f92f6af672ad6f6a2153b8230...89f80028b40ce6a1a5c52b406d37e5534460a1a1

### Motion ends

This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:

Discussion (7+ days)

- Start time: TBC
- End time: TBC

Vote for approval (7 days)

- Start time: TBC
- End time: TBC
________________________________
From: Validation <validation-bounces at cabforum.org<mailto:validation-bounces at cabforum.org>> on behalf of Paul van Brouwershaven via Validation <validation at cabforum.org<mailto:validation at cabforum.org>>
Sent: Thursday, September 5, 2024 16:40
To: CABforum3 <validation at cabforum.org<mailto:validation at cabforum.org>>
Subject: [EXTERNAL] [cabf_validation] Section 7.1.2.10.5 CA Certificate Certificate Policies for cross signing certificates

We would like to clarify the following requirement in section 7.1.2.10.5 CA Certificate Certificate Policies, specifically for cross signing certificates.

RFC 5280 states that you can have one CertPolicyId within the PolicyInformation, see below:

certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation

PolicyInformation ::= SEQUENCE {
        policyIdentifier   CertPolicyId,
        policyQualifiers   SEQUENCE SIZE (1..MAX) OF
                                PolicyQualifierInfo OPTIONAL }

CertPolicyId ::= OBJECT IDENTIFIER

Section 7.1.2.10.5 of the TLS BR states for the policyIdentifier:

The CA MUST include at least one Reserved Certificate Policy Identifier (see Section 7.1.6.1) associated with the given Subscriber Certificate type (see Section 7.1.2.7.1) directly or transitively issued by this Certificate.

This 'at least one' seems to contradict RFC 5280 which indicates that we can only have one policyIdentifier in the PolicyInformation sequence.

Then at the bottom of this section the TLS BRs states that entire certificate policies extension MUST contain exactly one Reserved Certificate Policy Identifier:

Regardless of the order of PolicyInformation values, the Certificate Policies extension MUST contain exactly one Reserved Certificate Policy Identifier.

While we can repeat the PolicyInformation within the certificatePolicies extension does this mean that CAs are prohibited from issuing a cross signing certificate (from a multi-purpose root to another multi-purpose root) with policy contrains that include DV, OV and EV reserved certificate policy identifiers. If our reading of this section is correct, this would mean that CAs need to issue three seperate cross signing certificates in that case.

Paul

Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
_______________________________________________
Validation mailing list
Validation at cabforum.org<mailto:Validation at cabforum.org>
https://lists.cabforum.org/mailman/listinfo/validation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20240911/76b5a3cd/attachment-0001.html>