From jopurvis at cisco.com Wed Mar 3 16:03:58 2021 From: jopurvis at cisco.com (Jos Purvis (jopurvis)) Date: Wed, 3 Mar 2021 16:03:58 +0000 Subject: [Servercert-wg] Results of Ballot SC41v2: Reformat the BRs, EVGs, and NCSSRs In-Reply-To: <01000177df35dc5b-16fecf30-82b5-4618-87a2-c7df7fb88892-000000@email.amazonses.com> References: <01000177da5d949c-a7befcae-21b5-4cf6-8c46-3d9a041924ed-000000@email.amazonses.com> <01000177da7c5744-78098d94-fec9-4cf5-8c92-76939c3de692-000000@email.amazonses.com> <01000177df35dc5b-16fecf30-82b5-4618-87a2-c7df7fb88892-000000@email.amazonses.com> Message-ID: Re-re-amended results? Amended Results: The voting period for Ballot SC41v2 has concluded and the Ballot has Passed. Voting Results Certificate Issuers 21 votes total, with no abstentions ? 21 Yes votes: Buypass, Certum, D-TRUST, DigiCert, Disig, eMudhra, Entrust, Firmaprofesional, GDCA, GlobalSign, GoDaddy, HARICA, ISRG (Let?s Encrypt), Izenpe, Kamu SM, Sectigo, SecureTrust, SwissSign, Telia Company, TrustCor, Visa ? 0 No Votes ? 0 Abstentions Certificate Consumers 6 votes total, with no abstentions 1. 5 Yes votes: Apple, Cisco, Google, Microsoft, Mozilla, 360 2. 0 No votes 3. 0 Abstentions Bylaw Requirements 1. Bylaw 2.3(f) requires: o A "yes" vote by two-thirds of Certificate Issuer votes and by 50%-plus-one of Certificate Consumer votes. Votes to abstain are not counted for this purpose. This requirement was met for both Certificate Issuers and Certificate Consumers. o at least one Certificate Issuer and one Certificate Consumer Member must vote in favor of a ballot for the ballot to be adopted. This requirement was also met. 2. Bylaw 2.3(g) requires that a ballot result only be considered valid when ?more than half of the number of currently active Members has participated?. Votes to abstain are counted in determining quorum. Half of the currently active members at the start of voting was 12, so the quorum was 13 for this ballot. This requirement was met. This ballot now enters the IP Rights Review Period to permit members to review the ballot for relevant IP rights issues. -- Jos Purvis (jopurvis at cisco.com) .:|:.:|:. cisco systems | Cryptographic Services PGP: 0xFD802FEE07D19105 | Controls and Trust Verification -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3699 bytes Desc: not available URL: From jopurvis at cisco.com Wed Mar 3 20:34:03 2021 From: jopurvis at cisco.com (Jos Purvis (jopurvis)) Date: Wed, 3 Mar 2021 20:34:03 +0000 Subject: [Servercert-wg] Minutes of the Server Certificate Working Group, 2021-02-18 Message-ID: <25F9995E-CE57-4BEE-AD40-8CBF72E22BC2@cisco.com> Server Certificate Working Group ? 18 February 2021 Attendees (in alphabetical order) Aaron Gable (Let's Encrypt), Adrian Mueller (SwissSign), Ali Gholami (Telia), Andrea Holland (SecureTrust), Bruce Morton (Entrust), Chris Kemmerer (SSL.com), Chris McMillan (Visa), Clint Wilson (Apple), Corey Bonnell (DigiCert), Corey Rasmussen (OATI), Curt Spann (Apple), Daniela Hood (GoDaddy), Dean Coclin (Digicert), Dimitris Zacharopoulos (HARICA), Doug Beattie (GlobalSign), Dustin Hollenback (Microsoft), Enrico Entschew (D-TRUST), Inaba Atsushi (GlobalSign), Janet Hines (SecureTrust), Jeff Ward (CPA Canada/WebTrust), Johnny Reading (GoDaddy), Jos Purvis (Cisco Systems), Karina Sirota (Microsoft), Mads Henriksveen (Buypass AS), Mike Reilly (Microsoft), Neil Dunbar (TrustCor Systems), Niko Carpenter (SecureTrust), Patrick Nohe (GlobalSign), Peter Miskovic (Disig), Rebecca Kelley (Apple), Ryan Sleevi (Google), Sebastian Schulz (GlobalSign), Shelley Brewer (Digicert), Tadahiko Ito (SECOM Trust Systems), Thomas Zermeno (SSL.com), Tim Callan (Sectigo), Tim Hollebeek (Digicert), Tobias Josefowitz (Opera Software AS), Wayne Thayer (Mozilla), Wendy Brown (US Federal PKI Management Authority) 1. Read Antitrust Statement Jos read the antitrust statement. 2. Roll Call Dean read the roll. 3. Review Agenda No changes were made to the agenda. 4. Approval of minutes from last teleconference The minutes from the February 4th teleconference were approved without changes. 5. Validation Subcommittee Update Tim Hollebeek said that there was a significant discussion on IP address validation and the use of Start of Authority (SOA) DNS records for IP address validation. To be clear, the use of SOA records is not permitted. The subcommittee then discussed Ryan Sleevi?s work on formatting certificate profiles into tables in markdown. Tim said that we are close to being able to put the work on profiles and formatting together into a document that we can review. The subcommittee didn?t have time to discuss ADN wildcard validation on the call. On the next call they will discuss an agenda for the upcoming face-to-face (F2F) meeting. 6. NetSec Subcommittee Update Neil Dunbar reported that the subcommittee met on Tuesday. The cloud services team continued discussion on what documents to produce. Consensus is that rather than creating a standalone document they will reference ISO and other documents. Next, the subcommittee continued their work to analyze the DigiNotar breach to close down practices that are not strictly forbidden but clearly should be. The subcommittee had a long discussion on SC40 trying to address issues on wording around data flowing into and out of an air-gapped system. They wIll try to get some new wording out to resolve these ambiguities. Finally, they discussed a draft presentation for the F2F. They plan to hold an open forum on how to present future work coming from the subcommittee because ballots may not always be the best approach. One idea is to produce a reference implementation to act as an example of how to properly implement the NCSSRs. Clint and Neil continued to work on the fallout of ballot SC38 to address BR section 4.1.1?s suspicious certificate database and a reformatting of BR 5.4 and 5.5 retention periods. 7. Ballot Status Ballots in Discussion Period ? SC38 ? Alignment of Record Archival Neil said that this ballot is past the 21-day period and has automatically failed. Jos said that he will confirm and post an update to the list. Ballots in Voting Period ? SC41 - Reformat the BRs, EVGs, and NCSSRs Ryan asked everyone to vote. Ballots in Review Period ? SC39v3 ? Definition of Critical Vulnerability Jos asked everyone to perform an IPR review and file exclusions if needed. Draft Ballots Under Consideration ? Ballot SC40: Security Requirements for Air-Gapped CA Systems (Ben) Ben Wilson said that there are two comments. The first is about data going in and out of root CA system. CAs input things to sign and then take out signed objects. The second comment was that this process needs to be more secure. The first is easy to fix via a change to the ?unidirectional? language. The second is quite difficult to fix succinctly. It might be better suited for the reference implementation document that Neil mentioned. Ben will post a revision to keep the discussion alive. Wayne Thayer noted that the changes in this ballot can have significant unintended consequences, a few of which have already been discussed. Wayne encouraged all CAs to closely review the ballot while it is still in the discussion phase and easy to modify. Jos stated his agreement with Wayne. ? Ballot SCXX: Debian Weak Keys (Chris) Chris Kemmerer said that he?d like to discuss this at the upcoming F2F, and that he will send a proposal in advance. Jos will add this to the agenda. ? Ballot SC34 Account Management (Tobi) Tobi Josefowitz said that if SC41 passes this pull request will have conflicts, and asked what the procedure is for that. Jos said that Tobi could update the PR by merging in the changes from SC41. Ryan offered to help via Slack and suggested that Tobi rebase the change on top of the SC41 branch. Tobi said that it?d be nice if we can retain the comments, and Ryan said that he would think about how to do that. Ryan said that he?d invite Tobi to the Infrastructure Slack group. Jos noted that Slack is a good way to ask questions of the Infrastructure subcommittee, and Ryan said that Slack is great for real-time communications but the mailing list is also an appropriate place to ask questions. 8. Any Other Business Jos said that the agenda has been posted on the wiki and asked members to review and contact him with any proposed updates. 9. Next call:TBD (after the F2F) at 11AM Eastern Adjourn; Immediately convene meeting of CA Browser Forum call (same call) -- Jos Purvis (jopurvis at cisco.com) .:|:.:|:. cisco systems | Cryptographic Services PGP: 0xFD802FEE07D19105 | Controls and Trust Verification -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3699 bytes Desc: not available URL: From jopurvis at cisco.com Wed Mar 3 20:56:59 2021 From: jopurvis at cisco.com (Jos Purvis (jopurvis)) Date: Wed, 3 Mar 2021 20:56:59 +0000 Subject: [Servercert-wg] Minutes of the Server Certificate Working Group, 2021-02-18 In-Reply-To: <01000177f9cc4fa7-481fcb72-05ad-4416-8f14-f6767e179908-000000@email.amazonses.com> References: <01000177f9cc4fa7-481fcb72-05ad-4416-8f14-f6767e179908-000000@email.amazonses.com> Message-ID: <10F267DF-9411-4528-97E1-072D0F60A566@cisco.com> PUblished -- Jos Purvis (jopurvis at cisco.com) .:|:.:|:. cisco systems | Cryptographic Services PGP: 0xFD802FEE07D19105 | Controls and Trust Verification From: Servercert-wg on behalf of CABF Server Cert WG Reply-To: "Jos Purvis (jopurvis)" , CABF Server Cert WG Date: Wednesday, March 3, 2021 at 3:34 PM To: CABF Server Cert WG Subject: [Servercert-wg] Minutes of the Server Certificate Working Group, 2021-02-18 Server Certificate Working Group ? 18 February 2021 Attendees (in alphabetical order) Aaron Gable (Let's Encrypt), Adrian Mueller (SwissSign), Ali Gholami (Telia), Andrea Holland (SecureTrust), Bruce Morton (Entrust), Chris Kemmerer (SSL.com), Chris McMillan (Visa), Clint Wilson (Apple), Corey Bonnell (DigiCert), Corey Rasmussen (OATI), Curt Spann (Apple), Daniela Hood (GoDaddy), Dean Coclin (Digicert), Dimitris Zacharopoulos (HARICA), Doug Beattie (GlobalSign), Dustin Hollenback (Microsoft), Enrico Entschew (D-TRUST), Inaba Atsushi (GlobalSign), Janet Hines (SecureTrust), Jeff Ward (CPA Canada/WebTrust), Johnny Reading (GoDaddy), Jos Purvis (Cisco Systems), Karina Sirota (Microsoft), Mads Henriksveen (Buypass AS), Mike Reilly (Microsoft), Neil Dunbar (TrustCor Systems), Niko Carpenter (SecureTrust), Patrick Nohe (GlobalSign), Peter Miskovic (Disig), Rebecca Kelley (Apple), Ryan Sleevi (Google), Sebastian Schulz (GlobalSign), Shelley Brewer (Digicert), Tadahiko Ito (SECOM Trust Systems), Thomas Zermeno (SSL.com), Tim Callan (Sectigo), Tim Hollebeek (Digicert), Tobias Josefowitz (Opera Software AS), Wayne Thayer (Mozilla), Wendy Brown (US Federal PKI Management Authority) 1. Read Antitrust Statement Jos read the antitrust statement. 2. Roll Call Dean read the roll. 3. Review Agenda No changes were made to the agenda. 4. Approval of minutes from last teleconference The minutes from the February 4th teleconference were approved without changes. 5. Validation Subcommittee Update Tim Hollebeek said that there was a significant discussion on IP address validation and the use of Start of Authority (SOA) DNS records for IP address validation. To be clear, the use of SOA records is not permitted. The subcommittee then discussed Ryan Sleevi?s work on formatting certificate profiles into tables in markdown. Tim said that we are close to being able to put the work on profiles and formatting together into a document that we can review. The subcommittee didn?t have time to discuss ADN wildcard validation on the call. On the next call they will discuss an agenda for the upcoming face-to-face (F2F) meeting. 6. NetSec Subcommittee Update Neil Dunbar reported that the subcommittee met on Tuesday. The cloud services team continued discussion on what documents to produce. Consensus is that rather than creating a standalone document they will reference ISO and other documents. Next, the subcommittee continued their work to analyze the DigiNotar breach to close down practices that are not strictly forbidden but clearly should be. The subcommittee had a long discussion on SC40 trying to address issues on wording around data flowing into and out of an air-gapped system. They wIll try to get some new wording out to resolve these ambiguities. Finally, they discussed a draft presentation for the F2F. They plan to hold an open forum on how to present future work coming from the subcommittee because ballots may not always be the best approach. One idea is to produce a reference implementation to act as an example of how to properly implement the NCSSRs. Clint and Neil continued to work on the fallout of ballot SC38 to address BR section 4.1.1?s suspicious certificate database and a reformatting of BR 5.4 and 5.5 retention periods. 7. Ballot Status Ballots in Discussion Period ? SC38 ? Alignment of Record Archival Neil said that this ballot is past the 21-day period and has automatically failed. Jos said that he will confirm and post an update to the list. Ballots in Voting Period ? SC41 - Reformat the BRs, EVGs, and NCSSRs Ryan asked everyone to vote. Ballots in Review Period ? SC39v3 ? Definition of Critical Vulnerability Jos asked everyone to perform an IPR review and file exclusions if needed. Draft Ballots Under Consideration ? Ballot SC40: Security Requirements for Air-Gapped CA Systems (Ben) Ben Wilson said that there are two comments. The first is about data going in and out of root CA system. CAs input things to sign and then take out signed objects. The second comment was that this process needs to be more secure. The first is easy to fix via a change to the ?unidirectional? language. The second is quite difficult to fix succinctly. It might be better suited for the reference implementation document that Neil mentioned. Ben will post a revision to keep the discussion alive. Wayne Thayer noted that the changes in this ballot can have significant unintended consequences, a few of which have already been discussed. Wayne encouraged all CAs to closely review the ballot while it is still in the discussion phase and easy to modify. Jos stated his agreement with Wayne. ? Ballot SCXX: Debian Weak Keys (Chris) Chris Kemmerer said that he?d like to discuss this at the upcoming F2F, and that he will send a proposal in advance. Jos will add this to the agenda. ? Ballot SC34 Account Management (Tobi) Tobi Josefowitz said that if SC41 passes this pull request will have conflicts, and asked what the procedure is for that. Jos said that Tobi could update the PR by merging in the changes from SC41. Ryan offered to help via Slack and suggested that Tobi rebase the change on top of the SC41 branch. Tobi said that it?d be nice if we can retain the comments, and Ryan said that he would think about how to do that. Ryan said that he?d invite Tobi to the Infrastructure Slack group. Jos noted that Slack is a good way to ask questions of the Infrastructure subcommittee, and Ryan said that Slack is great for real-time communications but the mailing list is also an appropriate place to ask questions. 8. Any Other Business Jos said that the agenda has been posted on the wiki and asked members to review and contact him with any proposed updates. 9. Next call:TBD (after the F2F) at 11AM Eastern Adjourn; Immediately convene meeting of CA Browser Forum call (same call) -- Jos Purvis (jopurvis at cisco.com) .:|:.:|:. cisco systems | Cryptographic Services PGP: 0xFD802FEE07D19105 | Controls and Trust Verification -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3699 bytes Desc: not available URL: From bwilson at mozilla.com Mon Mar 8 03:35:45 2021 From: bwilson at mozilla.com (Ben Wilson) Date: Sun, 7 Mar 2021 20:35:45 -0700 Subject: [Servercert-wg] Ballot SC40v3: Security Requirements for Air-Gapped CA Systems Message-ID: This is a continuation of discussion on the air-gapped CA ballot. This formally continues the discussion for this ballot. The discussion period will continue until initiation of the Voting Period (TBD) unless extended or as otherwise determined, pursuant to the CA/Browser Forum Bylaws. Based on the comments received, we discussed the definition of Air-Gapped CA System and now propose it to read: "A system that is (a) physically and logically separated from all other CA systems, and (b) used by a CA or Delegated Third Party to store and manage CA private keys and to sign CA certificates, CRLs, or OCSP responses. This means that the CA hardware is securely stored in a powered-off state, and when powered on, is not connected to any other system at any time. Approved transportable media is used to move ceremony materials (e.g. ceremony code, certificate profiles, CSRs, public keys) and to export ceremony materials (e.g. public keys, certificates, CRLs, and OCSP responses) in accordance with the CA?s established procedures." ------------------ Ballot SC 40v3: Security Requirements for Air-Gapped CA Systems Purpose of the Ballot: This ballot increases the security of Air-Gapped/Offline CA systems (?Air-Gapped CA Systems?) by clarifying the controls that CAs must implement to protect them. Air-Gapped CA systems are maintained in physically isolated environments, and while they can share certain exterior physical controls with online systems, they are not connected to online systems or the Internet. Thus, they have different operational requirements and controls due to their separate risk profile. While the scope of the current Network and Certificate System Security Requirements includes Air-Gapped CA systems, the document focuses on online systems and contains a number of requirements that are not practical to implement in an offline environment and could increase the risk to offline systems. As an example, access to offline systems frequently elevates the risk to the environment. A quarterly vulnerability scan in the offline environment is not practical, because there is an increased risk involved with attaching a scanning device to an Air-Gapped CA system. As another example, because such systems are not connected, the provisions of subsection 1.g (ports and protocols) are not applicable. This ballot develops a working definition for an ?Air-Gapped CA System? to allow for a clear delineation between those system components that fall under this category of Air-Gapped/Offline requirements and those under other requirements. In doing so, the ballot creates two sets of requirements tailored to their respective operating environments and characteristics. Not only does this ballot introduce a new section 5, it also adds additional physical security requirements for air-gapped CAs by requiring video monitoring, intrusion detection, and other intrusion prevention controls to protect Air-Gapped CA Systems against unauthorized physical access attempts. These proposed subsections in a new section 5 come from the current NCSSRs as follows: Description Offline Criteria # General Criteria # 5.1 Logical Security of Air-Gapped CA Systems Configuration review 5.1.1 1h Appointing individuals to trusted roles 5.1.2 2a Grant access to Air-Gapped CAs 5.1.3 1i Document responsibilities of Trusted roles 5.1.4 2b Segregation of duties 5.1.5 2d Require least privileged access for Trusted Roles 5.1.6 2e All access tracked to individual account 5.1.7 2f Password requirements 5.1.8 2gi Review logical access 5.1.9 2j Implement multi-factor access 5.1.10 2m Monitor Air-Gapped CA systems 5.1.11 3b Review logging integrity 5.1.12 3e Monitor archive and retention of logs 5.1.13 3f 5.2 Physical Security of Air-Gapped CA Systems Grant physical access 5.2.1 1i Multi-person physical access 5.2.2 1j Review physical access 5.2.3 2j Video monitoring 5.2.4 3a Physical access monitoring 5.2.5 3a Review accounts with physical access 5.2.6 2j Monitor retention of physical access of records 5.2.7 3f Review integrity of physical access logs 5.2.8 3e This motion is made by Ben Wilson of Mozilla and endorsed by David Kluge of Google Trust Services and Neil Dunbar of TrustCor. --- Motion Begins --- That the CA/Browser Forum Server Certificate Working Group adopt the following requirements as amendments to the Network and Certificate System Security Requirements. Replace 1.c. with "Maintain Root CA Systems in a High Security Zone and as Air-Gapped CA Systems, in accordance with Section 5;" Add definition of "Air-Gapped CA System" as "A system that is (a) physically and logically separated from all other CA systems, and (b) used by a CA or Delegated Third Party to store and manage CA private keys and to sign CA certificates, CRLs, or OCSP responses. This means that the CA hardware is securely stored in a powered-off state, and when powered on, is not connected to any other system at any time. Approved transportable media is used to move ceremony materials (e.g. ceremony code, certificate profiles, CSRs, public keys) and to export ceremony materials (e.g. public keys, certificates, CRLs, and OCSP responses) in accordance with the CA?s established procedures." Revise the definition of Security Support System to read: "A system used to provide physical and logical security support functions, which MAY include authentication, network boundary control, audit logging, audit log reduction and analysis, vulnerability scanning, and intrusion detection (physical intrusion detection, Host-based intrusion detection, Network-based intrusion detection)." Add a new Section 5 - 5. GENERAL PROTECTIONS FOR AIR-GAPPED CA SYSTEMS This Section 5 separates requirements for Air-Gapped CA Systems into two categories--logical security and physical security. 5.1 Logical Security of Air-Gapped CA Systems Certification Authorities and Delegated Third Parties SHALL implement the following controls to ensure the logical security of Air-Gapped CA Systems: 1. Review configurations of Air-Gapped CA Systems at least on an annual basis; 2. Follow a documented procedure for appointing individuals to those Trusted Roles that are authorized to operate Air-Gapped CA Systems; 3. Grant logical access to Air-Gapped CA Systems only to persons acting in Trusted Roles and implement controls so that all logical access to Air-Gapped CA Systems can be traced back to an accountable individual; 4. Document the responsibilities assigned to Trusted Roles based on the security principle of multi-person control and the security-related concerns of the functions to be performed; 5. Ensure that an individual in a Trusted Role acts only within the scope of such role when performing administrative tasks assigned to that role; 6. Require employees and contractors to observe the principle of "least privilege" when accessing, or when configuring access privileges on, Air-Gapped CA Systems; 7. Require that all access to systems and offline key material can be traced back to an individual in a Trusted Role (through a combination of recordkeeping, use of logical and physical credentials, authentication factors, video recording, etc.); 8. If an authentication control used by a Trusted Role is a username and password, then, where technically feasible require that passwords have at least twelve (12) characters; 9. Review logical access control lists at least annually and deactivate any accounts that are no longer necessary for operations; 10. Enforce Multi-Factor Authentication OR multi-party authentication for administrator access to Air-Gapped CA Systems; 11. Identify those Air-Gapped CA Systems capable of monitoring and logging system activity and enable those systems to continuously monitor and log system activity. Back up logs to an external system each time the system is used or on a quarterly basis, whichever is less frequent; 12. On a quarterly basis or each time the Air-Gapped CA System is used, whichever is less frequent, check the integrity of the logical access logging processes and ensure that logging and log-integrity functions are effective; 13. On a quarterly basis or each time the Air-Gapped CA System is used, whichever is less frequent, monitor the archival and retention of logical access logs to ensure that logs are retained for the appropriate amount of time in accordance with the disclosed business practices and applicable legislation. 5.2 Physical Security of Air-Gapped CA Systems Certification Authorities and Delegated Third Parties SHALL implement the following controls to ensure the physical security of Air-Gapped CA Systems: 1. Grant physical access to Air-Gapped CA Systems only to persons acting in Trusted Roles and implement controls so that all physical access to Air-Gapped CA Systems can be traced back to an accountable individual; 2. Ensure that only personnel assigned to Trusted Roles have physical access to Air-Gapped CA Systems and multi-person access controls are enforced at all times; 3. Implement a process that removes physical access of an individual to all Air-Gapped CA Systems within twenty-four (24) hours upon termination of the individual?s employment or contracting relationship with the CA or Delegated Third Party; 4. Implement video monitoring, intrusion detection, and intrusion prevention controls to protect Air-Gapped CA Systems against unauthorized physical access attempts; 5. Implement a Security Support System that monitors, detects, and alerts personnel to any physical access to Air-Gapped CA Systems; 6. Implement a process that prevents physical access of an individual to an Air-Gapped CA within twenty-four (24) hours of removal from the relevant authorized Trusted Role, and review lists of holders of physical keys and combinations to doors and safes as well as logical accounts tied to physical access controls at least every three (3) months, and; 7. On a quarterly basis or each time the Air-Gapped CA System is used, whichever is less frequent, monitor the archival and retention of the physical access logs to ensure that logs are retained for the appropriate amount of time in accordance with the disclosed business practices and applicable legislation. 8. On a quarterly basis or each time the Air-Gapped CA System is used, whichever is less frequent, check the integrity of the physical access logging processes and ensure that logging and log-integrity functions are effective. --- Motion Ends --- Discussion Period - This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows: Discussion (7+ days) Start Time: 2021-03-08 04:00 UTC End Time: TBD Vote for approval (7 days) Start Time: TBD End Time: TBD -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Morton at entrust.com Mon Mar 8 13:53:53 2021 From: Bruce.Morton at entrust.com (Bruce Morton) Date: Mon, 8 Mar 2021 13:53:53 +0000 Subject: [Servercert-wg] [EXTERNAL] Ballot SC40v3: Security Requirements for Air-Gapped CA Systems In-Reply-To: <010001780fe7f293-b84540e4-722d-4c38-9914-46333bd5903a-000000@email.amazonses.com> References: <010001780fe7f293-b84540e4-722d-4c38-9914-46333bd5903a-000000@email.amazonses.com> Message-ID: Hi Ben, The definition of ?Air-Gapped CA System? also has some requirements which state, ?This means that the CA hardware is securely stored in a powered-off state, and when powered on, is not connected to any other system at any time. Approved transportable media is used to move ceremony materials (e.g. ceremony code, certificate profiles, CSRs, public keys) and to export ceremony materials (e.g. public keys, certificates, CRLs, and OCSP responses) in accordance with the CA?s established procedures.? I think that it will be better for compliance and auditing if the requirements were listed in section 5. You mention that the ballot ?also adds additional physical security requirements.? This may mean that some CAs will need to make changes. As such, I think that a future n effectivity date should be part of the ballot. For clarity, in 5.2 items 3 and 6 it states ?an individual to all Air-Gapped CA Systems.? Could this be changed to ?an individual in a Trusted Role to all Air-Gapped CA Systems?? Just a comment on editing, but for consistency, can this section be a list of sentences that end in a period? I see that some end with a semi-colon, an and with a semi-colon, or a period. Thanks, Bruce. From: Servercert-wg On Behalf Of Ben Wilson via Servercert-wg Sent: Sunday, March 7, 2021 10:36 PM To: CA/B Forum Server Certificate WG Public Discussion List Subject: [EXTERNAL] [Servercert-wg] Ballot SC40v3: Security Requirements for Air-Gapped CA Systems WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. ________________________________ This is a continuation of discussion on the air-gapped CA ballot. This formally continues the discussion for this ballot. The discussion period will continue until initiation of the Voting Period (TBD) unless extended or as otherwise determined, pursuant to the CA/Browser Forum Bylaws. Based on the comments received, we discussed the definition of Air-Gapped CA System and now propose it to read: "A system that is (a) physically and logically separated from all other CA systems, and (b) used by a CA or Delegated Third Party to store and manage CA private keys and to sign CA certificates, CRLs, or OCSP responses. This means that the CA hardware is securely stored in a powered-off state, and when powered on, is not connected to any other system at any time. Approved transportable media is used to move ceremony materials (e.g. ceremony code, certificate profiles, CSRs, public keys) and to export ceremony materials (e.g. public keys, certificates, CRLs, and OCSP responses) in accordance with the CA?s established procedures." ------------------ Ballot SC 40v3: Security Requirements for Air-Gapped CA Systems Purpose of the Ballot: This ballot increases the security of Air-Gapped/Offline CA systems (?Air-Gapped CA Systems?) by clarifying the controls that CAs must implement to protect them. Air-Gapped CA systems are maintained in physically isolated environments, and while they can share certain exterior physical controls with online systems, they are not connected to online systems or the Internet. Thus, they have different operational requirements and controls due to their separate risk profile. While the scope of the current Network and Certificate System Security Requirements includes Air-Gapped CA systems, the document focuses on online systems and contains a number of requirements that are not practical to implement in an offline environment and could increase the risk to offline systems. As an example, access to offline systems frequently elevates the risk to the environment. A quarterly vulnerability scan in the offline environment is not practical, because there is an increased risk involved with attaching a scanning device to an Air-Gapped CA system. As another example, because such systems are not connected, the provisions of subsection 1.g (ports and protocols) are not applicable. This ballot develops a working definition for an ?Air-Gapped CA System? to allow for a clear delineation between those system components that fall under this category of Air-Gapped/Offline requirements and those under other requirements. In doing so, the ballot creates two sets of requirements tailored to their respective operating environments and characteristics. Not only does this ballot introduce a new section 5, it also adds additional physical security requirements for air-gapped CAs by requiring video monitoring, intrusion detection, and other intrusion prevention controls to protect Air-Gapped CA Systems against unauthorized physical access attempts. These proposed subsections in a new section 5 come from the current NCSSRs as follows: Description Offline Criteria # General Criteria # 5.1 Logical Security of Air-Gapped CA Systems Configuration review 5.1.1 1h Appointing individuals to trusted roles 5.1.2 2a Grant access to Air-Gapped CAs 5.1.3 1i Document responsibilities of Trusted roles 5.1.4 2b Segregation of duties 5.1.5 2d Require least privileged access for Trusted Roles 5.1.6 2e All access tracked to individual account 5.1.7 2f Password requirements 5.1.8 2gi Review logical access 5.1.9 2j Implement multi-factor access 5.1.10 2m Monitor Air-Gapped CA systems 5.1.11 3b Review logging integrity 5.1.12 3e Monitor archive and retention of logs 5.1.13 3f 5.2 Physical Security of Air-Gapped CA Systems Grant physical access 5.2.1 1i Multi-person physical access 5.2.2 1j Review physical access 5.2.3 2j Video monitoring 5.2.4 3a Physical access monitoring 5.2.5 3a Review accounts with physical access 5.2.6 2j Monitor retention of physical access of records 5.2.7 3f Review integrity of physical access logs 5.2.8 3e This motion is made by Ben Wilson of Mozilla and endorsed by David Kluge of Google Trust Services and Neil Dunbar of TrustCor. --- Motion Begins --- That the CA/Browser Forum Server Certificate Working Group adopt the following requirements as amendments to the Network and Certificate System Security Requirements. Replace 1.c. with "Maintain Root CA Systems in a High Security Zone and as Air-Gapped CA Systems, in accordance with Section 5;" Add definition of "Air-Gapped CA System" as "A system that is (a) physically and logically separated from all other CA systems, and (b) used by a CA or Delegated Third Party to store and manage CA private keys and to sign CA certificates, CRLs, or OCSP responses. This means that the CA hardware is securely stored in a powered-off state, and when powered on, is not connected to any other system at any time. Approved transportable media is used to move ceremony materials (e.g. ceremony code, certificate profiles, CSRs, public keys) and to export ceremony materials (e.g. public keys, certificates, CRLs, and OCSP responses) in accordance with the CA?s established procedures." Revise the definition of Security Support System to read: "A system used to provide physical and logical security support functions, which MAY include authentication, network boundary control, audit logging, audit log reduction and analysis, vulnerability scanning, and intrusion detection (physical intrusion detection, Host-based intrusion detection, Network-based intrusion detection)." Add a new Section 5 - 5. GENERAL PROTECTIONS FOR AIR-GAPPED CA SYSTEMS This Section 5 separates requirements for Air-Gapped CA Systems into two categories--logical security and physical security. 5.1 Logical Security of Air-Gapped CA Systems Certification Authorities and Delegated Third Parties SHALL implement the following controls to ensure the logical security of Air-Gapped CA Systems: 1. Review configurations of Air-Gapped CA Systems at least on an annual basis; 2. Follow a documented procedure for appointing individuals to those Trusted Roles that are authorized to operate Air-Gapped CA Systems; 3. Grant logical access to Air-Gapped CA Systems only to persons acting in Trusted Roles and implement controls so that all logical access to Air-Gapped CA Systems can be traced back to an accountable individual; 4. Document the responsibilities assigned to Trusted Roles based on the security principle of multi-person control and the security-related concerns of the functions to be performed; 5. Ensure that an individual in a Trusted Role acts only within the scope of such role when performing administrative tasks assigned to that role; 6. Require employees and contractors to observe the principle of "least privilege" when accessing, or when configuring access privileges on, Air-Gapped CA Systems; 7. Require that all access to systems and offline key material can be traced back to an individual in a Trusted Role (through a combination of recordkeeping, use of logical and physical credentials, authentication factors, video recording, etc.); 8. If an authentication control used by a Trusted Role is a username and password, then, where technically feasible require that passwords have at least twelve (12) characters; 9. Review logical access control lists at least annually and deactivate any accounts that are no longer necessary for operations; 10. Enforce Multi-Factor Authentication OR multi-party authentication for administrator access to Air-Gapped CA Systems; 11. Identify those Air-Gapped CA Systems capable of monitoring and logging system activity and enable those systems to continuously monitor and log system activity. Back up logs to an external system each time the system is used or on a quarterly basis, whichever is less frequent; 12. On a quarterly basis or each time the Air-Gapped CA System is used, whichever is less frequent, check the integrity of the logical access logging processes and ensure that logging and log-integrity functions are effective; 13. On a quarterly basis or each time the Air-Gapped CA System is used, whichever is less frequent, monitor the archival and retention of logical access logs to ensure that logs are retained for the appropriate amount of time in accordance with the disclosed business practices and applicable legislation. 5.2 Physical Security of Air-Gapped CA Systems Certification Authorities and Delegated Third Parties SHALL implement the following controls to ensure the physical security of Air-Gapped CA Systems: 1. Grant physical access to Air-Gapped CA Systems only to persons acting in Trusted Roles and implement controls so that all physical access to Air-Gapped CA Systems can be traced back to an accountable individual; 2. Ensure that only personnel assigned to Trusted Roles have physical access to Air-Gapped CA Systems and multi-person access controls are enforced at all times; 3. Implement a process that removes physical access of an individual to all Air-Gapped CA Systems within twenty-four (24) hours upon termination of the individual?s employment or contracting relationship with the CA or Delegated Third Party; 4. Implement video monitoring, intrusion detection, and intrusion prevention controls to protect Air-Gapped CA Systems against unauthorized physical access attempts; 5. Implement a Security Support System that monitors, detects, and alerts personnel to any physical access to Air-Gapped CA Systems; 6. Implement a process that prevents physical access of an individual to an Air-Gapped CA within twenty-four (24) hours of removal from the relevant authorized Trusted Role, and review lists of holders of physical keys and combinations to doors and safes as well as logical accounts tied to physical access controls at least every three (3) months, and; 7. On a quarterly basis or each time the Air-Gapped CA System is used, whichever is less frequent, monitor the archival and retention of the physical access logs to ensure that logs are retained for the appropriate amount of time in accordance with the disclosed business practices and applicable legislation. 8. On a quarterly basis or each time the Air-Gapped CA System is used, whichever is less frequent, check the integrity of the physical access logging processes and ensure that logging and log-integrity functions are effective. --- Motion Ends --- Discussion Period - This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows: Discussion (7+ days) Start Time: 2021-03-08 04:00 UTC End Time: TBD Vote for approval (7 days) Start Time: TBD End Time: TBD -------------- next part -------------- An HTML attachment was scrubbed... URL: From wendy.brown at gsa.gov Mon Mar 8 14:06:52 2021 From: wendy.brown at gsa.gov (Wendy Brown - QT3LB-C) Date: Mon, 8 Mar 2021 09:06:52 -0500 Subject: [Servercert-wg] Ballot SC40v3: Security Requirements for Air-Gapped CA Systems In-Reply-To: <010001780fe7f59a-a8b7830b-406a-4720-bfcc-71067582f5b6-000000@email.amazonses.com> References: <010001780fe7f59a-a8b7830b-406a-4720-bfcc-71067582f5b6-000000@email.amazonses.com> Message-ID: I'm not sure I agree with the first clause of the definition: A system that is (a) physically and logically separated from all other CA systems for 2 reasons: 1) if the CA uses an HSM server, it should be able to be connected to the HSM when turned on as long as the HSM is powered off when the CA is and not connected to any other systems 2) Why would it not be reasonable to have the same hardware host VMs for multiple offline CAs all operated by the same trusted roles? Or some CA software can support multiple CAs (such as Red Hat, Unicert, and PrimeKey/EJBCA). Multiple CAs running on the same platform, that is offline, should be considered offline, even though they are not physically separate from each other. Thanks, Wendy Wendy Brown Supporting GSA FPKI Protiviti Government Services 703-965-2990 (cell) wendy.brown at gsa.gov wendy.brown at protiviti.com On Sun, Mar 7, 2021 at 10:36 PM Ben Wilson via Servercert-wg < servercert-wg at cabforum.org> wrote: > This is a continuation of discussion on the air-gapped CA ballot. This > formally continues the discussion for this ballot. The discussion period > will continue until initiation of the Voting Period (TBD) unless extended > or as otherwise determined, pursuant to the CA/Browser Forum Bylaws. > > Based on the comments received, we discussed the definition of Air-Gapped > CA System and now propose it to read: "A system that is (a) physically > and logically separated from all other CA systems, and (b) used by a CA or > Delegated Third Party to store and manage CA private keys and to sign CA > certificates, CRLs, or OCSP responses. This means that the CA hardware is > securely stored in a powered-off state, and when powered on, is not > connected to any other system at any time. Approved transportable media is > used to move ceremony materials (e.g. ceremony code, certificate profiles, > CSRs, public keys) and to export ceremony materials (e.g. public keys, > certificates, CRLs, and OCSP responses) in accordance with the CA?s > established procedures." > > ------------------ > > Ballot SC 40v3: Security Requirements for Air-Gapped CA Systems > > Purpose of the Ballot: > > This ballot increases the security of Air-Gapped/Offline CA systems > (?Air-Gapped CA Systems?) by clarifying the controls that CAs must > implement to protect them. > > Air-Gapped CA systems are maintained in physically isolated environments, > and while they can share certain exterior physical controls with online > systems, they are not connected to online systems or the Internet. Thus, > they have different operational requirements and controls due to their > separate risk profile. While the scope of the current Network and > Certificate System Security Requirements includes Air-Gapped CA systems, > the document focuses on online systems and contains a number of > requirements that are not practical to implement in an offline environment > and could increase the risk to offline systems. > > As an example, access to offline systems frequently elevates the risk to > the environment. A quarterly vulnerability scan in the offline environment > is not practical, because there is an increased risk involved with > attaching a scanning device to an Air-Gapped CA system. As another example, > because such systems are not connected, the provisions of subsection 1.g > (ports and protocols) are not applicable. > > This ballot develops a working definition for an ?Air-Gapped CA System? to > allow for a clear delineation between those system components that fall > under this category of Air-Gapped/Offline requirements and those under > other requirements. In doing so, the ballot creates two sets of > requirements tailored to their respective operating environments and > characteristics. > > Not only does this ballot introduce a new section 5, it also adds > additional physical security requirements for air-gapped CAs by requiring > video monitoring, intrusion detection, and other intrusion prevention > controls to protect Air-Gapped CA Systems against unauthorized physical > access attempts. > > These proposed subsections in a new section 5 come from the current NCSSRs > as follows: > > > Description > > Offline > > Criteria # > > General > > Criteria # > > 5.1 Logical Security of Air-Gapped CA Systems > > > Configuration review > > 5.1.1 > > 1h > > Appointing individuals to trusted roles > > 5.1.2 > > 2a > > Grant access to Air-Gapped CAs > > 5.1.3 > > 1i > > Document responsibilities of Trusted roles > > 5.1.4 > > 2b > > Segregation of duties > > 5.1.5 > > 2d > > Require least privileged access for Trusted Roles > > 5.1.6 > > 2e > > All access tracked to individual account > > 5.1.7 > > 2f > > Password requirements > > 5.1.8 > > 2gi > > Review logical access > > 5.1.9 > > 2j > > Implement multi-factor access > > 5.1.10 > > 2m > > Monitor Air-Gapped CA systems > > 5.1.11 > > 3b > > Review logging integrity > > 5.1.12 > > 3e > > Monitor archive and retention of logs > > 5.1.13 > > 3f > > 5.2 Physical Security of Air-Gapped CA Systems > > > Grant physical access > > 5.2.1 > > 1i > > Multi-person physical access > > 5.2.2 > > 1j > > Review physical access > > 5.2.3 > > 2j > > Video monitoring > > 5.2.4 > > 3a > > Physical access monitoring > > 5.2.5 > > 3a > > Review accounts with physical access > > 5.2.6 > > 2j > > Monitor retention of physical access of records > > 5.2.7 > > 3f > > Review integrity of physical access logs > > 5.2.8 > > 3e > > This motion is made by Ben Wilson of Mozilla and endorsed by David Kluge > of Google Trust Services and Neil Dunbar of TrustCor. > > > --- Motion Begins --- > > That the CA/Browser Forum Server Certificate Working Group adopt the > following requirements as amendments to the Network and Certificate System > Security Requirements. > > Replace 1.c. with "Maintain Root CA Systems in a High Security Zone and as > Air-Gapped CA Systems, in accordance with Section 5;" > > Add definition of "Air-Gapped CA System" as "A system that is (a) > physically and logically separated from all other CA systems, and (b) used > by a CA or Delegated Third Party to store and manage CA private keys and to > sign CA certificates, CRLs, or OCSP responses. This means that the CA > hardware is securely stored in a powered-off state, and when powered on, is > not connected to any other system at any time. Approved transportable media > is used to move ceremony materials (e.g. ceremony code, certificate > profiles, CSRs, public keys) and to export ceremony materials (e.g. public > keys, certificates, CRLs, and OCSP responses) in accordance with the CA?s > established procedures." > > Revise the definition of Security Support System to read: > > "A system used to provide physical and logical security support functions, > which MAY include authentication, network boundary control, audit logging, > audit log reduction and analysis, vulnerability scanning, and intrusion > detection (physical intrusion detection, Host-based intrusion detection, > Network-based intrusion detection)." > > Add a new Section 5 - > > 5. GENERAL PROTECTIONS FOR AIR-GAPPED CA SYSTEMS > > This Section 5 separates requirements for Air-Gapped CA Systems into two > categories--logical security and physical security. > > 5.1 Logical Security of Air-Gapped CA Systems > > Certification Authorities and Delegated Third Parties SHALL implement the > following controls to ensure the logical security of Air-Gapped CA Systems: > > 1. Review configurations of Air-Gapped CA Systems at least on an annual > basis; > > 2. Follow a documented procedure for appointing individuals to those > Trusted Roles that are authorized to operate Air-Gapped CA Systems; > > 3. Grant logical access to Air-Gapped CA Systems only to persons acting in > Trusted Roles and implement controls so that all logical access to > Air-Gapped CA Systems can be traced back to an accountable individual; > > 4. Document the responsibilities assigned to Trusted Roles based on the > security principle of multi-person control and the security-related > concerns of the functions to be performed; > > 5. Ensure that an individual in a Trusted Role acts only within the scope > of such role when performing administrative tasks assigned to that role; > > 6. Require employees and contractors to observe the principle of "least > privilege" when accessing, or when configuring access privileges on, > Air-Gapped CA Systems; > > 7. Require that all access to systems and offline key material can be > traced back to an individual in a Trusted Role (through a combination of > recordkeeping, use of logical and physical credentials, authentication > factors, video recording, etc.); > > 8. If an authentication control used by a Trusted Role is a username and > password, then, where technically feasible require that passwords have at > least twelve (12) characters; > > 9. Review logical access control lists at least annually and deactivate > any accounts that are no longer necessary for operations; > > 10. Enforce Multi-Factor Authentication OR multi-party authentication for > administrator access to Air-Gapped CA Systems; > > 11. Identify those Air-Gapped CA Systems capable of monitoring and logging > system activity and enable those systems to continuously monitor and log > system activity. Back up logs to an external system each time the system is > used or on a quarterly basis, whichever is less frequent; > > 12. On a quarterly basis or each time the Air-Gapped CA System is used, > whichever is less frequent, check the integrity of the logical access > logging processes and ensure that logging and log-integrity functions are > effective; > > 13. On a quarterly basis or each time the Air-Gapped CA System is used, > whichever is less frequent, monitor the archival and retention of logical > access logs to ensure that logs are retained for the appropriate amount of > time in accordance with the disclosed business practices and applicable > legislation. > > 5.2 Physical Security of Air-Gapped CA Systems > > Certification Authorities and Delegated Third Parties SHALL implement the > following controls to ensure the physical security of Air-Gapped CA Systems: > > 1. Grant physical access to Air-Gapped CA Systems only to persons acting > in Trusted Roles and implement controls so that all physical access to > Air-Gapped CA Systems can be traced back to an accountable individual; > > 2. Ensure that only personnel assigned to Trusted Roles have physical > access to Air-Gapped CA Systems and multi-person access controls are > enforced at all times; > > 3. Implement a process that removes physical access of an individual to > all Air-Gapped CA Systems within twenty-four (24) hours upon termination of > the individual?s employment or contracting relationship with the CA or > Delegated Third Party; > > 4. Implement video monitoring, intrusion detection, and intrusion > prevention controls to protect Air-Gapped CA Systems against unauthorized > physical access attempts; > > 5. Implement a Security Support System that monitors, detects, and alerts > personnel to any physical access to Air-Gapped CA Systems; > > 6. Implement a process that prevents physical access of an individual to > an Air-Gapped CA within twenty-four (24) hours of removal from the relevant > authorized Trusted Role, and review lists of holders of physical keys and > combinations to doors and safes as well as logical accounts tied to > physical access controls at least every three (3) months, and; > > 7. On a quarterly basis or each time the Air-Gapped CA System is used, > whichever is less frequent, monitor the archival and retention of the > physical access logs to ensure that logs are retained for the appropriate > amount of time in accordance with the disclosed business practices and > applicable legislation. > > 8. On a quarterly basis or each time the Air-Gapped CA System is used, > whichever is less frequent, check the integrity of the physical access > logging processes and ensure that logging and log-integrity functions are > effective. > > --- Motion Ends --- > > Discussion Period - > > This ballot proposes a Final Maintenance Guideline. > > The procedure for approval of this ballot is as follows: > > Discussion (7+ days) > > Start Time: 2021-03-08 04:00 UTC > > End Time: TBD > > Vote for approval (7 days) > > Start Time: TBD > > End Time: TBD > _______________________________________________ > Servercert-wg mailing list > Servercert-wg at cabforum.org > https://lists.cabforum.org/mailman/listinfo/servercert-wg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleevi at google.com Mon Mar 8 17:18:32 2021 From: sleevi at google.com (Ryan Sleevi) Date: Mon, 8 Mar 2021 12:18:32 -0500 Subject: [Servercert-wg] Ballot SC40v3: Security Requirements for Air-Gapped CA Systems In-Reply-To: <010001781229ba08-88f265b3-a04b-45db-8944-eb40bee4e0f6-000000@email.amazonses.com> References: <010001780fe7f59a-a8b7830b-406a-4720-bfcc-71067582f5b6-000000@email.amazonses.com> <010001781229ba08-88f265b3-a04b-45db-8944-eb40bee4e0f6-000000@email.amazonses.com> Message-ID: On Mon, Mar 8, 2021 at 9:07 AM Wendy Brown - QT3LB-C via Servercert-wg < servercert-wg at cabforum.org> wrote: > I'm not sure I agree with the first clause of the definition: A system > that is (a) physically and logically separated from all other CA systems > for 2 reasons: > 1) if the CA uses an HSM server, it should be able to be connected to the > HSM when turned on as long as the HSM is powered off when the CA is and not > connected to any other systems > When would this scenario be used? It seems somewhat dangerous - for example, if the CA system is considered online, but the HSM considered offline (even though physically connected, simply powered off), it seems like there's new threat models to consider (e.g. if the CA system can send a WoL packet to wake up the HSM system). So I'm trying to understand a bit more about what scenario this would be useful for, since it sounds like there's concern that the proposed language would prevent that scenario, to figure out how to resolve that. > 2) Why would it not be reasonable to have the same hardware host VMs for > multiple offline CAs all operated by the same trusted roles? Or some CA > software can support multiple CAs (such as Red Hat, Unicert, and > PrimeKey/EJBCA). Multiple CAs running on the same platform, that is > offline, should be considered offline, even though they are not physically > separate from each other. > I'm not sure I understand this second point. Are you suggesting that a CA running on such a system could have one CA configuration offline, and another CA configuration online? Or one CA configuration that is considered airgapped running on the same machine/software as another CA configuration that is not? Neither of those sound like good things to me, and I don't think it'd be what you'd be suggesting. I *think* in such scenarios we want the same outcome: namely, if you bring such a system online (whether a device with multiple VMs or a server instance with multiple CAs), the point at which *one* is online should be considered the point in which *all* are online, and the same obligations occur regarding configuration state expectations. Is that a correct understanding? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wendy.brown at gsa.gov Mon Mar 8 17:43:48 2021 From: wendy.brown at gsa.gov (Wendy Brown - QT3LB-C) Date: Mon, 8 Mar 2021 12:43:48 -0500 Subject: [Servercert-wg] Ballot SC40v3: Security Requirements for Air-Gapped CA Systems In-Reply-To: References: <010001780fe7f59a-a8b7830b-406a-4720-bfcc-71067582f5b6-000000@email.amazonses.com> <010001781229ba08-88f265b3-a04b-45db-8944-eb40bee4e0f6-000000@email.amazonses.com> Message-ID: no - I am suggesting in both cases these configurations are for offline CAs but seem to contradict the first clause of the proposed definition: A system that is (a) physically and logically separated from all other CA systems 1) an OFFLINE & Air-gapped CA that uses a network HSM - BOTH the CA server & the HSM are only connected to each other and both powered off, except when needed to be powered on to do some function like sign or revoke a cert or issue a CRL or 2) again hardware dedicated only to the operation of OFFLINE & Air-gapped CAs, but potentially hosting multiple offline/Air-gapped CAs on the same hardware, operated by the same trusted roles - not co-mingling with anything considered online or connected to any supporting systems that have to be online Wendy Wendy Brown Supporting GSA FPKI Protiviti Government Services 703-965-2990 (cell) wendy.brown at gsa.gov wendy.brown at protiviti.com On Mon, Mar 8, 2021 at 12:19 PM Ryan Sleevi wrote: > > > On Mon, Mar 8, 2021 at 9:07 AM Wendy Brown - QT3LB-C via Servercert-wg < > servercert-wg at cabforum.org> wrote: > >> I'm not sure I agree with the first clause of the definition: A system >> that is (a) physically and logically separated from all other CA systems >> for 2 reasons: >> 1) if the CA uses an HSM server, it should be able to be connected to the >> HSM when turned on as long as the HSM is powered off when the CA is and not >> connected to any other systems >> > > When would this scenario be used? It seems somewhat dangerous - for > example, if the CA system is considered online, but the HSM considered > offline (even though physically connected, simply powered off), it seems > like there's new threat models to consider (e.g. if the CA system can send > a WoL packet to wake up the HSM system). So I'm trying to understand a bit > more about what scenario this would be useful for, since it sounds like > there's concern that the proposed language would prevent that scenario, to > figure out how to resolve that. > > >> 2) Why would it not be reasonable to have the same hardware host VMs for >> multiple offline CAs all operated by the same trusted roles? Or some CA >> software can support multiple CAs (such as Red Hat, Unicert, and >> PrimeKey/EJBCA). Multiple CAs running on the same platform, that is >> offline, should be considered offline, even though they are not physically >> separate from each other. >> > > I'm not sure I understand this second point. Are you suggesting that a CA > running on such a system could have one CA configuration offline, and > another CA configuration online? Or one CA configuration that is considered > airgapped running on the same machine/software as another CA configuration > that is not? > > Neither of those sound like good things to me, and I don't think it'd be > what you'd be suggesting. I *think* in such scenarios we want the same > outcome: namely, if you bring such a system online (whether a device with > multiple VMs or a server instance with multiple CAs), the point at which > *one* is online should be considered the point in which *all* are online, > and the same obligations occur regarding configuration state expectations. > Is that a correct understanding? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jopurvis at cisco.com Mon Mar 8 18:13:17 2021 From: jopurvis at cisco.com (Jos Purvis (jopurvis)) Date: Mon, 8 Mar 2021 18:13:17 +0000 Subject: [Servercert-wg] Ballot SC40v3: Security Requirements for Air-Gapped CA Systems In-Reply-To: <0100017812f05413-38de86c4-a94b-48d9-88ad-6dea0e074d96-000000@email.amazonses.com> References: <010001780fe7f59a-a8b7830b-406a-4720-bfcc-71067582f5b6-000000@email.amazonses.com> <010001781229ba08-88f265b3-a04b-45db-8944-eb40bee4e0f6-000000@email.amazonses.com> <0100017812f05413-38de86c4-a94b-48d9-88ad-6dea0e074d96-000000@email.amazonses.com> Message-ID: <014EB0B4-9B52-4A1F-8151-05C15B9AFC91@cisco.com> Of those, the first definition (server + direct-attached HSM) seems not to be blocked by the definition, if we?re including both the server and its HSM as one ?CA system?. (That is, the ?CA system? consists of one server plus HSM.) The language might need tweaking to specifically allow that and under what circumstances (for example, the HSM must be directly connected via dedicated cable). Considering the two as a pair would seem to also eliminate any possibility of trying to have an online server but an ?offline? HSM, too: all parts of the CA required to perform issuance tasks must either be considered online or offline. The second one would arguably be problematic, yes. Just off the cuff, I?ve seen at least these three configurations in various (non-BR-involved!) contexts: I have a single offline server-plus-HSM pair that is capable of operating CAs foo, bar, baz, and quux. The keys for all four CAs are stored offline in the HSM, but I only activate and utilize one CA at a time, enforced by the hardware activation mechanisms of the HSM. (Thus, if I am busy performing operations on CA foo, it is not possible to perform any PKI operations on CA quux, and so forth.) All four CAs are physically isolated from the outside, and are also isolated from each other in the HSM, but there is a common set of OS and CA files in use. I have a single offline server-plus-HSM set with a common OS, but all of the files for the CA are kept on a removable disk and checked into a safe when not in use, while the keys are only stored in any form in the HSM when the CA is in use and then wiped after. Now the isolation is stronger thanks to unique CA files as well as HSM isolation, but you still have a shared OS platform. (And you could extend this model further to a diskless system in which I simply insert the disks for each CA, to create complete system-level isolation for each one, just on a common hardware platform.) I have four offline CAs, each of which have their own server, but which share a common network-based HSM. The whole environment is physically air-gapped from any outside connections and the CAs are logically isolated, but each has network access to a common HSM (perhaps via a common ?dumb? switch). The whole ecosystem thus exists in a physically air-gapped bubble, but the isolation of the CA servers from each other becomes a matter of logical protections rather than physical. All of these are things that people will commonly refer to as an ?offline CA?, but there are definitely shades of grey when it comes to how much real isolation is occurring. Which of those we want to permit or not permit would be the question. -- Jos Purvis (jopurvis at cisco.com) .:|:.:|:. cisco systems | Cryptographic Services PGP: 0xFD802FEE07D19105 | Controls and Trust Verification From: Servercert-wg on behalf of CABF Server Cert WG Reply-To: Wendy Brown - QT3LB-C , CABF Server Cert WG Date: Monday, March 8, 2021 at 12:44 PM To: Ryan Sleevi Cc: CABF Server Cert WG Subject: Re: [Servercert-wg] Ballot SC40v3: Security Requirements for Air-Gapped CA Systems no - I am suggesting in both cases these configurations are for offline CAs but seem to contradict the first clause of the proposed definition: A system that is (a) physically and logically separated from all other CA systems 1) an OFFLINE & Air-gapped CA that uses a network HSM - BOTH the CA server & the HSM are only connected to each other and both powered off, except when needed to be powered on to do some function like sign or revoke a cert or issue a CRL or 2) again hardware dedicated only to the operation of OFFLINE & Air-gapped CAs, but potentially hosting multiple offline/Air-gapped CAs on the same hardware, operated by the same trusted roles - not co-mingling with anything considered online or connected to any supporting systems that have to be online Wendy Wendy Brown Supporting GSA FPKI Protiviti Government Services 703-965-2990 (cell) wendy.brown at gsa.gov wendy.brown at protiviti.com On Mon, Mar 8, 2021 at 12:19 PM Ryan Sleevi wrote: On Mon, Mar 8, 2021 at 9:07 AM Wendy Brown - QT3LB-C via Servercert-wg wrote: I'm not sure I agree with the first clause of the definition: A system that is (a) physically and logically separated from all other CA systems for 2 reasons: 1) if the CA uses an HSM server, it should be able to be connected to the HSM when turned on as long as the HSM is powered off when the CA is and not connected to any other systems When would this scenario be used? It seems somewhat dangerous - for example, if the CA system is considered online, but the HSM considered offline (even though physically connected, simply powered off), it seems like there's new threat models to consider (e.g. if the CA system can send a WoL packet to wake up the HSM system). So I'm trying to understand a bit more about what scenario this would be useful for, since it sounds like there's concern that the proposed language would prevent that scenario, to figure out how to resolve that. 2) Why would it not be reasonable to have the same hardware host VMs for multiple offline CAs all operated by the same trusted roles? Or some CA software can support multiple CAs (such as Red Hat, Unicert, and PrimeKey/EJBCA). Multiple CAs running on the same platform, that is offline, should be considered offline, even though they are not physically separate from each other. I'm not sure I understand this second point. Are you suggesting that a CA running on such a system could have one CA configuration offline, and another CA configuration online? Or one CA configuration that is considered airgapped running on the same machine/software as another CA configuration that is not? Neither of those sound like good things to me, and I don't think it'd be what you'd be suggesting. I *think* in such scenarios we want the same outcome: namely, if you bring such a system online (whether a device with multiple VMs or a server instance with multiple CAs), the point at which one is online should be considered the point in which all are online, and the same obligations occur regarding configuration state expectations. Is that a correct understanding? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3699 bytes Desc: not available URL: From bwilson at mozilla.com Mon Mar 8 21:05:40 2021 From: bwilson at mozilla.com (Ben Wilson) Date: Mon, 8 Mar 2021 14:05:40 -0700 Subject: [Servercert-wg] [EXTERNAL] Re: Reducing Domain/IP Address Validation Reuse to 398 Days In-Reply-To: <01000177da8bffb1-52c13db3-fc4e-4a2d-9287-1ffbba8999ac-000000@email.amazonses.com> References: <0100017774aa83bc-7b5c45fd-84d1-448b-8951-71a6ccea8cf6-000000@email.amazonses.com> <0100017782c7bb0e-aa038cae-abdb-46ef-ab18-5911aa850ef6-000000@email.amazonses.com> <0100017782d3ddb6-fb397740-7ff5-4a5d-93b3-d20f189c36ea-000000@email.amazonses.com> <0100017789405697-953be8e8-c7da-41ea-960a-e729ab523e25-000000@email.amazonses.com> <01000177a707641c-8c794a76-c1fb-4558-87d2-5d76372dcb90-000000@email.amazonses.com> <01000177bbb6adc9-11776fd6-1db1-4b93-8c1c-625fed861889-000000@email.amazonses.com> <01000177da8bffb1-52c13db3-fc4e-4a2d-9287-1ffbba8999ac-000000@email.amazonses.com> Message-ID: It has been proposed that we add the following language to the end of the third paragraph of BR section 4.2.1: "Effective 2021-10-01, the CA SHALL verify Domain Names and IP Addresses no more than 398 days prior to Certificate issuance." Is this language clear enough? On Thu, Feb 25, 2021 at 11:55 AM Ben Wilson via Servercert-wg < servercert-wg at cabforum.org> wrote: > Hi Bruce, > > See my responses inline below. > > On Mon, Feb 22, 2021 at 2:17 PM Bruce Morton > wrote: > >> Hi Ben, >> >> >> >> A couple of comments. >> >> >> >> The ballot does not address the ?cliff? that CAs have stated will occur. >> > > I do not see a "cliff" - it is more like a small hump. > > >> The thinking is that currently CAs are verifying domains, which can be >> reused for 825-days (~27 months). >> > > Agreed - currently CAs can reuse domain verification for 825-days (~27 > months). However, they should not be reusing FQDN and IP address > verification for such a long period, especially for one-year certificates. > There should only be a very small number of domains that are difficult to > verify, and if they've verified once before, then customers and CAs should > have procedures in place that can be re-performed. > > The new requirement implies that the domain verification can only be >> reused for 398-days (~13 months). >> > > The new requirement would apply to certificates issued on or after July 1, > 2021. This proposal does not require all certificate validations to be > redone, and the most recent verifications are more likely to still be > accurate. > > >> This means that for CAs which reuse domain validation, there will be 14 >> months of validation which will expire on the effective date of the ballot. >> > > Correct, but the 14 months of validation would be for those old > validations that were performed nearly 3 years ago -- from approximately > October 5, 2018 through December 6, 2109. > > >> In many cases this may create a lot of work on the Subscriber and the CA >> to revalidate these domains. >> > > I disagree. As stated above, there should be fewer reuse of validations > performed. I don't know of any statistics supporting the amount of work > that would need to be performed. Shouldn't these processes be automated? > Do you have data for the type of validations that were originally performed > between October 5, 2018 and December 6, 2109, to indicate how many of those > will be problematic? Also, the July 1, 2021, date has been circulated by > Mozilla for quite some time, and CAs should have been preparing for it. > > >> Is it possible to have the ballot only address domains which are >> validated after the effective date? The domains which are currently >> validated can be reused per their current schedule. >> > > We can discuss this more, but your request is just that new domains and IP > addresses be validated - which would already be required with or without an > amendment to policy. I think the currently proposed amendment is the best > approach. > >> >> >> Would it also be possible to push out the effective date by a quarter, so >> October 1, 2021? >> > > That might be a possibility, but doesn't that just move your "cliff". As > I say above, CAs and customers should already be moving toward more > frequent FQDN and IP Address verification. > > >> This will give the CAs more time to implement the change and to advise >> Subscribers of the impact. It will also give the Subscribers some time to >> address the volume of domains which will have to be re-validated. >> > > What is the volume of domains that will need to be revalidated? Two-year > certificates were eliminated last year, but how many 2-year certificates > would be coming up for renewal, and of those, how many had problematic > domain validation procedures that would need to be re-performed or replaced > with the currently allowed methods? > > Respectfully, > > Ben > > >> >> >> >> Thanks, Bruce. >> >> >> >> *From:* Servercert-wg *On Behalf Of >> *Ben Wilson via Servercert-wg >> *Sent:* Friday, February 19, 2021 2:14 PM >> *To:* CA/B Forum Server Certificate WG Public Discussion List < >> servercert-wg at cabforum.org> >> *Subject:* [EXTERNAL] Re: [Servercert-wg] Reducing Domain/IP Address >> Validation Reuse to 398 Days >> >> >> >> WARNING: This email originated outside of Entrust. >> DO NOT CLICK links or attachments unless you trust the sender and know >> the content is safe. >> ------------------------------ >> >> Here is a preliminary, rough draft of Ballot SC42 for discussion and >> comment. Please let me know if you spot any deficiencies in required >> content or procedure. >> >> In other words, this email is not intended to and does not begin the >> discussion period on this ballot. A separate, official email will be sent >> out next week for that purpose. >> >> Name of Ballot: 398-Day Reuse >> >> Purpose of Ballot: >> >> This ballot changes validation reuse periods for FQDN and IP Address >> validation in the Baseline Requirements and for all purposes in the EV >> Guidelines. The ballot does not change the 825-day reuse period in section >> 4.2.1. of the Baseline Requirements for Organizational Validation (OV) >> information. >> >> Specifically: >> >> * It inserts in BR section 3.2.2.4 ?For Certificates issued on or after >> July 1, 2021, the CA SHALL verify that each FQDN is confirmed as permitted >> by this section at intervals of 398 days or less.? It also requires that >> the validation be completed within the 398 days preceding certificate >> issuance and removes cross-references to BR section 4.2.1. >> >> * It modifies BR sections 3.2.2.4.3 and 3.2.2.4.6 to eliminate reuse of >> FQDN validation performed under those sunsetted provisions. >> >> * It modifies BR section 3.2.2.4.7 to replace subsections i. and ii. with >> a 30-day limit on reuse of the Random Value. >> >> * It inserts in BR section 3.2.2.5 ?For Certificates issued on or after >> July 1, 2021, the CA SHALL validate each IP address as permitted by this >> section at intervals of 398 days or less.? It also requires that the >> validation be completed within the 398 days preceding certificate issuance >> and removes cross-references to BR section 4.2.1. >> >> * It clarifies BR section 4.2.1 by stating, ?This 825-day period does not >> apply to the validation of domain authorization or control performed under >> [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) or >> the authentication of an IP address performed under [Section >> 3.2.2.5](#3225-authentication-for-an-ip-address), which have a 398-day >> reuse period.? >> >> * It replaces eight instances of ?thirteen months/thirteen-month? in EVG >> 11.14.3 with 398 days. >> >> The following motion has been proposed by Ben Wilson of Mozilla and >> endorsed by Dimitris Zacharopoulos of HARICA and Chema Lopez of >> Firmaprofesional. >> >> ? MOTION BEGINS ? >> >> This ballot modifies the ?Baseline Requirements for the Issuance and >> Management of Publicly-Trusted Certificates? (?Baseline Requirements?), >> based on Version 1.7.3: >> >> MODIFY the Baseline Requirements as defined in the following redline: >> https://github.com/sleevi/cabforum-docs/compare/2020-11-30_Pandocification...BenWilson-Mozilla:398-day-FQDN-validation >> >> (GITHUB URL TO BE UPDATED) >> >> This ballot modifies the ?Guidelines for the Issuance and Management of >> Extended Validation Certificates? (?EV Guidelines?) as follows, based on >> Version 1.7.4: >> >> MODIFY the EV Guidelines as defined in the following redline: >> https://github.com/sleevi/cabforum-docs/compare/2020-11-30_Pandocification...BenWilson-Mozilla:398-day-FQDN-validation >> >> (GITHUB URL TO BE UPDATED) >> >> ? MOTION ENDS ? >> >> This ballot proposes two Final Maintenance Guidelines. >> >> The procedure for approval of this ballot is as follows: >> >> Discussion (7+ days) >> >> Start Time: TBD >> >> End Time: TBD >> >> Vote for approval (7 days) >> >> Start Time: TBD >> >> End Time: TBD >> >> >> >> On Mon, Feb 15, 2021 at 11:50 AM Ben Wilson via Servercert-wg < >> servercert-wg at cabforum.org> wrote: >> >> See >> https://github.com/BenWilson-Mozilla/servercert/commit/26bd5a9f9f8bd2a251153a4cceb6226b859a3464 >> >> >> >> >> On Mon, Feb 15, 2021 at 11:44 AM Ben Wilson wrote: >> >> I have created a GitHub branch to make changes in for this ballot. >> >> >> https://github.com/BenWilson-Mozilla/servercert/tree/398-day-FQDN-validation/docs >> >> >> I intend to replace "thirteen months" in section 11.14.3 of the EV >> Guidelines with "398 days". >> >> >> >> On Tue, Feb 9, 2021 at 5:03 PM Ben Wilson via Servercert-wg < >> servercert-wg at cabforum.org> wrote: >> >> All, >> >> >> >> >> >> Amend BR section 3.2.2.5.1 and possibly make the Random Value valid for >> only 30 days or 60 days because what is meant by "if the Applicant >> submitted the certificate request"? Otherwise, just editing out some of >> the existing language it would read something like, "If a Random Value is >> used, the CA SHALL provide a Random Value unique to the certificate request >> and SHALL not use the Random Value after the longer of (i) 30 days or (ii) >> if the Applicant submitted the certificate request, 398 days," but someone >> should explain how that makes any sense. >> >> >> >> I seem to recall that harmonizing the Random Value (which, I agree, is >> also a good change) touches a few other sections. In particular, we >> identified previously that the (ii) is an anti-pattern; that is, that the >> Random Value should be valid 30 days or less, and it's the cached >> validation that is reused after that, rather than the Random Value itself. >> We updated several of the places, but not all. That is, 3.2.2.4.7 also >> needs to be cleaned up >> >> >> >> Can someone propose alternative language that says what was intended >> (i.e. "cached validation" as indicated by Ryan)? Otherwise, in BR section >> 3.2.2.4.7 (DNS Change) and BR section 3.2.2.5.1 (Agreed Upon Change to >> Website), as part of this proposed ballot, I intend to limit use of the >> Random Value to 30 days and delete the phrase "ii. if the Applicant >> submitted the Certificate request, the timeframe permitted for reuse of >> validated information relevant to the Certificate (such as in Section 4.2.1 >> of these Guidelines or Section 11.14.3 of the EV Guidelines)" because it >> makes no sense as currently worded. In any event, even the structure is bad >> because it combines two unrelated conditions into one concept. In other >> words, it wouldn't make sense to say the longer of (i) 30 days or (ii) 398 >> days for cached validations. As proposed by the ballot, the 398-day limit >> will apply to all methods of validation. >> >> >> >> I am still a little unclear on the intent of the language in (ii). Would >> the intent have been better served if that second part had been placed in a >> separate sentence? E.g., "The same Random Value may also be used for >> submitting subsequent certificate requests for the same domain for the >> timeframe permitted for reuse ...." >> >> >> >> Thanks, >> >> >> >> Ben >> >> _______________________________________________ >> Servercert-wg mailing list >> Servercert-wg at cabforum.org >> https://lists.cabforum.org/mailman/listinfo/servercert-wg >> >> >> _______________________________________________ >> Servercert-wg mailing list >> Servercert-wg at cabforum.org >> https://lists.cabforum.org/mailman/listinfo/servercert-wg >> >> >> _______________________________________________ > Servercert-wg mailing list > Servercert-wg at cabforum.org > https://lists.cabforum.org/mailman/listinfo/servercert-wg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwilson at mozilla.com Mon Mar 8 22:00:27 2021 From: bwilson at mozilla.com (Ben Wilson) Date: Mon, 8 Mar 2021 15:00:27 -0700 Subject: [Servercert-wg] [EXTERNAL] Re: Reducing Domain/IP Address Validation Reuse to 398 Days In-Reply-To: <0100017813a92ac6-649fa997-7124-4d7c-9c05-8ad333ac41e4-000000@email.amazonses.com> References: <0100017774aa83bc-7b5c45fd-84d1-448b-8951-71a6ccea8cf6-000000@email.amazonses.com> <0100017782c7bb0e-aa038cae-abdb-46ef-ab18-5911aa850ef6-000000@email.amazonses.com> <0100017782d3ddb6-fb397740-7ff5-4a5d-93b3-d20f189c36ea-000000@email.amazonses.com> <0100017789405697-953be8e8-c7da-41ea-960a-e729ab523e25-000000@email.amazonses.com> <01000177a707641c-8c794a76-c1fb-4558-87d2-5d76372dcb90-000000@email.amazonses.com> <01000177bbb6adc9-11776fd6-1db1-4b93-8c1c-625fed861889-000000@email.amazonses.com> <01000177da8bffb1-52c13db3-fc4e-4a2d-9287-1ffbba8999ac-000000@email.amazonses.com> <0100017813a92ac6-649fa997-7124-4d7c-9c05-8ad333ac41e4-000000@email.amazonses.com> Message-ID: Here is a link to the current redline. https://github.com/sleevi/cabforum-docs/compare/2020-11-30_Pandocification...BenWilson-Mozilla:398-day-FQDN-validation On Mon, Mar 8, 2021 at 2:05 PM Ben Wilson via Servercert-wg < servercert-wg at cabforum.org> wrote: > It has been proposed that we add the following language to the end of the > third paragraph of BR section 4.2.1: "Effective 2021-10-01, the CA SHALL > verify Domain Names and IP Addresses no more than 398 days prior to > Certificate issuance." Is this language clear enough? > > On Thu, Feb 25, 2021 at 11:55 AM Ben Wilson via Servercert-wg < > servercert-wg at cabforum.org> wrote: > >> Hi Bruce, >> >> See my responses inline below. >> >> On Mon, Feb 22, 2021 at 2:17 PM Bruce Morton >> wrote: >> >>> Hi Ben, >>> >>> >>> >>> A couple of comments. >>> >>> >>> >>> The ballot does not address the ?cliff? that CAs have stated will occur. >>> >> >> I do not see a "cliff" - it is more like a small hump. >> >> >>> The thinking is that currently CAs are verifying domains, which can be >>> reused for 825-days (~27 months). >>> >> >> Agreed - currently CAs can reuse domain verification for 825-days (~27 >> months). However, they should not be reusing FQDN and IP address >> verification for such a long period, especially for one-year certificates. >> There should only be a very small number of domains that are difficult to >> verify, and if they've verified once before, then customers and CAs should >> have procedures in place that can be re-performed. >> >> The new requirement implies that the domain verification can only be >>> reused for 398-days (~13 months). >>> >> >> The new requirement would apply to certificates issued on or after July >> 1, 2021. This proposal does not require all certificate validations to be >> redone, and the most recent verifications are more likely to still be >> accurate. >> >> >>> This means that for CAs which reuse domain validation, there will be 14 >>> months of validation which will expire on the effective date of the ballot. >>> >> >> Correct, but the 14 months of validation would be for those old >> validations that were performed nearly 3 years ago -- from approximately >> October 5, 2018 through December 6, 2109. >> >> >>> In many cases this may create a lot of work on the Subscriber and the CA >>> to revalidate these domains. >>> >> >> I disagree. As stated above, there should be fewer reuse of validations >> performed. I don't know of any statistics supporting the amount of work >> that would need to be performed. Shouldn't these processes be automated? >> Do you have data for the type of validations that were originally performed >> between October 5, 2018 and December 6, 2109, to indicate how many of those >> will be problematic? Also, the July 1, 2021, date has been circulated by >> Mozilla for quite some time, and CAs should have been preparing for it. >> >> >>> Is it possible to have the ballot only address domains which are >>> validated after the effective date? The domains which are currently >>> validated can be reused per their current schedule. >>> >> >> We can discuss this more, but your request is just that new domains and >> IP addresses be validated - which would already be required with or without >> an amendment to policy. I think the currently proposed amendment is the >> best approach. >> >>> >>> >>> Would it also be possible to push out the effective date by a quarter, >>> so October 1, 2021? >>> >> >> That might be a possibility, but doesn't that just move your "cliff". As >> I say above, CAs and customers should already be moving toward more >> frequent FQDN and IP Address verification. >> >> >>> This will give the CAs more time to implement the change and to advise >>> Subscribers of the impact. It will also give the Subscribers some time to >>> address the volume of domains which will have to be re-validated. >>> >> >> What is the volume of domains that will need to be revalidated? Two-year >> certificates were eliminated last year, but how many 2-year certificates >> would be coming up for renewal, and of those, how many had problematic >> domain validation procedures that would need to be re-performed or replaced >> with the currently allowed methods? >> >> Respectfully, >> >> Ben >> >> >>> >>> >>> >>> Thanks, Bruce. >>> >>> >>> >>> *From:* Servercert-wg *On Behalf >>> Of *Ben Wilson via Servercert-wg >>> *Sent:* Friday, February 19, 2021 2:14 PM >>> *To:* CA/B Forum Server Certificate WG Public Discussion List < >>> servercert-wg at cabforum.org> >>> *Subject:* [EXTERNAL] Re: [Servercert-wg] Reducing Domain/IP Address >>> Validation Reuse to 398 Days >>> >>> >>> >>> WARNING: This email originated outside of Entrust. >>> DO NOT CLICK links or attachments unless you trust the sender and know >>> the content is safe. >>> ------------------------------ >>> >>> Here is a preliminary, rough draft of Ballot SC42 for discussion and >>> comment. Please let me know if you spot any deficiencies in required >>> content or procedure. >>> >>> In other words, this email is not intended to and does not begin the >>> discussion period on this ballot. A separate, official email will be sent >>> out next week for that purpose. >>> >>> Name of Ballot: 398-Day Reuse >>> >>> Purpose of Ballot: >>> >>> This ballot changes validation reuse periods for FQDN and IP Address >>> validation in the Baseline Requirements and for all purposes in the EV >>> Guidelines. The ballot does not change the 825-day reuse period in section >>> 4.2.1. of the Baseline Requirements for Organizational Validation (OV) >>> information. >>> >>> Specifically: >>> >>> * It inserts in BR section 3.2.2.4 ?For Certificates issued on or after >>> July 1, 2021, the CA SHALL verify that each FQDN is confirmed as permitted >>> by this section at intervals of 398 days or less.? It also requires that >>> the validation be completed within the 398 days preceding certificate >>> issuance and removes cross-references to BR section 4.2.1. >>> >>> * It modifies BR sections 3.2.2.4.3 and 3.2.2.4.6 to eliminate reuse of >>> FQDN validation performed under those sunsetted provisions. >>> >>> * It modifies BR section 3.2.2.4.7 to replace subsections i. and ii. >>> with a 30-day limit on reuse of the Random Value. >>> >>> * It inserts in BR section 3.2.2.5 ?For Certificates issued on or after >>> July 1, 2021, the CA SHALL validate each IP address as permitted by this >>> section at intervals of 398 days or less.? It also requires that the >>> validation be completed within the 398 days preceding certificate issuance >>> and removes cross-references to BR section 4.2.1. >>> >>> * It clarifies BR section 4.2.1 by stating, ?This 825-day period does >>> not apply to the validation of domain authorization or control performed >>> under [Section >>> 3.2.2.4](#3224-validation-of-domain-authorization-or-control) or the >>> authentication of an IP address performed under [Section >>> 3.2.2.5](#3225-authentication-for-an-ip-address), which have a 398-day >>> reuse period.? >>> >>> * It replaces eight instances of ?thirteen months/thirteen-month? in EVG >>> 11.14.3 with 398 days. >>> >>> The following motion has been proposed by Ben Wilson of Mozilla and >>> endorsed by Dimitris Zacharopoulos of HARICA and Chema Lopez of >>> Firmaprofesional. >>> >>> ? MOTION BEGINS ? >>> >>> This ballot modifies the ?Baseline Requirements for the Issuance and >>> Management of Publicly-Trusted Certificates? (?Baseline Requirements?), >>> based on Version 1.7.3: >>> >>> MODIFY the Baseline Requirements as defined in the following redline: >>> https://github.com/sleevi/cabforum-docs/compare/2020-11-30_Pandocification...BenWilson-Mozilla:398-day-FQDN-validation >>> >>> (GITHUB URL TO BE UPDATED) >>> >>> This ballot modifies the ?Guidelines for the Issuance and Management of >>> Extended Validation Certificates? (?EV Guidelines?) as follows, based on >>> Version 1.7.4: >>> >>> MODIFY the EV Guidelines as defined in the following redline: >>> https://github.com/sleevi/cabforum-docs/compare/2020-11-30_Pandocification...BenWilson-Mozilla:398-day-FQDN-validation >>> >>> (GITHUB URL TO BE UPDATED) >>> >>> ? MOTION ENDS ? >>> >>> This ballot proposes two Final Maintenance Guidelines. >>> >>> The procedure for approval of this ballot is as follows: >>> >>> Discussion (7+ days) >>> >>> Start Time: TBD >>> >>> End Time: TBD >>> >>> Vote for approval (7 days) >>> >>> Start Time: TBD >>> >>> End Time: TBD >>> >>> >>> >>> On Mon, Feb 15, 2021 at 11:50 AM Ben Wilson via Servercert-wg < >>> servercert-wg at cabforum.org> wrote: >>> >>> See >>> https://github.com/BenWilson-Mozilla/servercert/commit/26bd5a9f9f8bd2a251153a4cceb6226b859a3464 >>> >>> >>> >>> >>> On Mon, Feb 15, 2021 at 11:44 AM Ben Wilson wrote: >>> >>> I have created a GitHub branch to make changes in for this ballot. >>> >>> >>> https://github.com/BenWilson-Mozilla/servercert/tree/398-day-FQDN-validation/docs >>> >>> >>> I intend to replace "thirteen months" in section 11.14.3 of the EV >>> Guidelines with "398 days". >>> >>> >>> >>> On Tue, Feb 9, 2021 at 5:03 PM Ben Wilson via Servercert-wg < >>> servercert-wg at cabforum.org> wrote: >>> >>> All, >>> >>> >>> >>> >>> >>> Amend BR section 3.2.2.5.1 and possibly make the Random Value valid for >>> only 30 days or 60 days because what is meant by "if the Applicant >>> submitted the certificate request"? Otherwise, just editing out some of >>> the existing language it would read something like, "If a Random Value is >>> used, the CA SHALL provide a Random Value unique to the certificate request >>> and SHALL not use the Random Value after the longer of (i) 30 days or (ii) >>> if the Applicant submitted the certificate request, 398 days," but someone >>> should explain how that makes any sense. >>> >>> >>> >>> I seem to recall that harmonizing the Random Value (which, I agree, is >>> also a good change) touches a few other sections. In particular, we >>> identified previously that the (ii) is an anti-pattern; that is, that the >>> Random Value should be valid 30 days or less, and it's the cached >>> validation that is reused after that, rather than the Random Value itself. >>> We updated several of the places, but not all. That is, 3.2.2.4.7 also >>> needs to be cleaned up >>> >>> >>> >>> Can someone propose alternative language that says what was intended >>> (i.e. "cached validation" as indicated by Ryan)? Otherwise, in BR section >>> 3.2.2.4.7 (DNS Change) and BR section 3.2.2.5.1 (Agreed Upon Change to >>> Website), as part of this proposed ballot, I intend to limit use of the >>> Random Value to 30 days and delete the phrase "ii. if the Applicant >>> submitted the Certificate request, the timeframe permitted for reuse of >>> validated information relevant to the Certificate (such as in Section 4.2.1 >>> of these Guidelines or Section 11.14.3 of the EV Guidelines)" because it >>> makes no sense as currently worded. In any event, even the structure is bad >>> because it combines two unrelated conditions into one concept. In other >>> words, it wouldn't make sense to say the longer of (i) 30 days or (ii) 398 >>> days for cached validations. As proposed by the ballot, the 398-day limit >>> will apply to all methods of validation. >>> >>> >>> >>> I am still a little unclear on the intent of the language in (ii). >>> Would the intent have been better served if that second part had been >>> placed in a separate sentence? E.g., "The same Random Value may also be >>> used for submitting subsequent certificate requests for the same domain for >>> the timeframe permitted for reuse ...." >>> >>> >>> >>> Thanks, >>> >>> >>> >>> Ben >>> >>> _______________________________________________ >>> Servercert-wg mailing list >>> Servercert-wg at cabforum.org >>> https://lists.cabforum.org/mailman/listinfo/servercert-wg >>> >>> >>> _______________________________________________ >>> Servercert-wg mailing list >>> Servercert-wg at cabforum.org >>> https://lists.cabforum.org/mailman/listinfo/servercert-wg >>> >>> >>> _______________________________________________ >> Servercert-wg mailing list >> Servercert-wg at cabforum.org >> https://lists.cabforum.org/mailman/listinfo/servercert-wg >> > _______________________________________________ > Servercert-wg mailing list > Servercert-wg at cabforum.org > https://lists.cabforum.org/mailman/listinfo/servercert-wg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwilson at mozilla.com Thu Mar 11 17:13:57 2021 From: bwilson at mozilla.com (Ben Wilson) Date: Thu, 11 Mar 2021 10:13:57 -0700 Subject: [Servercert-wg] [EXTERNAL] Re: Reducing Domain/IP Address Validation Reuse to 398 Days In-Reply-To: <0100017813db4fa8-c937b25a-0a50-4bfb-8881-07fd242bbe09-000000@email.amazonses.com> References: <0100017774aa83bc-7b5c45fd-84d1-448b-8951-71a6ccea8cf6-000000@email.amazonses.com> <0100017782c7bb0e-aa038cae-abdb-46ef-ab18-5911aa850ef6-000000@email.amazonses.com> <0100017782d3ddb6-fb397740-7ff5-4a5d-93b3-d20f189c36ea-000000@email.amazonses.com> <0100017789405697-953be8e8-c7da-41ea-960a-e729ab523e25-000000@email.amazonses.com> <01000177a707641c-8c794a76-c1fb-4558-87d2-5d76372dcb90-000000@email.amazonses.com> <01000177bbb6adc9-11776fd6-1db1-4b93-8c1c-625fed861889-000000@email.amazonses.com> <01000177da8bffb1-52c13db3-fc4e-4a2d-9287-1ffbba8999ac-000000@email.amazonses.com> <0100017813a92ac6-649fa997-7124-4d7c-9c05-8ad333ac41e4-000000@email.amazonses.com> <0100017813db4fa8-c937b25a-0a50-4bfb-8881-07fd242bbe09-000000@email.amazonses.com> Message-ID: We'll put this into ballot format then and introduce it. On Mon, Mar 8, 2021 at 3:00 PM Ben Wilson via Servercert-wg < servercert-wg at cabforum.org> wrote: > Here is a link to the current redline. > https://github.com/sleevi/cabforum-docs/compare/2020-11-30_Pandocification...BenWilson-Mozilla:398-day-FQDN-validation > > On Mon, Mar 8, 2021 at 2:05 PM Ben Wilson via Servercert-wg < > servercert-wg at cabforum.org> wrote: > >> It has been proposed that we add the following language to the end of the >> third paragraph of BR section 4.2.1: "Effective 2021-10-01, the CA SHALL >> verify Domain Names and IP Addresses no more than 398 days prior to >> Certificate issuance." Is this language clear enough? >> >> On Thu, Feb 25, 2021 at 11:55 AM Ben Wilson via Servercert-wg < >> servercert-wg at cabforum.org> wrote: >> >>> Hi Bruce, >>> >>> See my responses inline below. >>> >>> On Mon, Feb 22, 2021 at 2:17 PM Bruce Morton >>> wrote: >>> >>>> Hi Ben, >>>> >>>> >>>> >>>> A couple of comments. >>>> >>>> >>>> >>>> The ballot does not address the ?cliff? that CAs have stated will >>>> occur. >>>> >>> >>> I do not see a "cliff" - it is more like a small hump. >>> >>> >>>> The thinking is that currently CAs are verifying domains, which can be >>>> reused for 825-days (~27 months). >>>> >>> >>> Agreed - currently CAs can reuse domain verification for 825-days (~27 >>> months). However, they should not be reusing FQDN and IP address >>> verification for such a long period, especially for one-year certificates. >>> There should only be a very small number of domains that are difficult to >>> verify, and if they've verified once before, then customers and CAs should >>> have procedures in place that can be re-performed. >>> >>> The new requirement implies that the domain verification can only be >>>> reused for 398-days (~13 months). >>>> >>> >>> The new requirement would apply to certificates issued on or after July >>> 1, 2021. This proposal does not require all certificate validations to be >>> redone, and the most recent verifications are more likely to still be >>> accurate. >>> >>> >>>> This means that for CAs which reuse domain validation, there will be 14 >>>> months of validation which will expire on the effective date of the ballot. >>>> >>> >>> Correct, but the 14 months of validation would be for those old >>> validations that were performed nearly 3 years ago -- from approximately >>> October 5, 2018 through December 6, 2109. >>> >>> >>>> In many cases this may create a lot of work on the Subscriber and the >>>> CA to revalidate these domains. >>>> >>> >>> I disagree. As stated above, there should be fewer reuse of validations >>> performed. I don't know of any statistics supporting the amount of work >>> that would need to be performed. Shouldn't these processes be automated? >>> Do you have data for the type of validations that were originally performed >>> between October 5, 2018 and December 6, 2109, to indicate how many of those >>> will be problematic? Also, the July 1, 2021, date has been circulated by >>> Mozilla for quite some time, and CAs should have been preparing for it. >>> >>> >>>> Is it possible to have the ballot only address domains which are >>>> validated after the effective date? The domains which are currently >>>> validated can be reused per their current schedule. >>>> >>> >>> We can discuss this more, but your request is just that new domains and >>> IP addresses be validated - which would already be required with or without >>> an amendment to policy. I think the currently proposed amendment is the >>> best approach. >>> >>>> >>>> >>>> Would it also be possible to push out the effective date by a quarter, >>>> so October 1, 2021? >>>> >>> >>> That might be a possibility, but doesn't that just move your "cliff". >>> As I say above, CAs and customers should already be moving toward more >>> frequent FQDN and IP Address verification. >>> >>> >>>> This will give the CAs more time to implement the change and to advise >>>> Subscribers of the impact. It will also give the Subscribers some time to >>>> address the volume of domains which will have to be re-validated. >>>> >>> >>> What is the volume of domains that will need to be revalidated? >>> Two-year certificates were eliminated last year, but how many 2-year >>> certificates would be coming up for renewal, and of those, how many had >>> problematic domain validation procedures that would need to be re-performed >>> or replaced with the currently allowed methods? >>> >>> Respectfully, >>> >>> Ben >>> >>> >>>> >>>> >>>> >>>> Thanks, Bruce. >>>> >>>> >>>> >>>> *From:* Servercert-wg *On Behalf >>>> Of *Ben Wilson via Servercert-wg >>>> *Sent:* Friday, February 19, 2021 2:14 PM >>>> *To:* CA/B Forum Server Certificate WG Public Discussion List < >>>> servercert-wg at cabforum.org> >>>> *Subject:* [EXTERNAL] Re: [Servercert-wg] Reducing Domain/IP Address >>>> Validation Reuse to 398 Days >>>> >>>> >>>> >>>> WARNING: This email originated outside of Entrust. >>>> DO NOT CLICK links or attachments unless you trust the sender and know >>>> the content is safe. >>>> ------------------------------ >>>> >>>> Here is a preliminary, rough draft of Ballot SC42 for discussion and >>>> comment. Please let me know if you spot any deficiencies in required >>>> content or procedure. >>>> >>>> In other words, this email is not intended to and does not begin the >>>> discussion period on this ballot. A separate, official email will be sent >>>> out next week for that purpose. >>>> >>>> Name of Ballot: 398-Day Reuse >>>> >>>> Purpose of Ballot: >>>> >>>> This ballot changes validation reuse periods for FQDN and IP Address >>>> validation in the Baseline Requirements and for all purposes in the EV >>>> Guidelines. The ballot does not change the 825-day reuse period in section >>>> 4.2.1. of the Baseline Requirements for Organizational Validation (OV) >>>> information. >>>> >>>> Specifically: >>>> >>>> * It inserts in BR section 3.2.2.4 ?For Certificates issued on or after >>>> July 1, 2021, the CA SHALL verify that each FQDN is confirmed as permitted >>>> by this section at intervals of 398 days or less.? It also requires that >>>> the validation be completed within the 398 days preceding certificate >>>> issuance and removes cross-references to BR section 4.2.1. >>>> >>>> * It modifies BR sections 3.2.2.4.3 and 3.2.2.4.6 to eliminate reuse of >>>> FQDN validation performed under those sunsetted provisions. >>>> >>>> * It modifies BR section 3.2.2.4.7 to replace subsections i. and ii. >>>> with a 30-day limit on reuse of the Random Value. >>>> >>>> * It inserts in BR section 3.2.2.5 ?For Certificates issued on or after >>>> July 1, 2021, the CA SHALL validate each IP address as permitted by this >>>> section at intervals of 398 days or less.? It also requires that the >>>> validation be completed within the 398 days preceding certificate issuance >>>> and removes cross-references to BR section 4.2.1. >>>> >>>> * It clarifies BR section 4.2.1 by stating, ?This 825-day period does >>>> not apply to the validation of domain authorization or control performed >>>> under [Section >>>> 3.2.2.4](#3224-validation-of-domain-authorization-or-control) or the >>>> authentication of an IP address performed under [Section >>>> 3.2.2.5](#3225-authentication-for-an-ip-address), which have a 398-day >>>> reuse period.? >>>> >>>> * It replaces eight instances of ?thirteen months/thirteen-month? in >>>> EVG 11.14.3 with 398 days. >>>> >>>> The following motion has been proposed by Ben Wilson of Mozilla and >>>> endorsed by Dimitris Zacharopoulos of HARICA and Chema Lopez of >>>> Firmaprofesional. >>>> >>>> ? MOTION BEGINS ? >>>> >>>> This ballot modifies the ?Baseline Requirements for the Issuance and >>>> Management of Publicly-Trusted Certificates? (?Baseline Requirements?), >>>> based on Version 1.7.3: >>>> >>>> MODIFY the Baseline Requirements as defined in the following redline: >>>> https://github.com/sleevi/cabforum-docs/compare/2020-11-30_Pandocification...BenWilson-Mozilla:398-day-FQDN-validation >>>> >>>> (GITHUB URL TO BE UPDATED) >>>> >>>> This ballot modifies the ?Guidelines for the Issuance and Management of >>>> Extended Validation Certificates? (?EV Guidelines?) as follows, based on >>>> Version 1.7.4: >>>> >>>> MODIFY the EV Guidelines as defined in the following redline: >>>> https://github.com/sleevi/cabforum-docs/compare/2020-11-30_Pandocification...BenWilson-Mozilla:398-day-FQDN-validation >>>> >>>> (GITHUB URL TO BE UPDATED) >>>> >>>> ? MOTION ENDS ? >>>> >>>> This ballot proposes two Final Maintenance Guidelines. >>>> >>>> The procedure for approval of this ballot is as follows: >>>> >>>> Discussion (7+ days) >>>> >>>> Start Time: TBD >>>> >>>> End Time: TBD >>>> >>>> Vote for approval (7 days) >>>> >>>> Start Time: TBD >>>> >>>> End Time: TBD >>>> >>>> >>>> >>>> On Mon, Feb 15, 2021 at 11:50 AM Ben Wilson via Servercert-wg < >>>> servercert-wg at cabforum.org> wrote: >>>> >>>> See >>>> https://github.com/BenWilson-Mozilla/servercert/commit/26bd5a9f9f8bd2a251153a4cceb6226b859a3464 >>>> >>>> >>>> >>>> >>>> On Mon, Feb 15, 2021 at 11:44 AM Ben Wilson >>>> wrote: >>>> >>>> I have created a GitHub branch to make changes in for this ballot. >>>> >>>> >>>> https://github.com/BenWilson-Mozilla/servercert/tree/398-day-FQDN-validation/docs >>>> >>>> >>>> I intend to replace "thirteen months" in section 11.14.3 of the EV >>>> Guidelines with "398 days". >>>> >>>> >>>> >>>> On Tue, Feb 9, 2021 at 5:03 PM Ben Wilson via Servercert-wg < >>>> servercert-wg at cabforum.org> wrote: >>>> >>>> All, >>>> >>>> >>>> >>>> >>>> >>>> Amend BR section 3.2.2.5.1 and possibly make the Random Value valid for >>>> only 30 days or 60 days because what is meant by "if the Applicant >>>> submitted the certificate request"? Otherwise, just editing out some of >>>> the existing language it would read something like, "If a Random Value is >>>> used, the CA SHALL provide a Random Value unique to the certificate request >>>> and SHALL not use the Random Value after the longer of (i) 30 days or (ii) >>>> if the Applicant submitted the certificate request, 398 days," but someone >>>> should explain how that makes any sense. >>>> >>>> >>>> >>>> I seem to recall that harmonizing the Random Value (which, I agree, is >>>> also a good change) touches a few other sections. In particular, we >>>> identified previously that the (ii) is an anti-pattern; that is, that the >>>> Random Value should be valid 30 days or less, and it's the cached >>>> validation that is reused after that, rather than the Random Value itself. >>>> We updated several of the places, but not all. That is, 3.2.2.4.7 also >>>> needs to be cleaned up >>>> >>>> >>>> >>>> Can someone propose alternative language that says what was intended >>>> (i.e. "cached validation" as indicated by Ryan)? Otherwise, in BR section >>>> 3.2.2.4.7 (DNS Change) and BR section 3.2.2.5.1 (Agreed Upon Change to >>>> Website), as part of this proposed ballot, I intend to limit use of the >>>> Random Value to 30 days and delete the phrase "ii. if the Applicant >>>> submitted the Certificate request, the timeframe permitted for reuse of >>>> validated information relevant to the Certificate (such as in Section 4.2.1 >>>> of these Guidelines or Section 11.14.3 of the EV Guidelines)" because it >>>> makes no sense as currently worded. In any event, even the structure is bad >>>> because it combines two unrelated conditions into one concept. In other >>>> words, it wouldn't make sense to say the longer of (i) 30 days or (ii) 398 >>>> days for cached validations. As proposed by the ballot, the 398-day limit >>>> will apply to all methods of validation. >>>> >>>> >>>> >>>> I am still a little unclear on the intent of the language in (ii). >>>> Would the intent have been better served if that second part had been >>>> placed in a separate sentence? E.g., "The same Random Value may also be >>>> used for submitting subsequent certificate requests for the same domain for >>>> the timeframe permitted for reuse ...." >>>> >>>> >>>> >>>> Thanks, >>>> >>>> >>>> >>>> Ben >>>> >>>> _______________________________________________ >>>> Servercert-wg mailing list >>>> Servercert-wg at cabforum.org >>>> https://lists.cabforum.org/mailman/listinfo/servercert-wg >>>> >>>> >>>> _______________________________________________ >>>> Servercert-wg mailing list >>>> Servercert-wg at cabforum.org >>>> https://lists.cabforum.org/mailman/listinfo/servercert-wg >>>> >>>> >>>> _______________________________________________ >>> Servercert-wg mailing list >>> Servercert-wg at cabforum.org >>> https://lists.cabforum.org/mailman/listinfo/servercert-wg >>> >> _______________________________________________ >> Servercert-wg mailing list >> Servercert-wg at cabforum.org >> https://lists.cabforum.org/mailman/listinfo/servercert-wg >> > _______________________________________________ > Servercert-wg mailing list > Servercert-wg at cabforum.org > https://lists.cabforum.org/mailman/listinfo/servercert-wg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From NCarpenter at securetrust.com Thu Mar 11 22:33:40 2021 From: NCarpenter at securetrust.com (Niko Carpenter) Date: Thu, 11 Mar 2021 22:33:40 +0000 Subject: [Servercert-wg] Discussion Period Begins on Ballot SC43: Clarify Acceptable Status Codes Message-ID: This begins the discussion period for ballot SC43: Clarify Acceptable Status Codes. Purpose of Ballot: This ballot clarifies the allowed HTTP status codes used for following redirects in domain validation methods 18 and 19, and specifies that the target URI must come from the Location response header. In Section 3.2.2.4.18 and 3.2.2.4.19, it replaces ?Redirects MUST be the result of an HTTP status code result within the 3xx Redirection class of status codes, as defined in RFC 7231, Section 6.4.? with the following: * ?Redirects MUST be the result of a 301, 302, 307, or 308 HTTP status code response.? * ?Redirects MUST be to resource URLs contained in the Location HTTP response header.? The following motion has been proposed by Niko Carpenter of SecureTrust and endorsed by Corey Bonnell of DigiCert and Ryan Sleevi of Google. ?MOTION BEGINS? This ballot modifies the ?Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates? as defined in the following redline, based on Version 1.7.3: https://github.com/cabforum/servercert/compare/2b7720f7821764f0ea9d0d583ec5c61896a3f4cd..2dacfa41d2fdd9c8ec4bbd365cfa759870243c3 ?MOTION ENDS? This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows: Discussion (7+ days) Start Time: 11-March 2021 21:30 UTC End Time: TBD Vote for approval (7 days) Start Time: TBD End Time: TBD Niko Carpenter Software Engineer www.securetrust.com 2020 Best PCI Compliance Provider Winner ? Card Not Present Awards This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dzacharo at harica.gr Fri Mar 12 05:59:35 2021 From: dzacharo at harica.gr (Dimitris Zacharopoulos) Date: Fri, 12 Mar 2021 05:59:35 +0000 (UTC) Subject: [Servercert-wg] Discussion Period Begins on Ballot SC43: Clarify Acceptable Status Codes In-Reply-To: <01000178236caee4-be5c7a8e-8d5a-4b04-9de3-47952d591e17-000000@email.amazonses.com> References: <01000178236caee4-be5c7a8e-8d5a-4b04-9de3-47952d591e17-000000@email.amazonses.com> Message-ID: <14304ae1-6ee5-48f7-bf7b-3b37280a5f0e@harica.gr> Shouldn't there be an effective date in this ballot so that CAs have time to update their various systems to support these updated requirements? Software vendors might also need time to update and test their software before releasing a newer version, which then needs to be properly tested and installed by CAs. Thanks, Dimitris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleevi at google.com Fri Mar 12 16:47:09 2021 From: sleevi at google.com (Ryan Sleevi) Date: Fri, 12 Mar 2021 11:47:09 -0500 Subject: [Servercert-wg] Discussion Period Begins on Ballot SC43: Clarify Acceptable Status Codes In-Reply-To: <010001782504ecb9-3e8022aa-db4b-4442-9907-e1708ea12b74-000000@email.amazonses.com> References: <01000178236caee4-be5c7a8e-8d5a-4b04-9de3-47952d591e17-000000@email.amazonses.com> <010001782504ecb9-3e8022aa-db4b-4442-9907-e1708ea12b74-000000@email.amazonses.com> Message-ID: Dimitris, Given the length of discussion here, are you aware of systems not yet conforming? Perhaps you can speak about what concrete (rather than abstract) difficulties there would be? That's not to say an effective date is a forgone conclusion, but I think as a Forum, we're much more productive when members with concrete concerns bring them forward, rather than abstracts "on behalf of someone else". For example, what challenges might HARICA face? Understanding that would help both make better ballots, and perhaps highlight industry good practices from other CAs that HARICA could adopt so that these aren't concerns in the future. On Fri, Mar 12, 2021 at 12:59 AM Dimitris Zacharopoulos via Servercert-wg < servercert-wg at cabforum.org> wrote: > Shouldn't there be an effective date in this ballot so that CAs have time > to update their various systems to support these updated requirements? > > Software vendors might also need time to update and test their software > before releasing a newer version, which then needs to be properly tested > and installed by CAs. > > Thanks, > > > Dimitris. > _______________________________________________ > Servercert-wg mailing list > Servercert-wg at cabforum.org > https://lists.cabforum.org/mailman/listinfo/servercert-wg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dzacharo at harica.gr Fri Mar 12 18:11:38 2021 From: dzacharo at harica.gr (Dimitris Zacharopoulos (HARICA)) Date: Fri, 12 Mar 2021 20:11:38 +0200 Subject: [Servercert-wg] Discussion Period Begins on Ballot SC43: Clarify Acceptable Status Codes In-Reply-To: References: <01000178236caee4-be5c7a8e-8d5a-4b04-9de3-47952d591e17-000000@email.amazonses.com> <010001782504ecb9-3e8022aa-db4b-4442-9907-e1708ea12b74-000000@email.amazonses.com> Message-ID: On 12/3/2021 6:47 ?.?., Ryan Sleevi wrote: > Dimitris, > > Given the length of discussion here, are you aware of systems not yet > conforming? Perhaps you can speak about what concrete (rather than > abstract) difficulties there would be? > > That's not to say an effective date is a forgone conclusion, but I > think as a Forum, we're much more productive when members with > concrete concerns bring them forward, rather than abstracts "on behalf > of someone else". For example, what challenges might HARICA face? > Understanding that would help both make better ballots, and perhaps > highlight industry good practices from other CAs that HARICA could > adopt so that these aren't concerns in the future. CAs need to update their validation code to allow ONLY these specific HTTP responses for redirects. This also needs to be applied consistently, including ACME implementations that may not currently support this configuration option. For example, I believe EJBCA does not have this option for their ACME server engine component. For HARICA, it's easy to update the main RA code but we currently rely on EJBCA for ACME and that might cause some delays. I hope this helps. Dimitris. > > On Fri, Mar 12, 2021 at 12:59 AM Dimitris Zacharopoulos via > Servercert-wg > wrote: > > Shouldn't there be an effective date in this ballot so that CAs > have time to update their various systems to support these updated > requirements? > > Software vendors might also need time to update and test their > software before releasing a newer version, which then needs to be > properly tested and installed by CAs. > > Thanks, > > > Dimitris. > _______________________________________________ > Servercert-wg mailing list > Servercert-wg at cabforum.org > https://lists.cabforum.org/mailman/listinfo/servercert-wg > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleevi at google.com Fri Mar 12 18:13:36 2021 From: sleevi at google.com (Ryan Sleevi) Date: Fri, 12 Mar 2021 13:13:36 -0500 Subject: [Servercert-wg] Discussion Period Begins on Ballot SC43: Clarify Acceptable Status Codes In-Reply-To: References: <01000178236caee4-be5c7a8e-8d5a-4b04-9de3-47952d591e17-000000@email.amazonses.com> <010001782504ecb9-3e8022aa-db4b-4442-9907-e1708ea12b74-000000@email.amazonses.com> Message-ID: On Fri, Mar 12, 2021 at 1:11 PM Dimitris Zacharopoulos (HARICA) < dzacharo at harica.gr> wrote: > > > On 12/3/2021 6:47 ?.?., Ryan Sleevi wrote: > > Dimitris, > > Given the length of discussion here, are you aware of systems not yet > conforming? Perhaps you can speak about what concrete (rather than > abstract) difficulties there would be? > > That's not to say an effective date is a forgone conclusion, but I think > as a Forum, we're much more productive when members with concrete concerns > bring them forward, rather than abstracts "on behalf of someone else". For > example, what challenges might HARICA face? Understanding that would help > both make better ballots, and perhaps highlight industry good practices > from other CAs that HARICA could adopt so that these aren't concerns in the > future. > > > CAs need to update their validation code to allow ONLY these specific HTTP > responses for redirects. This also needs to be applied consistently, > including ACME implementations that may not currently support this > configuration option. For example, I believe EJBCA does not have this > option for their ACME server engine component. > > For HARICA, it's easy to update the main RA code but we currently rely on > EJBCA for ACME and that might cause some delays. > > I hope this helps. > Yup! Makes total sense now :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From NCarpenter at securetrust.com Fri Mar 12 21:41:10 2021 From: NCarpenter at securetrust.com (Niko Carpenter) Date: Fri, 12 Mar 2021 21:41:10 +0000 Subject: [Servercert-wg] Discussion Period Begins on Ballot SC43: Clarify Acceptable Status Codes In-Reply-To: <0100017827a56bc7-1e083b2e-e4fd-458c-83a0-2056c1fbf0ea-000000@email.amazonses.com> References: <01000178236caee4-be5c7a8e-8d5a-4b04-9de3-47952d591e17-000000@email.amazonses.com> <010001782504ecb9-3e8022aa-db4b-4442-9907-e1708ea12b74-000000@email.amazonses.com> , <0100017827a56bc7-1e083b2e-e4fd-458c-83a0-2056c1fbf0ea-000000@email.amazonses.com> Message-ID: We were thinking a three month window, IE an effective date of July 1, would be reasonable. If there are CAs that require more time to implement changes in order to comply with this new requirement, please provide a date that would work for you. Niko Carpenter Software Engineer From: Servercert-wg on behalf of Ryan Sleevi via Servercert-wg Date: Friday, March 12, 2021 at 13:32 To: Dimitris Zacharopoulos (HARICA) Cc: CA/B Forum Server Certificate WG Public Discussion List Subject: Re: [Servercert-wg] Discussion Period Begins on Ballot SC43: Clarify Acceptable Status Codes On Fri, Mar 12, 2021 at 1:11 PM Dimitris Zacharopoulos (HARICA) > wrote: On 12/3/2021 6:47 ?.?., Ryan Sleevi wrote: Dimitris, Given the length of discussion here, are you aware of systems not yet conforming? Perhaps you can speak about what concrete (rather than abstract) difficulties there would be? That's not to say an effective date is a forgone conclusion, but I think as a Forum, we're much more productive when members with concrete concerns bring them forward, rather than abstracts "on behalf of someone else". For example, what challenges might HARICA face? Understanding that would help both make better ballots, and perhaps highlight industry good practices from other CAs that HARICA could adopt so that these aren't concerns in the future. CAs need to update their validation code to allow ONLY these specific HTTP responses for redirects. This also needs to be applied consistently, including ACME implementations that may not currently support this configuration option. For example, I believe EJBCA does not have this option for their ACME server engine component. For HARICA, it's easy to update the main RA code but we currently rely on EJBCA for ACME and that might cause some delays. I hope this helps. Yup! Makes total sense now :) This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. -------------- next part -------------- An HTML attachment was scrubbed... URL: From NCarpenter at securetrust.com Mon Mar 15 15:32:15 2021 From: NCarpenter at securetrust.com (Niko Carpenter) Date: Mon, 15 Mar 2021 15:32:15 +0000 Subject: [Servercert-wg] Discussion Period Begins on Ballot SC43: Clarify Acceptable Status Codes In-Reply-To: References: <01000178236caee4-be5c7a8e-8d5a-4b04-9de3-47952d591e17-000000@email.amazonses.com> <010001782504ecb9-3e8022aa-db4b-4442-9907-e1708ea12b74-000000@email.amazonses.com> , <0100017827a56bc7-1e083b2e-e4fd-458c-83a0-2056c1fbf0ea-000000@email.amazonses.com>, Message-ID: We were thinking a three month window, IE an effective date of July 1, would be reasonable. If there are CAs that require more time to implement changes in order to comply with this new requirement, please provide a date that would work for you. Niko Carpenter Software Engineer From: Servercert-wg on behalf of Ryan Sleevi via Servercert-wg Date: Friday, March 12, 2021 at 13:32 To: Dimitris Zacharopoulos (HARICA) Cc: CA/B Forum Server Certificate WG Public Discussion List Subject: Re: [Servercert-wg] Discussion Period Begins on Ballot SC43: Clarify Acceptable Status Codes On Fri, Mar 12, 2021 at 1:11 PM Dimitris Zacharopoulos (HARICA) > wrote: On 12/3/2021 6:47 ?.?., Ryan Sleevi wrote: Dimitris, Given the length of discussion here, are you aware of systems not yet conforming? Perhaps you can speak about what concrete (rather than abstract) difficulties there would be? That's not to say an effective date is a forgone conclusion, but I think as a Forum, we're much more productive when members with concrete concerns bring them forward, rather than abstracts "on behalf of someone else". For example, what challenges might HARICA face? Understanding that would help both make better ballots, and perhaps highlight industry good practices from other CAs that HARICA could adopt so that these aren't concerns in the future. CAs need to update their validation code to allow ONLY these specific HTTP responses for redirects. This also needs to be applied consistently, including ACME implementations that may not currently support this configuration option. For example, I believe EJBCA does not have this option for their ACME server engine component. For HARICA, it's easy to update the main RA code but we currently rely on EJBCA for ACME and that might cause some delays. I hope this helps. Yup! Makes total sense now :) This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleevi at google.com Tue Mar 16 18:58:54 2021 From: sleevi at google.com (Ryan Sleevi) Date: Tue, 16 Mar 2021 14:58:54 -0400 Subject: [Servercert-wg] Examples of infrastructure certificates signed by Root CAs Message-ID: Section 6.1.7 of the BRs contains the following language in terms of restricting what a Root CA Certificate can issue: "Certificates for infrastructure purposes (administrative role certificates, internal CA operational device certificates); and" I was wondering if any CAs that are currently using/relying on this provision can share (either on-list or feel free to reply off-list/directly) examples of the certificate. Additionally, if you're using COTS software for CA management, any documentation you could reference or point to in how these certificates are used. I'd like to propose some changes to this language, but I want to make sure I understand this use case in particular. I'm hoping no one is confused in thinking this applies to, say, TSA certificates, but if you have interpreted it that way, that's also useful and valuable! Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jopurvis at cisco.com Wed Mar 17 14:11:48 2021 From: jopurvis at cisco.com (Jos Purvis (jopurvis)) Date: Wed, 17 Mar 2021 14:11:48 +0000 Subject: [Servercert-wg] Agenda for 18 March SCWG Meeting Message-ID: Below is the draft agenda for tomorrow?s meeting of the Server Certificate Working Group. Please let me know if you have updates or changes. Server Certificate Working Group Agenda ? 18 March 2021 ItemDescriptionPresenters 1.Roll CallJos 2.Read Antitrust Statement 3.Review Agenda, assign minute taker for next call 4.F2F Minutes Review / Approval Jos 5.Validation Subcommittee Update Tim 6.NetSec Subcommittee UpdateNeil 7.Ballot Status ? see table at end of AgendaAll 8.Any Other BusinessAll 9.Next call: 1 April at 11AM Eastern Adjourn; Immediately convene meeting of CA/B Forum call (same call) CURRENT STATUS OF BALLOTS 1. Ballots in Discussion Period o SC43 ? Clarify Acceptable Status Codes o SC40 ? Security Requirements for Airgapped CAs 2. Ballots in Voting Period None 3. Ballots in Review Period o SC39 ? Definition of Critical Vulnerability o SC41 ? Reformatting the BRs, EVGs, and NSRs 4. Draft Ballots Under Consideration ? Ballot SCXX: Debian Weak Keys (Chris) ? SC34 Account Management (Tobi) -- Jos Purvis (jopurvis at cisco.com) .:|:.:|:. cisco systems | Cryptographic Services PGP: 0xFD802FEE07D19105 | Controls and Trust Verification -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3699 bytes Desc: not available URL: From jopurvis at cisco.com Thu Mar 18 14:33:47 2021 From: jopurvis at cisco.com (Jos Purvis (jopurvis)) Date: Thu, 18 Mar 2021 14:33:47 +0000 Subject: [Servercert-wg] Agenda for 18 March SCWG Meeting Message-ID: <0F687B71-E28C-4A23-9B72-B5EE690851F5@cisco.com> All, Hearing no updates, the below is the final agenda for today?s meeting of the Server Certificate Working Group. Server Certificate Working Group Agenda ? 18 March 2021 ItemDescriptionPresenters 1.Roll CallJos 2.Read Antitrust Statement 3.Review Agenda, assign minute taker for next call 4.F2F Minutes Review / Approval Jos 5.Validation Subcommittee Update Tim 6.NetSec Subcommittee UpdateNeil 7.Ballot Status ? see table at end of AgendaAll 8.Any Other BusinessAll 9.Next call: 1 April at 11AM Eastern Adjourn; Immediately convene meeting of CA/B Forum call (same call) CURRENT STATUS OF BALLOTS 1. Ballots in Discussion Period o SC43 ? Clarify Acceptable Status Codes o SC40 ? Security Requirements for Airgapped CAs 2. Ballots in Voting Period None 3. Ballots in Review Period o SC39 ? Definition of Critical Vulnerability o SC41 ? Reformatting the BRs, EVGs, and NSRs 4. Draft Ballots Under Consideration ? Ballot SCXX: Debian Weak Keys (Chris) ? SC34 Account Management (Tobi) -- Jos Purvis (jopurvis at cisco.com) .:|:.:|:. cisco systems | Cryptographic Services PGP: 0xFD802FEE07D19105 | Controls and Trust Verification -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3699 bytes Desc: not available URL: From sleevi at google.com Thu Mar 18 15:32:11 2021 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 18 Mar 2021 11:32:11 -0400 Subject: [Servercert-wg] Examples of infrastructure certificates signed by Root CAs In-Reply-To: References: Message-ID: On Tue, Mar 16, 2021 at 2:58 PM Ryan Sleevi wrote: > Section 6.1.7 of the BRs contains the following language in terms of > restricting what a Root CA Certificate can issue: > > "Certificates for infrastructure purposes (administrative role > certificates, internal CA > operational device certificates); and" > > I was wondering if any CAs that are currently using/relying on this > provision can share (either on-list or feel free to reply > off-list/directly) examples of the certificate. Additionally, if you're > using COTS software for CA management, any documentation you could > reference or point to in how these certificates are used. > > I'd like to propose some changes to this language, but I want to make sure > I understand this use case in particular. I'm hoping no one is confused in > thinking this applies to, say, TSA certificates, but if you have > interpreted it that way, that's also useful and valuable! > > Thanks! > Just poking this since we had some mail delivery issues, and wanted to make sure everyone saw this question :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron at letsencrypt.org Fri Mar 19 23:47:49 2021 From: aaron at letsencrypt.org (Aaron Gable) Date: Fri, 19 Mar 2021 16:47:49 -0700 Subject: [Servercert-wg] OCSP Responder Requirements for Unexpired, Not-in-Use Intermediates Message-ID: Hello all, We (Let's Encrypt) are interested in any requirements, recommendations, or CA ecosystem best practices for turning off an Intermediate OCSP responder in the following scenario: An intermediate that is unexpired, with all end-entity certs it signed expired, and the CA is no longer going to issue from it. We think fully decommissioning OCSP responders for an intermediate in this scenario is not a violation of the Baseline Requirements. However, it might be best to return some kind of fully-formed unauthorized response until the intermediate is expired or a set time after expiry. Additionally, we're interested to know the recommendations related to an expired intermediate. How long should an OCSP responder exist after the intermediate issuer is expired? Regards Aaron, on behalf of Jillian Karner and Let's Encrypt / ISRG -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleevi at google.com Mon Mar 22 18:28:10 2021 From: sleevi at google.com (Ryan Sleevi) Date: Mon, 22 Mar 2021 14:28:10 -0400 Subject: [Servercert-wg] OCSP Responder Requirements for Unexpired, Not-in-Use Intermediates In-Reply-To: <010001784ce38983-537dd81e-5242-47a7-b2cb-0d248d362672-000000@email.amazonses.com> References: <010001784ce38983-537dd81e-5242-47a7-b2cb-0d248d362672-000000@email.amazonses.com> Message-ID: Aaron, Thanks for raising this! A few comments inline below. On Fri, Mar 19, 2021 at 7:48 PM Aaron Gable via Servercert-wg < servercert-wg at cabforum.org> wrote: > Hello all, > > We (Let's Encrypt) are interested in any requirements, recommendations, or > CA ecosystem best practices for turning off an Intermediate OCSP responder > in the following scenario: > > An intermediate that is unexpired, with all end-entity certs it signed > expired, and the CA is no longer going to issue from it. > Just to make sure I follow the problem statement: There is an OCSP Responder A, at some Defined URL, which provides status for a number of issued certificates. All of those issued certificates have expired, and so your question is "If there is no unexpired certificate for that responder URL, does that responder URL need to continue functioning". Is that correct? The clarifying distinction I'm making here is that it's not just end-entity certs, it's that all issued certs that have that URL are expired. We think fully decommissioning OCSP responders for an intermediate in this > scenario is not a violation of the Baseline Requirements. However, it might > be best to return some kind of fully-formed unauthorized response until the > intermediate is expired or a set time after expiry. > So, the main requirements for OCSP come from 9.6.1 of the BRs ("That the CA maintains a 24x7 publicly-accessible Repository with current information regarding the status (valid or revoked) of **all unexpired Certificates**") and 4.10.2 ("The CA SHALL maintain an online 24x7 Repository that application software can use to automatically check the current status of **all unexpired Certificates** issued by the CA"), with emphasis added by **. This, of course, is in addition to 7.1.23(c), which requires the OCSP Responder URL be included in the issued certificates. Is there any situation in which that responder URL may still be used? If not, then I think all of the expiration means it should be safe, from the BRs point of view, to turn down, although the obligations of 4.9.10 will still continue for the lifetime of the CA (and its inclusion in the relevant audits), so it does support your remark that providing a well-formed response gives you at least some determinism to make sure there's no "good" response ever issued. > > Additionally, we're interested to know the recommendations related to an > expired intermediate. How long should an OCSP responder exist after the > intermediate issuer is expired? > This one is a bit trickier. I would say the expiration of the intermediate is largely orthogonal, the question is about the expiration of the issued certificates. This becomes a bit clearer when you consider the same issuing intermediate may have multiple certificate paths, so the expiration of a single intermediate does not necessarily mean those existing certificates are invalidated, or that the obligation for providing a response goes away. Your main requirement should be from 4.10.1 of the BRs, but after that, it seems to be flexible. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron at letsencrypt.org Mon Mar 22 19:33:08 2021 From: aaron at letsencrypt.org (Aaron Gable) Date: Mon, 22 Mar 2021 12:33:08 -0700 Subject: [Servercert-wg] OCSP Responder Requirements for Unexpired, Not-in-Use Intermediates In-Reply-To: References: <010001784ce38983-537dd81e-5242-47a7-b2cb-0d248d362672-000000@email.amazonses.com> Message-ID: Ryan, Thanks for your reply! Yes, your understanding of the question is correct. In fact, I can narrow the scope of the questions even further, thanks to our simple issuing intermediate setup. Our Let's Encrypt Authority X3 (https://crt.sh/?caid=16418) intermediate is represented by two certificates; one (from DST Root CA X3) has already expired, and the other (from ISRG Root X1) expires later this year. We ceased issuance from this intermediate in December of last year, and only ever issued 90-day end-entity certificates from it, so that all of its issued certificates would expire prior to the expiration of either of its certificates. However, our OCSP responder for Let's Encrypt Authority X3 has still been receiving small amounts of traffic, querying for the status of expired certificates. We simply wanted to get a second opinion on the matter before taking down this OCSP responder, in case there was a requirement we had missed to keep it active throughout the lifetime (all possible lifetimes) of the issuing intermediate. For our practical purposes, the second question is a subset of the first -- we do not issue end-entity certificates which expire after the issuing intermediate, so an OCSP responder for an expired intermediate is also an OCSP responder for an intermediate with no unexpired issued certificates, and is covered by the response you gave above. (Obviously this is not true in general, but is for our case here.) We were asking primarily to cover the case where maintaining an OCSP responder for the above case was required, in order to determine when that requirement would cease. Thank you again for the reply, Aaron On Mon, Mar 22, 2021 at 11:28 AM Ryan Sleevi wrote: > Aaron, > > Thanks for raising this! A few comments inline below. > > On Fri, Mar 19, 2021 at 7:48 PM Aaron Gable via Servercert-wg < > servercert-wg at cabforum.org> wrote: > >> Hello all, >> >> We (Let's Encrypt) are interested in any requirements, recommendations, >> or CA ecosystem best practices for turning off an Intermediate OCSP >> responder in the following scenario: >> >> An intermediate that is unexpired, with all end-entity certs it >> signed expired, and the CA is no longer going to issue from it. >> > > Just to make sure I follow the problem statement: > > There is an OCSP Responder A, at some Defined URL, which provides status > for a number of issued certificates. All of those issued certificates have > expired, and so your question is "If there is no unexpired certificate for > that responder URL, does that responder URL need to continue functioning". > Is that correct? The clarifying distinction I'm making here is that it's > not just end-entity certs, it's that all issued certs that have that URL > are expired. > > We think fully decommissioning OCSP responders for an intermediate in this >> scenario is not a violation of the Baseline Requirements. However, it might >> be best to return some kind of fully-formed unauthorized response until the >> intermediate is expired or a set time after expiry. >> > > So, the main requirements for OCSP come from 9.6.1 of the BRs ("That the > CA maintains a 24x7 publicly-accessible Repository with current information > regarding the status (valid or revoked) of **all unexpired Certificates**") > and 4.10.2 ("The CA SHALL maintain an online 24x7 Repository that > application software can use to automatically check the current status of > **all unexpired Certificates** issued by the CA"), with emphasis added by > **. This, of course, is in addition to 7.1.23(c), which requires the OCSP > Responder URL be included in the issued certificates. > > Is there any situation in which that responder URL may still be used? If > not, then I think all of the expiration means it should be safe, from the > BRs point of view, to turn down, although the obligations of 4.9.10 will > still continue for the lifetime of the CA (and its inclusion in the > relevant audits), so it does support your remark that providing a > well-formed response gives you at least some determinism to make sure > there's no "good" response ever issued. > > >> >> Additionally, we're interested to know the recommendations related to an >> expired intermediate. How long should an OCSP responder exist after the >> intermediate issuer is expired? >> > > This one is a bit trickier. I would say the expiration of the > intermediate is largely orthogonal, the question is about the expiration of > the issued certificates. This becomes a bit clearer when you consider the > same issuing intermediate may have multiple certificate paths, so the > expiration of a single intermediate does not necessarily mean those > existing certificates are invalidated, or that the obligation for providing > a response goes away. > > Your main requirement should be from 4.10.1 of the BRs, but after that, it > seems to be flexible. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From NCarpenter at securetrust.com Thu Mar 25 15:49:26 2021 From: NCarpenter at securetrust.com (Niko Carpenter) Date: Thu, 25 Mar 2021 15:49:26 +0000 Subject: [Servercert-wg] Discussion Period Begins on Ballot SC43 Version 2: Clarify Acceptable Status Codes In-Reply-To: References: Message-ID: This begins the discussion period for ballot SC43 version 2: Clarify Acceptable Status Codes. An effective date of July 1, 2021 was added in this version. Purpose of Ballot: This ballot clarifies the allowed HTTP status codes used for following redirects in domain validation methods 18 and 19, and specifies that the target URI must come from the Location response header. In Section 3.2.2.4.18 and 3.2.2.4.19, it replaces "Redirects MUST be the result of an HTTP status code result within the 3xx Redirection class of status codes, as defined in RFC 7231, Section 6.4." with the following: * "Redirects MUST be the result of a 301, 302, 307, or 308 HTTP status code response." * "Redirects MUST be to resource URLs contained in the Location HTTP response header." The following motion has been proposed by Niko Carpenter of SecureTrust and endorsed by Corey Bonnell of DigiCert and Ryan Sleevi of Google. --MOTION BEGINS-- This ballot modifies the ?Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates? as defined in the following redline, based on Version 1.7.3: https://github.com/cabforum/servercert/compare/2b7720f7821764f0ea9d0d583ec5c61896a3f4cd..bd7915249a0360a28fe37b785c367d70645c7e8f --MOTION ENDS-- This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows: Discussion (7+ days) Start Time: 11-March 2021 21:30 UTC End Time: 01-April 2021 16:00 UTC Vote for approval (7 days) Start Time: 01-April 2021 16:00 UTC End Time: 08-April 2021 16:00 UTC Niko Carpenter Software Engineer www.securetrust.com 2020 Best PCI Compliance Provider Winner ? Card Not Present Awards This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwilson at mozilla.com Mon Mar 29 21:08:52 2021 From: bwilson at mozilla.com (Ben Wilson) Date: Mon, 29 Mar 2021 15:08:52 -0600 Subject: [Servercert-wg] Ballot SC42: 398-day Reuse Period Message-ID: This email begins the public discussion period of Ballot SC42: 398-day Reuse Period. Pursuant to section 2.3 of the Bylaws, "The discussion period then shall take place for at least seven (7) calendar days before votes are cast. At any time, a new version of the ballot (marked with a distinguishing version number) may be posted by the proposer in the same manner as the original. Once no new version of the ballot has been posted for seven (7) calendar days, the proposer may end the discussion period and start the voting period by reposting the final version of the ballot and clearly indicating that voting is to begin, along with the start and end dates and times (including time zone) for the voting period." *Type of Ballot:* This is a ballot to adopt two Final Maintenance Guidelines which modify the Forum's Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates (BRs) and the Guidelines for the Issuance and Management of Extended Validation Certificates (EVGs). *Purpose of Ballot:* This ballot changes validation reuse periods for FQDN and IP Address validation to 398 days in section 4.2.1 of the BRs and for all purposes in section 11.14.3 of the EVGs. The ballot does not change the 825-day reuse period in section 4.2.1. of the BRs for Organizational Validation (OV) information. *Specifically:* * It inserts as the last sentence in the third paragraph of BR section 4.2.1, "Effective 2021-10-01, the CA SHALL verify Domain Names and IP Addresses no more than 398 days prior to Certificate issuance." * It replaces eight instances of "thirteen months" or "thirteen-month" in EVG section 11.14.3 with 398 days. The following motion has been proposed by Ben Wilson of Mozilla and endorsed by Dimitris Zacharopoulos of HARICA and Chema Lopez of Firmaprofesional. * ? MOTION BEGINS ?* This ballot modifies the ?Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates? (?BRs?), based on Version 1.7.3: Insert as the last sentence in the third paragraph of section 4.2.1 of the BRs, "Effective 2021-10-01, the CA SHALL verify Domain Names and IP Addresses no more than 398 days prior to Certificate issuance." as illustrated in the attached redlined PDF document and in the following redline: https://github.com/sleevi/cabforum-docs/compare/2020-11-30_Pandocification...BenWilson-Mozilla:398-day-FQDN-validation This ballot modifies the ?Guidelines for the Issuance and Management of Extended Validation Certificates? (?EVGs?) as follows, based on Version 1.7.4: REPLACE all eight instances of "thirteen months" (or "thirteen-month") in section 11.14.3 of the EVGs with 398 days and 398-day, respectively, as illustrated in the attached redlined PDF and in the following redline: https://github.com/sleevi/cabforum-docs/compare/2020-11-30_Pandocification...BenWilson-Mozilla:398-day-FQDN-validation * ? MOTION ENDS ?* This ballot proposes two Final Maintenance Guidelines. The procedure for approval of this ballot is as follows: Discussion (7+ days) Start Time: 2021-03-29 21:00:00 UTC End Time: TBD Vote for approval (7 days) Start Time: TBD End Time: TBD -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: BR section 4.2.1 amended by SC42.pdf Type: application/pdf Size: 62796 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Section 11.14.3 from CA-Browser-Forum-EV-Guidelines-v1.7.4.pdf Type: application/pdf Size: 109617 bytes Desc: not available URL: From bwilson at mozilla.com Mon Mar 29 22:28:51 2021 From: bwilson at mozilla.com (Ben Wilson) Date: Mon, 29 Mar 2021 16:28:51 -0600 Subject: [Servercert-wg] Ballot SC40v3: Security Requirements for Air-Gapped CA Systems In-Reply-To: <01000178130b3666-c1595c9e-7b50-4686-ba79-b489f840b45b-000000@email.amazonses.com> References: <010001780fe7f59a-a8b7830b-406a-4720-bfcc-71067582f5b6-000000@email.amazonses.com> <010001781229ba08-88f265b3-a04b-45db-8944-eb40bee4e0f6-000000@email.amazonses.com> <0100017812f05413-38de86c4-a94b-48d9-88ad-6dea0e074d96-000000@email.amazonses.com> <01000178130b3666-c1595c9e-7b50-4686-ba79-b489f840b45b-000000@email.amazonses.com> Message-ID: All, I let Ballot SC40v3 fail per the 21-day limit in section 2.3 of the Bylaws, which I believe is too short because it didn't provide me with sufficient time to work through the difficult wording issues. The next time we re-visit the Bylaws, I'll support a revision making it a 30-day period or greater. Meanwhile, I am thinking about changing the concept from offline "CA System" to offline "Hardware Security Module." We didn't yet define "CA System". We also haven't addressed deactivated partitions on an HSM and whether those are considered "offline". So we have more work to do. Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Morton at entrust.com Tue Mar 30 20:12:17 2021 From: Bruce.Morton at entrust.com (Bruce Morton) Date: Tue, 30 Mar 2021 20:12:17 +0000 Subject: [Servercert-wg] Discussion Period Begins on Ballot SC43 Version 2: Clarify Acceptable Status Codes In-Reply-To: <010001786a14920e-79898392-510e-4898-8766-47239845fc12-000000@email.amazonses.com> References: <010001786a14920e-79898392-510e-4898-8766-47239845fc12-000000@email.amazonses.com> Message-ID: Hi Niko, Our team believes that a single 303 redirect from http to https scheme for the same fqdn should be acceptable. Is there a reason why 303 is not allowed? Thanks, Bruce. From: Servercert-wg On Behalf Of Niko Carpenter via Servercert-wg Sent: Thursday, March 25, 2021 11:51 AM To: CA/B Forum Server Certificate WG Public Discussion List Subject: [EXTERNAL] [Servercert-wg] Discussion Period Begins on Ballot SC43 Version 2: Clarify Acceptable Status Codes WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. ________________________________ This begins the discussion period for ballot SC43 version 2: Clarify Acceptable Status Codes. An effective date of July 1, 2021 was added in this version. Purpose of Ballot: This ballot clarifies the allowed HTTP status codes used for following redirects in domain validation methods 18 and 19, and specifies that the target URI must come from the Location response header. In Section 3.2.2.4.18 and 3.2.2.4.19, it replaces "Redirects MUST be the result of an HTTP status code result within the 3xx Redirection class of status codes, as defined in RFC 7231, Section 6.4." with the following: * "Redirects MUST be the result of a 301, 302, 307, or 308 HTTP status code response." * "Redirects MUST be to resource URLs contained in the Location HTTP response header." The following motion has been proposed by Niko Carpenter of SecureTrust and endorsed by Corey Bonnell of DigiCert and Ryan Sleevi of Google. --MOTION BEGINS-- This ballot modifies the "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates" as defined in the following redline, based on Version 1.7.3: https://github.com/cabforum/servercert/compare/2b7720f7821764f0ea9d0d583ec5c61896a3f4cd..bd7915249a0360a28fe37b785c367d70645c7e8f --MOTION ENDS-- This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows: Discussion (7+ days) Start Time: 11-March 2021 21:30 UTC End Time: 01-April 2021 16:00 UTC Vote for approval (7 days) Start Time: 01-April 2021 16:00 UTC End Time: 08-April 2021 16:00 UTC Niko Carpenter Software Engineer www.securetrust.com 2020 Best PCI Compliance Provider Winner - Card Not Present Awards This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleevi at google.com Tue Mar 30 20:31:31 2021 From: sleevi at google.com (Ryan Sleevi) Date: Tue, 30 Mar 2021 16:31:31 -0400 Subject: [Servercert-wg] Discussion Period Begins on Ballot SC43 Version 2: Clarify Acceptable Status Codes In-Reply-To: <0100017884c41d40-49db94f9-cceb-4dc3-95a6-7bedc14eecba-000000@email.amazonses.com> References: <010001786a14920e-79898392-510e-4898-8766-47239845fc12-000000@email.amazonses.com> <0100017884c41d40-49db94f9-cceb-4dc3-95a6-7bedc14eecba-000000@email.amazonses.com> Message-ID: The semantics of 303 indicate that the new resource (referred to via the Location field) is not necessarily the same as the requested resource. The semantics/interpretation of that redirected-to-resource are left up to the user and user agent, while the goal with this was to ensure unambiguous semantics. >From RFC 7231, Section 6.4.4 (Emphasis added) The 303 (See Other) status code indicates that the server is redirecting the user agent to a different resource, as indicated by a URI in the Location header field, which is intended to provide an indirect response to the original request. A user agent can perform a retrieval request targeting that URI (a GET or HEAD request if using HTTP), which might also be redirected, and present the eventual result as an answer to the original request. *Note that the new URI in the Location header field is not considered equivalent to the effective request URI.* On Tue, Mar 30, 2021 at 4:12 PM Bruce Morton via Servercert-wg < servercert-wg at cabforum.org> wrote: > Hi Niko, > > > > Our team believes that a single 303 redirect from http to https scheme for > the same fqdn should be acceptable. Is there a reason why 303 is not > allowed? > > > > Thanks, Bruce. > > > > *From:* Servercert-wg *On Behalf Of *Niko > Carpenter via Servercert-wg > *Sent:* Thursday, March 25, 2021 11:51 AM > *To:* CA/B Forum Server Certificate WG Public Discussion List < > servercert-wg at cabforum.org> > *Subject:* [EXTERNAL] [Servercert-wg] Discussion Period Begins on Ballot > SC43 Version 2: Clarify Acceptable Status Codes > > > > WARNING: This email originated outside of Entrust. > DO NOT CLICK links or attachments unless you trust the sender and know the > content is safe. > ------------------------------ > > This begins the discussion period for ballot SC43 version 2: Clarify > Acceptable Status Codes. An effective date of July 1, 2021 was added in > this version. > > > > Purpose of Ballot: > > > > This ballot clarifies the allowed HTTP status codes used for following > redirects in domain validation methods 18 and 19, and specifies that the > target URI must come from the Location response header. > > In Section 3.2.2.4.18 and 3.2.2.4.19, it replaces > > "Redirects MUST be the result of an HTTP status code result within the 3xx > Redirection class of status codes, as defined in RFC 7231, Section 6.4." > with the following: > > > > * "Redirects MUST be the result of a 301, 302, 307, or 308 HTTP status > code response." > > * "Redirects MUST be to resource URLs contained in the Location HTTP > response header." > > > > The following motion has been proposed by Niko Carpenter of SecureTrust > and endorsed by Corey Bonnell of DigiCert and Ryan Sleevi of Google. > > > > --MOTION BEGINS-- > > > > This ballot modifies the ?Baseline Requirements for the Issuance and > Management of Publicly-Trusted Certificates? as defined in the following > redline, based on Version 1.7.3: > > > > > https://github.com/cabforum/servercert/compare/2b7720f7821764f0ea9d0d583ec5c61896a3f4cd..bd7915249a0360a28fe37b785c367d70645c7e8f > > > > > --MOTION ENDS-- > > > > This ballot proposes a Final Maintenance Guideline. > > > > The procedure for approval of this ballot is as follows: > > > > Discussion (7+ days) > > > > Start Time: 11-March 2021 21:30 UTC > > > > End Time: 01-April 2021 16:00 UTC > > > > Vote for approval (7 days) > > > > Start Time: 01-April 2021 16:00 UTC > > > > End Time: 08-April 2021 16:00 UTC > > > > > *Niko Carpenter *Software Engineer > > www.securetrust.com > > > *2020 Best PCI Compliance Provider Winner ? Card Not Present Awards* > > This transmission may contain information that is privileged, > confidential, and/or exempt from disclosure under applicable law. If you > are not the intended recipient, you are hereby notified that any > disclosure, copying, distribution, or use of the information contained > herein (including any reliance thereon) is STRICTLY PROHIBITED. If you > received this transmission in error, please immediately contact the sender > and destroy the material in its entirety, whether in electronic or hard > copy format. > _______________________________________________ > Servercert-wg mailing list > Servercert-wg at cabforum.org > https://lists.cabforum.org/mailman/listinfo/servercert-wg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jopurvis at cisco.com Wed Mar 31 15:02:26 2021 From: jopurvis at cisco.com (Jos Purvis (jopurvis)) Date: Wed, 31 Mar 2021 15:02:26 +0000 Subject: [Servercert-wg] Draft Agenda for 1 April SCWG Meeting Message-ID: Below is the draft agenda for tomorrow?s meeting of the Server Certificate Working Group. Please let me know if you have updates or changes. Server Certificate Working Group Agenda ? 18 March 2021 ItemDescriptionPresenters 1.Roll CallJos 2.Read Antitrust Statement 3.Review Agenda, assign minute taker for next call 4.F2F Minutes Review / Approval Jos 5.Validation Subcommittee Update Tim 6.NetSec Subcommittee UpdateNeil 7.Ballot Status ? see table at end of AgendaAll 8.Any Other BusinessAll 9.Next call: 15 April at 11AM Eastern Adjourn; Immediately convene meeting of CA/B Forum call (same call) CURRENT STATUS OF BALLOTS 1. Ballots in Discussion Period o SC43 ? Clarify Acceptable Status Codes o SC42 ? 398-day Re-use Period 2. Ballots in Voting Period None 3. Ballots in Review Period o SC41 ? Reformatting the BRs, EVGs, and NSRs 4. Draft Ballots Under Consideration ? Ballot SCXX: Debian Weak Keys (Chris) ? SC34 Account Management (Tobi) -- Jos Purvis (jopurvis at cisco.com) .:|:.:|:. cisco systems | Cryptographic Services PGP: 0xFD802FEE07D19105 | Controls and Trust Verification -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3699 bytes Desc: not available URL: From Mike.Reilly at microsoft.com Wed Mar 31 21:05:01 2021 From: Mike.Reilly at microsoft.com (Mike Reilly (SECURITY)) Date: Wed, 31 Mar 2021 21:05:01 +0000 Subject: [Servercert-wg] [EXTERNAL] Re: Ballot SC40v3: Security Requirements for Air-Gapped CA Systems In-Reply-To: <01000178801acfbf-b915c4a4-fdbf-4fb0-a821-79fadd35d92e-000000@email.amazonses.com> References: <010001780fe7f59a-a8b7830b-406a-4720-bfcc-71067582f5b6-000000@email.amazonses.com> <010001781229ba08-88f265b3-a04b-45db-8944-eb40bee4e0f6-000000@email.amazonses.com> <0100017812f05413-38de86c4-a94b-48d9-88ad-6dea0e074d96-000000@email.amazonses.com> <01000178130b3666-c1595c9e-7b50-4686-ba79-b489f840b45b-000000@email.amazonses.com> <01000178801acfbf-b915c4a4-fdbf-4fb0-a821-79fadd35d92e-000000@email.amazonses.com> Message-ID: Thanks for the update Ben. I had some additional feedback from within Microsoft to consider when this is brough up again: * In the definition of the Security Support System, the word ?reduction? is used. I think the word we want in relation to logging is ?retention?. * 5.1.6 refers to the ?principle of least privilege?. Is there a definition or discussion of this principle somewhere else in the requirements. Without something to make it concrete, I don?t know how there could be any specific audit requirement to meet because it is very subjective in nature. Although I totally agree that we should observe this principle because it is a core component of security I don?t know how one can objectively evaluate whether it is observed or not. All of the other requirements listed are easily auditable but this one not as much. Thanks, Mike From: Servercert-wg On Behalf Of Ben Wilson via Servercert-wg Sent: Monday, March 29, 2021 3:29 PM To: CA/B Forum Server Certificate WG Public Discussion List Subject: [EXTERNAL] Re: [Servercert-wg] Ballot SC40v3: Security Requirements for Air-Gapped CA Systems All, I let Ballot SC40v3 fail per the 21-day limit in section 2.3 of the Bylaws, which I believe is too short because it didn't provide me with sufficient time to work through the difficult wording issues. The next time we re-visit the Bylaws, I'll support a revision making it a 30-day period or greater. Meanwhile, I am thinking about changing the concept from offline "CA System" to offline "Hardware Security Module." We didn't yet define "CA System". We also haven't addressed deactivated partitions on an HSM and whether those are considered "offline". So we have more work to do. Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: