Re: [Servercert-wg] Voting Period Begins: Ballot SC-076v2 "Clarify and Improve OCSP Requirements"

[Clint Wilson via Servercert-wg]

Apple votes YES on SC-076v2.

> On Sep 26, 2024, at 12:01 PM, Aaron Gable via Servercert-wg 
>  wrote:
> 
> Purpose of Ballot
> 
> This is v2 of this ballot; you can see the discussion thread for v1 here: 
> https://lists.cabforum.org/pipermail/servercert-wg/2024-August/004798.html
> 
> This ballot attempts to address three concerns:
> - The confusion around "reserved" serials, which do not actually exist 
> because all Precertificate serials are assumed to also exist in corresponding 
> Certificates and are therefore actually "assigned";
> - Confusion around whether, and how quickly, OCSP responders must begin 
> providing authoritative responses for Certificates and Precertificates; and
> - Confusion around whether and how the OCSP requirements apply to 
> Certificates which do not contain an AIA OCSP URL, but for which the CA's 
> OCSP responder is still willing to provide responses.
> 
> These concerns have been previously discussed in this Mozilla policy bug 
> , this ServerCert WG bug 
> , and this Bugzilla 
> incident .
> 
> It addresses these concerns by:
> - Stating that OCSP responses must be available within 15 minutes of signing 
> a certificate containing an AIA OCSP URL;
> - Removing the concept of a "reserved" serial entirely;
> - Moving all OCSP requirements into Section 4.9.9, leaving Section 4.9.10 
> (which RFC 3647 says is meant to place requirements on relying parties, not 
> on CAs) empty; and
> - Organizing the requirements in Section 4.9.9 into three clusters:
>   - Definitions of "validity interval", "assigned", and "unassigned";
>   - Requirements on OCSP Responders, which apply only to responses from AIA 
> OCSP URLs found in issued certs; and
>   - Requirements on OCSP Responses, which apply to all responses regardless 
> of whether the certificate in question has an AIA OCSP URL.
> 
> GitHub PR representing this ballot: 
> https://github.com/cabforum/servercert/pull/535
> Rendered view of the resulting text: 
> https://github.com/cabforum/servercert/blob/a8a36690802250cdbe508a6c1f99f700a5357bd3/docs/BR.md#499-on-line-revocationstatus-checking-availability
> 
> Motion
> 
> The following motion has been proposed by Aaron Gable (Let's Encrypt / ISRG), 
> and is endorsed by Ben Wilson (Mozilla) and Antonis Eleftheriadis (HARICA).
> 
> Motion Begins
> 
> Modify the "Baseline Requirements for the Issuance and Management of 
> Publicly-Trusted TLS Server Certificates", based on Version 2.0.6, as 
> specified in the following redline:
> 
> https://github.com/cabforum/servercert/compare/929d9b4a1ed1f13f92f6af672ad6f6a2153b8230...a8a36690802250cdbe508a6c1f99f700a5357bd3
> 
> Motion Ends
> 
> This ballot proposes a Final Maintenance Guideline. The procedure for 
> approval of this ballot is as follows:
> 
> Discussion Period (at least 7 days)
> 
> Start: August 29, 2024 19:00 UTC
> End: September 26, 2024 19:00 UTC
> 
> Voting Period (7 days)
> 
> Start: September 26, 2024 19:00 UTC
> End: October 3, 2024 19:00 UTC
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] Discussion Period Begins - Ballot SC-080 V1: "Sunsetting use of WHOIS to identify Domain Contacts"

[Clint Wilson via Servercert-wg]

Hi Ryan,

Both of these objectives are valuable outcomes to pursue, from my perspective. 
Regarding Objective 2, I think a shorter timeline for an effective date is 
desirable, especially in relation to 3.2.2.4.2’s inclusion of Fax, SMS, and 
Postal Mail as communication mediums for domain validation. I would suggest 
July 15, 2025 as a reasonable date which still meets the criteria you provided, 
excepting that it doesn’t match an effective date already present in the TBRs. 
Other than that, I think these objectives and the overall proposal are sound 
and provide demonstrable improvement to the overall security of domain 
validation. Thank you for spearheading this!

Cheers,
-Clint

> On Sep 23, 2024, at 12:48 PM, Ryan Dickson via Servercert-wg 
>  wrote:
> 
> [Responding to the most recent message in the discussion, apologies if this 
> causes unexpected threading.]
> 
> Hi all,
> 
> Given the discussion thus far, I’d like to propose the following for the 
> group’s consideration in an effort to help guide a second round of discussion 
> (TBD, but expected to begin no earlier than September 30).
> 
> Objective 1: Enhance WHOIS/RDAP validation of gTLDs with comparable security 
> properties to DNS-based validation and sunset WHOIS/RDAP for ccTLDs.
> 
> Justification:
> A recent disclosure [1] demonstrated how threat actors could exploit 
> deficiencies in the WHOIS protocol and WHOIS tools served via HTTPS websites 
> to obtain fraudulent TLS certificates.
> Discussions within the Mozilla Dev Security Policy (MDSP) community [2] 
> further expressed corresponding risks related to WHOIS, while also noting 
> that ccTLDs may not maintain accurate or up-to-date WHOIS server records. 
> Several examples of inoperative WHOIS servers for ccTLDs were identified.
> Discussion in [3] further called into question the reliability of ccTLD WHOIS 
> servers given, per IANA, there is no global policy requirement for ccTLD 
> managers to operate a WHOIS server, and if they do, what kind of information 
> is provided.
> Solutions to strengthen existing WHOIS lookup methods were proposed in [4] 
> and are considered in this update.
> Approach:
> Add the following requirements in Sections 3.2.2.4.2 (“Email, Fax, SMS, or 
> Postal Mail to Domain Contact”), 3.2.2.4.12 (“Validating Applicant as a 
> Domain Contact”), and 3.2.2.4.15 (“Phone Contact with Domain Contact”).
> “Effective January 15, 2025, when issuing Subscriber Certificates…
> The CA MUST NOT rely on Domain Contact information obtained using an HTTPS 
> website, regardless of whether previously obtained information is within the 
> allowed reuse period.
> The CA MUST NOT rely on Domain Contact information obtained using the WHOIS 
> protocol (RFC 3912) or the Registry Data Access Protocol (RFC 7482) if the 
> requested Domain Name contains a ccTLD, regardless of whether previously 
> obtained information is within the allowed reuse period.
> When obtaining Domain Contact information using the WHOIS protocol, the CA 
> MUST query IANA's WHOIS server and follow referrals to the appropriate gTLD 
> WHOIS server.
> When obtaining Domain Contact information using the Registry Data Access 
> Protocol, the CA MUST utilize IANA's bootstrap file to identify and query the 
> correct RDAP server for the domain.
> The CA SHOULD NOT rely on cached 1) WHOIS server information or 2) RDAP 
> bootstrap data from IANA to ensure that it relies upon up-to-date and 
> accurate information.”
> 
> Objective 2: Sunset Methods 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to 
> Domain Contact”) and 3.2.2.4.15 (“Phone Contact with Domain Contact”).
> 
> Justification:
> While solutions to strengthen WHOIS-relying DCV methods are considered in 
> this update (above), there is limited public evidence of significant reliance 
> on these methods, including in response to [2] and [5].
> Instead, discussion has identified at least one CA Owner has already sunset 
> reliance on WHOIS [6], and another that has changed its approach [7] for 
> relying on WHOIS since disclosure of [1].
> More modern and heavily relied-upon DCV methods offer advantages over the 
> existing WHOIS-based methods, including greater opportunity for seamless 
> certificate lifecycle management automation (e.g., [8] and [9]), while also 
> benefiting from recently improved security practices [10]. These methods can 
> also more effectively align subscriber capabilities with agility and 
> resilience expectations necessary to respond to the revocation timelines 
> described in the TLS BRs [11].
> Beyond the above, previous discussions within the CA/Browser Forum have 
> raised concerns about the perceived value (e.g., [12]) and security (e.g., 
> [13]) of the DCV methods relying on WHOIS, further supporting the rationale 
> for their gradual sunset.
> Approach:
> Add the following requirements to Sections 3.2.2.4.2 (“Email, Fax, SMS, or 
> Postal Mail to Domain Contact”) and 3.2.2.4.15 (“Phone Contact with Domain 
> Contact”).

Re: [Servercert-wg] Voting Period Begins: Ballot SC-078 - Subject organizationName alignment for DBA / Assumed Name

[Clint Wilson via Servercert-wg]

Apple votes YES on Ballot SC-078.

> On Sep 17, 2024, at 6:20 AM, Martijn Katerbarg via Servercert-wg 
>  wrote:
> 
> Summary
> The TLS Baseline Requirements currently state an OV certificate may contain 
> either a DBA / Assumed Name or Legal Name. The EVGs and SBRs allow for the 
> common format of "DBA (Legal Name)". This ballot aims to align the practices 
> for OV certificates with this. 
> 
> While still allowing the inclusion of the sole DBA / Assumed Name, it will 
> also allow for the "DBA (Legal Name)" format to be used, allowing CAs to 
> align practices with the EVG and SBRs.
>  
> The following motion has been proposed by Martijn Katerbarg (Sectigo) and 
> endorsed by Clint Wilson (Apple) and Enrico Entschew (D-Trust).
>  
> Motion Begins
> MODIFY the "Baseline Requirements for the Issuance and Management of 
> Publicly-Trusted Certificates" ("Baseline Requirements") based on Version 
> 2.0.7 as specified in the following redline:
>  
> https://github.com/cabforum/servercert/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5...d69373c35ff72121a912b69b060ff89f32d41383
>  
> 
>  
> Motion Ends
>  
> This ballot proposes a Final Maintenance Guideline. The procedure for 
> approval of this ballot is as follows:
>  
> Discussion (at least 7 days)
> Start time: 2024-09-10 13:00 UTC
> End time: 2024-09-17 13:20 UTC
>  
> Vote for approval (7 days)
> Start time: 2024-09-17 13:20 UTC
> End time: 2024-09-24 13:20 UTC
>  
>  
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org 
> https://lists.cabforum.org/mailman/listinfo/servercert-wg



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] VOTING Period Begins - Ballot SC-077: Update WebTrust Audit name in Section 8.4 and References

[Clint Wilson via Servercert-wg]

Apple votes YES on Ballot SC-077

> On Aug 13, 2024, at 10:04 AM, Clint Wilson via Servercert-wg 
>  wrote:
> 
> Purpose of Ballot
> 
> CPA Canada has separated the audit criteria which map to the Network and 
> Certificate System Security Requirements (NCSSRs) from the audit criteria 
> which map to the TLS Baseline Requirements (TBRs). As a result, the 
> requirements in Section 8.4 are out of date for audits which use the 
> updated/separated audit criteria. However, we also need to ensure the 
> combined audit criteria are able to be used until fully deprecated by CPA 
> Canada and/or Root Programs stop accepting them.
> 
> This ballot modifies Section 8.4 to allow for a CA to be audited against 
> either:
> 
> WebTrust Principles and Criteria for Certification Authorities – SSL Baseline 
> with Network Security; or
> WebTrust Principles and Criteria for Certification Authorities – SSL Baseline 
> AND WebTrust Principles and Criteria for Certification Authorities – Network 
> Security
> Motion
> 
> The following motion has been proposed by Clint Wilson (Apple) and endorsed 
> by Dimitris Zacharopoulos (HARICA) and Trevoli Ponds-White (Amazon)
> 
> You can view and comment on the Github pull request representing this ballot 
> here <https://github.com/cabforum/servercert/pull/514/files>. 
> 
> 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.5 as specified in the following redline:
> 
> https://github.com/cabforum/servercert/compare/20af1b271f2b689344ae353d3e78dc6b772199db...a9d3e3b6e514cf8b4d44ace625a447108c04a91c
> Motion Ends
> 
> This ballot proposes a Final Maintenance Guideline. The procedure for 
> approval of this ballot is as follows:
> 
> Discussion (at least 7 days)
> 
> Start time: August 6, 2024 17:00 UTC
> End time: on or after August 13, 2024 17:00 UTC
> Vote for approval (7 days)
> 
> Start time: August 13, 2024 17:00 UTC
> End time: August 20, 2024 17:00 UTC
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

[Servercert-wg] VOTING Period Begins - Ballot SC-077: Update WebTrust Audit name in Section 8.4 and References

[Clint Wilson via Servercert-wg]

Purpose of Ballot

CPA Canada has separated the audit criteria which map to the Network and 
Certificate System Security Requirements (NCSSRs) from the audit criteria which 
map to the TLS Baseline Requirements (TBRs). As a result, the requirements in 
Section 8.4 are out of date for audits which use the updated/separated audit 
criteria. However, we also need to ensure the combined audit criteria are able 
to be used until fully deprecated by CPA Canada and/or Root Programs stop 
accepting them.

This ballot modifies Section 8.4 to allow for a CA to be audited against either:

WebTrust Principles and Criteria for Certification Authorities – SSL Baseline 
with Network Security; or
WebTrust Principles and Criteria for Certification Authorities – SSL Baseline 
AND WebTrust Principles and Criteria for Certification Authorities – Network 
Security
Motion

The following motion has been proposed by Clint Wilson (Apple) and endorsed by 
Dimitris Zacharopoulos (HARICA) and Trevoli Ponds-White (Amazon)

You can view and comment on the Github pull request representing this ballot 
here . 

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.5 as specified in the following redline:

https://github.com/cabforum/servercert/compare/20af1b271f2b689344ae353d3e78dc6b772199db...a9d3e3b6e514cf8b4d44ace625a447108c04a91c
Motion Ends

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

Discussion (at least 7 days)

Start time: August 6, 2024 17:00 UTC
End time: on or after August 13, 2024 17:00 UTC
Vote for approval (7 days)

Start time: August 13, 2024 17:00 UTC
End time: August 20, 2024 17:00 UTC

smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

[Servercert-wg] Discussion Period Begins - Ballot SC-077: Update WebTrust Audit name in Section 8.4 and References

[Clint Wilson via Servercert-wg]

Purpose of Ballot

CPA Canada has separated the audit criteria which map to the Network and 
Certificate System Security Requirements (NCSSRs) from the audit criteria which 
map to the TLS Baseline Requirements (TBRs). As a result, the requirements in 
Section 8.4 are out of date for audits which use the updated/separated audit 
criteria. However, we also need to ensure the combined audit criteria are able 
to be used until fully deprecated by CPA Canada and/or Root Programs stop 
accepting them.

This ballot modifies Section 8.4 to allow for a CA to be audited against either:

WebTrust Principles and Criteria for Certification Authorities – SSL Baseline 
with Network Security; or
WebTrust Principles and Criteria for Certification Authorities – SSL Baseline 
AND WebTrust Principles and Criteria for Certification Authorities – Network 
Security
Motion

The following motion has been proposed by Clint Wilson (Apple) and endorsed by 
Dimitris Zacharopoulos (HARICA) and Trevoli Ponds-White (Amazon)

You can view and comment on the Github pull request representing this ballot 
here . 

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.5 as specified in the following redline:

https://github.com/cabforum/servercert/compare/20af1b271f2b689344ae353d3e78dc6b772199db...a9d3e3b6e514cf8b4d44ace625a447108c04a91c
Motion Ends

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

Discussion (at least 7 days)

Start time: August 6, 2024 17:00 UTC
End time: on or after August 13, 2024 17:00 UTC
Vote for approval (7 days)

Start time: TBD
End time: TBD

smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

[Servercert-wg] Seeking Endorsers and Feedback - SC-077: Update WebTrust Audit name in Section 8.4 and References

[Clint Wilson via Servercert-wg]

Hello all,

I think it’s worth getting the WebTrust audit criteria titles and references 
updated in the TBRs before a CA runs up against a non-compliance that’s really 
avoidable :)
I threw together this Pull Request: 
https://github.com/cabforum/servercert/pull/514/files. I’ve also added the 
Ballot to the wiki (so hopefully I successfully picked an unreserved ballot 
number).

When I last brought this up, I believe Dimitris had volunteered to endorse; is 
that still the case? Is there anyone else willing/able to endorse this? 
(Apologies in advance if I’ve forgotten a second endorser in the interim!)

I would also appreciate any feedback or suggestions on the ballot changes 
themselves, of course!

Cheers,
-Clint

smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] Voting Period Begins - Ballot SC-067 V3: "Require domain validation and CAA checks to be performed from multiple Network Perspectives"

[Clint Wilson via Servercert-wg]

Apple votes YES on Ballot SC-067 V3.

> On Jul 15, 2024, at 8:29 AM, Chris Clements via Servercert-wg 
>  wrote:
> 
> Purpose of Ballot SC-067 V3:
> 
> This Ballot proposes updates to the Baseline Requirements for the Issuance 
> and Management of Publicly-Trusted TLS Server Certificates (i.e., TLS BRs) 
> related to “Multi-Perspective Issuance Corroboration” (“MPIC”).
> 
> Background:
> 
> - MPIC refers to performing domain validation and CAA checks from multiple 
> Network Perspectives before certificate issuance, as described within the 
> Ballot for the applicable validation methods in TLS BR Sections 3.2.2.4 and 
> 3.2.2.5.
> - Not all methods described in TLS BR Sections 3.2.2.4 and 3.2.2.5 will 
> require using MPIC.
> - This work was most recently motivated by research presented at Face-to-Face 
> 58 [1] by Princeton University, but has been discussed for years prior as 
> well.
> - The goal of this proposal is to make it more difficult for adversaries to 
> successfully launch equally-specific prefix attacks against the domain 
> validation processes described in the TLS BRs.
> - Additional background information can be found in an update shared at 
> Face-to-Face 60 [2].
> 
> Benefits of Adoption:
> 
> - Recent publicly-documented attacks have used BGP hijacks to fool domain 
> control validation and obtain malicious certificates, which led to the 
> impersonation of HTTPS websites [3][4].
> - Routing security defenses (e.g., RPKI) can mitigate the risk of global BGP 
> attacks, but localized, equally-specific BGP attacks still pose a significant 
> threat to the Web PKI [5][6].
> - Corroborating domain control validation checks from multiple network 
> perspectives (i.e., MPIC) spread across the Internet substantially reduces 
> the threat posed by equally-specific BGP attacks, ensuring the integrity of 
> domain validation and issuance decisions [5][7][8].
> - Existing deployments of MPIC at the scale of millions of certificates a day 
> demonstrate the feasibility of this technique at Internet scale [7][9].
> 
> Intellectual Property (IP) Disclosure:
> 
> - While not a Server Certificate Working Group Member, researchers from 
> Princeton University presented at Face-to-Face 58, provided academic 
> expertise, and highlighted publicly-available peer-reviewed research to 
> support Members in drafting this ballot.
> - The Princeton University researchers indicate that they have not filed for 
> any patents relating to their MPIC work and do not plan to do so in the 
> future.
> - Princeton University has indicated that it is unable to agree to the 
> CA/Browser Forum IPR agreement because it could encumber inventions invented 
> by researchers not involved in the development of MPIC or with the CA/B Forum.
> - Princeton University has instead provided the attached IPR statement. 
> Pursuant to the IPR statement, Princeton University has granted a worldwide 
> royalty free license to the intellectual property in MPIC developed by the 
> researchers and has made representations regarding its lack of knowledge of 
> any other Princeton intellectual property needed to implement MPIC.
> - The attached IPR statement has not changed since disclosed in Discussion 
> Round 1.
> - For clarity, Princeton University’s IPR statement is NOT intended to 
> replace the Forum’s IPR agreement or allow Princeton to participate in the 
> Forum in any capacity.
> - Members seeking legal advice regarding this ballot should consult their own 
> counsel.
> 
> Proposal Revision History:
> 
> - Pre-Ballot Release #1 (work team artifacts and broader Validation 
> Subcommittee collaboration) [10]
> - Pre-Ballot Release #2 [11]
> 
> Previous versions of this Ballot:
> 
> - Ballot Release #1 [12] (comparing Version 2 to Version 1) [13]. Note, some 
> of the changes represented in the comparison are updates made by other 
> ballots that have since passed (e.g., SC-069).
> - Ballot Release #2 [14] (comparing Version 3 to Version 2) [15]. Note, some 
> of the changes represented in the comparison are updates made by other 
> ballots that have since passed (e.g., SC-072).
> 
> References:
> [1] 
> https://cabforum.org/wp-content/uploads/13-CAB-Forum-face-to-face-multiple-vantage-points.pdf
> [2] 
> https://drive.google.com/file/d/1LTwtAwHXcSaPVSsqKQztNJrV2ozHJ7ZL/view?usp=drive_link
>  
> [3] 
> https://medium.com/s2wblog/post-mortem-of-klayswap-incident-through-bgp-hijacking-en-3ed7e33de600
>  
> [4] https://www.coinbase.com/blog/celer-bridge-incident-analysis 
> [5] 
> https://www.usenix.org/conference/usenixsecurity23/presentation/cimaszewski  
> [6] 
> https://www.blackhat.com/docs/us-15/materials/us-15-Gavrichenkov-Breaking-HTTPS-With-BGP-Hijacking-wp.pdf
>  
> [7] https://www.usenix.org/conference/usenixsecurity21/presentation/birge-lee 
> [8] https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee 
> [9] 
> https://security.googleblog.com/2023/05/google-trust-services-acme-api_0503894189.html
>  
> [10]

Re: [Servercert-wg] [Voting Begins] Ballot SC-75 v3 - Pre-sign linting

[Clint Wilson via Servercert-wg]

Apple votes YES on Ballot SC-75 v3 - Pre-sign linting.

Thanks to all involved for the diligent efforts in establishing consensus and 
moving this forward! :)

> On Jun 19, 2024, at 3:13 AM, Dimitris Zacharopoulos (HARICA) via 
> Servercert-wg  wrote:
> 
> Voting begins for this ballot.
> SC-75 v3 Pre-sign linting
> 
> Summary
> 
> There have been numerous compliance incidents publicly disclosed by CAs in 
> which they failed to comply with the technical requirements described in 
> standards associated with the issuance and management of publicly-trusted TLS 
> Certificates. However, the industry has developed open-source tools, linters, 
> that are free to use and can help CAs avoid certificate misissuance. Using 
> such linters before issuing a precertificate from a Publicly-Trusted CA 
> (pre-issuance linting) can prevent the mis-issuance in a wide variety of 
> cases.
> 
> The following motion has been proposed by Dimitris Zacharopoulos of HARICA 
> and endorsed by Corey Bonnell of Digicert and Ben Wilson of Mozilla.
> 
> You can view the GitHub pull request representing this ballot here 
> . 
> 
> Motion Begins
> 
> MODIFY the "Baseline Requirements for the Issuance and Management of 
> Publicly-Trusted TLS Server Certificates" based on Version 2.0.5 as specified 
> in the following redline:
> 
> https://github.com/cabforum/servercert/compare/20af1b271f2b689344ae353d3e78dc6b772199db...d809c41bc063109e15d46bfe1b5ad6403d823381
> Motion Ends
> 
> This ballot proposes a Final Maintenance Guideline. The procedure for 
> approval of this ballot is as follows:
> 
> Discussion (at least 7 days)
> 
> Start time: 2024-06-12 06:30:00 UTC
> End time: on or after 2024-06-19 06:30:00 UTC
> Vote for approval (7 days)
> 
> Start time: 2024-06-19 10:00:00 UTC
> End time: 2024-06-26 10:00:00 UTC
> 
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] Discussion Period Begins - Ballot SC-067 V3: "Require domain validation and CAA checks to be performed from multiple Network Perspectives"

[Clint Wilson via Servercert-wg]

Hi Roman,

I think it’s because these developments are at an early stage (amongst other 
reasons) that it doesn’t make sense to postpone the ballot. I don’t see 
anything super concrete indicating that this project will alter the industry’s 
approach to MPIC adoption, and I believe something pretty substantive would be 
necessary in order for it to make sense to adopt this external project as a 
dependency for updating policy requirements in the TBRs.

Cheers,
-Clint

> On Jun 4, 2024, at 12:47 AM, Roman Fischer via Servercert-wg 
>  wrote:
> 
> Dear all,
>  
> I was informed by direct mail about the following which I find very 
> interesting and wanted to share here:
>  
> Princeton researchers are working on an open source implementation of MPIC 
> and are looking for collaborators: 
> https://freedom-to-tinker.com/2024/02/13/announcing-the-open-multi-perspective-issuance-corroboration-project/.
>  The first version of the API specification is on github 
> .
>  
> As these developments seem to be in an early stage, wouldn’t it make sense to 
> postpone this ballot until at least a first draft of this open source 
> implementation is available? I don’t think it makes sense that each CA 
> invents their own protocols and possibly makes avoidable mistakes coding / 
> implementing this non-trivial topic..
>  
> Kind regards
> Roman
>  
> From: Servercert-wg  > On Behalf Of Chris Clements via 
> Servercert-wg
> Sent: Montag, 20. Mai 2024 16:30
> To: CA/B Forum Server Certificate WG Public Discussion List 
> mailto:servercert-wg@cabforum.org>>
> Subject: [Servercert-wg] Discussion Period Begins - Ballot SC-067 V3: 
> "Require domain validation and CAA checks to be performed from multiple 
> Network Perspectives"
>  
> Purpose of Ballot SC-067 V3:
>  
> This Ballot proposes updates to the Baseline Requirements for the Issuance 
> and Management of Publicly-Trusted TLS Server Certificates (i.e., TLS BRs) 
> related to “Multi-Perspective Issuance Corroboration” (“MPIC”).
>  
> Background:
>  
> - MPIC refers to performing domain validation and CAA checks from multiple 
> Network Perspectives before certificate issuance, as described within the 
> Ballot for the applicable validation methods in TLS BR Sections 3.2.2.4 and 
> 3.2.2.5.
> - Not all methods described in TLS BR Sections 3.2.2.4 and 3.2.2.5 will 
> require using MPIC.
> - This work was most recently motivated by research presented at Face-to-Face 
> 58 [1] by Princeton University, but has been discussed for years prior as 
> well.
> - The goal of this proposal is to make it more difficult for adversaries to 
> successfully launch equally-specific prefix attacks against the domain 
> validation processes described in the TLS BRs.
> - Additional background information can be found in an update shared at 
> Face-to-Face 60 [2].
>  
> Benefits of Adoption:
>  
> - Recent publicly-documented attacks have used BGP hijacks to fool domain 
> control validation and obtain malicious certificates, which led to the 
> impersonation of HTTPS websites [3][4].
> - Routing security defenses (e.g., RPKI) can mitigate the risk of global BGP 
> attacks, but localized, equally-specific BGP attacks still pose a significant 
> threat to the Web PKI [5][6].
> - Corroborating domain control validation checks from multiple network 
> perspectives (i.e., MPIC) spread across the Internet substantially reduces 
> the threat posed by equally-specific BGP attacks, ensuring the integrity of 
> domain validation and issuance decisions [5][7][8].
> - Existing deployments of MPIC at the scale of millions of certificates a day 
> demonstrate the feasibility of this technique at Internet scale [7][9].
>  
> Intellectual Property (IP) Disclosure:
>  
> - While not a Server Certificate Working Group Member, researchers from 
> Princeton University presented at Face-to-Face 58, provided academic 
> expertise, and highlighted publicly-available peer-reviewed research to 
> support Members in drafting this ballot.
> - The Princeton University researchers indicate that they have not filed for 
> any patents relating to their MPIC work and do not plan to do so in the 
> future.
> - Princeton University has indicated that it is unable to agree to the 
> CA/Browser Forum IPR agreement because it could encumber inventions invented 
> by researchers not involved in the development of MPIC or with the CA/B Forum.
> - Princeton University has instead provided the attached IPR statement. 
> Pursuant to the IPR statement, Princeton University has granted a worldwide 
> royalty free license to the intellectual property in MPIC developed by the 
> researchers and has made representations regarding its lack of knowledge of 
> any other Princeton intellectual property needed to implement MPIC.
> - The attached IPR statement has not changed since disclosed in Discussion 
> Round 1.
> - For clarity, Prin

Re: [Servercert-wg] [External Sender] Discussion about single-purpose client authentication leaf certificates issued from a server TLS Issuing CA

[Clint Wilson via Servercert-wg]

Hi Pedro,

All CAs in the Apple Root Program are required to complete an audit based on 
either WebTrust Principles and Criteria for Certification Authorities or ETSI 
EN 319 411-1 LCP, NCP, or NCP+ per Section 1.1.1 of the ARP Policy. For 
clientAuth-only CAs, these are currently the only audit criteria.

I appreciate the comment regarding TLS CAs; I’ll look at improving this 
language, but this specifically is referencing CAs capable of asserting the 
serverAuth EKU as clientAuth is not required for TLS. That is, the serverAuth 
EKU is required at a protocol level to establish a secure TLS connection, while 
the clientAuth EKU is only used in specific contexts, such as mTLS — which is 
almost always a use-case better (or perhaps more ideally) solved by Enterprise 
or Private PKIs.

Thanks!
-Clint

> On May 17, 2024, at 2:32 AM, Pedro FUENTES  wrote:
> 
> I also oversaw that…
> 
> Anyhow… @Clint, what are the audit requirements for these clientAuth CAs?
> In your program you mention WTBR as a requirement for "TLS CAs”, but there’s 
> no distinction between clientAuth or serverAuth… while both are used to 
> secure TLS handshakes.
> 
>> On 17 May 2024, at 11:22, Dimitris Zacharopoulos (HARICA) 
>>  wrote:
>> 
>> 
>> 
>> On 16/5/2024 10:29 μ.μ., Clint Wilson wrote:
 AFAIK Apple and Mozilla also don't have a specific "trust bit" for Client 
 Authentication. Only Microsoft does.
>>> FWIW, Apple does indeed have a specific trust bit for id-kp-clientAuth EKU 
>>> and allows for (and ships) dedicated clientAuth Root CAs in the Apple Root 
>>> Program (as outlined in 2.1.3 of the ARP Policy).
>>> 
>> 
>> Thanks for the correction Clint. I had the impression that you shipped only 
>> Apple Roots for clientAuth. My bad.
>> 
>> Dimitris.
>> 
>> 
>> 
> 
> 
> WISeKey SA
> Pedro Fuentes
> CSO - Trust Services Manager
> Office: + 41 (0) 22 594 30 00
> Mobile: + 41 (0) 791 274 790
> Address: Avenue Louis-Casaï 58 | 1216 Cointrin | Switzerland
> Stay connected with WISeKey 
> 
> THIS IS A TRUSTED MAIL: This message is digitally signed with a WISeKey 
> identity. If you get a mail from WISeKey please check the signature to avoid 
> security risks
> 
> CONFIDENTIALITY: This email and any files transmitted with it can be 
> confidential and it’s intended solely for the use of the individual or entity 
> to which they are addressed. If you are not the named addressee you should 
> not disseminate, distribute or copy this e-mail. If you have received this 
> email in error please notify the sender
> 
> DISCLAIMER: WISeKey does not warrant the accuracy or completeness of this 
> message and does not accept any liability for any errors or omissions herein 
> as this message has been transmitted over a public network. Internet 
> communications cannot be guaranteed to be secure or error-free as information 
> may be intercepted, corrupted, or contain viruses. Attachments to this e-mail 
> are checked for viruses; however, we do not accept any liability for any 
> damage sustained by viruses and therefore you are kindly requested to check 
> for viruses upon receipt.
> 



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] [External Sender] Discussion about single-purpose client authentication leaf certificates issued from a server TLS Issuing CA

[Clint Wilson via Servercert-wg]

> AFAIK Apple and Mozilla also don't have a specific "trust bit" for Client 
> Authentication. Only Microsoft does.

FWIW, Apple does indeed have a specific trust bit for id-kp-clientAuth EKU and 
allows for (and ships) dedicated clientAuth Root CAs in the Apple Root Program 
(as outlined in 2.1.3 of the ARP Policy).



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] [External Sender] Discussion about single-purpose client authentication leaf certificates issued from a server TLS Issuing CA

[Clint Wilson via Servercert-wg]

> On May 16, 2024, at 1:19 AM, Dimitris Zacharopoulos (HARICA) 
>  wrote:
> 
> 
> 
> On 15/5/2024 11:07 μ.μ., Clint Wilson wrote:
>> Hi Dimitris,
>> 
>> I guess I’m confused about how this is relevant to the scope of the CA/BF as 
>> it seems quite orthogonal to the questions you posed initially. Regardless 
>> of how clients check certificates, the question is about the issuance of a 
>> certificate.
>> As a side-note, the question that comes to mind for me is what would be the 
>> reason to allow issuance of clientAuth-only certificates by a subCA that 
>> also issues TBR-compliant TLS certificates? Why is such a thing necessary or 
>> valuable? 
> 
> This is easy to answer. Some use cases need single-purpose client 
> authentication certificates. There are numerous use cases where client 
> authentication certificates are used for strong authentication, I'm sure you 
> are aware of such use cases. While client authentication use cases can ALL be 
> supported by non-public CAs, there are some regulatory requirements that 
> demand such certificates be issued from an audited and publicly-trusted CA. 
> In fact, HARICA has participated in public tenders where client 
> authentication certificates need to be issued from a CA that chains to Apple, 
> Microsoft and Mozilla Root Stores. Client authentication certificates are 
> asked in addition to server TLS certificates.
> 
> The good practice here is for the CA to create a TC non-TLS SubCA that 
> includes the id-kp-clientAuth EKU and issue single-purpose client 
> authentication certificates off of that TC SubCA. However, some CAs might 
> have used a TLS SubCA, that also includes the id-kp-clientAuth EKU, to issue 
> those single-purpose client authentication certificates. This was allowed 
> before SC-62.

Right, fully agreed here — and a step further, beyond being a good practice, I 
think it’s the only compliant practice. The way to do this is through a 
dedicated clientAuth subCA if using a multi-purpose Root CA.

> 
>> Regardless of the conclusion to the questions you posed, I’m failing to see 
>> why we would want any other outcome than to have subCAs which issue 
>> TBR-compliant TLS certificate always and only issue TBR-compliant TLS 
>> certificates. Perhaps if you could help me understand the motivations behind 
>> seeking clarity on this, I would be better able to understand how/why these 
>> questions have been posed (even if those motivations are simple idle 
>> curiosity, that would still help).
> 
> I don't object to the change of the goal from "we don't really care so much 
> about non-TLS server leaf certificates" to "we only want server TLS-capable 
> CAs to issue server TLS leaf certificates". There's a difference. I'm trying 
> to establish if the prohibition of single-purpose clientAuth certs was 
> intended in SC-62 or not. To the best of my recollection, we didn't intend to 
> enforce that, "only server TLS leaf certificates are to be issued from server 
> TLS-capable Issuing CAs".

(Just to confirm, you don’t object to this change?)
Ah, this is quite interesting (genuinely) as my understanding is that one of, 
if not the, primary goals of SC-62 was to ensure only TLS leaf certificates 
could be issued from server TLS-capable CAs. This was done by ensuring the 
allowed uses of CA Key material in-scope of the TBRs are comprehensively 
defined as certificate profiles.

> 
> This is why I insisted in establishing the past motivation before the group 
> decides where to go. Based on this outcome , we can add more clarity in the 
> BRs. To put this very clearly, if we didn't intend to enforce that only 
> server TLS leaf certs should be issued from server TLS-capable CAs, then the 
> current language that prohibits issuance of single-purpose client 
> authentication certificates from server TLS-capable CAs, is an unintended 
> prohibition that we should fix it. If no CA is interested to lift this 
> prohibition, then we should just add clarification language that every 
> certificate issued from a server TLS-capable Issuing CA is in scope of the 
> TLS BRs and it MUST be a leaf server-TLS Certificate which MAY have 
> additional EKUs (as described in the corresponding table in the BRs). If the 
> group decides to lift this unintended prohibition, we could add rules around 
> the policy OIDs (e.g. that the TLS BR OIDs must not be used in no-TLS server 
> certificates).

This makes sense to me; it is relevant to understand the intended outcome in 
addition to the outcome itself. I think there’s agreement that the outcome 
itself has been to prohibit the issuance of single-purpose client 
authentication certificates from server TLS-capable CAs. 
As far as the intended outcome, I believe that’s roughly the same as the 
outcome itself, though there was also discussion of further updates with the 
hypothetical future “Profiles 2.0” ballot that a fair number of items were 
pushed off to. For example, the current allowance for anyPolicy in som

Re: [Servercert-wg] [External Sender] Discussion about single-purpose client authentication leaf certificates issued from a server TLS Issuing CA

[Clint Wilson via Servercert-wg]

Hi Dimitris,

I guess I’m confused about how this is relevant to the scope of the CA/BF as it 
seems quite orthogonal to the questions you posed initially. Regardless of how 
clients check certificates, the question is about the issuance of a certificate.
As a side-note, the question that comes to mind for me is what would be the 
reason to allow issuance of clientAuth-only certificates by a subCA that also 
issues TBR-compliant TLS certificates? Why is such a thing necessary or 
valuable? Regardless of the conclusion to the questions you posed, I’m failing 
to see why we would want any other outcome than to have subCAs which issue 
TBR-compliant TLS certificate always and only issue TBR-compliant TLS 
certificates. Perhaps if you could help me understand the motivations behind 
seeking clarity on this, I would be better able to understand how/why these 
questions have been posed (even if those motivations are simple idle curiosity, 
that would still help).

However, leaving aside that there’s likely some level of ignorance on my part, 
to the extent I understand it, the question at hand is essentially: 
Is it compliant for a CA, that wants to be considered compliant with the TBRs, 
to issue a certificate which asserts compliance with the TBRs — by way of 
including an OID under the CA/BF OID arc defined to represent a certificate’s 
compliance with the Policy document associated with that OID — where the issued 
certificate does not match one of the profiles defined in Section 7.1 of the 
TBRs?

Breaking this apart, there are several aspects to consider.

First, does the CA want to be considered compliant with the TBRs? If not, then 
it doesn’t matter which TBR OIDs they assert because they’re not intending to 
be considered compliant. If the CA doesn’t have a relying party they’re 
expecting to rely on their assertions in general, then the rest of the question 
is relatively moot; on the other hand, if the CA’s assertions are intended to 
be accurate and treated as such, then it’s a pretty important foundational 
point I think. For the purposes of this discussion, I’m assuming the CA does 
want to be considered compliant with the TBRs because if that’s not the case 
then the conclusions to the rest of this don’t really matter.

Second, are TBR OIDs defined by their node owner as representing compliance 
with the TLS Baseline Requirements? Based on what’s documented in 
https://cabforum.org/resources/object-registry/, I believe this is clearly the 
case. For example, issuing a certificate with the 2.23.140.1.2.2 OID is a 
representation that the “Certificate [was] issued in compliance with the TLS 
Baseline Requirements – Organization identity asserted”. Maybe this should be 
brought into 7.1.6.1 of the TBRs, but I don’t think that’s necessary to come to 
a conclusion here.

Third, does inclusion of a TBR OID in a certificate issued by such a CA 
constitute that CA asserting that certificate’s compliance with the TBRs? 
Combined with the fact that the OID itself defines this to be the case, my 
reading of Section 4.2.1.4 
 of RFC 5280[1] 
is that if a Policy OID is present in a certificate — or any certificate 
subordinate to a certificate in which it’s present — then the certificate has 
been issued under the Policy document represented by that OID.

Fourth, does a certificate which meets the above conditions (i.e. wants to be 
considered compliant, includes a TBR OID), need to match one of the profiles in 
the TBRs? Section 7.1 announces quite clearly that "the CA SHALL issue 
Certificates in accordance with the profile specified in these Requirements” 
and further reinforces in Section 7.1.2 that (emphasis mine) "If the CA asserts 
compliance with these Baseline Requirements, all certificates that it issues 
MUST comply with one of the following certificate profiles”. There are possible 
problematic interpretations of this, but I find it difficult to grasp a truly 
good-faith reading of this as meaning anything other than “Yes, a certificate 
which includes a TBR OID is asserting compliance with the TBRs and thus, the 
certificate itself must comply with one of the certificate profiles defined in 
the TBRs.” That doesn’t mean there’s not room to improve the language, 
especially in 7.1.2 (which I’ve highlighted before in Issue 495 
(https://github.com/cabforum/servercert/issues/495)). 
I personally also think the statements in 7.1 and 7.1.2 go quite a bit further 
than just this constrained example of a certificate which explicitly indicates 
its own compliance with the TBRs, but to keep the discussion focused I’m only 
opining on that specific scenario.

Fifth, does the certificate match one of the profiles defined in Section 7.1 of 
the TBRs? Here we have to look at the certificate in question, with a couple 
components quickly narrowing our search within Section 7.1. In your first 
email, you indicated the question is about a leaf certif

Re: [Servercert-wg] [External Sender] Discussion about single-purpose client authentication leaf certificates issued from a server TLS Issuing CA

[Clint Wilson via Servercert-wg]

Apologies if I’m replying to the wrong thread, but I wanted to comment on one 
point here.

> On May 14, 2024, at 8:54 AM, Dimitris Zacharopoulos (HARICA) via 
> Servercert-wg  wrote:
> 
> 
> 
> On 14/5/2024 1:27 μ.μ., Adriano Santoni via Servercert-wg wrote:
>> I would agree to consider out-of-scope (of the BRs) a leaf certificate with 
>> EKU=clientAuth issued by a SubCA that has EKU={server,client}, provided of 
>> course the leaf certificate does not assert a BR TLS policy OID because this 
>> would be contradictory. 
>> 
>> Besides, at least one widely used linter considers a certificate in-scope if 
>> it contains EKU=serverAuth and/or it contains a BR policy OID, which seems 
>> quite logical to me.
>> 
>> Adriano
>> 
>> 
>> 
> 
> I think the policy OID is effectively completely ignored (along with anything 
> in the subject of the certificate or other extensions) because the 
> certificate is by design "incompatible for server TLS", so it is discarded by 
> server TLS consumers which are conformant with RFC 5280.

I don’t think it’s entirely germane whether or not the policy OID is discarded 
by an application; the inclusion of the policy OID itself is a violation of RFC 
5280 by the CA (if it’s included in a certificate or certificate chain where 
the leaf certificate being validated doesn’t comply with the policy referenced 
by the OID).

Thanks!
-Clint

> 
> It is misleading, but it is very difficult to add requirements around what a 
> Certificate MUST NOT include (e.g. an existing TLS BR policy OID). I'd prefer 
> to clarify that these are out-of-scope of the BRs as long as they are 
> structured according to RFC 5280, and do not contain EKU=serverAuth, just 
> like we did for the TC non-TLS subCA Profile.
> 
> Dimitris.
> 
>> 
>> Il 14/05/2024 11:33, Dimitris Zacharopoulos (HARICA) via Servercert-wg ha 
>> scritto:
>>> 
>>> NOTICE: Pay attention - external email - Sender is 
>>> 0100018f76738e97-739d5cad-6797-4977-b997-150e338d5740-000...@amazonses.com 
>>> 
>>> 
>>> Dear Members, 
>>> 
>>> Following-up on an interesting public incident 
>>>  , I would like 
>>> to have a discussion about the scope of the TLS BRs as specified in the 
>>> SCWG Charter and in the actual TLS BRs, especially when it comes to 
>>> single-purpose "client authentication" certificates (i.e. leaf certificates 
>>> that include the id-kp-clientAuth and DO NOT include the id-kp-serverAuth 
>>> KeyPurposeId in their extKeyUsage extension).
>>> The TLS BRs describe the profiles of Subordinate CA Certificates issued 
>>> from a Root that is in-scope for server TLS authentication, even for the 
>>> case of Technically-Constrained non-TLS CA Certificates. There was a lot of 
>>> discussion about whether this is permitted based on the SCWG Charter and 
>>> there was consensus that Browsers want to make sure that there are some 
>>> minimum expectations about the structure of such non-TLS CA certificates, 
>>> especially the adherence to RFC 5280. I recall that there was also 
>>> consensus that whatever is issued off of these TC non-TLS CAs is not in 
>>> scope of the TLS BRs.
>>> 
>>> Does this seem like a fair statement about intent of the group on the 
>>> expectations of TC non-TLS CAs and their leaf certificates?
>>> 
>>> Technically Constrained non-TLS Issuing CAs have a defined profile in the 
>>> TLS BRs but IMO it cannot, and should not mandate the profile of non-TLS 
>>> leaf certificates based on the CA/Browser Forum Server Certificate Working 
>>> Group Charter  which 
>>> states (emphasis mine):
>>> 
 (a) To specify Baseline Requirements, Extended Validation Guidelines, and 
 other acceptable practices for the issuance and management of TLS server 
 certificates used for authenticating servers accessible through the 
 Internet
>>> It gets more interesting when an Issuing CA that is technically capable of 
>>> issuing server authentication TLS Certificates (by including the 
>>> id-kp-serverAuth KeyPurposeId in its extKeyUsage extension), also includes 
>>> the id-kp-clientAuth KeyPurposeId, thus being technically capable of 
>>> issuing client authentication TLS Certificates.
>>> 
>>> Please recall that a few years back multi-purpose Issuing CAs existed, 
>>> where the EKU was not present, and even if it was, it allowed the inclusion 
>>> of various KeyPurposeIds.
>>> 
>>> Is it ok for such an Issuing CA to create a single-purpose client 
>>> authentication TLS Certificate, one that is structured according to RFC 
>>> 5280 (thus can be successfully parsed by Relying Party RFC 5280-conformant 
>>> software), contains an extKeyUsage extension which contains the 
>>> id-kp-clientAuth and DOES NOT include the id-kp-serverAuth KeyPurposeId?
>>> 
>>> My understanding is that these particular leaf certificates are

Re: [Servercert-wg] Timeline for compromised key blocking

[Clint Wilson via Servercert-wg]

Hi Aaron,

This seems reasonable to me. It might also be worth adding a similar timeline 
to 6.1.1.5.(1) so that, under a circumstance in which the Debian-weak-keys repo 
is updated, there is some amount of time for CAs to ensure their own systems 
are also updated. Since that repo is under the control of the CA/BF, we should 
know ahead of time if it’s going to be updated, so maybe it’s not really 
necessary, but just a thought.

Cheers,
-Clint

> On May 8, 2024, at 2:15 PM, Aaron Gable via Servercert-wg 
>  wrote:
> 
> Section 6.1.1.3 (4) of the Baseline Requirements (as of Ballot SC-073) says 
> "The CA SHALL reject a certificate request if... the CA has previously been 
> notified that the Applicant's Private Key has suffered a Key Compromise using 
> the CA's procedure for revocation request".
> Section 4.9.1.1 (3) of the Baseline Requirements says "The CA SHALL revoke a 
> Certificate within 24 hours... if... the CA obtains evidence that the 
> Subscriber's Private Key... suffered a Key Compromise".
> 
> Imagine the following hypothetical:
> 1. A CA issues a certificate containing a particular public key.
> 2. The private key corresponding to that public key is compromised, and this 
> compromise is reported via the CA's revocation request procedure.
> 3. _Immediately_ thereafter, the CA receives another request for a 
> certificate containing the same public key.
> 
> Is the CA required to reject the certificate request in Step 3?
> 
> Arguments for "yes":
> * By virtue of being notified via the revocation request procedure, the CA 
> has been made aware of the compromise, and therefore must reject it.
> 
> Arguments for "no":
> * It is obviously impossible for a CA to _immediately_ begin rejecting such 
> requests; this is why CAs have a 24-hour timeline for revocation.
> * The relevant text in Section 4.9.1.1 uses the phrase "obtains evidence" 
> rather than "made aware", so perhaps the CA is only "made aware" of the key 
> compromise somewhere later in the revocation and blocking process.
> 
> If I were to propose a ballot which introduces a 24-hour timeline into 
> Section 6.1.1.3 (4), would others be willing to endorse?
> 
> Thanks,
> Aaron
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] Ballot SC-74 - Clarify CP/CPS structure according to RFC 3647

[Clint Wilson via Servercert-wg]

Hi Tim,

> On May 10, 2024, at 8:52 AM, Tim Hollebeek via Servercert-wg 
>  wrote:
> 
> Whether the comparison should be case sensitive or not is not a question of 
> how “strict” the linter should be, but what the requirements are.  Linters 
> MUST NOT make their own determinations as to what the requirements are, and 
> SHOULD highlight cases like this where ambiguity may be present.  For 
> example, it would be sensible to WARN that a value deviates in case from the 
> correct value, and that the requirements are unclear whether that’s allowed 
> (assuming SC-74 had passed in its current form).
>  
> However, I would question whether it’s actually even unclear at all.  It’s 
> impossible to interpret the highlighted language into a, b, or c, because the 
> language is completely silent on not just capitalization, but the titles 
> themselves.  I interpret the highlighted language as saying you have to 
> include at least every section and subsection, but it doesn’t matter what 
> titles you give those sections or subsections (since there’s no relevant 
> requirements).  That’s what the highlighted text says, and questions of 
> whether it has to be capitalized the same way miss the fact that it doesn’t 
> even say the same titles need to be used.
>  
> There are also some hilarious errors in 3647 if you look closely.  I think 
> the best path forward would be something along the lines of:
>  
> MUST include at least every section and subsection defined in Appendix ZZ, 
> and MUST use the section and subsection titles listed there
> The titles SHOULD be formatted, worded, capitalized and spelled the same way, 
> and
> Errors in formatting or titling sections of a CPS are not grounds for 
> revocation of affected certificates. 

Overall agreed with what’s stated here, except this part of the proposal. I do 
agree with what I believe your intent to be, but depending on how this is 
worded it seems it could lead to overly broad application (e.g. the error in 
titling “Non-verified subscriber information” results in a title of “Verified 
subscriber information”). Mostly just drawing attention to it as something that 
would need to be crafted somewhat carefully and perhaps would be preferable to 
have the MUST and SHOULD sections worded specifically enough that the intended 
allowance for errors in formatting or titling are encapsulated as clearly not 
part of the MUST requirement and clearly part of the SHOULD requirement. That 
approach would also avoid (I think) needing to consider the interaction of 
something like #3 with 4.9.1.2.(5).

Cheers,
-Clint

> And then explicitly list the outline we want in Appendix ZZ.  The outline 
> should be very close to what 3647 says, to avoid unnecessary churn or 
> deviation from IETF standards, but it would give us a chance to fix the 
> obvious errors, and perhaps fix some historical baggage.
>  
> The resulting outline could be submitted back to IETF for publication as an 
> update to 3647, which is starting to show its age.
>  
> -Tim
>  
> From: Servercert-wg  > On Behalf Of Roman Fischer via 
> Servercert-wg
> Sent: Friday, May 10, 2024 4:20 AM
> To: CA/B Forum Server Certificate WG Public Discussion List 
> mailto:servercert-wg@cabforum.org>>
> Subject: Re: [Servercert-wg] Ballot SC-74 - Clarify CP/CPS structure 
> according to RFC 3647
>  
> Hi Wendy,
>  
> I would definitely go for c) because the documents are overall not 
> standardized enough to do any kind of automatic parsing where a) or b) would 
> maybe help.
>  
> Rgds
> Roman
>  
> From: Servercert-wg  > On Behalf Of Wendy Brown - 
> QT3LB-C via Servercert-wg
> Sent: Donnerstag, 9. Mai 2024 16:58
> To: Aaron Gable mailto:aa...@letsencrypt.org>>
> Cc: CA/B Forum Server Certificate WG Public Discussion List 
> mailto:servercert-wg@cabforum.org>>
> Subject: Re: [Servercert-wg] Ballot SC-74 - Clarify CP/CPS structure 
> according to RFC 3647
>  
> OK - then I have a question for all those voting on SC74 (as an Associate 
> member rep, I do not have a vote)
> How do you interpret the proposed new language:
> include at least every section and subsection defined in section 6 of RFC 3647
>  
> Does this mean:
> a) that the section and subsection headers have to exactly match the text in 
> RFC 3647 including its use of capitalization, or 
> b) just that the words must be the same or 
> c) you just have to have the same numbering and the title can be slightly 
> different as long as it covers the intended content?
>  
> Sorry to not have asked this during the discussion period, until I saw the 
> output of the linter Aaron prepared, it didn't occur to me that anyone would 
> have interpreted it as the capitalization had to match.
>  
> thanks,
> Wendy
>  
> Wendy Brown
> Supporting GSA
> FPKIMA Technical Liaison
> Protiviti Government Services
> 703-965-2990 (cell)
>  
>  
> On Thu, May 9, 2024 at 10:33 AM Aaron Gable  

Re: [Servercert-wg] [External Sender] Question regarding the id-ad-caIssuers accessMethod URI

[Clint Wilson via Servercert-wg]

I did a quick check, but was only able to find one recently issued leaf 
certificate that contained an https CA Issuers URI. There seems to be about 26 
CA certificates that do as well, but all were issued before 2019 except for 2. 
Of the 1 leaf and 2 CA certificates that are more recent, they’re all from CAs 
that have very limited root inclusion in the ecosystem and do not participate 
in the CA/BF afaict.

Not sure how relevant all that is, but just to share what I’d found. I’m sure 
others could do a more thorough job, but I don’t see clear signs that this is a 
widespread issue at least (phew! :)

Cheers,
-Clint

> On Apr 30, 2024, at 11:40 PM, Dimitris Zacharopoulos (HARICA) 
>  wrote:
> 
> Thanks Clint,
> 
> It would help doing some research in CENSYS to see if this is a real problem 
> or not. I will try to get some additional resources internally to help me 
> with this. In any case, this discussion might inspire some of the linting 
> software developers to write a lint expecting only http:// URLs in that field.
> 
> 
> Best regards,
> Dimitris.
> 
> On 1/5/2024 12:52 π.μ., Clint Wilson wrote:
>> Hi Dimitris,
>> 
>> My understanding is that the intent was indeed to restrict these to HTTP 
>> specifically. That is, the phrase “the only URLS present MUST be HTTP URLs” 
>> is intended to preclude the use of HTTPS, and not just to indicate that any 
>> scheme which relies on the Hypertext Transfer Protocol can be used.
>> 
>> Presumably when 5280 was drafted, the authors were aware of the updates 2817 
>> made to 2616, but chose not to reference those updates. Even if not, I 
>> concur with Ryan and my recollection is also that the discussion during 
>> SC-62’s formation did include this topic with the consensus (at that time) 
>> being that some fields would be restricted to using only HTTP URIs.
>> 
>> To your original questions:
>> Do Members agree with that interpretation? 
>> 
>> Yes
>> 
>> 
>> If this is the correct interpretation, would it be considered a 
>> violation of the BRs if a CA or end-entity certificate contains https:// 
>> URL in the id-ad-caIssuers accessMethod ? 
>> 
>> Yes, at least for certificates issued after SC-62 went into effect (maybe 
>> also for those prior, I just haven’t looked).
>> 
>> 
>> I'm afraid that this might not be as clear in the BRs as it should be, 
>> so if people agree with the above, we should probably update section 
>> 7.1.2.7.7 
>> 
>>  (and possibly other parts) to explicitly state that the allowed scheme 
>> is "http" and not "https", just like we do for the CRLDP in section 
>> 7.1.2.11.2 
>> 
>>  . 
>> 
>> I’m not convinced a clarification is worthwhile here. To be clear, I’m not 
>> opposed, I’m just not sure it’s something CAs are actively getting or likely 
>> to get wrong — if some are, then I would instead support such a 
>> clarification.
>> 
>> Cheers!
>> -Clint
>> 
>>> On Apr 25, 2024, at 5:41 AM, Dimitris Zacharopoulos (HARICA) via 
>>> Servercert-wg  
>>>  wrote:
>>> 
>>> Hi Ryan,
>>> 
>>> The question is not between HTTP vs FTP vs LDAP but specifically for "HTTP 
>>> URL" that could have two schemes "http" and "https".
>>> 
>>> RFC 2616 (June 1999) included only "http" and was updated in May 2000 by 
>>> RFC 2817  to include TLS 
>>> Within HTTP/1.1 ("https").
>>> 
>>> I hope this clarifies the issue.
>>> 
>>> 
>>> Dimitris.
>>> 
>>> On 25/4/2024 3:29 μ.μ., Ryan Dickson via Servercert-wg wrote:
 It's my understanding that the intent of the updates made in SC-62 were to 
 prohibit any non-HTTP URI. This was discussed in:
 
 1) at least one historical GitHub discussion 
  (referenced in ballot 
 preamble 
 ):
 
 "authorityInformationAccess: This is a new requirement.
 BRs 7.1.2.2 (c) notes that it SHOULD contain the HTTP URL of the Issuing 
 CA's certificate and MAY contain the HTTP URL of the Issuing CA's OCSP 
 responder.
 Some questions were raised about whether this means other URLs, other 
 schemes, or multiple URLs can be included. Similar to 
 crlDistributionPoints, the ordering of URLs implies processing semantics 
 on clients, and only particular URL schemes are supported. Namely, if one 
 of the two supported access methods are present (CA issuer or OCSP), then 
 the only URLs present MUST be HTTP URLs, and MUST be listed in order of 
 priority.
 This prohibits the use of other access methods, as they are not used in 
 the Web PKI."
 
 and 2) Corey's Validation Subcom

Re: [Servercert-wg] [External Sender] Question regarding the id-ad-caIssuers accessMethod URI

[Clint Wilson via Servercert-wg]

Hi Dimitris,

My understanding is that the intent was indeed to restrict these to HTTP 
specifically. That is, the phrase “the only URLS present MUST be HTTP URLs” is 
intended to preclude the use of HTTPS, and not just to indicate that any scheme 
which relies on the Hypertext Transfer Protocol can be used.

Presumably when 5280 was drafted, the authors were aware of the updates 2817 
made to 2616, but chose not to reference those updates. Even if not, I concur 
with Ryan and my recollection is also that the discussion during SC-62’s 
formation did include this topic with the consensus (at that time) being that 
some fields would be restricted to using only HTTP URIs.

To your original questions:
 Do Members agree with that interpretation? 

Yes

 
 If this is the correct interpretation, would it be considered a violation 
 of the BRs if a CA or end-entity certificate contains https:// URL in the 
 id-ad-caIssuers accessMethod ? 

Yes, at least for certificates issued after SC-62 went into effect (maybe also 
for those prior, I just haven’t looked).

 
 I'm afraid that this might not be as clear in the BRs as it should be, so 
 if people agree with the above, we should probably update section 
 7.1.2.7.7 
 
  (and possibly other parts) to explicitly state that the allowed scheme is 
 "http" and not "https", just like we do for the CRLDP in section 
 7.1.2.11.2 
 
  . 

I’m not convinced a clarification is worthwhile here. To be clear, I’m not 
opposed, I’m just not sure it’s something CAs are actively getting or likely to 
get wrong — if some are, then I would instead support such a clarification.

Cheers!
-Clint

> On Apr 25, 2024, at 5:41 AM, Dimitris Zacharopoulos (HARICA) via 
> Servercert-wg  wrote:
> 
> Hi Ryan,
> 
> The question is not between HTTP vs FTP vs LDAP but specifically for "HTTP 
> URL" that could have two schemes "http" and "https".
> 
> RFC 2616 (June 1999) included only "http" and was updated in May 2000 by RFC 
> 2817  to include TLS Within 
> HTTP/1.1 ("https").
> 
> I hope this clarifies the issue.
> 
> 
> Dimitris.
> 
> On 25/4/2024 3:29 μ.μ., Ryan Dickson via Servercert-wg wrote:
>> It's my understanding that the intent of the updates made in SC-62 were to 
>> prohibit any non-HTTP URI. This was discussed in:
>> 
>> 1) at least one historical GitHub discussion 
>>  (referenced in ballot 
>> preamble 
>> ):
>> 
>> "authorityInformationAccess: This is a new requirement.
>> BRs 7.1.2.2 (c) notes that it SHOULD contain the HTTP URL of the Issuing 
>> CA's certificate and MAY contain the HTTP URL of the Issuing CA's OCSP 
>> responder.
>> Some questions were raised about whether this means other URLs, other 
>> schemes, or multiple URLs can be included. Similar to crlDistributionPoints, 
>> the ordering of URLs implies processing semantics on clients, and only 
>> particular URL schemes are supported. Namely, if one of the two supported 
>> access methods are present (CA issuer or OCSP), then the only URLs present 
>> MUST be HTTP URLs, and MUST be listed in order of priority.
>> This prohibits the use of other access methods, as they are not used in the 
>> Web PKI."
>> 
>> and 2) Corey's Validation Subcommittee presentation at F2F 56 
>> 
>>  (slide 14 
>> ,
>>  "Non-HTTP (i.e., LDAP and FTP) OCSP and CA Issuers URIs are prohibited").
>> 
>> D-Trust volunteered to propose an update to the BRs to address the issue in 
>> this  Bugzilla Bug 
>> (Actions Table).
>> 
>> Thanks,
>> Ryan
>> 
>> On Thu, Apr 25, 2024 at 3:44 AM Adriano Santoni via Servercert-wg 
>> mailto:servercert-wg@cabforum.org>> wrote:
>>> Hi,
>>> 
>>> IMO, including an HTTPS URI in the id-ad-caIssuers accessMethod is at least 
>>> a bad practice and very unwise (if done on purpose), as it may give rise to 
>>> unbounded loops, as it is clearly explained in RFC5280:
>>> 
>>> 
  CAs SHOULD NOT include URIs that specify https, ldaps, or similar
 schemes in extensions.  CAs that include an https URI in one of these
 extensions MUST ensure that the server's certificate can be validated
 without using the information that is pointed to by the URI.  Relying
 parties that choose to validate the server's certificate when
 obtaining information pointed to by an https URI in the
 cRLDistributionPoints, authorityInfoAcces

Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

[Clint Wilson via Servercert-wg]

Hi Wayne,

That was indeed my intent, but I’m happy with the proposal either way.

Thank you,
-Clint

> On Apr 12, 2024, at 12:33 PM, Wayne Thayer  wrote:
> 
> Thank you Clint and Aaron, this is helpful. Here is what I propose:
> 
>> In the case of Debian weak keys vulnerability 
>> ([https://wiki.debian.org/SSLkeys)]), the CA SHALL reject all keys found at 
>> [https://github.com/cabforum/debian-weak-keys/] for each key type (e.g. RSA, 
>> ECDSA) and size listed in the repository. For all other key types and sizes, 
>> the CA SHALL reject Debian weak keys.
> 
> This change can be viewed in context 
> https://github.com/wthayer/servercert/pull/1/files
> 
> This language allows us to add key sizes in the future without updating the 
> TLS BRs.
> 
> Clint Wilson: I did not exclude key sizes larger than 8192 RSA/521 ECDSA bits 
> from the requirements but would be happy to do so if you will confirm that 
> this was your intent?
> 
> Rob Stradling: I would like to import your repo to 
> github.com/cabforum/Debian-weak-keys 
> <http://github.com/cabforum/Debian-weak-keys>. May I have your permission to 
> do so?
> 
> Thanks,
> 
> Wayne
> 
> On Thu, Apr 11, 2024 at 10:11 AM Clint Wilson  <mailto:cli...@apple.com>> wrote:
>> Hi Aaron,
>> 
>> Your proposed phrasing sounds good to me and matches what I had in mind as 
>> the end result of the changes represented in Set 1, just structured slightly 
>> differently.
>> 
>> Cheers,
>> -Clint
>> 
>>> On Apr 11, 2024, at 9:47 AM, Aaron Gable >> <mailto:aa...@letsencrypt.org>> wrote:
>>> 
>>> On Thu, Apr 11, 2024 at 9:12 AM Clint Wilson via Servercert-wg 
>>> mailto:servercert-wg@cabforum.org>> wrote:
>>>> In other words, I believe it satisfactory to establish a constrained set 
>>>> of Debian weak keys which CAs must block (rather than leaving the 
>>>> requirement fully open-ended), but I don’t believe that should obviate the 
>>>> need for a CA to check uncommon key sizes — which are otherwise in the key 
>>>> size ranges of that constrained set’s key sizes — should a CA allow those 
>>>> uncommon key sizes. 
>>> 
>>> I completely concur. 
>>> 
>>> I don't think that either of your Set 1 / Set 2 proposals quite hits the 
>>> mark for me, for one reason: they both contain the phrase "CAs must not 
>>> issue certificates containing Debian weak keys". As long as that statement 
>>> exists, the requirement is "evaluate everything yourself, and if new sets 
>>> of weak keys come to light, you're already behind" -- the existence of the 
>>> github repo is just a nicety.
>>> 
>>> Instead, I would phrase the requirement as "In the case of [list of common 
>>> RSA and ECDSA key sizes] Debian Weak Keys, the CA SHALL reject keys 
>>> identified by [link to CABF repository]. For other key sizes, the CA SHALL 
>>> reject Debian Weak Keys."
>>> 
>>> In other words -- for these common key sizes, the repository is the source 
>>> of truth. Every key in it is considered compromised and must be blocked, 
>>> but you don't need to waste time replicating the work of generating all of 
>>> these keys to prove to yourself that it has been done correctly. If you 
>>> want to issue for other key sizes, then the onus is on you to do the 
>>> relevant due diligence.
>>> 
>>> Aaron
>> 



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

[Clint Wilson via Servercert-wg]

Hi Aaron,

Your proposed phrasing sounds good to me and matches what I had in mind as the 
end result of the changes represented in Set 1, just structured slightly 
differently.

Cheers,
-Clint

> On Apr 11, 2024, at 9:47 AM, Aaron Gable  wrote:
> 
> On Thu, Apr 11, 2024 at 9:12 AM Clint Wilson via Servercert-wg 
> mailto:servercert-wg@cabforum.org>> wrote:
>> In other words, I believe it satisfactory to establish a constrained set of 
>> Debian weak keys which CAs must block (rather than leaving the requirement 
>> fully open-ended), but I don’t believe that should obviate the need for a CA 
>> to check uncommon key sizes — which are otherwise in the key size ranges of 
>> that constrained set’s key sizes — should a CA allow those uncommon key 
>> sizes. 
> 
> I completely concur. 
> 
> I don't think that either of your Set 1 / Set 2 proposals quite hits the mark 
> for me, for one reason: they both contain the phrase "CAs must not issue 
> certificates containing Debian weak keys". As long as that statement exists, 
> the requirement is "evaluate everything yourself, and if new sets of weak 
> keys come to light, you're already behind" -- the existence of the github 
> repo is just a nicety.
> 
> Instead, I would phrase the requirement as "In the case of [list of common 
> RSA and ECDSA key sizes] Debian Weak Keys, the CA SHALL reject keys 
> identified by [link to CABF repository]. For other key sizes, the CA SHALL 
> reject Debian Weak Keys."
> 
> In other words -- for these common key sizes, the repository is the source of 
> truth. Every key in it is considered compromised and must be blocked, but you 
> don't need to waste time replicating the work of generating all of these keys 
> to prove to yourself that it has been done correctly. If you want to issue 
> for other key sizes, then the onus is on you to do the relevant due diligence.
> 
> Aaron



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

[Clint Wilson via Servercert-wg]

Hi Wayne,

Agreed, your proposal [1] is basically what I was describing; I only added that 
it would be useful, in my mind, to add a repository usable by Certificate 
Issuers (but not required to be used) similar to what we’ve provided for ROCA 
and Close Primes.

However, based on the discussion today, I think both of the below sets of 
changes make sense to me, though I sensed consensus on the call leaning towards 
the first set of changes. Set 2 is intended to be the same as what I previously 
described in Option 2.

I believe the only clarification I’ve added in Set 1, beyond what Aaron and Tim 
discussed, is the addition of a requirement for key sizes other than those 
specifically represented in a known complete (at this time) repository of 
Debian weak keys for common key sizes. At least, that was my only intentional 
addition, so if the described set of changes don’t otherwise align with the 
proposal represented in Aaron and Tim’s discussion, please let me know. 
In other words, I believe it satisfactory to establish a constrained set of 
Debian weak keys which CAs must block (rather than leaving the requirement 
fully open-ended), but I don’t believe that should obviate the need for a CA to 
check uncommon key sizes — which are otherwise in the key size ranges of that 
constrained set’s key sizes — should a CA allow those uncommon key sizes. 

I want to further clarify that I do expect any such repository representing 
this constrained set of Debian weak keys to be updated in the future if some 
meaningful change is identified to Debian weak keys generated in the included 
key size ranges, but this approach would allow that to be a structured process 
within the CA/BF, rather than some “surprise, here’s a random def con preso; 
block all the keys it describes as being possible to generate yesterday please” 
situation as we could otherwise (and currently) encounter.

Set 1:
1) Create a CA/BF repo with presently known Debian weak keys for the key sizes 
RSA 2048, 3072, 4096, 8192; ECC 256, 384, 521 (the repo Rob pointed to seems 
the most complete from what I’ve seen, but no particularly strong opinions here)
2) Update TBRs: For RSA key sizes or smaller than 8193 bits and ECC key sizes 
smaller than 522 bits, CAs must not issue certificates containing Debian weak 
keys
3) Update TBRs: Include a reference to the above CA/BF repo as the set of 
Debian weak keys which meet the requirement of 2) specifically for the key 
sizes RSA 2048, 3072, 4096, 8192; ECC 256, 384, 521 included in that repo
4) Update TBRs: Add an explanatory note clarifying that if a CA allows for 
issuance of certificates other than RSA 2048, 3072, 4096, 8192; ECC 256, 384, 
521, the CA must ensure certificates containing any other key size do not 
contain a Debian weak key

Set 2:
1) Create a CA/BF repo with presently known Debian weak keys for the key sizes 
RSA 2048, 3072, 4096, 8192; ECC 256, 384, 521
2) Update TBRs: For RSA key sizes smaller than 8193 bits and ECC key sizes 
smaller than 522 bits, CAs must not issue certificates containing Debian weak 
keys
3) Update TBRs: Include a reference to the above CA/BF repo as an optional 
resource for CAs to use in checking for Debian weak keys

I hope I’m contributing something useful to this discussion; please reach out 
if I could do better here.

Thank you!
-Clint

[1] https://github.com/wthayer/servercert/pull/1/files

> On Apr 10, 2024, at 11:51 AM, Wayne Thayer  wrote:
> 
> Hi Clint,
> 
> I think my latest proposal [1] is essentially what you are proposing in 
> option #2, the only difference being that we would add repositories 
> containing weak keys to https://cabforum.org/resources/tools/ (and we can do 
> that without a ballot). If you are instead proposing that we require CAs to 
> check for a specified weak keys contained in one or more repositories, then 
> that is similar to Aaron's proposal except that I understand you want to 
> require CAs to also check for weak keys even if they sign non-standard key 
> sizes that are not included in the repository of weak keys.
> 
> The more I think about the two approaches, the more I prefer my current 
> proposal [1] that does not require CAs to check for specific keys found in 
> one or more repositories. The reason is that I believe CAs already have 
> Debian weak key checks in place and would likely prefer not to have to change 
> their systems to use different logic/data to meet the same requirement as 
> before.
> 
> Thanks,
> 
> Wayne
> 
> [1] https://github.com/wthayer/servercert/pull/1/files
> 
> 
> 
> On Tue, Apr 9, 2024 at 2:26 PM Clint Wilson  > wrote:
>> Hi Wayne,
>> 
>> I think this does seem like it could be a tractable solution, however I’d 
>> like to understand why one of the proposals I’ve brought up a couple times 
>> on the calls isn’t also a suitable option. From what I can gather, they’re 
>> nearly identical in practical impact, but one provides a much more defined 
>> boundary fo

Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

[Clint Wilson via Servercert-wg]

Hi Wayne,

I think this does seem like it could be a tractable solution, however I’d like 
to understand why one of the proposals I’ve brought up a couple times on the 
calls isn’t also a suitable option. From what I can gather, they’re nearly 
identical in practical impact, but one provides a much more defined boundary 
for relying parties. 

Option 1:
The CA/BF creates or mirrors a repository of pre-computed Debian Weak keys for 
the following key sizes (representing those most commonly issued against): RSA 
2048, 3072, 4096, 8192; ECC 256, 384, 521. The TBRs stipulate that CAs must not 
issue certificates containing keys in this repository.

Option 2:
The CA/BF creates or mirrors a repository of pre-computed Debian Weak keys for 
the following key sizes (representing those most commonly issued against): RSA 
2048, 3072, 4096, 8192; ECC 256, 384, 521. The TBRs stipulate that CAs must not 
issue certificates containing weak keys, with a pointer to the repository of 
the most common key sizes of Debian Weak keys among other similar/relevant 
pointers for other vulnerabilities.

The reason these 2 proposals are so nearly identical in practice is that there 
are only a very tiny number of certificates issued against key sizes that are 
not RSA 2048, 3072, 4096, or 8192; or ECC 256, 384, or 521. By my count, 
somewhere around 80 certificates out of roughly 750 million (though I really 
only took a quick glance, so perhaps this is off to an extent… but probably not 
by huge quantities).

Under Option 2, if a CA wants to allow for Certificate requests containing a 
key size other than these 7, they’re fully free to do so; they must merely 
ensure the key is not a Debian Weak key. For every other CA, they can limit the 
accepted key sizes to those in the repository and the result is functionally 
the same as Option 1, but without the possibility of “certificates can be 
issued that are weak and CAs are under no obligation to prevent that if it’s 
not one of 7 key sizes”.

Concretely, is there a reason Option 2 is intractable for CAs? If so, I would 
greatly appreciate help understanding how that approach meaningfully differs 
from Option 1.

Thanks,
-Clint

> On Apr 9, 2024, at 11:43 AM, Rob Stradling via Servercert-wg 
>  wrote:
> 
> > * Aaron Gable commented in the PR with a suggestion that we require CAs to 
> > reject any key found in Hanno Bock's repository at 
> > https://github.com/badkeys/debianopenssl. This includes RSA 
> > 1024/2048/3072/4096 and EC P256/P384 keys.
> 
> Some of the EC key files in Hanno's repository have ASN.1 encoding issues 
> (see 
> https://www.mail-archive.com/dev-security-policy@mozilla.org/msg00911.html); 
> whereas the equivalent files inhttps://github.com/CVE-2008-0166/private_keys 
> are correctly encoded.
> 
> > * Roman Fischer suggested that we limit the requirement to check Debian 
> > weak keys only with sizes up to RSA 4096 under the logic that no one would 
> > “accidentally” create an 8192 bit RSA key on a system vulnerable to Debian 
> > Weak keys
> 
> FWIW, https://github.com/CVE-2008-0166/private_keys already has all of the 
> possible 8192-bit RSA Debian weak keys.
> 
> From: Servercert-wg  > on behalf of Wayne Thayer via 
> Servercert-wg mailto:servercert-wg@cabforum.org>>
> Sent: 05 April 2024 23:47
> To: CA/B Forum Server Certificate WG Public Discussion List 
> mailto:servercert-wg@cabforum.org>>
> Subject: Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal
>  
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> Two new alternatives have been proposed in addition to the one I proposed 
> below:
> 
> * Aaron Gable commented in the PR with a suggestion that we require CAs to 
> reject any key found in Hanno Bock's repository 
> athttps://github.com/badkeys/debianopenssl. This includes RSA 
> 1024/2048/3072/4096 and EC P256/P384 keys. We might prefer to reference a 
> clone in the CAB Forum GitHub org (or some other source of the actual 
> generated weak keys) but that's a detail we can work out if others like this 
> approach.
> * Roman Fischer suggested that we limit the requirement to check Debian weak 
> keys only with sizes up to RSA 4096 under the logic that no one would 
> “accidentally” create an 8192 bit RSA key on a system vulnerable to Debian 
> Weak keys
> 
> Each of these methods has the benefit of adding clarity to the Debian 
> requirement rather than just maintaining the existing language, but they also 
> [arguably] allow CAs to issue certs containing abnormally sized Debian weak 
> keys.
> 
> I would like to hear from other members (especially Apple) if you prefer or 
> object to either of these alternatives?
> 
> Thanks,
> 
> Wayne
> 
> On Thu, Mar 28, 2024 at 4:13 PM Wayne Thayer via Servercert-wg 
> mailto:servercert-wg@cabforum.org>> wrote:
> There was further discuss

Re: [Servercert-wg] [Voting Period Begins]: SC-72 - Delete except to policyQualifiers in EVGs; align with BRs by making them NOT RECOMMENDED

[Clint Wilson via Servercert-wg]

Apple votes YES on Ballot SC-072.

> On Mar 25, 2024, at 5:00 AM, Paul van Brouwershaven via Servercert-wg 
>  wrote:
> 
> This ballot updates the TLS Extended Validation Guidelines (EVGs) by removing 
> the exceptions to policyQualifiers​ in section 9.7, to align them with the 
> Baseline Requirements (BRs).
> 
> The following motion has been proposed by Paul van Brouwershaven (Entrust) 
> and endorsed by Dimitris Zacharopoulos (HARICA) and Iñigo Barreira (Sectigo).
> 
> --- Motion Begins ---
> 
> This ballot modifies the “Guidelines for the Issuance and Management of 
> Extended Validation Certificates” (“EV Guidelines”) as follows, based on 
> version 1.8.1:
> 
> MODIFY the Extended Validation Guidelines as specified in the following 
> redline: 
> https://github.com/cabforum/servercert/compare/8e7fc7d5cac0cc27c44fe2aa88cf45f5606f4b94...7b9bb1dbfd41b1d0459b8a985ed629ad841ce122
>  
> 
> --- Motion Ends ---
> 
> Discussion (at least 7 days):
> - Start: 2024-03-15 10:00 UTC
> - End no earlier than 2024-03-22 10:00 UTC
> 
> Vote for approval (7 days):
> - Start: 2024-03-25 12:00 UTC
> - End: 2024-04-01 12:00 UTC
> 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. 
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org 
> https://lists.cabforum.org/mailman/listinfo/servercert-wg



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] [External Sender] Re: [EXTERNAL]- Subject attribute encoding order requirement (rationale for)

[Clint Wilson via Servercert-wg]

Hi Adriano,

I haven’t looked through minutes and such yet, but as I recall this ordering 
was discussed a number of times on Validation Subcommittee calls during the 
creation of SC-062 (i.e. sometime in 2020-2023). The resultant ordering 
originated from the combination of 3 primary sources:
1. X.509/X.520
2. RFC 5280
3. WG Consensus

I think there’s additional discussion in the link that Jaime provided that’s 
relevant as well:

chrisbn May 13, 2022
How would fields need to be handled that are not in the current list? E.g. 
subject:businessCategory or subject:jurisdictionLocalityName from EVG? I'm also 
interested to know if there's a source for this requirement, or what's the 
driver for the ordering?

sleevi May 13, 2022
You mean, where would these be sorted?
These are requirements derived from the semantics of RFC 5280 and X.509. A DN 
is hierarchical in semantic naming, and an RDN with multiple elements is saying 
that these names are semantically equivalent hierarchically.
For the name forms listed, they are not semantically equivalent (e.g. a 
countryName is not the same hierarchy as a localityName / interchangeable 
with), and there is a semantic hierarchy.
These are already existing logical requirements, just being made explicit.

chrisbn May 13, 2022
Yes, I wonder about the order of fields not in this list.
I understand the hierarchy to order logic, but is the order defined in Section 
7.1.4.2 based on an existing specification, or how did we come to this ordering?

sleevi May 13, 2022
It is based on the definitions within X.509 and X.520, given these fields are 
generally geographical in nature.
That said, there’s definitely flexibility here to get us closer to consistency 
among CAs, which is a key point of profiling, so if there are changes and 
concerns, it’s totally appropriate to highlight.
Prior relevant art includes RFC 2377 
[https://datatracker.ietf.org/doc/html/rfc2377], RFC 1218 
[https://www.rfc-editor.org/rfc/rfc1218.html], and RFC 1255 
[https://www.rfc-editor.org/rfc/rfc1255]

Cheers,
-Clint



> On Mar 21, 2024, at 2:06 AM, Adriano Santoni via Servercert-wg 
>  wrote:
> 
> Thank you Jaime , but I had already checked that.
> 
> At that link I can only find the following very short exchange between 
> chrisbn and sleevi:
> 
> 
>> @chrisbn chrisbn May 13, 2022
>> Yes, I wonder about the order of fields not in this list.
>> I understand the hierarchy to order logic, but is the order defined in 
>> Section 7.1.4.2 based on an existing specification, or how did we come to 
>> this ordering?
>> @sleevi sleevi May 13, 2022
>> It is based on the definitions within X.509 and X.520, given these fields 
>> are generally geographical in nature.
>> That said, there’s definitely flexibility here to get us closer to 
>> consistency among CAs, which is a key point of profiling, so if there are 
>> changes and concerns, it’s totally appropriate to highlight.
> 
> That does not seem to clarify much, so I suppose there is more somewhere else.
> 
> No discussion of the mailing list? No discussion in SCWG calls?
> 
> Adriano
> 
> 
> 
> 
> 
> Il 21/03/2024 09:52, Jaime Hablutzel ha scritto:
>> The discussion in 
>> https://github.com/sleevi/cabforum-docs/pull/36#discussion_r872103477 could 
>> help.
>> 
>>> On 21 Mar 2024, at 09:39, Adriano Santoni via Servercert-wg 
>>>   wrote:
>>> 
>>> All, can anyone help me find the past email discussion, or at least the 
>>> rationale that someone wrote somewhere (e.g. on Github?), supporting the 
>>> Subject attributes encoding relative order requirement that was introduced 
>>> in BR 2.0.0 (Ballot SC-062) ? 
>>> 
>>> I am talking about §7.1.4.2 Subject Attribute Encoding, and specifically 
>>> about this language:
>>> 
>>> "CAs that include attributes in the Certificate subject field that are 
>>> listed in the table below
>>> SHALL encode those attributes in the relative order as they appear in the 
>>> table and follow the
>>> specified encoding requirements for the attribute."
>>> 
>>> I do not recall, and cannot find, a discussion on this mailing list on this 
>>> particular topic. Maybe I just missed a whole bunch of email messages due 
>>> to some otherwise undetected email problem. I also did a search on Github, 
>>> starting from the links provided at 
>>> https://cabforum.org/2023/03/17/ballot-sc62v2-certificate-profiles-update/),
>>>  but was unable to figure out who proposed it and, above all, for what 
>>> reason.
>>> 
>>> Adriano
>>> ___
>>> Servercert-wg mailing list
>>> Servercert-wg@cabforum.org 
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_servercert-2Dwg&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=TmnUymVu4aN7JJUi7E4FNf5W7JAuYX7-j6JtyhXK9EAAxJqhk7RvTa9sOsMmibge&s=pzZ-HMcq_CggzRO87gqT5_XxYy9n5hIbsxrERd7c_so&e=
>> 
> _

Re: [Servercert-wg] [EXTERNAL] [Discussion Period Begins]: SC-72 - Delete except to policyQualifiers in EVGs; align with BRs by making them NOT RECOMMENDED

[Clint Wilson via Servercert-wg]

Hi Paul,

There are a lot of ways that the EVGs differ from the TBRs; that’s basically 
the point of them, as I understand it. Specifically it’s within the profiles 
that most non-process-oriented differences can be found between EV, OV, IV, and 
DV TLS certificates. Are all of these differences issues which should be 
addressed by the WG to bring EV TLS certificates more in line with the leaner 
profiles found in the TBRs?

I don’t see how this is a genuine misalignment between the TBRs and the EVGs. I 
could possibly see a misalignment between RFC 5280 and the EVGs, but even there 
it’s very intentional that allowance is given such that individual use-cases 
can successfully be addressed without violating the RFC.

From https://datatracker.ietf.org/doc/html/rfc2119#section-4: (emphasis mine)
"SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.”

From https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.4:
"To promote interoperability, this profile RECOMMENDS that policy
   information terms consist of only an OID.  Where an OID alone is
   insufficient, this profile strongly recommends that the use of
   qualifiers be limited to those identified in this section.”

In both cases, it’s clear to me, when encountering a SHOULD, SHOULD NOT, 
RECOMMENDS, or NOT RECOMMENDED that the expectation is for CAs to individually 
assess what is the most appropriate action to take. That doesn’t sound like a 
misalignment, so much as an acknowledgement of potential nuance and the need 
for additional consideration. As you say, they shouldn’t "unless they have a 
good reason to" — such as the EV Guidelines explicitly requiring 
policyQualifiers.

I don’t have any particular concern with the change itself, to be clear, but 
the motivation behind this — and the abruptness of the introduction of the 
topic — remain opaque to me.

Thank you,
-Clint

> On Mar 15, 2024, at 9:09 AM, Paul van Brouwershaven 
>  wrote:
> 
> Hi Clint,
> 
> If the BRs specified MAY and the EVGs MUST you can put it in both and thus 
> have profile alignment. After this changed from MAY to NOT RECOMMENDED we end 
> up with a conflicting requirement, while allowed, its expected that CAs 
> adhere to a NOT RECOMMENDED unless they have a good reason to do so.
> 
> While it's possible to implement two different policies this does creates a 
> clear misalignment.
> 
> Paul
> 
> From: Clint Wilson
> Sent: Friday, March 15, 2024 17:00
> To: Paul van Brouwershaven; ServerCert CA/BF
> Subject: [EXTERNAL] Re: [Servercert-wg] [Discussion Period Begins]: SC-72 - 
> Delete except to policyQualifiers in EVGs; align with BRs by making them NOT 
> RECOMMENDED
> 
> Hi,
> 
> Could the ballot author and endorsers please provide some additional 
> explanation and context surrounding this ballot? As far as I can recall, this 
> topic hasn’t been discussed since SC-062, so it’s rather coming out of 
> nowhere as a ballot proposal (which is, of course, totally fine, but also 
> still abrupt/confusing). Why is this difference between the TBRs and the EVGs 
> necessary/valuable for the WG to address at the moment?
> 
> You indicate that this is a discrepancy introduced by Ballot SC-062, but I 
> don’t see how that’s the case. Before SC-062, the TBRs specified 
> policyQualifiers as Optional and after as NOT RECOMMENDED. Neither of these 
> match the MUST present in the EVGs and both of these are 
> compatible/non-conflicting with the MUST present in the EVGs.
> 
> Thanks,
> -Clint
> 
> 
> 
> On Mar 15, 2024, at 3:01 AM, Paul van Brouwershaven via Servercert-wg 
>  wrote:
> 
> This ballot updates the TLS Extended Validation Guidelines (EVGs) by removing 
> the exceptions topolicyQualifiers​ in section 9.7, to align them with the 
> Baseline Requirements (BRs).As result, this ballot changes policyQualifiers​ 
> from MUST​ to NOT RECOMMENDED​ as stated in the TLS Baseline Requirements, 
> resolving a discrepancy introduced byBallot SC-62v2 
>  
> between section 7.1.2.7.9 Subscriber Certificate Policies 
> 
>  of the BRs and the Additional Technical Requirements for EV Certificates 
> 
>  in the EVGs.
> 
> The following motion has been proposed by Paul van Brouwershaven (Entrust) 
> and endorsed by Dimitris Zacharopoulos (HARICA) and Iñigo Barreira (Sectigo).
> 
> You can view and comment on the GitHub pull request representing this ballot 
> here:https://github.

Re: [Servercert-wg] [Discussion Period Begins]: SC-72 - Delete except to policyQualifiers in EVGs; align with BRs by making them NOT RECOMMENDED

[Clint Wilson via Servercert-wg]

Hi,

Could the ballot author and endorsers please provide some additional 
explanation and context surrounding this ballot? As far as I can recall, this 
topic hasn’t been discussed since SC-062, so it’s rather coming out of nowhere 
as a ballot proposal (which is, of course, totally fine, but also still 
abrupt/confusing). Why is this difference between the TBRs and the EVGs 
necessary/valuable for the WG to address at the moment?

You indicate that this is a discrepancy introduced by Ballot SC-062, but I 
don’t see how that’s the case. Before SC-062, the TBRs specified 
policyQualifiers as Optional and after as NOT RECOMMENDED. Neither of these 
match the MUST present in the EVGs and both of these are 
compatible/non-conflicting with the MUST present in the EVGs.

Thanks,
-Clint



> On Mar 15, 2024, at 3:01 AM, Paul van Brouwershaven via Servercert-wg 
>  wrote:
> 
> This ballot updates the TLS Extended Validation Guidelines (EVGs) by removing 
> the exceptions to policyQualifiers​ in section 9.7, to align them with the 
> Baseline Requirements (BRs).As result, this ballot changes policyQualifiers​ 
> from MUST​ to NOT RECOMMENDED​ as stated in the TLS Baseline Requirements, 
> resolving a discrepancy introduced byBallot SC-62v2 
>  
> between section 7.1.2.7.9 Subscriber Certificate Policies 
> 
>  of the BRs and the Additional Technical Requirements for EV Certificates 
> 
>  in the EVGs.
> 
> The following motion has been proposed by Paul van Brouwershaven (Entrust) 
> and endorsed by Dimitris Zacharopoulos (HARICA) and Iñigo Barreira (Sectigo).
> 
> You can view and comment on the GitHub pull request representing this ballot 
> here:https://github.com/cabforum/servercert/pull/490 
> 
> --- Motion Begins ---
> 
> This ballot modifies the “Guidelines for the Issuance and Management of 
> Extended Validation Certificates” (“EV Guidelines”) as follows, based on 
> version 1.8.1:
> 
> MODIFY the Extended Validation Guidelines as specified in the following 
> redline: 
> https://github.com/cabforum/servercert/compare/8e7fc7d5cac0cc27c44fe2aa88cf45f5606f4b94...7b9bb1dbfd41b1d0459b8a985ed629ad841ce122
>  
> 
> --- Motion Ends ---
> 
> Discussion (at least 7 days):
> - Start: 2024-03-15 10:00 UTC
> - End no earlier than 2024-03-22 10:00 UTC
> 
> Vote for approval (7 days):
> - Start: TBD
> - End: TBD
> 
> 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. 
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org 
> https://lists.cabforum.org/mailman/listinfo/servercert-wg



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

[Clint Wilson via Servercert-wg]

Hi Wayne,

Thank you for carrying this work item forward. I have a few concerns regarding 
the proposed removal of Debian weak key checking, outlined below.

I don’t believe there has been sufficient explanation or data presented to 
justify the removal of the requirement to check for Debian weak keys. It seems 
to me there are feasible methods for CAs to continue performing this check. 
Similar to what Martijn has pointed out, the reasoning provided is lacking 
(hasty generalization, fallacy of composition, etc.). 

I don’t believe a compromise where Debian weak keys only need be checked for 
specific key sizes addresses the core issue, unless tied together with a 
restriction from accepting key sizes which are not included in such a list 
(which I do see as reasonable and something I’m under the impression is already 
being done by some CAs).

The removal of this check seems to shift a burden currently placed on CAs to a 
risk (long assumed resolved) for Relying Parties and Subscribers. From my 
reading of the ballot, the requirement that a CA revoke Certificates with 
Debian weak keys remains in effect, serving only to remove the pre-issuance 
“blocking” requirement, but retaining an expectation that certificates are 
checked post-issuance based on the CA’s awareness of this method of 
compromising a Private Key; this generally seems a significantly worse 
experience for Subscribers. Have I missed something regarding the intent of the 
changes in this regard?

There have been incidents involving certificates issued to Debian weak keys in 
recent years; some CAs have indicated that they don’t receive Debian weak keys 
in requests, but evidence exists to the contrary for the ecosystem as a whole.

Thank you!
-Clint

> On Mar 5, 2024, at 12:01 PM, Wayne Thayer via Servercert-wg 
>  wrote:
> 
> Now that everyone should be back from the F2F meeting, I'd like to get back 
> to this ballot. It currently removes all requirements for Debian weak key 
> checks. I'll plan to begin the formal discussion period in a few days unless 
> there are more responses to this thread.
> 
> Thanks,
> 
> Wayne
> 
> On Mon, Feb 26, 2024 at 1:24 PM Wayne Thayer via Servercert-wg 
> mailto:servercert-wg@cabforum.org>> wrote:
>> Martijn,
>> 
>> The purpose of the first weak keys ballot was to make the requirements more 
>> explicit. If I correctly understand your proposal, by removing the exception 
>> for Debian keys from this ballot, it does the opposite. The only compromise 
>> I can see is to require checking for Debian weak keys but only for specific 
>> key sizes, e.g. 2048, 3072, and 4096. That would somewhat reduce the burden 
>> of these checks, and I'd be happy to go that route if there is consensus for 
>> doing so (with approval of the endorsers, of course). I would appreciate 
>> input from other members on the preferred approach to Debian weak key 
>> checking requirements.
>> 
>> Thanks,
>> 
>> Wayne
>> 
>> On Sun, Feb 25, 2024 at 12:15 AM Martijn Katerbarg 
>> mailto:martijn.katerb...@sectigo.com>> wrote:
>>> Thanks Wayne,
>>> 
>>>  
>>> 
>>> >- The Debian vulnerability is more than 15 years old. If an Applicant 
>>> >submits a Debian weak key at this point, they almost certainly have bigger 
>>> >security issues.
>>> 
>>>  
>>> 
>>> This is the bit I have problems with. Just because the applicant (probably) 
>>> has bigger security issues, doesn’t mean we should be putting relying 
>>> parties at even further risk.  If that’s our measure stick, we might as wel 
>>> allow MD5 again because only insecure systems would generate it.
>>> 
>>> Just this year I’ve seen at least one applicant trying to submit a debian 
>>> weak key for order (which obviously got blocked).
>>> 
>>>  
>>> 
>>> I really like what was done with this ballot, except for this bit. I’d even 
>>> be alright with removing the debian weak key check requirement itself. But 
>>> calling it out explicitly as an excempt, I feel is a step too much.
>>> 
>>>  
>>> 
>>> Regards,
>>> 
>>> Martijn
>>> 
>>>  
>>> 
>>> From: Wayne Thayer mailto:wtha...@gmail.com>>
>>> Date: Friday, 23 February 2024 at 17:21
>>> To: Martijn Katerbarg >> >
>>> Cc: CA/B Forum Server Certificate WG Public Discussion List 
>>> mailto:servercert-wg@cabforum.org>>
>>> Subject: Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal
>>> 
>>> CAUTION: This email originated from outside of the organization. Do not 
>>> click links or open attachments unless you recognize the sender and know 
>>> the content is safe.
>>> 
>>>  
>>> 
>>> Martijn,
>>> 
>>>  
>>> 
>>> I would summarize the reasoning for removing the Debian requirements as 
>>> follows:
>>> 
>>> - CAs would prefer the greater clarity that would be provided by the weak 
>>> keys ballot that failed last year.
>>> 
>>> - However, some CAs were of the opinion that the prior ballot imposed more 
>>> explicit requirements for Debian weak key checking rather than just 
>>> clarifying existing 

Re: [Servercert-wg] [Voting Period Begins]: SC-69v2 Clarify router and firewall logging requirements

[Clint Wilson via Servercert-wg]

Hi Martijn,

This is a nit, but is there an extra quotation mark in line 1556? Sorry for not 
spotting this earlier :(

Thanks!
-Clint

> On Feb 22, 2024, at 11:50 AM, Martijn Katerbarg via Servercert-wg 
>  wrote:
> 
> Summary: 
> 
> This ballot aims to clarify what data needs to be logged as part of the 
> "Firewall and router activities" logging requirement in the Baseline 
> Requirements.
> 
> This ballot is proposed by Martijn Katerbarg (Sectigo) and endorsed by Daniel 
> Jeffery (Fastly) and Ben Wilson (Mozilla).
> 
> --- Motion Begins ---
> 
> This ballot modifies the “Baseline Requirements for the Issuance and 
> Management of Publicly-Trusted Certificates" ("Baseline Requirements"), based 
> on Version 2.0.2.
> 
> MODIFY the Baseline Requirements as specified in the following Redline: 
> https://github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031cd1bff3d4f35...08dcb7c244113cc370c15b725f031d18687a074f
>  
> 
> --- Motion Ends ---
> 
> This ballot proposes a Final Maintenance Guideline. The procedure for 
> approval of this ballot is as follows:
> 
> Discussion (at least 7 days)
> 
> Start time: 2024-02-15 11:35:00 UTC
> End time: 2024-02-22 19:50:00 UTC
> Vote for approval (7 days)
> 
> Start time: 2024-02-22 19:50:00 UTC
> End time: 2024-02-29 19:50:00 UTC
>  
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org 
> https://lists.cabforum.org/mailman/listinfo/servercert-wg



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] [Voting Period Begins] SC-070: Clarify the use of DTPs for Domain Control Validation

[Clint Wilson via Servercert-wg]

Apple votes Yes on Ballot SC-070.

> On Feb 13, 2024, at 8:56 AM, Aaron Gable via Servercert-wg 
>  wrote:
> 
> This new voting period is to fix a typo in the End timestamp of the voting 
> period for the previous version of this ballot. The contents of the motion 
> itself are identical. My apologies for the confusion.
> 
> This ballot aims to clarify the existing language around the use of delegated 
> third-parties during domain and IP address control validation. It leaves the 
> existing language in place, and adds specifics for the cases of DNS queries, 
> WHOIS lookups, and contact with the Domain Name Registrat or IP Address 
> Registration Authority.
> 
> Additionally, it places these same restrictions on CAA checking, with an 
> effective date of 2024-05-15.
> 
> This ballot is proposed by Aaron Gable (ISRG / Let's Encrypt) and endorsed by 
> Mads Henriksveen (Buypass) and Dimitris Zacharopoulos (HARICA). You can view 
> and comment on the github pull request representing this ballot here: 
> https://github.com/cabforum/servercert/puhttps://lists.cabforum.org/pipermail/servercert-wg/2024-February/004174.htmlll/475
>  
> 
> The preceding discussion can be seen here: 
> https://lists.cabforum.org/pipermail/servercert-wg/2024-February/004174.html
> 
> --- Motion Begins ---
> 
> This ballot modifies the "Baseline Requirements for the Issuance and 
> Management of Publicly-Trusted Certificates" ("Baseline Requirements") based 
> on Version 2.0.2
> 
> MODIFY the Baseline Requirements as specified in the following redline: 
> https://github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031cd1bff3d4f35...00ea6e24c474fd0ab6eecc25cb8eb733fffc60c3
> 
> --- Motion Ends ---
> 
> Discussion (at least 7 days):
> - Start: 2024-02-02 22:30 UTC
> - End: 2024-02-12 22:30 UTC
> 
> Vote for approval (7 days):
> - Start: 2024-02-13 17:00 UTC
> - End: 2024-02-20 17:00 UTC
> 
> Thanks,
> Aaron
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] [Discussion Period Begins]: SC-69 Clarify router and firewall logging requirements

[Clint Wilson via Servercert-wg]

Hi Martijn,

Thanks for sending this out for discussion. Just a few comments at this point:

I’m not sure the wording "Router and firewall activities" is considered an 
unspecified term, and leaves the exact definition and scope up to the CA, 
however” is necessary or even really helpful. I think it would be clearer to 
introduce Section 5.4.1.1 with something like “Logging of router and firewall 
activities necessary to meet the requirements of Section 5.4.1, Subsection 3.6 
MUST at a minimum include:”
I’m not sold on the “Subsection” part, but I don’t recall if we have good 
semantics established for referencing the numbered paragraphs/sections under a 
Section heading.
I think the entire section including and under "Logging of router and firewall 
activities SHOULD NOT include:” should be removed. 
The first item listed seems overly broad (arguably, imo, even covering the 
“inbound and outbound” connections of the second item) and so making it a 
SHOULD NOT seems too strong a recommendation.
The second item seems counterintuitive and difficult to implement 
correctly+consistently. It could be read as something like “don’t log unless 
you know you’re being exploited”, which doesn’t sound like a recommendation we 
should be making (especially in the context of post-incident data analysis).
Neither of these recommendations seems necessary to accomplish the goals of 
additional clarity and specificity of what MUST be logged.
The concluding sentence "CAs are encouraged to recommend additional MUST and 
SHOULD NOT requirements through an email to questi...@cabforum.org, for future 
discussion within the appropriate Working Group.” stands out as I think it’s 
the only such “encouragement” in the BRs. I don’t think that makes it bad or 
that it should be removed, but I’m also not sure how valuable it is to the BRs 
as a policy. I admit that may be because I view this encouragement as 
fundamental to membership and participation in the CA/B Forum at all — every 
member, regardless of type, should feel welcome and encouraged to recommend 
changes to any of the CA/B Forum documents. But we don’t say that anywhere, so 
maybe this is a  good start?

Cheers!
-Clint

> On Jan 29, 2024, at 10:30 AM, Martijn Katerbarg via Servercert-wg 
>  wrote:
> 
> Summary: 
> 
> This ballot aims to clarify what data needs to be logged as part of the 
> "Firewall and router activities" logging requirement in the Baseline 
> Requirements.
> 
> This ballot is proposed by Martijn Katerbarg (Sectigo) and endorsed by Daniel 
> Jeffery (Fastly) and Ben Wilson (Mozilla).
> 
> --- Motion Begins ---
> 
> This ballot modifies the “Baseline Requirements for the Issuance and 
> Management of Publicly-Trusted Certificates" ("Baseline Reuqirements"), based 
> on Version 2.0.2.
> 
> MODIFY the Baseline Requirements as specified in the following Redline: 
> https://github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031cd1bff3d4f35...807675c91c8500157b0ffd58ab3a40b0b17075e5
> 
> --- Motion Ends ---
> 
> This ballot proposes a Final Maintenance Guideline. The procedure for 
> approval of this ballot is as follows:
> 
> Discussion (at least 7 days)
> 
> Start time: 2024-01-29 18:30:00 UTC
> End time: not before 2024-02-05 18:30:00 UTC
> Vote for approval (7 days)
> 
> Start time: TBD
> End time: TBD
>  
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org 
> https://lists.cabforum.org/mailman/listinfo/servercert-wg



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] Voting Begins for Ballot SC-68: Allow VATEL and VATXI for organizationIdentifier

[Clint Wilson via Servercert-wg]

Apple votes YES on Ballot SC-068.

> On Jan 23, 2024, at 1:00 AM, Dimitris Zacharopoulos (HARICA) via 
> Servercert-wg  wrote:
> 
> This email initiates the voting period for ballot SC-68. Please vote.
> 
> Purpose of the Ballot
> 
> The EV Guidelines have strict rules in the organizationIdentifier values and 
> require the country code of all currently-allowed Registration Schemes (NTR, 
> VAT, PSD) to follow the ISO 3166-1 for the 2-letter country prefix.
> 
> The organizationIdentifier language mainly came from ETSI EN 319 412-1 and 
> then the SCWG made several modifications. However, there is an exception for 
> Greece specifically for the VAT Registration Scheme that is aligned with 
> Article 215 of Council Directive 2006/112/EC 
>  that allows Greece to use the 
> country prefix "EL". In practice, Greece uses the prefix "EL" to identify 
> itself next to the VAT number of all Legal Entities 
> registered/incorporated/established in Greece, and all other European 
> Countries use this prefix to identify Greek VAT numbers. This can easily be 
> verified in the VIES VAT number validation website 
>  where Greece is 
> listed as"EL".
> 
> There is also Council Directive 2020/1756 
>  amending Directive 2006/112/EC 
> that requires the prefix "XI" for the identification of taxable persons in 
> Northern Ireland.
> 
> This pull request  proposes 
> updates to the EV Guidelines to allow those additional prefixes. It also 
> fixes some formatting issues.
> 
> The following motion has been proposed by Dimitris Zacharopoulos of HARICA 
> and endorsed by Ben Wilson of Mozilla and Corey Bonnell of Digicert.
> 
> MOTION BEGINS
> 
> This ballot modifies the “Guidelines for the Issuance and Management of 
> Extended Validation Certificates” (“EV Guidelines”), based on Version 1.8.0.
> 
> MODIFY the EV Guidelines as specified in the following Redline:
> 
> https://github.com/cabforum/servercert/compare/da89d0e9700c6dd89a8263526addc39f472bf54c.
> MOTION ENDS
> 
> The procedure for this ballot is as follows:
> 
> 
> Start time (8:00 UTC) End time (8:00 UTC)
> Discussion (at least 7 days)  2024-01-16  2024-01-23
> Expected Vote for approval (7 days)   2024-01-23
> 2024-01-30
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] Draft ballot SCXX- Fall 2023 Clean-up

[Clint Wilson via Servercert-wg]

Hi Inigo,

These changes look good to me as well (though the rearranging of P-Label did 
get me for a second there, thinking it had been removed) and I’d be willing to 
endorse if needed.

Cheers,
-Clint


> On Sep 13, 2023, at 4:45 AM, Inigo Barreira via Servercert-wg 
>  wrote:
> 
> Hello all,
>  
> We are looking for feedback on the following draft ballot as well as 
> endorsers. 
> Thank you,
>  
> Purpose of Ballot SCXX: Fall 2023 Cleanup
> This ballot proposes updates to the Baseline Requirements for the Issuance 
> and Management of Publicly-Trusted Certificates related to the issues and 
> typos that have happened due to the different updates of the document. 
>  
> Notes: 
> The majority of these issues have been documented in GitHub and have 
> therefore labeled as cleanup and have been the basis for this update.
> Some have been provided by emails to the CABF lists and included in this 
> reviewed version because were typos.
>  
>  
>  
> The following motion has been proposed by Iñigo Barreira of Sectigo. And, 
> endorsed by  of  and  of .
>  
> — Motion Begins —
>  
> This ballot modifies the “Baseline Requirements for the Issuance and 
> Management of Publicly-Trusted Certificates” (“Baseline Requirements”), based 
> on Version 2.0.1.
>  
> MODIFY the Baseline Requirements as specified in the following Pull Request: 
> Fall 2023 clean up by barrini · Pull Request #460 · cabforum/servercert 
> (github.com) 
>  
> — Motion Ends —
>  
>  
> This ballot proposes a Final Maintenance Guideline. The procedure for 
> approval of this ballot is as follows:
>  
> Discussion (13+ days)
> • Start time: DD-MM- 12:00:00 UTC
> • End time: DD-MM- 12:00:00 UTC
>  
> Vote for approval (7 days)
> • Start time: DD-MM- 12:00:00 UTC
> • End time: DD-MM- 12:00:00 UTC
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org 
> https://lists.cabforum.org/mailman/listinfo/servercert-wg



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] Draft ballot SC-XX: Profiles cleanup ballot

[Clint Wilson via Servercert-wg]

Hi all,

Is anyone able to identify the product in question such that we can review its 
documentation and behavior in greater detail and collectively determine whether 
(and if so, how) the certificates it’s issuing should fit into or be accounted 
for by the BRs?
The profiles ballot — version 2.0 of the BRs — has been momentous in moving us 
towards clearer, more comprehensive definitions of what exists with any 
relation to the Web PKI’s TLS hierarchies, but as this ballot represents, there 
were some oversights that yet require addressing. It’s a tad difficult for me, 
personally, to view the continued allowance of these infrastructure 
certificates as justified without having a substantially clearer understanding 
of exactly what they are and how they relate to the trusted TLS Root CA 
Certificates (and their keypairs) subject to the BRs.

I’m hopeful we can have greater clarity and transparency around infrastructure 
certificates which need to chain to publicly trusted Root CAs. Until then, I 
remain supportive of the current ballot removing them from the BRs.

Thank you,
-Clint

> On Aug 2, 2023, at 11:57 AM, Wendy Brown - QT3LB-C  
> wrote:
> 
> Clint, 
> I'll have to defer to others in terms of available documentation on the 
> product.
> But the certs & keys created are definitely the result of explicit CA 
> personnel actions - the first action being the establishment of a new 
> self-signed Root CA.  Personnel authentication certificates also must be 
> issued through explicit commands.
> These aren't things that just happen after the CA has been up and running , 
> it doesn't make a decision on its own to issue new certificates.  
> It is a CA that has been widely used on very secure PKIs.  And being 
> self-sufficient like that is a good implementation for an offline Root CA so 
> as to minimize the number of supplemental systems that might be required to 
> support it.
> 
> thanks,
> Wendy
> 
> 
> 
> Wendy Brown
> 
> Supporting GSA
> 
> FPKIMA Technical Liaison
> 
> Protiviti Government Services
> 
> 703-965-2990 (cell)
> 
> 
> On Wed, Aug 2, 2023 at 2:07 PM Clint Wilson  > wrote:
>> Hi Wendy,
>> 
>> Thanks for this additional information and context. Is there publicly 
>> available documentation for the product and this functionality? I think that 
>> might be the most efficient way to answer some of the questions arising 
>> around this. If not, I have a few follow-on questions. In what ways and to 
>> what extent can the profiles be adjusted prior to issuance? Is the TLS 
>> certificate issued directly by a Root, or a subordinate CA? Is the OCSP 
>> signing certificate generated even if no OCSP responders are configured or 
>> expected to be used? What are the default profiles used for each of the 
>> certificates, if not adjusted prior to issuance?
>> 
>> I’d like to understand better how these events occur — and why within the 
>> context of the product — but currently it seems the described product is not 
>> well-suited to operations within the Web (or any Public) PKI. While it’s 
>> promising that the profiles are configurable, it remains quite concerning 
>> that a CA/HSM would issue certificates automatically, without the initiation 
>> and explicit input of CA personnel being prerequisite.
>> 
>> Cheers,
>> -Clint
>> 
>> 
>>> On Aug 2, 2023, at 10:52 AM, Wendy Brown - QT3LB-C via Servercert-wg 
>>> mailto:servercert-wg@cabforum.org>> wrote:
>>> 
>>> Corey - 
>>> For at least 1 CA product that I am aware of, issuance of these 
>>> certificates is automatic, and we don't believe that issuance can be 
>>> disabled, or that a separate private PKI can be used to issue these 
>>> certificates instead.  In the event a separate, private PKI is used for CA 
>>> infrastructure, it would be important that the private PKI at a minimum 
>>> meets the same security and monitoring requirements of the CA for which it 
>>> issues infrastructure certificates.  In a situation where a CA requires 
>>> these certificates, it would be more secure to have optional Baseline 
>>> profiles than stand up a separate private PKI to avoid the certificates.
>>> 
>>> While the issuance is automatic, the profiles can be adjusted prior to 
>>> issuance.  The profiles required would be for a Trusted Role authentication 
>>> certificate (unless the two factor authentication requirement is waived and 
>>> password authentication is used instead), audit log signing certificate, 
>>> OCSP signing certificate, TLS certificate (for the local web interface of 
>>> the CA), and a subsystem certificate so the certificate manager subsystem 
>>> can communicate with the CA subsystem for issuance/revocation/Trusted Role 
>>> authentication, etc.
>>> 
>>> In addition, for an offline Root CA - requiring the use of a separate 
>>> internal PKI might also require network capability each time the Root is 
>>> activated so the Root CA can validate the current status of those 
>>> externally issued certificat

Re: [Servercert-wg] SC-XXX: Modify Subscriber Agreement and Terms of Use

[Clint Wilson via Servercert-wg]

Hi Ben,

As I understand it the goal of these changes is just to simplify the terms used 
in the BRs — and, as has been brought up separately, potentially other CA/BF 
Final Guidelines — in order to enable collapsing their use of “Terms of Use” 
into the concept of the “Subscriber Agreement”. Is that an accurate description 
of the intent of this draft? Are there any other goals or outcomes being aimed 
at with these changes?

Thanks!
-Clint

> On Aug 14, 2023, at 12:40 PM, Ben Wilson via Servercert-wg 
>  wrote:
> 
> Hi,
> Dustin Hollenback and I are looking for another endorser for a proposed 
> ballot - see 
> https://github.com/cabforum/servercert/compare/a0360b61e73476959220dc328e3b68d0224fa0b3..663695b8319c0cd32e0060bb9304ecd32e3737a1
> It would remove the concept of a separate "Terms of Use" and replace it with 
> "Subscriber Agreement" and make several other changes with respect to 
> "Subscriber Agreements".
> Is anyone interested in endorsing?
> Thanks,
> Ben
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] Draft ballot SC-XX: Profiles cleanup ballot

[Clint Wilson via Servercert-wg]

Hi Wendy,

Thanks for this additional information and context. Is there publicly available 
documentation for the product and this functionality? I think that might be the 
most efficient way to answer some of the questions arising around this. If not, 
I have a few follow-on questions. In what ways and to what extent can the 
profiles be adjusted prior to issuance? Is the TLS certificate issued directly 
by a Root, or a subordinate CA? Is the OCSP signing certificate generated even 
if no OCSP responders are configured or expected to be used? What are the 
default profiles used for each of the certificates, if not adjusted prior to 
issuance?

I’d like to understand better how these events occur — and why within the 
context of the product — but currently it seems the described product is not 
well-suited to operations within the Web (or any Public) PKI. While it’s 
promising that the profiles are configurable, it remains quite concerning that 
a CA/HSM would issue certificates automatically, without the initiation and 
explicit input of CA personnel being prerequisite.

Cheers,
-Clint


> On Aug 2, 2023, at 10:52 AM, Wendy Brown - QT3LB-C via Servercert-wg 
>  wrote:
> 
> Corey - 
> For at least 1 CA product that I am aware of, issuance of these certificates 
> is automatic, and we don't believe that issuance can be disabled, or that a 
> separate private PKI can be used to issue these certificates instead.  In the 
> event a separate, private PKI is used for CA infrastructure, it would be 
> important that the private PKI at a minimum meets the same security and 
> monitoring requirements of the CA for which it issues infrastructure 
> certificates.  In a situation where a CA requires these certificates, it 
> would be more secure to have optional Baseline profiles than stand up a 
> separate private PKI to avoid the certificates.
> 
> While the issuance is automatic, the profiles can be adjusted prior to 
> issuance.  The profiles required would be for a Trusted Role authentication 
> certificate (unless the two factor authentication requirement is waived and 
> password authentication is used instead), audit log signing certificate, OCSP 
> signing certificate, TLS certificate (for the local web interface of the CA), 
> and a subsystem certificate so the certificate manager subsystem can 
> communicate with the CA subsystem for issuance/revocation/Trusted Role 
> authentication, etc.
> 
> In addition, for an offline Root CA - requiring the use of a separate 
> internal PKI might also require network capability each time the Root is 
> activated so the Root CA can validate the current status of those externally 
> issued certificates.
> 
> thanks,
> Wendy
> 
> 
> 
> Wendy Brown
> 
> Supporting GSA
> 
> FPKIMA Technical Liaison
> 
> Protiviti Government Services
> 
> 703-965-2990 (cell)
> 
> 
> On Tue, Aug 1, 2023 at 2:27 PM Corey Bonnell  > wrote:
>> Hi Wendy,
>> 
>> Do you know if the automatic issuance of such certificates can be disabled, 
>> and a private PKI be used for infrastructure purposes instead? Based on the 
>> discussions during the development of the profiles ballot, it was clear that 
>> private PKI should be used for CA infrastructure. However, prohibiting such 
>> use on a short timeframe would likely cause migration issues, so such 
>> issuance may need to continue to be permitted for at least some time.
>> 
>>  
>> 
>> I’m wondering whether it’s feasible to create a “infrastructure certificate" 
>> profile in the BRs that can allow for the continued issuance of these types 
>> of certificates while also establishing some guard rails. Do you happen to 
>> know whether these certificates share a profile that is roughly like one 
>> another? I personally haven’t used CA software that exhibits this “automatic 
>> issuance” behavior, so I’ll lean on others who do have experience.
>> 
>>  
>> 
>> Thanks,
>> 
>> Corey
>> 
>>  
>> 
>> From: Wendy Brown - QT3LB-C > > 
>> Sent: Friday, July 21, 2023 8:24 AM
>> To: Corey Bonnell > >
>> Cc: CA/B Forum Server Certificate WG Public Discussion List 
>> mailto:servercert-wg@cabforum.org>>
>> Subject: Re: [Servercert-wg] Draft ballot SC-XX: Profiles cleanup ballot
>> 
>>  
>> 
>> Corey - 
>> 
>> not according to some CA products - these additional certificates are 
>> created automatically at the time a new CA is established - so if they are 
>> not excluded those products are no longer eligible for use as Root CAs.  It 
>> was my understanding that the original language that you are proposing to 
>> eliminate was put there so these products could continue to be used.
>> 
>> 
>> 
>> Wendy
>> 
>>  
>> 
>> Wendy Brown
>> 
>> Supporting GSA
>> 
>> FPKIMA Technical Liaison
>> 
>> Protiviti Government Services
>> 
>> 703-965-2990 (cell)
>> 
>>  
>> 
>>  
>> 
>> On Fri, Jul 21, 2023 at 8:19 AM Corey Bonnell > > wrote:
>> 
>>

Re: [Servercert-wg] [secdir] Secdir last call review of draft-gutmann-testkeys-04

[Clint Wilson via Servercert-wg]

Hi Wayne,

This is helpful and much appreciated!

> On Jul 18, 2023, at 11:15 AM, Wayne Thayer  wrote:
> 
> Hi Clint,
> 
> Thank you for helping to unpack my concerns.
> 
> On Mon, Jul 17, 2023 at 2:28 PM Clint Wilson  > wrote:
>> Hi Wayne,
>> 
>> I’d like to better understand your worry and perhaps interpretation of BR 
>> 6.1.1.3(4) and 4.9.1.1(3,4,16). Just to restate for my benefit, the concern 
>> is that: IF we interpret Tim’s message regarding the testkeys draft as 
>> qualifying the keys present in the draft as “[All] CAs [subscribed to the 
>> Servercert-wg list being] made aware that [a future] Applicant’s Private Key 
>> has suffered a Key Compromise….” THEN, in a similar situation, any 
>> servercert-wg member could share any number of compromised keys here and, 
>> theoretically, bloat (with no upper bounds) the set of known compromised 
>> keys a CA has to retain and check in order to reject certificate requests as 
>> needed to meet the requirements of 6.1.1.3 WHILE also not necessarily 
>> increasing the meaningful security provided by the BRs. Is that correct?
>> As a concrete example (an extreme I could imagine), someone could generate, 
>> and potentially delete, 100 or 100,000,000,000 keypairs easily (for a value 
>> of “easily” most associated with effort rather than time or resources), 
>> share a CSV, or even just pointer to a repository/document, with the 
>> Servercert-wg, and (if interpreted per your worry) cause a bunch of keys 
>> never intended to be used for actual certificate issuance to be forever part 
>> of a set of keys which all CAs must check every received certificate request 
>> against.
>> 
> 
> The magnitude of the problem is not my primary concern, but that is something 
> to consider.

Agreed, though I do think it highlights that there may be multiple weaknesses 
in the current wording of the BRs related to this topic and likely some overlap 
with other “weak key” checking requirements. I apologize for the distinct lack 
of polish this is likely to have, but just to share some personal thoughts on 
the matter, the possible weaknesses that have become clear(er) to me in this 
discussion are:

1. Method and/or means of communication 
I think this is more concretely the primary concern you have at this point or 
at least was the primary point of your initial response.
The BRs only stipulate a required action (rejecting certificate requests and/or 
revoking issued certificates) based on the receipt (being made aware) of 
certain types of communication (proof that a key has been compromised). Trying 
to dig one level deeper and describing a scenario that, I believe, maps to the 
text of the BRs today: 
The sender of the information is not mentioned in these sections of the 
requirements, so the “message" can come from anyone or anywhere
But that message must be communicated to the CA 
“the CA” being another term of some ambiguity in this specific context) 
AND the communication must convey keys — typically just the public key 
component of a key pair whose private key is compromised
receiving private keys themselves qualifies, of course, but is absolutely not 
necessary and should be heavily discouraged (let’s please not go through that 
again…)
AND prove or demonstrate to the CA that the keys have indeed been compromised
I think, in the context of the “compromised keys” we’re talking about, the 
communication with the CA must supply specific keys, not broad classes of keys 
based on some contained attribute or something.
So, essentially, the BRs say that in the event of communication to the CA that 
demonstrates certain keys are compromised, the CA must both revoke any 
certificates they’ve issued which contain those keys and, from that point on, 
reject any certificate requests containing those keys. 
There’s sort of an interesting little interaction here where, hypothetically, a 
certificate request could have been received by a CA prior to the compromised 
key being reported, in which case it seems the CA could still issue the 
certificate, but would then need to revoke it within 24 hours… but I digress.
AFAICT, this is as far as the BRs set requirements on this topic, so it seems 
to me there are reasonably 2 ways this could play out on either a per-CA or 
BR-wide basis from here:
Further specification:
The BRs, act as a governing policy, to the CA’s policy(ies). The CA could 
further specify in their CPS (or other authoritative policy or practices 
document) that the communication referenced in this section must be directed in 
a specific way or to a specific target (i.e. taking “the CA” and mapping it to 
“this form on this website”, taking “made aware” and mapping it to “this report 
shared at this location”, or similar). It seems the CA can thus comply with the 
BRs while also providing additional stipulations of what practices they have in 
place to meet the policy requirements set forth in the BRs. 
Related, I believe there are still

Re: [Servercert-wg] [secdir] Secdir last call review of draft-gutmann-testkeys-04

[Clint Wilson via Servercert-wg]

Hi Wayne,

I’d like to better understand your worry and perhaps interpretation of BR 
6.1.1.3(4) and 4.9.1.1(3,4,16). Just to restate for my benefit, the concern is 
that: IF we interpret Tim’s message regarding the testkeys draft as qualifying 
the keys present in the draft as “[All] CAs [subscribed to the Servercert-wg 
list being] made aware that [a future] Applicant’s Private Key has suffered a 
Key Compromise….” THEN, in a similar situation, any servercert-wg member could 
share any number of compromised keys here and, theoretically, bloat (with no 
upper bounds) the set of known compromised keys a CA has to retain and check in 
order to reject certificate requests as needed to meet the requirements of 
6.1.1.3 WHILE also not necessarily increasing the meaningful security provided 
by the BRs. Is that correct?
As a concrete example (an extreme I could imagine), someone could generate, and 
potentially delete, 100 or 100,000,000,000 keypairs easily (for a value of 
“easily” most associated with effort rather than time or resources), share a 
CSV, or even just pointer to a repository/document, with the Servercert-wg, and 
(if interpreted per your worry) cause a bunch of keys never intended to be used 
for actual certificate issuance to be forever part of a set of keys which all 
CAs must check every received certificate request against.

Notable to this worry, I think, is that nothing about the language in in the 
BRs today indicates to me that Tim’s message or the above, somewhat silly, 
scenario would not be interpreted to qualify as a reason to reject those 
associated keys. That is, if a CA subscribed to this mailing list and 
conforming to the BRs, issued a certificate to a key in the testkeys draft 
after July 4, 2023, it seems that the BRs would consider that a misissuance as 
there’s no limitation or specification regarding what (or whether) any specific 
bar is met in order to constitute “the CA [being] made aware”. 4.9.3 I think 
comes quite close, but stops short of saying something like “For the purposes 
of requirements in 4.9.1.1, 4.9.1.2, and 6.1.1.3, the CA MAY require a 
Certificate Problem Report to be submitted in order to constitute being made 
aware of reasons to reject certificate requests or revoke certificates.” which 
I think would remove the current ambiguity regarding what needs to happen in 
order for a CA to need to begin rejecting certificate requests for compromised 
keys. (Note, I’m not saying this change is a good or well-thought-out idea, 
just what came to mind as one option to increase clarity in a way that would 
address the worry raised.)

This is separate, in my mind, to any potential interpretation that would expect 
CAs to go out and look for compromised keys elsewhere. “Looking" implies to me 
a proactive effort, whereas “made aware” is much more passive and would 
seemingly include any receipt of information by the CA (or its official 
representatives?). More to the point, I don’t see any implication that CAs 
should be looking for compromised keys in the current BR text, which hopefully 
helps with part of the worry (though adding something like that as a 
requirement has been discussed before, iirc, especially in the context of 
pwnedkeys.com  and I could see that, and related topics, 
coming up again with 
https://www.ietf.org/archive/id/draft-mpalmer-key-compromise-attestation-00.txt).

While I don’t foresee near-term, major, and negative impact from my 
interpretation of the BRs, I do think we can maintain the intent of the 
requirement without leaving it as open as a rough analogue to a zip bomb. While 
I proposed something purely for illustration above, I’ve also filed 
https://github.com/cabforum/servercert/issues/442 to track this if there’s 
further interest in ensuring the BRs could address this worry.

As always, please let me know if I’ve missed some crucial detail or interaction 
here that’s led me to an erroneous conclusion on the topic. Cheers!
-Clint

> On Jul 7, 2023, at 3:13 PM, Wayne Thayer via Servercert-wg 
>  wrote:
> 
> Thanks for sharing this Tim.
> 
> I want to comment on the statement that CAs should blocklist the keys 
> published in this RFC. Doing that may very well be helpful to the CA and 
> their customers, but I do not believe it is a requirement set forth by the 
> CAB Forum or root store policy.
> 
> Prior discussions on this topic have not resulted in requirements beyond the 
> clarification of BR 6.1.1.3(4): "The CA has previously been made aware that 
> the Applicant’s Private Key has suffered a Key Compromise, such as through 
> the provisions of Section 4.9.1.1;". My worry is that we will begin 
> interpreting "has previously been made aware" as inclusive of keys published 
> in a RFC that Tim sent to the mailing list, without any bounds or guidance on 
> where else CAs must look for compromised keys (e.g. scanning online databases 
> and software packages). I don't necessarily intend to start a bi

Re: [Servercert-wg] Voting Period Begins - Ballot SC-59 v2 "Weak Key Guidance"

[Clint Wilson via Servercert-wg]

Apple votes YES on Ballot SC-059.

> On Jul 6, 2023, at 9:17 AM, Tom Zermeno via Servercert-wg 
>  wrote:
> 
> Purpose of the Ballot SC-59
> 
> This ballot proposes updates to the Baseline Requirements for the Issuance 
> and Management of Publicly-Trusted Certificates related to the identification 
> and revocation of certificates with private keys that were generated in a 
> manner that may make them susceptible to easy decryption. It specifically 
> deals with Debian weak keys, ROCA, and Close Primes Vulnerability. 
> 
> Notes:  
> 
> Thank you to the participants who voiced opinions and concerns about the 
> previous version of the ballot.  While there were many concerns about the 
> inclusion of the Debian weak keys checks, we have decided to leave the checks 
> in the ballot.  Our reasoning is that we wanted to strengthen the guidance 
> statements, to help CAs ensure compliant certificate generation.  Future 
> reviews of the BRs may cull the requirements, as is required by the needs of 
> the community. 
> We believe that the requested date of November 15, 2023, will allow enough 
> time for Certificate Authorities to enact any changes to their systems to 
> ensure that they perform the weak key checks on all CSRs submitted for TLS 
> certificates. 
> The changes introduced in SC-59 do not conflict with any of the recent 
> ballots. As observed with other ballots in the past, minor administrative 
> updates must be made to the proposed ballot text before publication such that 
> the appropriate Version # and Change History are accurately represented 
> (e.g., to indicate these changes will be represented in Version 2.0.1).  
> The following motion has been proposed by Thomas Zermeno of SSL.com 
>  and has been endorsed by Martijn Katerbarg of Sectigo and 
> Ben Wilson of Mozilla. 
> 
> - Motion Begins -  
> 
> This ballot modifies the “Baseline Requirements for the Issuance and 
> Management of Publicly-Trusted Certificates” (“Baseline Requirements”), based 
> on Version 2.0.0. 
> 
> MODIFY the Baseline Requirements as specified in the following Redline: 
> https://github.com/cabforum/servercert/compare/a0360b61e73476959220dc328e3b68d0224fa0b3...SSLcom:servercert:958e6ccac857b826fead6e4bd06d58f4fdd7fa7a
>   
> 
> - Motion Ends - 
> 
> The procedure for approval of this ballot is as follows:
> 
> Discussion (7 days) 
> 
> • Start time: 2023-06-26 22:00:00 UTC 
> 
> • End time: 2023-07-03 21:59:59 UTC 
> 
> Vote for approval (7 days) 
> 
>   •  Start Time:  2023-07-06 17:00:00
> 
>   •  End Time:   2023-07-13 16:59:59 
> 
>  
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org 
> https://lists.cabforum.org/mailman/listinfo/servercert-wg



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] Voting Period Begins - Ballot SC-063 V4: “Make OCSP Optional, Require CRLs, and Incentivize Automation”

[Clint Wilson via Servercert-wg]

Apple votes YES on Ballot SC-063.

> On Jul 6, 2023, at 8:59 AM, Ryan Dickson via Servercert-wg 
>  wrote:
> 
> Purpose of Ballot SC-063
> This Ballot proposes updates to the Baseline Requirements for the Issuance 
> and Management of Publicly-Trusted Certificates related to making Online 
> Certificate Status Protocol (OCSP) services optional for CAs. This proposal 
> does not prohibit or otherwise restrict CAs who choose to continue supporting 
> OCSP from doing so. If CAs continue supporting OCSP, the same requirements 
> apply as they exist today.
> 
> Additionally, this proposal introduces changes related to CRL requirements 
> including:
> 
> CRLs must conform with the proposed profile.
> CAs must generate and publish either:
> a full and complete, or 
> a set of partitioned CRLs (sometimes called “sharded” CRLs), that when 
> aggregated, represent the equivalent of a full and complete CRL.
> CAs issuing Subscriber Certificates must update and publish a new CRL…
> within twenty-four (24) hours after recording a Certificate as revoked; and 
> Otherwise: 
> at least every seven (7) days if all Certificates include an Authority 
> Information Access extension with an id-ad-ocsp accessMethod (“AIA OCSP 
> pointer”), or
> at least every four (4) days in all other cases.
> 
> Finally, the proposal revisits the concept of a “short-lived” certificate, 
> introduced in Ballot 153 
> .  As 
> described in this ballot, short-lived certificates (sometimes called 
> “short-term certificates” in ETSI specifications 
> )
>  are:
> 
> optional. CAs will not be required to issue short-lived certificates. For TLS 
> certificates that do not meet the definition of a short-lived certificate 
> introduced in this proposed update, the current maximum validity period of 
> 398 days remains applicable. 
> constrained to an initial maximum validity period of ten (10) days. The 
> proposal stipulates that short-lived certificates issued on or after 15 March 
> 2026 must not have a Validity Period greater than seven (7) days.
> not required to contain a CRLDP or OCSP pointer and are not required to be 
> revoked. The primary mechanism of certificate invalidation for these 
> short-lived certificates would be through certificate expiry. CAs may 
> optionally revoke short-lived certificates. The initial maximum certificate 
> validity is aligned with the existing maximum values for CRL “nextUpdate” and 
> OCSP response validity allowed by the BRs today. 
> 
> Additional background, justification, and considerations are outlined here 
> .
> 
> Proposal Revision History:
> 
> The set of updates resulting from the first round of discussion are presented 
> here .
> The set of updates resulting from the second round of discussion are 
> presented here .
> The set of updates resulting from the third round of discussion are presented 
> here . 
> 
> The following motion has been proposed by Ryan Dickson and Chris Clements of 
> Google (Chrome Root Program) and endorsed by Kiran Tummala of Microsoft and 
> Tim Callan of Sectigo.
> 
> 
> — Motion Begins —
> 
> This ballot modifies the “Baseline Requirements for the Issuance and 
> Management of Publicly-Trusted Certificates” (“Baseline Requirements”), based 
> on Version 2.0.0.
> 
> MODIFY the Baseline Requirements as specified in the following Redline: 
> https://github.com/cabforum/servercert/compare/a0360b61e73476959220dc328e3b68d0224fa0b3..b8a0453e59ff342779d5083f2f1f8b8b5930a66a
>  
> 
> 
> — Motion Ends —
> 
> This ballot proposes a Final Maintenance Guideline. The procedure for 
> approval of this ballot is as follows:
> 
> Discussion (13+ days)
> Start time: 2023-06-22 20:30:00 UTC
> End time: 2023-07-06 15:59:59 UTC
> 
> Vote for approval (7 days)
> Start time: 2023-07-06 16:00:00 UTC
> End time: 2023-07-13 16:00:00 UTC
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg