From ndunbar at trustcorsystems.com Mon Apr 12 13:15:09 2021 From: ndunbar at trustcorsystems.com (Neil Dunbar) Date: Mon, 12 Apr 2021 14:15:09 +0100 Subject: [cabf_netsec] Network Security Subcommittee Agenda for 2021-04-13 1100 PDT/1400 EDT/1900 BST/200 CEST Message-ID: All, This the agenda for Tuesday's meeting. If we want changes, mail them or bring them up in the meeting. Best, Neil Network Security Browser Forum Agenda *Time** * *Start (PDT)** * *Stop** * *Item** * *Description** * *Presenter** * 00:02 11:00 11:02 1 Review Agenda Neil 00:03 11:02 11:05 2 Agree Minutes Neil 00:05 11:05 11:10 3 Cloud Services Team Update David 00:10 11:10 11:20 4 Update to BR 4.1.1 Ballot Clint 00:10 11:20 11:30 5 Update to BR 5.4/5.4 Ballot Clint 00:10 11:30 11:40 6 Update to file monitoring ballot Neil 00:10 11:40 11:50 7 Update to vulnerability patching ballot Neil Adjourn -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndunbar at trustcorsystems.com Mon Apr 26 18:10:19 2021 From: ndunbar at trustcorsystems.com (Neil Dunbar) Date: Mon, 26 Apr 2021 19:10:19 +0100 Subject: [cabf_netsec] Minutes for NetSec Meeting 2021-03-30 Message-ID: All, Please find attached the (rather long) minutes for the 30th March meeting for consideration. If there are any corrections or observations, as always, do let me know. Thanks, Neil -------------- next part -------------- Network Security Subcommittee Minutes - 2020-03-30 Attendees Neil Dunbar [TrustCor] (Chair) Aaron Poulsen [DigiCert] Corey Bonnell [DigiCert] Corey Rasmussen [OATI] Bruce Morton [Entrust] Trevoli Ponds-White [Amazon] Ben Wilson [Mozilla] Clint Wilson [Apple] Tobias Josefowitz [Opera] Dustin Hollenback [Microsoft] Janet Hines [SecureTrust] Tim Crawford [BDO] 1. Review Agenda The Agenda was reviewed and agreed. Clint asked for a little time to cover some additional queries he had around definitions of OCSP Entries and IP addresses in logs. Neil added that time to Item 5 on the Agenda. 2. Agree Minutes The minutes from the previous meeting were approved. 3. Cloud Services Team Update David was absent from the attendees and there was no Cloud Services Team meeting scheduled, so there was no update. 4. SC40 Update Subsequent to an email to the list, Ben summarized that he had come up against a brick wall while trying to improve the language. He was unable to determine a good path forward to a version 4 of the ballot, so decided to let the ballot fail, and attempt to bring back an altered text which could address the issues covering the points raised on the list. Ben reported that the NCSSRs currently demand that the Root CA system be "offline" but no clear definition of "Root CA System" exists outside of an intuitive model. It was unclear if the HSM was the offline part, or even just partitions being deactivated, or whether the entire software stack of all components is included. If a proper definition of scope can be constructed perhaps it will become easier to address the points raised. Neil commented that for some HSMs, activation of partitions is the only method by which multi-person/party control can be maintained; therefore deactivation would be an essential component. Trev asked whether systems was included within the WebTrust language, brought up via GoDaddy, and that the language was overly broad. Ben replied that it was more the definition of "Certificate System" which was deemed overly broad. Ben continued that isolating down the definition of CA system to its bare essentials would be helpful. He asked if an HSM which was disconnected from anything, activated or not, would still be allowed, since no signing activity can be performed until other equipment is connected to the HSM. Neil said that might depend on the type of HSM - Network /USB/PCI. Neil added that it might indeed be useful to start from the bottom up. Ben replied that where a group of HSMs (referring to Wendy Brown's observation) were disconnected, this still would count as an offline system for the purposes of SC40; even if one was connected up for essential operations for a short time. Ben does not wish the text to languish indefinitely, but he does think that the 21 day limit is too tight for this sort of ballot. Neil agreed, saying that it was a large ballot and needed to be properly digested, and the list server unavailability for some days meant that the ballot could not have been discussed anyway. Ben said if anyone had definitions which would help, to get in touch with him. 5. Replacement ballots for SC38 sections Clint introduced some ballots which he had been working on to replace the abandoned SC38 ballot. These touch on logging and archiving; looking back on SC38, one of the problems was that in reviewing the BRs/NCSSRs/RFC 3467, there was no real alignment with real world expectations on how logging and archiving were supposed to happen; specifically around audit logs and retention and data archive and its retention - there is no clear link between the archive and the audit log material. Clint introduced three ballots, and desired feedback on direction and specifics. The first ballot simply removes BR Section 4.1.1 in its entirety. No matter what better requirements were substituted, the goal was the same: a fruitless endeavour with no clear gains. In particular, there is no clear premise on the meintenance database of suspicious activity which makes sense to the Apple Root Program. The second ballot replaces Section 4.1.1 with a requirement to maintain a database of known compromised key in perpetuity. While this might already be assumed as a duty on CAs, there is no clear requirement to maintain this database. The language is sufficiently general as not to demand a particular technology, but the intent is that the CAs must reject certificates which are known to be compromised. Neil asked if the language covered the case where a certificate is revoked for a reason which is _not_ key compromise; and later the CA discovers that the key has indeed become compromised. Since the CA cannot re-revoke the certificate, the key can be placed into the database; it also covers the case where private keys have been leaked. There is no requirement to monitor a specific source of compromised keys, the CA has a duty to add that to their database. Trev said that she was a fan of deleting 4.1.1; she asked if the compromised key database belongs in 4.1.1, or whether it belongs elsewhere. Clint replied that much of the text could go elsewhere, but that the requirement to reject a certificate does belong there. Trev also asked if the word database could be removed, since it defines a specific technology. Trev suggested "CAs should maintain a mechanism by which certificate requests will be rejected if their keys are known to have been compromised". Clint agreed, saying that the text needed to focus on what the CAs should be preventing, rather than how they should go about preventing it. Corey (Bonnell) mentioned that the ROCA vulnerability is more of an online check for vulnerability, rather than a defined table; and so suggested that the language encompass that model of operation, as well as a local discrete store. Clint agreed that the text should reflect that model too. Clint asked if there were any other places where the text should belong. Bruce suggested that 6.1.1.3 should be included, but that Section 4 should define the practice to detect weak keys. Clint added that he wanted it early on the process since CAs should be checking early on. Bruce asked that if a CA revokes a certificate due to key compromise, and that the CA knows about another certificate it has issued which shares the same key, that second certificate should be revoked too. Clint said that was a definite yes. Neil suggested some language and Clint thought he could adjust to fit. Clint introduced the third ballot, which consolidates and clarifies Sections 5.4 and 5.5 of the BRs in respect of types of events retained and retention periods. The new 5.4.1 (2) now includes the requirement to retain documentation for events. The second set of changes moves 5.4.3 (retention for audit logs) into 5.5.2 (Retention period for archives). The intent here is that long term retention is a function of archive, rather than audit log, which could be stored in, for example, Splunk for 30 days or 90. Clint stressed that this was down to his reading of RFC 3647, but other interpretations exist. Clint explained further that the need for documentation was because the previous 5.5.2 required the retention of documentation for certificate events; he believes that the majority of what was required covers much of documentation, but by explicitly including it, the full scope of what must be retained does not change. Finally, a statement in 5.5.1 was introduced, which states that audit log records must be retained per 5.5.2's retention period. Trev asked if an archive was a second copy of data; Clint replied that it was not defined as such, but it could be. Tim said that perhaps 5.5.1 could simply state that everything in 5.4.1 should be stored per 5.5.2, to make the type of data explicit to avoid the text mirroring. Trev said that it was unclear from the text if the expectation is that a CA has an archive for disaster recovery perspective, or rather if the CA can produce the logs. Clint replied that the current BRs imply the latter, because no backup requirement is defined. Trev suggested that then "archive" is synonymous with "store". Neil asked if 5.5.2 should state "The CA and each Delegated Third Party", in order to mirror the existing text from 5.4.1. Clint suggested that the DTP would be sending the logs back to the CA for storage. Neil said that would be fine, but wanted to avoid a "get out of jail free" scenario where a CA could simply say that a DTP with no duty to retain the logs was the sole storer of the relevant data. Trev suggested some text that spells out the duty that either the DTP or the CA should store the data; but the CA is solely responsible for the data being retained. Clint then introduced two more questions for the group to opine upon. The first question was the meaning of "OCSP Entries" as mentioned in 5.4.1 for Subscriber Lifecycle Certificate Management. What are CAs logging and retaining. Neil said that WebTrust imposes a duty to retain old CRLs, but not OCSP Entries. Clint then asked if an OCSP Entry is the signed OCSP response? Or is it the Entry in the database which marks the certificate as good or revoked. Trev asked why we would care about old OCSP entries. Clint stated that there is a reason to care that a CA reached a determination that a certificate needed to be revoked; but do we care if OCSP Entries are retained - Clint didn't know what an OCSP Entry _is_. Trev suggested we start from "what do we care about" and work backwards into stipulating what gets stored or mandated from that. Neil replied that one of the reasons that we might care is that a certificate does not get "un-revoked" per OCSP; a certificate should either expire or get revoked, but never revert to a "good" status. Neil suggested that the section might have been designed for CRLs, rather than OCSP; that his company logs the production of OCSP Entries in their batches and the success/failure thereof, but not each individual OCSP Response in a log entry. Bruce suggested that it might be to give the CA backup to prove that they had revoked a certificate. Trev said that one interpretation would be that we need to record OCSP generation so that evidence can be adduced regarding latency and availability of OCSP responses during the certificate life cycle. Trev noted that there is no requirement to record the _result_ of an OCSP response generation. Clint noted that such a requirement would be theoretically valuable, but such an effort would be huge. He added that he sees the value as being the act of moving a certificate from trustworthy to revoked is the key piece of information as to what to record. Clint asked the question as to whether this means that all OCSP response generations should be recorded, or merely the first one after a determination that a certificate should be revoked. The BRs do not contain the context to determine that unambiguously. Corey said that he could see the value of each response, because the log of the use of CA key material is valuable. Clint then asked if that meant the logging of the signing of a response, but not the actual response. Trev thought this was the case since its not about OCSP, but rather key usage. Clint thought this was a reasonable interpretation. Trev brought up Sections 4.9.9 and 4.9.10, which talks about revocation entries on a response not being removed until the certificate expires. She suggested that a similar duty obtains to OCSP. Neil suggested that with the logging of revocation, and logging of a response which states that an OCSP response containing that revocation is being generated, an upper bound on time to publish, and time to cache expiry (if using a CDN) can be deduced, meaning that the CA can establish that a relying party had all the information needed to calculate that a certificate should not be trusted. Clint asked if the text should reflect this intention. Trev thought yes, and Neil agreed. Trev suggested that the text be split out into the things we care about, and that section 5.4.1 specify the obligations of revocation latency from 4.9. Clint asked if this needed a separate ballot; Neil thought not - that the 5.4 and 5.5 ballot could contain this text. Clint then asked about IP addresses. Should audit logs record the IP addresses of each entity which accesses a CA service? Trev said that she had seen it defined as being recordable where the IP address can serve as a method to identify an accessing system. Clint asked if that then replaced the recording of the "person making the entry". Trev stated that the guidance she had was a unique identifier; so the IP address has no special status - it might be a unique identifier, or it might not, depending on situation. Clint agreed; it is not needed in itself. Trev argued that she did not like IP addresses, since they rarely serve as persistent unique identifiers. Neil agreed, saying that the meaning of 10.1.2.3 could mean anything, and the prevalence of NAT hardware meant that the its value as an identifier was excessively low. Clint asked if the text should clarify this interpretation; he thought not since it seemed like the interpretation of IP as a unique identifier was the dominant one. Neil replied that the drive should be "If I [a CA] have an IP address from an accessing system, and I have good reason to think it determines a persistent identity, I should record it", since what we really want to record is "Who did this thing"; and something like an RFC 1918 address does not serve that. Dustin did mention that a network could be strongly constrained to allocate IP addresses to individual hosts and their services. Neil agreed, adding that IPv6 could strongly bind to an individual or service; however, since IPv4 is still widespread, most IP addresses will be gross categorisations of devices making API calls, rather than specific and unique. Clint said that he was happy with the input. 6. Discussion on ballots for file monitoring Owing to the discussion above, this discussion was delayed until next meeting. Neil said that two discussion documents on draft ballots were in the Google Drive and members could look at them. This ballot is an attempt to mandate file system monitoring or read only file systems. 7. Discussion on ballots for vulnerability patching Owing to the discussion above, this discussion was delayed until next meeting. This ballot is intended to close up the leeway given in the NSRs, with exceptions for air-gapped systems. 8. Any Other Business There was no other business. 9. Adjourn The next meeting would occur on 2021-04-13. From ndunbar at trustcorsystems.com Mon Apr 26 18:15:14 2021 From: ndunbar at trustcorsystems.com (Neil Dunbar) Date: Mon, 26 Apr 2021 19:15:14 +0100 Subject: [cabf_netsec] Agenda for Network Security Subcommittee Meeting 2021-04-27 1100 PDT/1400 EDT/1900 BST/2000 CEST Message-ID: All, The agenda for discussion on Tuesday. I've allowed more time for Cloud Services as that draft requirements document is picking up steam, and some wider opinions on its shape are sought. Best, Neil Network Security Browser Forum Agenda *Time** * *Start (PDT)** * *Stop** * *Item** * *Description** * *Presenter** * 00:02 11:00 11:02 1 Review Agenda Neil 00:03 11:02 11:05 2 Agree Minutes Neil 00:10 11:05 11:15 3 Cloud Services Team Update David 00:05 11:15 11:20 4 Update to BR 4.1.1 Ballot Clint 00:10 11:20 11:30 5 Update to BR 5.4/5.5 Ballot Clint 00:05 11:30 11:35 6 Update to file monitoring ballot Neil 00:05 11:35 11:40 7 Update to vulnerability patching ballot Neil 00:05 11:40 11:45 8 Any Other Business Neil Adjourn -------------- next part -------------- An HTML attachment was scrubbed... URL: