From Corey.Bonnell at digicert.com Tue Sep 3 20:40:20 2024 From: Corey.Bonnell at digicert.com (Corey Bonnell) Date: Tue, 3 Sep 2024 20:40:20 +0000 Subject: [cabf_validation] 2024-09-05 validation-sc meeting agenda Message-ID: Hello, Proposed agenda for this Thursday's meeting: 1. Continue development of the STRIDE model for method #7 (link to Google Doc available on the Validation page of the Wiki) Scheduled minute-taker: Chris As always, if you have any additional agenda items, please reply to this email. Thanks, Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5231 bytes Desc: not available URL: From Paul.vanBrouwershaven at entrust.com Thu Sep 5 14:40:40 2024 From: Paul.vanBrouwershaven at entrust.com (Paul van Brouwershaven) Date: Thu, 5 Sep 2024 14:40:40 +0000 Subject: [cabf_validation] Section 7.1.2.10.5 CA Certificate Certificate Policies for cross signing certificates Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Paul.vanBrouwershaven at entrust.com Fri Sep 6 13:21:36 2024 From: Paul.vanBrouwershaven at entrust.com (Paul van Brouwershaven) Date: Fri, 6 Sep 2024 13:21:36 +0000 Subject: [cabf_validation] Section 7.1.2.10.5 CA Certificate Certificate Policies for cross signing certificates In-Reply-To: <01000191c2a187c5-e8e75fec-0c1d-4d49-8071-71aa69cb79d8-000000@email.amazonses.com> References: <01000191c2a187c5-e8e75fec-0c1d-4d49-8071-71aa69cb79d8-000000@email.amazonses.com> Message-ID: 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 on behalf of Paul van Brouwershaven via Validation Sent: Thursday, September 5, 2024 16:40 To: CABforum3 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:? 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwilson at mozilla.com Fri Sep 6 15:43:22 2024 From: bwilson at mozilla.com (Ben Wilson) Date: Fri, 6 Sep 2024 09:43:22 -0600 Subject: [cabf_validation] Section 7.1.2.10.5 CA Certificate Certificate Policies for cross signing certificates In-Reply-To: <01000191c77f8cbd-a064869b-16b9-4768-bcd1-4dff51659e31-000000@email.amazonses.com> References: <01000191c2a187c5-e8e75fec-0c1d-4d49-8071-71aa69cb79d8-000000@email.amazonses.com> <01000191c77f8cbd-a064869b-16b9-4768-bcd1-4dff51659e31-000000@email.amazonses.com> Message-ID: Mozilla will endorse. On Fri, Sep 6, 2024 at 7:21?AM Paul van Brouwershaven via Validation < 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 on behalf of Paul > van Brouwershaven via Validation > *Sent:* Thursday, September 5, 2024 16:40 > *To:* CABforum3 > *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: > 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 > https://lists.cabforum.org/mailman/listinfo/validation > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at ssl.com Fri Sep 6 16:46:40 2024 From: tom at ssl.com (Tom Zermeno) Date: Fri, 6 Sep 2024 16:46:40 +0000 Subject: [cabf_validation] Section 7.1.2.10.5 CA Certificate Certificate Policies for cross signing certificates In-Reply-To: <01000191c77f8f71-55c77fdd-45bc-452c-a32f-a4779b9e64cb-000000@email.amazonses.com> References: <01000191c2a187c5-e8e75fec-0c1d-4d49-8071-71aa69cb79d8-000000@email.amazonses.com> <01000191c77f8f71-55c77fdd-45bc-452c-a32f-a4779b9e64cb-000000@email.amazonses.com> Message-ID: SSL.com will endorse this ballot. Regards, Tom SSL.com From: Validation On Behalf Of Paul van Brouwershaven via Validation Sent: Friday, September 6, 2024 8:22 AM To: CABforum3 Subject: Re: [cabf_validation] Section 7.1.2.10.5 CA Certificate Certificate Policies for cross signing certificates 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 > on behalf of Paul van Brouwershaven via Validation > Sent: Thursday, September 5, 2024 16:40 To: CABforum3 > 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:? 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5934 bytes Desc: not available URL: From clintw at apple.com Fri Sep 6 18:45:06 2024 From: clintw at apple.com (Clint Wilson) Date: Fri, 06 Sep 2024 11:45:06 -0700 Subject: [cabf_validation] Section 7.1.2.10.5 CA Certificate Certificate Policies for cross signing certificates In-Reply-To: <01000191c77f8ccb-7cdb1416-584e-453c-a347-9c5f580ba382-000000@email.amazonses.com> References: <01000191c2a187c5-e8e75fec-0c1d-4d49-8071-71aa69cb79d8-000000@email.amazonses.com> <01000191c77f8ccb-7cdb1416-584e-453c-a347-9c5f580ba382-000000@email.amazonses.com> Message-ID: <5FE93775-5B31-482A-ABF9-67B00229E9FE@apple.com> 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 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 > on behalf of Paul van Brouwershaven via Validation > > Sent: Thursday, September 5, 2024 16:40 > To: CABforum3 > > 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 > https://lists.cabforum.org/mailman/listinfo/validation -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3621 bytes Desc: not available URL: From Bruce.Morton at entrust.com Fri Sep 6 20:18:43 2024 From: Bruce.Morton at entrust.com (Bruce Morton) Date: Fri, 6 Sep 2024 20:18:43 +0000 Subject: [cabf_validation] [EXTERNAL] Re: Section 7.1.2.10.5 CA Certificate Certificate Policies for cross signing certificates In-Reply-To: <01000191c8a7db57-d0487c81-931a-4e32-8508-7f3d2e058815-000000@email.amazonses.com> References: <01000191c2a187c5-e8e75fec-0c1d-4d49-8071-71aa69cb79d8-000000@email.amazonses.com> <01000191c77f8ccb-7cdb1416-584e-453c-a347-9c5f580ba382-000000@email.amazonses.com> <01000191c8a7db57-d0487c81-931a-4e32-8508-7f3d2e058815-000000@email.amazonses.com> Message-ID: 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 On Behalf Of Clint Wilson via Validation Sent: Friday, September 6, 2024 2:45 PM To: Paul van Brouwershaven ; CA/Browser Forum Validation SC List 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 > 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 > on behalf of Paul van Brouwershaven via Validation > Sent: Thursday, September 5, 2024 16:40 To: CABforum3 > 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 https://lists.cabforum.org/mailman/listinfo/validation -------------- next part -------------- An HTML attachment was scrubbed... URL: From clintw at apple.com Fri Sep 6 23:03:50 2024 From: clintw at apple.com (Clint Wilson) Date: Fri, 06 Sep 2024 16:03:50 -0700 Subject: [cabf_validation] [EXTERNAL] Section 7.1.2.10.5 CA Certificate Certificate Policies for cross signing certificates In-Reply-To: References: <01000191c2a187c5-e8e75fec-0c1d-4d49-8071-71aa69cb79d8-000000@email.amazonses.com> <01000191c77f8ccb-7cdb1416-584e-453c-a347-9c5f580ba382-000000@email.amazonses.com> <01000191c8a7db57-d0487c81-931a-4e32-8508-7f3d2e058815-000000@email.amazonses.com> Message-ID: 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 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 On Behalf Of Clint Wilson via Validation > Sent: Friday, September 6, 2024 2:45 PM > To: Paul van Brouwershaven ; CA/Browser Forum Validation SC List > 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 > 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 > on behalf of Paul van Brouwershaven via Validation > > Sent: Thursday, September 5, 2024 16:40 > To: CABforum3 > > 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 > https://lists.cabforum.org/mailman/listinfo/validation -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3621 bytes Desc: not available URL: From dzacharo at harica.gr Sat Sep 7 05:49:42 2024 From: dzacharo at harica.gr (Dimitris Zacharopoulos) Date: Sat, 7 Sep 2024 08:49:42 +0300 (GMT+03:00) Subject: [cabf_validation] [EXTERNAL] Re: Section 7.1.2.10.5 CA Certificate Certificate Policies for cross signing certificates In-Reply-To: <01000191c8fd859f-2b768c72-9be4-4c0e-b80f-5facc69ac3bd-000000@email.amazonses.com> References: <01000191c2a187c5-e8e75fec-0c1d-4d49-8071-71aa69cb79d8-000000@email.amazonses.com> <01000191c77f8ccb-7cdb1416-584e-453c-a347-9c5f580ba382-000000@email.amazonses.com> <01000191c8a7db57-d0487c81-931a-4e32-8508-7f3d2e058815-000000@email.amazonses.com> <01000191c8fd859f-2b768c72-9be4-4c0e-b80f-5facc69ac3bd-000000@email.amazonses.com> Message-ID: I believe sometimes we forget that the CABF is maintaining a list of "baseline requirements", so why is it problematic to have an issuing CA that is technically capable of issuing DV and OV, or OV and EV or any other combination of end-entity certificates? I am having second thoughts about the entire "Affiliate - non-Affiliate" separation. Ultimately we are talking about the same key management and policies. Let's take a quick example. We have two publicly-trusted Trust Service Providers A and B. TSP(A) has more ubiquity. TSP(B) has a Root CA and, according to the requirements, Root CAs do not allow the certificatePolicies extension which practically leads to "anyPolicy". TSP(B) issues an ICA that is technically capable of issuing all types of TLS Certificates (DV, OV, EV) using the anyPolicy value in the certificatePolicies extension. It also limits the scope to TLS using the EKU. Again, everything is by the book. Now, TSP(B) wants to get cross signed by TSP(A) for more ubiquity. According to the current rules, the cross certificate, even for the ICA, must include only one reserved CABF OID. Why should the rules require TSP(B) to practically change their CA structure when in fact the WebPKI approves their existing behavior? I think it should be allowed for a CA Certificate to include more than one reserved CABF OIDs. It should be up to the TSP to decide the structure and separation of DV, OV, IV or EV per ICA and enforce it via policy OID or not. Best regards, Dimitris. Sep 6, 2024 23:19:13 Bruce Morton via Validation : > 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 *On Behalf Of *Clint Wilson via Validation > *Sent:* Friday, September 6, 2024 2:45 PM > *To:* Paul van Brouwershaven ; CA/Browser Forum Validation SC List > *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 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 on behalf of Paul van Brouwershaven via Validation > *Sent:*?Thursday, September 5, 2024 16:40 > *To:*?CABforum3 > *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 > https://lists.cabforum.org/mailman/listinfo/validation -------------- next part -------------- An HTML attachment was scrubbed... URL: From Corey.Bonnell at digicert.com Mon Sep 9 12:28:35 2024 From: Corey.Bonnell at digicert.com (Corey Bonnell) Date: Mon, 9 Sep 2024 12:28:35 +0000 Subject: [cabf_validation] Final Minutes of the Validation Subcommittee Meeting on 2024-08-22 In-Reply-To: References: Message-ID: Here are the minutes for the 2024-08-22 meeting of the validation-sc, as recorded by Ryan Dickson and approved at the 2024-09-05 meeting. Minutes of the Validation Subcommittee Meeting on 2024-08-22 Attendees: Aaron Gable (Let's Encrypt), Aaron Poulsen (Amazon), Abhishek Bhat (eMudhra), Andrea Holland (VikingCloud), Aneta Wojtczak-Iwanicka (Microsoft), Ben Wilson (Mozilla), Chris Clements (Google), Clint Wilson (Apple), Corey Bonnell (DigiCert), Corey Rasmussen (OATI), Dimitris Zacharopoulos (HARICA), Dustin Hollenback (Microsoft), Enrico Entschew (D-TRUST), Gurleen Grewal (Google), Jaime Hablutzel (OISTE Foundation), Janet Hines (VikingCloud), Johnny Reading (GoDaddy), Kiran Tummala (Microsoft), Li-Chun Chen (Chunghwa Telecom), Mads Henriksveen (Buypass AS), Mahua Chaudhuri (Microsoft), Michael Slaughter (Amazon), Michelle Coon (OATI), Nargis Mannan (VikingCloud), Paul van Brouwershaven (Entrust), Rebecca Kelly (SSL.com), Rollin Yu (TrustAsia), Ryan Dickson (Google), Scott Rea (eMudhra), Stephen Davidson (DigiCert), Sven Rajala (Keyfactor), Tobias Josefowitz (Opera Software AS), Trevoli Ponds-White (Amazon), Wayne Thayer (Fastly), Wendy Brown (US Federal PKI Management Authority) Meeting Kickoff: * Corey greeted participants and noted recording has started * Ryan will take minutes * Corey read the note-well * Corey read the participants list (above) * The August 8, 2024 meeting minutes were approved due to no objections. * Question on minutes from Aaron: The participants list generated by the member tool wasn?t accurate after the meeting ended. Corey mentioned forcing the refresh is a good standard practice, but it?s not clear why the force refresh is needed. Dimitris encouraged Aaron to follow up with the Infrastructure WG or with Martijn directly. Scott also indicated similar issues in the past. Aaron also noticed refreshing changed the formatting of the list (hyphens removed). Wayne also volunteered to take note and raise with the Infrastructure WG during the next call. * Corey reviewed the Agenda, no updates. Discussion and reminder for call for endorsers on Organization Name alignment ballot ( https://lists.cabforum.org/pipermail/validation/2024-August/002006.html) * Martijn is seeking endorsers for the proposal, however was unable to join the call. If interested in endorsing, message Martijn or the list. * No further discussion. Discussion on language improvements for cPSUri and CRLDP ( https://lists.cabforum.org/pipermail/validation/2024-August/002009.html) * Corey highlighted the thread and Pull Request where changes were being proposed and discussed. * Corey mentioned some discussion on GitHub is ongoing focusing on defining the term ?scheme.? * Use of ?URI Scheme" appears to have general consensus from many members on the call (including Clint, Corey, and Dimitris). Enrico will work on creating updated language. * Next steps would be for the proposal to transition into the Server Certificate Working Group, Enrico agreed and will take action. Discussion on language improvements for EV Registration Number ( https://lists.cabforum.org/pipermail/validation/2024-August/002008.html) * Corey discussed recent feedback on the thread from Clint, and that the idea might require a forward-looking effective date. * Clint indicated consistent formatting of an attribute being included in Subject DNs would be helpful. A short effective date to require the recommended format appears to be a good middle ground. * Corey indicated he?d iterate and contemplate an effective date 3-6 months into the future. * Wayne re-visited the idea of having a lint available to accompany a potential future ballot. * Aaron offered a summary of past discussion (lints not required, but encouraged to accompany a ballot that updates profiles). * Wayne suggested as part of the future effective date, we should contemplate how long it might take to write a lint. * Corey also highlighted challenges with creating a lint that accurately detects potential mis-issuance. More investigation is required. * Dimitris shared a reminder that in the past there were discussions within the SCWG that offered potential improvement for more consistent methods of identifying organizations. Perhaps if pursued, those ideas could solve the challenge being addressed by this proposal. * Corey indicated this ballot arose out of an incident that appeared to be due to a misinterpretation of the existing language. He agreed the group should have a broader conversation on how to handle Organization ID moving forward. Threat modeling DNS-based domain validation (method #7) using the STRIDE model ( https://en.wikipedia.org/wiki/STRIDE_model) * On previous calls, various participants had different ideas on what was permitted during the DCV process. There also appeared to exist assumptions that were not universally shared. * Through the STRIDE exercise, the goal is to establish a common understanding and perspective. * The main reason for STRIDE is that it was used successfully in the past within the subcommittee. * There was some discussion on whether STRIDE was most appropriate, but no further discussion on list about a better threat modeling framework that might be better suited for the group. * No comments or objections related to using STRIDE, the group will proceed with this model. * Corey highlighted the existence of a video previously shared by Trev in NetSec that summarized STRIDE and how to sequence steps of the analysis. * High-level steps: * Step 1: Model the system (components and interactions between components) * Challenge: We?ll need to come up with a model that?s applicable to all CAs, despite possible differences between them. * Step 2: Come up with list of attacks on the system * Step 3: Come up with list of mitigations * The group discussed the best approach for operationalizing the framework. * Slaughter supported use of a Google Doc * Corey suggested we create a blank doc and make the URL accessible on the Wiki * We started using the model * Slaughter asked what we should consider the scope. Corey suggested strictly Method 7. Dimitris indicated we aren?t questioning the underlying security properties of DNS, in general. * Corey suggested the scope should be a system that performs Method 7, and study the interactions of the components of that system. At that point, we can identify interactions and define them as in or out of scope. * Tobi indicated the challenge is the DNS protocol itself and how it?s used by resolvers, and the idea of outsourcing the core functionality of what a CA has to provide before issuing certificates. In his opinion, this doesn?t translate into what the STRIDE model describes. He does not believe the framework will be useful. * The group briefly debated the value of the STRIDE model. * Tobi: Whatever part of the system actually makes the requests to the authoritative name server of the domains in question ? that are used to determine if validation has passed or not ? in the proposal from Google Trust Services, that could be a third-party resolver ? and in my perspective, that can only be a name server or some other implementation on the CA side. No other part of the system factors into it. * Slaughter: Scoping - you want to scope this to when the CA creates a DNS query to something? * Tobi: There are two distinct DNS protocols. They have the same name, they use the same packet format, but they are different. One is for requests to authoritative name servers and those responses. The other is for requests to resolvers. Some people here are suggesting that a CA could make a request to the resolver, the resolver does all the work, give you a single response back, and the CA would make a determination on the response. This is a different version of the protocol than the one used to talk to authoritative name servers. My concern is primarily in the addition of the DNS protocol spoken between authoritative name servers and resolvers. That is where I see the problem that in my opinion makes it not a viable option to use 3rd parties for DNS resolution in domain validation. If anyone wants to model anything in response to my concern, I don?t think STRIDE is a useful model. * Dimitris: I agree with Tobi, we should not allow delegated resolvers. This model will help us prove that. Maybe along the way we?ll find other threats that we may deem unacceptable. The reason for the proposal was to help explore unknown threats. * Tobi: I don?t see the assets we?d be discussing defined. * Dimitris: In my mind, any rogue resolver between a CA and the authoritative name server could alter the results. The framing could be as simple as that. * Slaughter: In modeling terms, this is an abstract asset. For example, maintaining the integrity of the Web PKI. * Tobi: The asset is the correctness of issued certificates. * Corey re-framed the discussion. Defining the system components is a good start to begin evaluating this. I see this as a way of identifying potential problems with Method 7 that we might be able to improve by updating the BRs. It?s about identifying concrete improvements to bolster security. * Tobi: I think it contemplates extending the scope of DNS validation which should not be allowed. When we say in the BRs that we need to check DNS, it?s unfortunate that it could be misinterpreted as allowing a CA to simply check a resolver, rather than the authoritative resolver. I have a problem expanding the scope to include that - it would be a distraction. This practice should not be considered acceptable to begin with. * Slaughter: To make sure I understand, the mitigation is to only query authoritative name servers. This mitigates a threat that is available when you query recursive resolvers. * Tobi: Correct, you don?t know if a recursive resolver is telling the truth. It?s not trusted to be authoritative. This is fundamentally always true, unless when operated by the CA. * Slaughter: Summarizes - top-level threat - use of a 3rd-party recursive resolver can result in tampered or forged DNS responses being returned and relied upon during DCV. * [Corey began defining entities and components in the doc, and we discussed possible assumptions.] * Slaughter: Back to the threat, any recursive resolver can result in tampered/forged resolvers. I believe what Tobi is implying is that there are steps a CA can perform to mitigate that threat. * Tobi agreed that there are many mitigations possible. * [We iterated on the doc.] * Tobi: If you say you can use a third-party resolver, it means you can use any third-party resolver. And that is definitely a threat for the use case a CA is relying on for certificate issuance. * Corey: A similar issue is if you use a 1st party resolver and have no mitigations in place to prevent attacks. * Tobi: No. Because a third-party can lie to you. It?s not the same. * Corey: A first party resolver could be grossly misconfigured, we have no requirements for these systems. You can still have bad security outcomes. There?s a difference in who controls it. * Tobi: It?s still a threat, but it?s a different threat. * Slaughter: Both threats require different mitigations and should be addressed separately. * Corey: We're running out of time. There's an opportunity to clean-up the doc, I?ll share the URL on the Wiki and we can pick it up here at the next meeting. Meeting Adjourned -- You received this message because you are subscribed to the Google Groups "Management (CA/B Forum)" group. To unsubscribe from this group and stop receiving emails from it, send an email to management+unsubscribe at groups.cabforum.org . To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/management/CADEW5O-HoNg%3DEvkG6RxMnTk8V_2RAaOv%3DAzh-K4ApWT_2aVVyA%40mail.gmail.com . -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5231 bytes Desc: not available URL: From Kateryna.Aleksieieva at assecods.pl Wed Sep 11 13:06:00 2024 From: Kateryna.Aleksieieva at assecods.pl (Kateryna Aleksieieva) Date: Wed, 11 Sep 2024 13:06:00 +0000 Subject: [cabf_validation] LEI as the Registration number in EV TLS Message-ID: Hi everyone, I have a question regarding the use of the LEI number for Private Organization Subjects as the Registration number in an EV TLS certificate. I couldn?t find confirmation in the EVG that it can be used, so I assume it can't. Has anyone encountered this situation before or can provide clarity on how this should be interpreted? 1.6.1 Definitions Registration Number: The unique number assigned to a Private Organization by the Incorporating Agency in the entity?s Jurisdiction of Incorporation. 3.2.2.2.1 Verification Requirements Registration Number: Obtain the specific Registration Number assigned to the Applicant by the Incorporating or Registration Agency in the Applicant?s Jurisdiction of Incorporation or Registration. If the Incorporating or Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant?s date of Incorporation or Registration. Also, I apologize if this question is sent to the wrong mailing list. Please let me know the correct path if I am mistaken. Thanks in advance for your help! Kind regards, Kateryna Aleksieieva Quality specialist Trust Services Department Asseco Data Systems S.A. Certum Kr?lowej Korony Polskiej 21 71-486 Szczecin mob. +48 785 505 660 kateryna.aleksieieva@assecods.pl assecods.pl Asseco Data Systems S.A. Headquarters: Jana z Kolna 11, 80 - 864 Gda?sk/Poland. Tax Identification Number (NIP): 517-035-94-58. Statistical ID number (REGON): 180853177. National Court Register: 0000421310 District Court in Gda?sk ? P??noc in Gda?sk, VIII Commercial Department of the National Court Register. Share capital: PLN 120.002.940,00 Please be informed that Asseco Data Systems is a large enterprise in a scope of the Act of 8 March 2013 on counteracting excessive payment delays in commercial transactions (consolidated text; Polish Journal of Laws of 2019, item 118) Please be informed that your personal data included in the electronic correspondence are processed by the controller, which is Asseco Data Systems S.A. seated in Gda?sk, ul. Jana z Kolna 11, 80 - 864 Gda?sk. We process your data for the following purposes: to correspond with you, including answering your questions; to document the findings of any such correspondence; to execute an agreement to which you are or may be a party or to take action at your request before entering into such an agreement; to contact you in the execution of agreements to which you are not a party and in connection with the execution of which we have obtained your personal data; to control and improve the quality of the service provided, including the handling of complaints or grievances; to comply with our legal obligations, including for billing, tax and accounting purposes; to protect us from claims and to pursue any claims. You have the right to access, restrict, transfer, delete, rectify and object to the processing of your personal data, with the exact extent of your rights depending on the legal basis of the processing or the purpose of the processing. You also have the right to lodge a complaint with the supervisory authority, i.e. the President of the Office for Personal Data Protection, if you believe that the processing violates the regulations on personal data protection. You can read the full content of the information concerning the processing of your personal data, including your rights and their scope at this address: https://www.assecods.pl/informacje-o-danych-osobowych-email/. This information is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Unauthorised use of this information by person or entity other than the intended recipient is prohibited by law. If you received this by mistake, please immediately contact the sender by e-mail or by telephone and delete this information from any computer. Thank you. Asseco Data Systems S.A. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Paul.vanBrouwershaven at entrust.com Wed Sep 11 15:25:40 2024 From: Paul.vanBrouwershaven at entrust.com (Paul van Brouwershaven) Date: Wed, 11 Sep 2024 15:25:40 +0000 Subject: [cabf_validation] [EXTERNAL] Section 7.1.2.10.5 CA Certificate Certificate Policies for cross signing certificates In-Reply-To: References: <01000191c2a187c5-e8e75fec-0c1d-4d49-8071-71aa69cb79d8-000000@email.amazonses.com> <01000191c77f8ccb-7cdb1416-584e-453c-a347-9c5f580ba382-000000@email.amazonses.com> <01000191c8a7db57-d0487c81-931a-4e32-8508-7f3d2e058815-000000@email.amazonses.com> Message-ID: 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 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 On Behalf Of Clint Wilson via Validation Sent: Friday, September 6, 2024 2:45 PM To: Paul van Brouwershaven ; CA/Browser Forum Validation SC List 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 > 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 > on behalf of Paul van Brouwershaven via Validation > Sent: Thursday, September 5, 2024 16:40 To: CABforum3 > 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 https://lists.cabforum.org/mailman/listinfo/validation -------------- next part -------------- An HTML attachment was scrubbed... URL: From Corey.Bonnell at digicert.com Tue Sep 17 15:28:24 2024 From: Corey.Bonnell at digicert.com (Corey Bonnell) Date: Tue, 17 Sep 2024 15:28:24 +0000 Subject: [cabf_validation] 2024-09-19 meeting agenda Message-ID: Hello, Proposed agenda for this week's meeting: 1. F2F planning a. What do we want to talk about? b. How much time do we need? 2. Cancel the meeting on October 3rd? 3. (time permitting) Method 7 STRIDE model development Scheduled minute-taker: Michael S. As always, if you have anything to add to the agenda, please reply to this email. Thanks, Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5231 bytes Desc: not available URL: From Corey.Bonnell at digicert.com Fri Sep 20 18:10:55 2024 From: Corey.Bonnell at digicert.com (Corey Bonnell) Date: Fri, 20 Sep 2024 18:10:55 +0000 Subject: [cabf_validation] Final minutes for the VSC Teleconference - September 5, 2024 Message-ID: These are the Final Minutes of the Teleconference described in the subject of this message as prepared by Chris Clements and approved on the 2024-09-19 meeting of the Validation sub-committee. Meeting Date: 2024-09-05 Attendees: Aaron Gable (Let's Encrypt), Aaron Poulsen (Amazon), Ben Wilson (Mozilla), Bruce Morton (Entrust), Chris Clements (Google), Clint Wilson (Apple), Corey Bonnell (DigiCert), Corey Rasmussen (OATI), Doug Beattie (GlobalSign), Dustin Hollenback (Microsoft), Gurleen Grewal (Google), I?igo Barreira (Sectigo), Johnny Reading (GoDaddy), Joseph Ramm (OATI), Kiran Tummala (Microsoft), Mads Henriksveen (Buypass AS), Mahua Chaudhuri (Microsoft), Martijn Katerbarg (Sectigo), Michelle Coon (OATI), Nargis Mannan (VikingCloud), Nate Smith (GoDaddy), Paul van Brouwershaven (Entrust), Puja Sehgal (Microsoft), Rebecca Kelly (SSL.com), Rollin Yu (TrustAsia), Ryan Dickson (Google), Scott Rea (eMudhra), Stephen Davidson (DigiCert), Steven Deitte (GoDaddy), Sven Rajala (Keyfactor), Thomas Zermeno (SSL.com), Tobias Josefowitz (Opera Software AS), Trevoli Ponds-White (Amazon), Wayne Thayer (Fastly), Wendy Brown (US Federal PKI Management Authority) 1. Meeting Open: - Corey Bonnell opened the meeting, read the note-well, and completed the roll call. 2. Minutes: - Minutes from the last meeting (August 22, 2024) were approved. - Corey shared the current list of minute takers and asked for any additions or removals. One person was added. 3. Next Meeting: - We?ll discuss F2F planning in the next meeting. 4. Agenda: - Only one topic planned for today, which continues the development of the STRIDE model for method #7. - Paul van Brouwershaven sent a message to the Validation distribution before the meeting: https://lists.cabforum.org/pipermail/validation/2024-September/002028.html 5. Section 7.1.2.10.5 CA Certificate Certificate Policies for cross signing certificates: - Paul introduced the topic where ?[...] at least one Reserved Certificate Policy Identifier? is stated in section 7.1.2.10.5 of the TLS BRs and RFC 5280 says ?Object Identifier?, possibly implying only one Identifier. Further, under the Policy Restricted table in 7.1.2.10.5 there is language that states: ?[...] the Certificate Policies extension MUST contain exactly one Reserved Certificate Policy Identifier.? This statement makes sense if referencing an Issuing CA, but in the context of a Cross-Certified CA it is not specified. His interpretation is that you cannot create a Cross-Certified CA that is constrained on TLS DV, OV, and EV policies. Is this interpretation correct and if so, was that the original intention of this language? - Martijn Katerbarg previously identified this contradiction and created an issue in GitHub ( https://github.com/cabforum/servercert/issues/539). He suggested that the language in the table be updated because minimally this is confusing. - Paul stated there are a few CAs issuing these certificates. Based on recent discussions nobody can issue Cross-Certified CAs at the moment and those that are already issued may be misissued. Is this an error in the document? It seems like the only approach is to cut multiple Cross-Certified certificates to avoid this problem, but there are people out there that have this problem. - Martijn clarified this is only true if the CAs are Non-Affiliated. Affiliated CAs can use the anyPolicy. - Paul suggested even if it is an Affiliated CA you may want to use the policy restricted cross-sign. - Corey also identified this when writing the profiles cleanup ballot last summer. In his opinion, restricting Cross-Signed certificates or CA certificates in general to just one Reserved Policy Identifier was not intended. He believes this language is a copy/paste error from the Subscriber Certificate section, where it makes more sense. - Paul suggested he draft a ballot to correct the language. Does this mean for the time being you cannot issue Cross-Certified CA certificates? - Wayne Thayer asked for clarity that you can issue a Cross-Signed CA certificate but it can only include one Reserved Policy Identifier. Paul confirmed this is correct. - Clint Wilson agreed with Corey and believes the sentence was supposed to say something like ?the Policy Qualifiers field must contain exactly one Reserved Certificate Policy Identifier?, since that is also what RFC 5280 states. It seems as if new Cross-Certified CAs are issued right now with multiple Policy Identifiers then that would be not compliant with the way this is stated, unless you can use the no policy restrictions for Affiliated CAs. It seems like we should pass a ballot to correct this. He suggested reviewing historical conversation to try and determine original intent. The specific sentence of ?[...] MUST contain exactly one Reserved Certificate Policy Identifier.? doesn?t seem appropriate in its context. - Aaron Gable referenced the PR description ( https://github.com/cabforum/servercert/pull/373) calling attention to: ?For CA Certificates, a new requirement that the Reserved Certificate Policy Identifier be the first policy identifier present. Although this is not required by RFC 5280, multiple applications have implemented logic that extracts the first matching/known policy identifier from a certificate, when computing special policies (e.g. EV treatment). Ensuring the Reserved Policy Identifier is first reduces the risk of improper classification of a certificate. As this only applies to new CA Certificates going forward, it's phased in with immediate effect.? There does appear to be some intent here that there be only one Reserved Policy Identifier and it be the first of the Policy Identifiers in the certificate. He suggested ?should only have one Reserved Policy Identifier" because clearly there are existing CA certificates that have DV, OV, and EV Identifiers in them and he doesn't think there is anything particularly wrong about this. He is less convinced the existing language is a typo. - Corey believes the summary language was a bit out of date compared to what was actually in SC-62, because originally it was a hard requirement that the first Policy Identifier be a Reserved ID, but that got relaxed to a ?should? in the final language. - Trevoli Ponds-White suggested Ryan Sleevi previously said Chrome ignores all Object Identifiers after the first one, so if you wanted EV treatment the EV OID had to be first. Ryan Dickson stated that is incorrect. Ben Willson suggested this was actually a Mozilla issue that they resolved and might have been the reason the requirement was relaxed. - Clint suggested that it makes sense to issue separate Sub CAs for each type of certificate being issued, at which point this requirement does not prevent the issuance of those Sub CAs, but either way we need to get clarity on the intent and how that's supposed to be handled by CAs. Trev suggested the intention was driven by what Browsers do. Clint confirmed that ordering might have been a driver, but whether or not you could have more than one Reserved Policy Identifier was not. He could see this being useful to have separate certificate types issued per CA. Paul suggested that maybe the intent was directed towards dedicated Issuing CAs. Trev stated the intent of the ballot was to make things more clear and if we introduced something that creates confusion, then we should clean it up. Clint stated the intent was also to ensure that there were clear boundaries for what each type of certificate was and that every certificate type that could be relevant to the TLS BRs was present. - Martijn does not see an issue with the language if it relates to normal Subordinate CAs and limiting them to just one Reserved Policy Identifier, but Cross-Signed CAs is an exception case and he suggested copying 7.1.2.10.5 to a new section called Cross-Signed CA Certificate Policies and have slightly relaxed text there. - Clint suggested that Subordinate CAs only have one Reserved Policy Identifier. It's not clear as to why a Subordinate CA between the Root and Issuing CA would need to have multiple Reserved Policy Identifiers. Paul reiterated his focus is on the Cross-Signed CA. - Ben stated he would support a ballot that treats this language as a mistake and allows a CA certificate to have multiple Reserved Policy Identifiers. Clint clarified that there are reasons why this might not make sense for all CA certificates, but it does for Cross-Signed CAs. Ben suggested otherwise CAs have to create multiple Sub CAs. - Doug Beattie highlighted that there is already a section for Cross-Certified Subordinate CA Certificate Profile in 7.1.2.2. Maybe we just add a Certificate Policy subsection there to indicate a special role. - Corey stated we already allow anyPolicy for CAs and if we wanted specific Reserved Policy Identifiers per CA we would need a prohibition on anyPolicy, which would be a pretty big change for the ecosystem. - Clint stated removing anyPolicy was slated for Profiles v2.0 and retaining it in the profiles was more of a compromise at the time. This does need to be removed if we want to have fully clean profiles. - Corey suggested proposing a ballot that only addresses the Cross-Signed CAs case. When we review profiles more holistically we can potentially have a ballot that addresses all Sub CAs. Clint suggested in the meantime, multiple Cross-Signed Sub CAs could be created. One with each policy. The current language does not block this, it's just less convenient. - Paul suggested the easiest approach would be to adjust the language in section 7.1.2.10.5, rather than copying and creating a new section. - Corey preferred duplicating the content because that is what is done throughout other sections. One thing that comes to mind is basicConstraints for CA certificates. It?s largely duplicative text for the root CA versus every other type of CA certificate, where basically one element is different, but the rest of the text is the same. Clint leans towards copying and pasting. - Paul will draft a ballot that adjusts the Cross-Signed CA Profile Policy OIDs and circulate that on the list. - Clint referenced a commit (https://github.com/cabforum/servercert/commit/a0360b61e73476959220dc328e3b6 8d0224fa0b3) calling attention to: ?Make PolicyIdentifier ordering optional. This makes the requirement for the Reserved Policy Identifier to be the first policyIdentifier optional, while explaining with a note the basis for that logic. To avoid confusion, it makes it clear that only one instance of a Reserved Policy Identifier may be present (e.g. can't be simultaneously OV and EV)". The intent seems clear for the general case of CA certificates. Generating multiple Cross-Signed CA certificates also seems appropriate. - Martijn thought multiple Sub CA cross signings is prevented by the subject naming which has to be byte-for-byte identical both in Issuing CA and Subject CA. It depends on interpretation. Paul suggested it would mean you could have multiple signing certificates with the same key and the same subject but only different policies, which would be really hard to identify. Corey?s recollection of SC-62 was that Microsoft Windows had some type of Sub CA cacher and it used the key ID as the identifier for that cache. If you have multiple Cross-Signed CAs floating around, same subject DN, same key identifier, and differentiated solely on policy, whether or not that would confuse the cache. It seems like this could introduce potential complications and operational issues for some environments. - Clint stated there are a lot of CAs with the same key and name with minor differences. There is one pattern where a large number of CAs are duplicated with only the AIA being different between the two CAs. We have not seen any issues with those. If CAs have seen any issues, that would be interesting to know. - Corey summarized that the next step is a ballot to allow multiple Reserved Policy Identifiers for Cross-Signed CAs and we?ll look holistically at all Sub CAs at a later time. 6. Any Other Business: - None. 6. Next call: - September 19, 2024 7. Adjourn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5231 bytes Desc: not available URL: From Corey.Bonnell at digicert.com Mon Sep 30 21:23:13 2024 From: Corey.Bonnell at digicert.com (Corey Bonnell) Date: Mon, 30 Sep 2024 21:23:13 +0000 Subject: [cabf_validation] REMINDER: no meeting this Thursday 2024-10-03 Message-ID: Hello, Just a reminder that we are cancelling this Thursday's meeting. Our next meeting will be at the Seattle F2F, 9 AM PDT next Thursday 2024-10-10. Safe travels to all who are attending in-person and look forward to the discussions! Thanks, Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5231 bytes Desc: not available URL: