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: