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.mor...@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-boun...@cabforum.org> On Behalf Of Clint Wilson > via Validation > Sent: Friday, September 6, 2024 2:45 PM > To: Paul van Brouwershaven <paul.vanbrouwersha...@entrust.com>; CA/Browser > Forum Validation SC List <validation@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@cabforum.org <mailto:validation@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-boun...@cabforum.org > <mailto:validation-boun...@cabforum.org>> on behalf of Paul van Brouwershaven > via Validation <validation@cabforum.org <mailto:validation@cabforum.org>> > Sent: Thursday, September 5, 2024 16:40 > To: CABforum3 <validation@cabforum.org <mailto:validation@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@cabforum.org <mailto:Validation@cabforum.org> > https://lists.cabforum.org/mailman/listinfo/validation
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Validation mailing list Validation@cabforum.org https://lists.cabforum.org/mailman/listinfo/validation
