Re: [Servercert-wg] - Sunsetting use of WHOIS to identify Domain Contacts

[Ponds-White, Trev via Servercert-wg]

The suggestion for that date is based on our discussions with customers about 
the time that it will take for organizations to change their practices, rather 
than the specific motivation for the deprecation.

From: Ryan Dickson 
Sent: Monday, September 16, 2024 12:48 PM
To: Ponds-White, Trev ; CA/B Forum Server Certificate WG 
Public Discussion List 
Cc: Ben Wilson ; Pedro FUENTES 
Subject: RE: [EXTERNAL] [Servercert-wg] - Sunsetting use of WHOIS to identify 
Domain Contacts


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


Hi Trev,

I interpret the 
motivation<https://aws.amazon.com/blogs/security/aws-certificate-manager-will-discontinue-whois-lookup-for-email-validated-certificates/#:~:text=Why%20are%20we,of%20this%20post.>
 for the behavior described in the link you shared as a matter of overcoming 
the low success rate of WHOIS-based communications (“Over the past several 
years, we’ve observed that the WHOIS lookup success rate has declined to less 
than 5 percent. If you rely on the contact addresses listed in the WHOIS 
database provided by your domain registrar to validate your domain ownership, 
this might create an availability risk.”)

The motivation for the ballot is focused on managing a separate risk, closing 
circumstances that can be actively exploited and result in fraudulent 
certificate issuance (and worse, abuse given the existence of that 
certificate). Given this perspective, can you help me better understand what 
you'd consider an appropriate timeline to close what could be considered an 
open vulnerability with this DCV method?

Thanks,
Ryan

On Mon, Sep 16, 2024 at 1:12 PM Ponds-White, Trev via Servercert-wg 
mailto:servercert-wg@cabforum.org>> wrote:
Thanks for putting this together Ryan. As some might be aware Amazon began a 
process earlier this year to remove use of this method. 
(https://aws.amazon.com/blogs/security/aws-certificate-manager-will-discontinue-whois-lookup-for-email-validated-certificates/)

We got feedback from customers that for some this is a non-trivial dependency 
to remove. It’s not uncommon for companies to have built automation on top of 
email validation. Based on the information we got I recommend a date of April 
30, 2025.

From: Servercert-wg 
mailto:servercert-wg-boun...@cabforum.org>> 
On Behalf Of Ben Wilson via Servercert-wg
Sent: Monday, September 16, 2024 9:16 AM
To: Pedro FUENTES mailto:pfuen...@wisekey.com>>; CA/B 
Forum Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org>>
Subject: RE: [EXTERNAL] [Servercert-wg] [EXTERNAL]- Sunsetting use of WHOIS to 
identify Domain Contacts


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


Mozilla will endorse, too, if needed.
Thanks,
Ben

On Mon, Sep 16, 2024 at 9:06 AM Pedro FUENTES via Servercert-wg 
mailto:servercert-wg@cabforum.org>> wrote:
OISTE would endorse this initiative

On 16 Sep 2024, at 16:32, Ryan Dickson via Servercert-wg 
mailto:Servercert-wg@cabforum.org>> wrote:

All,

In light of recent events where research from WatchTowr Labs demonstrated how 
threat actors could exploit WHOIS to obtain fraudulently issued TLS 
certificates [1] and follow-on discussions in MDSP [2][3], we drafted an 
introductory proposal [4] to sunset the use of WHOIS for identifying Domain 
Contacts.

The proposal sets a prohibition against relying on WHOIS to identify Domain 
Contacts beginning 11/1/2024.

While publicly-trusted CA Owners are required to disclose and maintain in-use 
DCV methods to the CCADB [5], the collected data lacks specificity, hindering 
our ability to assess the extent of reliance on WHOIS and the potential impact 
of transitioning away from it.

Feedback on the proposal (preferably using comments or suggestions on the Pull 
Request via GitHub) along with volunteers for endorsers would be appreciated.
Thanks,
Ryan

P.S., I apologize if this effort is redundant to discussions already taking 
place in the Forum, I was traveling last week and am catching up on email.

[1] 
https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/<https://urldefense.proofpoint.com/v2/url?u=https-3A__labs.watchtowr.com_we-2Dspent-2D20-2Dto-2Dachieve-2Drce-2Dand-2Daccidentally-2Dbecame-2Dthe-2Dadmins-2Dof-2Dmobi_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=1CJcldkOKNaH6Tu9kiTliBmTMzTdtFrQ0USL5juRHSkA78re2Z_FuT3Hr1z1Cd6m&s=qZzpnP-57sE4nQ6LxHM50ULVrjSKSIk2Fccl0d8PESE&e=>
[2] 
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/FuOi_uhQB6U<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_a_mozilla.org_g_dev-2Dsecurity-2

Re: [Servercert-wg] - Sunsetting use of WHOIS to identify Domain Contacts

[Ponds-White, Trev via Servercert-wg]

Thanks for putting this together Ryan. As some might be aware Amazon began a 
process earlier this year to remove use of this method. 
(https://aws.amazon.com/blogs/security/aws-certificate-manager-will-discontinue-whois-lookup-for-email-validated-certificates/)

We got feedback from customers that for some this is a non-trivial dependency 
to remove. It’s not uncommon for companies to have built automation on top of 
email validation. Based on the information we got I recommend a date of April 
30, 2025.

From: Servercert-wg  On Behalf Of Ben 
Wilson via Servercert-wg
Sent: Monday, September 16, 2024 9:16 AM
To: Pedro FUENTES ; CA/B Forum Server Certificate WG 
Public Discussion List 
Subject: RE: [EXTERNAL] [Servercert-wg] [EXTERNAL]- Sunsetting use of WHOIS to 
identify Domain Contacts


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


Mozilla will endorse, too, if needed.
Thanks,
Ben

On Mon, Sep 16, 2024 at 9:06 AM Pedro FUENTES via Servercert-wg 
mailto:servercert-wg@cabforum.org>> wrote:
OISTE would endorse this initiative


On 16 Sep 2024, at 16:32, Ryan Dickson via Servercert-wg 
mailto:Servercert-wg@cabforum.org>> wrote:

All,

In light of recent events where research from WatchTowr Labs demonstrated how 
threat actors could exploit WHOIS to obtain fraudulently issued TLS 
certificates [1] and follow-on discussions in MDSP [2][3], we drafted an 
introductory proposal [4] to sunset the use of WHOIS for identifying Domain 
Contacts.

The proposal sets a prohibition against relying on WHOIS to identify Domain 
Contacts beginning 11/1/2024.

While publicly-trusted CA Owners are required to disclose and maintain in-use 
DCV methods to the CCADB [5], the collected data lacks specificity, hindering 
our ability to assess the extent of reliance on WHOIS and the potential impact 
of transitioning away from it.

Feedback on the proposal (preferably using comments or suggestions on the Pull 
Request via GitHub) along with volunteers for endorsers would be appreciated.
Thanks,
Ryan

P.S., I apologize if this effort is redundant to discussions already taking 
place in the Forum, I was traveling last week and am catching up on email.

[1] 
https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/
[2] 
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/FuOi_uhQB6U
[3] 
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/mAl9XjieSkA
[4] 
https://github.com/cabforum/servercert/pull/548
[5] 
https://docs.google.com/spreadsheets/d/1IXL8Yk12gPQs8GXiosXCPLPgATJilaiVy-f9SbsMA28/edit?gid=268412787#gid=268412787

___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_servercert-2Dwg&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=1CJcldkOKNaH6Tu9kiTliBmTMzTdtFrQ0USL5juRHSkA78re2Z_FuT3Hr1z1Cd6m&s=hOfLasOApOVBc0Uwo83PbDiIvJ4IjPP7O-hs7suejHw&e=


WISeKey SA
Pedro Fuentes
CSO - 

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

[Ponds-White, Trev via Servercert-wg]

Hi Aaron G.,

We have some feedback on the ballot.

Can you add the word “first” into the sentence about 15 minutes to reinforce 
that we are discussing just the first published response. Not responses 
associated with status changes. We think this will improve clarity and future 
litigation of this requirements. So the new sentence would read “starting no 
more than 15 minutes after the Certificate or Precertificate is first published 
or otherwise made available.”

Do we need “using any current or previous key associated with that CA 
subject;”? What is additional clarity is that trying to provide? It kind of 
reads as an endorsement of reusing keys for new CAs.

When we read the lines starting at line 1391 we thought it might be more clear 
if there was a line break after the first sentence. So it would look like this 
instead:

“If the OCSP responder receives a request for the status of a certificate 
serial number that is "unassigned", then the responder SHOULD NOT respond with 
a "good" status.

If the OCSP responder is for a CA that is not Technically Constrained in line 
with [Section 
7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile)
 or [Section 
7.1.2.5](#7125-technically-constrained-tls-subordinate-ca-certificate-profile), 
the responder MUST NOT respond with a "good" status for such requests."

Thanks!
Trevoli Ponds-White

From: Servercert-wg  On Behalf Of Aaron 
Gable via Servercert-wg
Sent: Thursday, August 22, 2024 9:28 AM
To: CA/B Forum Server Certificate WG Public Discussion List 

Subject: [EXTERNAL] [Servercert-wg] Discussion Period Begins: Ballot SC-076 
"Clarify and Improve OCSP Requirements"


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


Purpose of Ballot

This ballot attempts to address three concerns:
- The confusion around "reserved" serials, which do not actually exist because 
all Precertificate serials are assumed to also exist in corresponding 
Certificates and are therefore actually "assigned";
- Confusion around whether, and how quickly, OCSP responders must begin 
providing authoritative responses for Certificates and Precertificates; and
- Confusion around whether and how the OCSP requirements apply to Certificates 
which do not contain an AIA OCSP URL, but for which the CA's OCSP responder is 
still willing to provide responses.

These concerns have been previously discussed in this Mozilla policy 
bug, this ServerCert WG 
bug, and this Bugzilla 
incident.

It addresses these concerns by:
- Stating that OCSP responses must be available within 15 minutes of signing a 
certificate containing an AIA OCSP URL;
- Removing the concept of a "reserved" serial entirely;
- Moving all OCSP requirements into Section 4.9.9, leaving Section 4.9.10 
(which RFC 3647 says is meant to place requirements on relying parties, not on 
CAs) empty; and
- Organizing the requirements in Section 4.9.9 into three clusters:
  - Definitions of "validity interval", "assigned", and "unassigned";
  - Requirements on OCSP Responders, which apply only to responses from AIA 
OCSP URLs found in issued certs; and
  - Requirements on OCSP Responses, which apply to all responses regardless of 
whether the certificate in question has an AIA OCSP URL.

GitHub PR representing this ballot: 
https://github.com/cabforum/servercert/pull/535
Rendered view of the resulting text: 
https://github.com/cabforum/servercert/blob/f61814473a1340774aec4022a6cbfe1fa2616458/docs/BR.md#499-on-line-revocationstatus-checking-availability

Motion

The following motion has been proposed by Aaron Gable (Let's Encrypt / ISRG), 
and is endorsed by Ben Wilson (Mozilla) and Antonis Eleftheriadis (HARICA).

Motion Begins

Modify the "Baseline Requirements for the Issuance and Management of 
Publicly-Trusted TLS Server Certificates", based on Version 2.0.6, as specified 
in the following redline:

https://github.com/cabforum/servercert/compare/929d9b4a1ed1f13f92f6af672ad6f6a2153b8230...f61814473a1340774aec4022a6cbfe1fa2616458

Motion Ends

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

Discussion Period (at least 7 days)

Start: August 22, 2024 16:30 UTC
End: on or after August 29, 2024 16:30 UTC

Voting Period (7 days)

Start: TBD
End: TBD
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Ponds-White, Trev via Servercert-wg]

Amazon Trust Services votes yes.

From: Servercert-wg  On Behalf Of Clint 
Wilson via Servercert-wg
Sent: Tuesday, August 13, 2024 10:05 AM
To: ServerCert CA/BF 
Subject: [EXTERNAL] [Servercert-wg] VOTING Period Begins - Ballot SC-077: 
Update WebTrust Audit name in Section 8.4 and References


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


Purpose of Ballot

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

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

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

Motion

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

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

Motion Begins

MODIFY the "Baseline Requirements for the Issuance and Management of 
Publicly-Trusted TLS Server Certificates" ("TLS Baseline Requirements") based 
on Version 2.0.5 as specified in the following redline:

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

Motion Ends

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

Discussion (at least 7 days)

  *   Start time: August 6, 2024 17:00 UTC
  *   End time: on or after August 13, 2024 17:00 UTC

Vote for approval (7 days)

  *   Start time: August 13, 2024 17:00 UTC
  *   End time: August 20, 2024 17:00 UTC
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Ponds-White, Trev via Servercert-wg]

We’ll be happy to!

From: Servercert-wg  On Behalf Of Clint 
Wilson via Servercert-wg
Sent: Thursday, August 1, 2024 4:28 PM
To: ServerCert CA/BF 
Subject: [EXTERNAL] [Servercert-wg] Seeking Endorsers and Feedback - SC-077: 
Update WebTrust Audit name in Section 8.4 and References


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


Hello all,

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

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

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

Cheers,
-Clint
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Ponds-White, Trev via Servercert-wg]

Amazon Trust Services votes no based on the discussion in the Server Cert group 
call where it was determined we want to make an additional revision to this 
ballot.

From: Servercert-wg  On Behalf Of Dimitris 
Zacharopoulos (HARICA) via Servercert-wg
Sent: Sunday, May 5, 2024 1:24 AM
To: CA/B Forum Server Certificate WG Public Discussion List 

Subject: [EXTERNAL] [Servercert-wg] [Voting Begins] Ballot SC-74 - Clarify 
CP/CPS structure according to RFC 3647


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


Voting begins for ballot SC-74.

SC-74 - Clarify CP/CPS structure according to RFC 3647
Summary

The TLS Baseline Requirements require in section 2.2 that:

"The Certificate Policy and/or Certification Practice Statement MUST be 
structured in accordance with RFC 3647 and MUST include all material required 
by RFC 3647."

The intent of this language was to ensure that all CAs' CP and/or CPS documents 
contain a similar structure, making it easier to review and compare against the 
BRs. However, there was some ambiguity as to the actual structure that CAs 
should follow. After several discussions in the SCWG Public Mailing 
List
 and F2F meetings, it was agreed that more clarity should be added to the 
existing requirement, pointing to the outline described in section 6 of RFC 
3647.

The following motion has been proposed by Dimitris Zacharopoulos (HARICA) and 
endorsed by Aaron Poulsen (Amazon) and Tim Hollebeek (Digicert).

You can view the github pull request representing this ballot 
here.

Motion Begins

MODIFY the "Baseline Requirements for the Issuance and Management of 
Publicly-Trusted TLS Server Certificates" based on Version 2.0.4 as specified 
in the following redline:

  *   
https://github.com/cabforum/servercert/compare/c4a34fe2292022e0a04ba66b5a85df75907ac2a2...f6a90e2a652fbb7a2d62a976b70f4af3adce8dae

Motion Ends

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

Discussion (at least 7 days)

  *   Start time: 2024-04-25 16:30:00 UTC
  *   End time: on or after 2024-05-02 16:30:00 UTC

Vote for approval (7 days)

  *   Start time: 2024-05-05 8:30:00 UTC
  *   End time: 2024-05-12 8:30:00 UTC

___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] [Voting Period Begins]: SC65: Convert EVGs into RFC 3647 format v2

[Ponds-White, Trev via Servercert-wg]

Inigo are you going to fix the redline? I agree with Dimitris that it’s not 
actually clear what the change is. For recording purposes I think we want the 
ballot content to be correct.

From: Servercert-wg  On Behalf Of Inigo 
Barreira via Servercert-wg
Sent: Thursday, March 7, 2024 2:23 AM
To: Dimitris Zacharopoulos (HARICA) ; CA/B Forum Server 
Certificate WG Public Discussion List 
Subject: RE: [EXTERNAL] [Servercert-wg] [Voting Period Begins]: SC65: Convert 
EVGs into RFC 3647 format v2


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


All,

Yes, you´re right Dimitris and I was also a bit confused but I think I know 
what has happened.
These changes are over version 2.0.2 as you can check in the PR but when 
created the comparing link I was copying the latest ones I was using since we 
started the ballot discussion, over last summer, which at that time the version 
was 2.0.0, so used this “old” version, then the 3 dots, and the new version 
over v2.0.2 every time (you can see that the changes applied in the last 2 
ballots are applied again) but without changing the initial one, so always took 
version 2.0.0 for comparing.
I think this happened because, first I didn´t pay enough attention to the 
links, also because it´s been a long time discussing ballot and finally because 
there are so many ongoing that I lost track. I´m really sorry and I apologize.

That said, the problem is just in the comparing link for the BRs (the EVGs are 
not affected which is the main objective of this ballot) but not on the version 
used for the changes. The changes are over the latest version published, 
v2.0.2, as you can check in the PR.

So, with this in mind I don´t know what to do next. According to the bylaws I 
can withdraw the ballot during the voting period and prepare a new version.
OTOH, (considering that the PR is correct) the ballot can continue and see the 
result.

Regards


De: Servercert-wg 
mailto:servercert-wg-boun...@cabforum.org>> 
En nombre de Dimitris Zacharopoulos (HARICA) via Servercert-wg
Enviado el: jueves, 7 de marzo de 2024 9:07
Para: servercert-wg@cabforum.org
Asunto: Re: [Servercert-wg] [Voting Period Begins]: SC65: Convert EVGs into RFC 
3647 format v2

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Apologies for not reviewing this ballot sooner.

I am a bit confused with the redline changes, especially in the BRG. Based on 
the GitHub link, the comparison of the BRs is against version 2.0.0, not 2.0.2 
as described in the summary of this ballot.

HARICA is uncertain about the changes introduced and therefore votes "no" to 
ballot SC65.

On 4/3/2024 5:33 μ.μ., Inigo Barreira via Servercert-wg wrote:

Summary:

The Extended Validation Certificates guidelines (EVGs) were developed and 
written in a specific format. Since then, the RFC 3647 has been the basis (and 
the de-facto standard) for the CA/Browser Forum to develop other documents.

This ballot aims to update the EVGs to follow the RFC 3647 format without 
changing any content, just moving current sections to those defined in the RFC 
3647. There are no normative requirements changes.

This change also affects the Baseline Requirements for TSL certificates (BRs) 
which needs to point to the new sections of the EVGs. Both documents will be 
updated according to the latest version published.

This ballot is proposed by Iñigo Barreira (Sectigo) and endorsed by Pedro 
Fuentes (OISTE) and Ben Wilson (Mozilla).

--- Motion Begins ---

This ballot modifies the “Baseline Requirements for the Issuance and Management 
of Publicly-Trusted TLS Certificates" ("TLS Baseline Requirements"), based on 
Version 2.0.2 and the “Guidelines for the Issuance and Management of Extended 
Validation Certificates” (EVGs) based on Version 1.8.0.

MODIFY the TLS EVGs and BRs as specified in the following Redline:

Comparing 
90a98dc7c1131eaab01af411968aa7330d315b9b...dedeebfe036fa5a6f0d7ae985ea08317ba60b8cb
 · cabforum/servercert 
(github.com)

--- Motion Ends ---

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

Discussion (at least 7 days)

  1.  Start time: 2024-02-20 17:00:00 UTC
  2.  End time: not bef

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

[Ponds-White, Trev via Servercert-wg]

Amazon Trust Services votes yes.

From: Servercert-wg  On Behalf Of Martijn 
Katerbarg via Servercert-wg
Sent: Monday, March 4, 2024 2:59 AM
To: CA/B Forum Server Certificate WG Public Discussion List 

Subject: [EXTERNAL] [Servercert-wg] [Voting Period Begins]: SC-69v3 Clarify 
router and firewall logging requirements


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.



Summary:

This ballot aims to clarify what data needs to be logged as part of the 
"Firewall and router activities" logging requirement in the Baseline 
Requirements.

This ballot is proposed by Martijn Katerbarg (Sectigo) and endorsed by Daniel 
Jeffery (Fastly) and Ben Wilson (Mozilla).

--- Motion Begins ---

This ballot modifies the “Baseline Requirements for the Issuance and Management 
of Publicly-Trusted Certificates" ("Baseline Requirements"), based on Version 
2.0.2.

MODIFY the Baseline Requirements as specified in the following Redline: 
https://github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031cd1bff3d4f35...d5bd141e14de098ff00c10de7cf500668cbc6843

--- Motion Ends ---

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

Discussion (at least 7 days)

  1.  Start time: 2024-02-26 07:00:00 UTC
  2.  End time: 2024-03-04 11:00:00 UTC

Vote for approval (7 days)

  1.  Start time: 2024-03-04 11:00:00 UTC
  2.  End time: 2024-03-11 11:00:00 UTC


___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Ponds-White, Trev via Servercert-wg]

Do we think that is already sufficiently taken care of by #5 (System crashes, 
hardware failures, and other anomalies;) on the security events list then? Or 
does it need to be specifically repeated for this item?

From: Tim Hollebeek 
Sent: Tuesday, February 6, 2024 10:08 AM
To: Ponds-White, Trev ; CA/B Forum Server Certificate WG 
Public Discussion List ; Christophe Bonjean 

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

There are a number of attack scenarios that cause network devices to 
crash/restart either as part of the attack, or as a consequence of the fallout 
from an attack.  So paying attention to if some of your network hardware and 
software crashes unexpectedly and/or becomes significantly less stable can be a 
useful signal.

That’s at least the historical reason for including this sort of monitoring, 
I’ll ask Bindi if it still makes sense to be watching for that sort of stuff 
today.

-Tim

From: Servercert-wg 
mailto:servercert-wg-boun...@cabforum.org>> 
On Behalf Of Ponds-White, Trev via Servercert-wg
Sent: Tuesday, February 6, 2024 12:59 PM
To: Christophe Bonjean 
mailto:christophe.bonj...@globalsign.com>>; 
CA/B Forum Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org>>
Subject: Re: [Servercert-wg] [Discussion Period Begins]: SC-69 Clarify router 
and firewall logging requirements

I had the same thought about firewall rules vs configuration changes being 
duplicative. I also agree about the dubious value of “hardware failures, 
software crashes, and system restarts”. I left it in since it was there but I 
was kind of struggling to figure out the purpose of some of that information. I 
assume its there for the purpose of understanding the impact and duration of an 
unexpected outage of your boundary protections? I don’t think that list really 
gets you that but it might be a piece of the picture for some, but not all, 
environments.

From: Christophe Bonjean 
mailto:christophe.bonj...@globalsign.com>>
Sent: Tuesday, February 6, 2024 5:39 AM
To: Ponds-White, Trev mailto:trevo...@amazon.com>>; CA/B 
Forum Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org>>
Subject: RE: [EXTERNAL] [Servercert-wg] [Discussion Period Begins]: SC-69 
Clarify router and firewall logging requirements

I agree with Trev’s perspective.

A few comments:

  *   Firewall rules are a separate item, but aren’t firewall rules covered by 
configuration changes? Should we merge it?
  *   What’s the purpose of “hardware failures, software crashes, and system 
restarts”? System restarts I could see how it’s relevant for audit logging 
purposes, but not sure what the additional value is of logging hardware 
failures and software crashes.

Christophe

From: Servercert-wg 
mailto:servercert-wg-boun...@cabforum.org>> 
On Behalf Of Ponds-White, Trev via Servercert-wg
Sent: Tuesday, February 6, 2024 3:08 AM
To: Martijn Katerbarg 
mailto:martijn.katerb...@sectigo.com>>; CA/B 
Forum Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org>>; Clint Wilson 
mailto:cli...@apple.com>>
Subject: Re: [Servercert-wg] [Discussion Period Begins]: SC-69 Clarify router 
and firewall logging requirements

I think “router and firewall activities” are solutions that don’t identify the 
problem we are trying to solve. Ultimately we want to know that the CA systems 
are segregated and protected. In this section we are specifying the required 
logs the CAs should have that allow them to monitor this and investigate if 
issues occur. I think it would be better to change this something like

“Network boundary controls (firewall, switch, router, gateway, or other network 
control device or system) activities. Relevant activities to log include 
configuration changes, firmware updates, and access control modifications. As 
well as system events and errors, including hardware failures, software 
crashes, and system restarts.”

This also better aligns with NetSec 1.f “Configure each network boundary 
control (firewall, switch, router, gateway, or other network control device or 
system) with rules that support only the services, protocols, ports, and 
communications that the CA has identified as necessary to its operations;”



From: Servercert-wg 
mailto:servercert-wg-boun...@cabforum.org>> 
On Behalf Of Martijn Katerbarg via Servercert-wg
Sent: Monday, February 5, 2024 12:52 PM
To: Clint Wilson mailto:cli...@apple.com>>; ServerCert CA/BF 
mailto:servercert-wg@cabforum.org>>
Subject: RE: [EXTERNAL] [Servercert-wg] [Discussion Period Begins]: SC-69 
Clarify router and firewall logging requirements


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


Hi Clint,

Thanks for the feedback!


  1

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

[Ponds-White, Trev via Servercert-wg]

I had the same thought about firewall rules vs configuration changes being 
duplicative. I also agree about the dubious value of “hardware failures, 
software crashes, and system restarts”. I left it in since it was there but I 
was kind of struggling to figure out the purpose of some of that information. I 
assume its there for the purpose of understanding the impact and duration of an 
unexpected outage of your boundary protections? I don’t think that list really 
gets you that but it might be a piece of the picture for some, but not all, 
environments.

From: Christophe Bonjean 
Sent: Tuesday, February 6, 2024 5:39 AM
To: Ponds-White, Trev ; CA/B Forum Server Certificate WG 
Public Discussion List 
Subject: RE: [EXTERNAL] [Servercert-wg] [Discussion Period Begins]: SC-69 
Clarify router and firewall logging requirements

I agree with Trev’s perspective.

A few comments:

  *   Firewall rules are a separate item, but aren’t firewall rules covered by 
configuration changes? Should we merge it?
  *   What’s the purpose of “hardware failures, software crashes, and system 
restarts”? System restarts I could see how it’s relevant for audit logging 
purposes, but not sure what the additional value is of logging hardware 
failures and software crashes.

Christophe

From: Servercert-wg 
mailto:servercert-wg-boun...@cabforum.org>> 
On Behalf Of Ponds-White, Trev via Servercert-wg
Sent: Tuesday, February 6, 2024 3:08 AM
To: Martijn Katerbarg 
mailto:martijn.katerb...@sectigo.com>>; CA/B 
Forum Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org>>; Clint Wilson 
mailto:cli...@apple.com>>
Subject: Re: [Servercert-wg] [Discussion Period Begins]: SC-69 Clarify router 
and firewall logging requirements

I think “router and firewall activities” are solutions that don’t identify the 
problem we are trying to solve. Ultimately we want to know that the CA systems 
are segregated and protected. In this section we are specifying the required 
logs the CAs should have that allow them to monitor this and investigate if 
issues occur. I think it would be better to change this something like

“Network boundary controls (firewall, switch, router, gateway, or other network 
control device or system) activities. Relevant activities to log include 
configuration changes, firmware updates, and access control modifications. As 
well as system events and errors, including hardware failures, software 
crashes, and system restarts.”

This also better aligns with NetSec 1.f “Configure each network boundary 
control (firewall, switch, router, gateway, or other network control device or 
system) with rules that support only the services, protocols, ports, and 
communications that the CA has identified as necessary to its operations;”



From: Servercert-wg 
mailto:servercert-wg-boun...@cabforum.org>> 
On Behalf Of Martijn Katerbarg via Servercert-wg
Sent: Monday, February 5, 2024 12:52 PM
To: Clint Wilson mailto:cli...@apple.com>>; ServerCert CA/BF 
mailto:servercert-wg@cabforum.org>>
Subject: RE: [EXTERNAL] [Servercert-wg] [Discussion Period Begins]: SC-69 
Clarify router and firewall logging requirements


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


Hi Clint,

Thanks for the feedback!


  1.  I’m not sure the wording "Router and firewall activities" is considered 
an unspecified term, and leaves the exact definition and scope up to the CA, 
however” is necessary or even really helpful. I think it would be clearer to 
introduce Section 5.4.1.1 with something like “Logging of router and firewall 
activities necessary to meet the requirements of Section 5.4.1, Subsection 3.6 
MUST at a minimum include:”
I’d agree, this makes sense to update.

 *   I’m not sold on the “Subsection” part, but I don’t recall if we have 
good semantics established for referencing the numbered paragraphs/sections 
under a Section heading.
This was more a design decision, since Section 5.4.1 is already a lengthy 
section with a lot of information. Personally I feel creating the subsection 
make it easier to follow through. I’m open to changing if more people feel this 
should be addressed.


  1.  I think the entire section including and under "Logging of router and 
firewall activities SHOULD NOT include:” should be removed.
Based on the reasoning provided, I agree that it doesn’t really add anything 
extra to the requirements.


  1.  The concluding sentence "CAs are encouraged to recommend additional MUST 
and SHOULD NOT requirements through an email to 
questi...@cabforum.org<mailto:questi...@cabforum.org>, for future discussion 
within the appropriate Working Group.” stands out as I think it’s the only such 
“encouragement” in the BRs. I don’t think that makes it bad or that it should 
be removed, but I’m also not sure how valuable it

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

[Ponds-White, Trev via Servercert-wg]

I think “router and firewall activities” are solutions that don’t identify the 
problem we are trying to solve. Ultimately we want to know that the CA systems 
are segregated and protected. In this section we are specifying the required 
logs the CAs should have that allow them to monitor this and investigate if 
issues occur. I think it would be better to change this something like

“Network boundary controls (firewall, switch, router, gateway, or other network 
control device or system) activities. Relevant activities to log include 
configuration changes, firmware updates, and access control modifications. As 
well as system events and errors, including hardware failures, software 
crashes, and system restarts.”

This also better aligns with NetSec 1.f “Configure each network boundary 
control (firewall, switch, router, gateway, or other network control device or 
system) with rules that support only the services, protocols, ports, and 
communications that the CA has identified as necessary to its operations;”



From: Servercert-wg  On Behalf Of Martijn 
Katerbarg via Servercert-wg
Sent: Monday, February 5, 2024 12:52 PM
To: Clint Wilson ; ServerCert CA/BF 

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


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


Hi Clint,

Thanks for the feedback!


  1.  I’m not sure the wording "Router and firewall activities" is considered 
an unspecified term, and leaves the exact definition and scope up to the CA, 
however” is necessary or even really helpful. I think it would be clearer to 
introduce Section 5.4.1.1 with something like “Logging of router and firewall 
activities necessary to meet the requirements of Section 5.4.1, Subsection 3.6 
MUST at a minimum include:”
I’d agree, this makes sense to update.

 *   I’m not sold on the “Subsection” part, but I don’t recall if we have 
good semantics established for referencing the numbered paragraphs/sections 
under a Section heading.
This was more a design decision, since Section 5.4.1 is already a lengthy 
section with a lot of information. Personally I feel creating the subsection 
make it easier to follow through. I’m open to changing if more people feel this 
should be addressed.


  1.  I think the entire section including and under "Logging of router and 
firewall activities SHOULD NOT include:” should be removed.
Based on the reasoning provided, I agree that it doesn’t really add anything 
extra to the requirements.


  1.  The concluding sentence "CAs are encouraged to recommend additional MUST 
and SHOULD NOT requirements through an email to 
questi...@cabforum.org, for future discussion 
within the appropriate Working Group.” stands out as I think it’s the only such 
“encouragement” in the BRs. I don’t think that makes it bad or that it should 
be removed, but I’m also not sure how valuable it is to the BRs as a policy. I 
admit that may be because I view this encouragement as fundamental to 
membership and participation in the CA/B Forum at all — every member, 
regardless of type, should feel welcome and encouraged to recommend changes to 
any of the CA/B Forum documents. But we don’t say that anywhere, so maybe this 
is a  good start?
I took this approach from the CSWG, which used it during the switch to 
hardware-based keys. I’m not sure it was ever utilized however.
If there’s strong opinions on removing this, I don’t have a problem with that.

I’ll leave the comments open for a bit, before I make the above changes, in 
case there is more feedback.

Regards,

Martijn

From: Clint Wilson mailto:cli...@apple.com>>
Date: Saturday, 3 February 2024 at 01:13
To: Martijn Katerbarg 
mailto:martijn.katerb...@sectigo.com>>, 
ServerCert CA/BF mailto:servercert-wg@cabforum.org>>
Subject: Re: [Servercert-wg] [Discussion Period Begins]: SC-69 Clarify router 
and firewall logging requirements
Hi Martijn,

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


  1.  I’m not sure the wording "Router and firewall activities" is considered 
an unspecified term, and leaves the exact definition and scope up to the CA, 
however” is necessary or even really helpful. I think it would be clearer to 
introduce Section 5.4.1.1 with something like “Logging of router and firewall 
activities necessary to meet the requirements of Section 5.4.1, Subsection 3.6 
MUST at a minimum include:”

 *   I’m not sold on the “Subsection” part, but I don’t recall if we have 
good semantics established for referencing the numbered paragraphs/sections 
under a Section heading.

  1.  I think the entire section including and under "Logging of router and 
firewall activities SHOULD NOT include:” should be removed.

 *   The first item listed seems overly broad (arguably, imo, even cover