From jopurvis at cisco.com Wed Dec 2 16:34:43 2020 From: jopurvis at cisco.com (Jos Purvis (jopurvis)) Date: Wed, 2 Dec 2020 16:34:43 +0000 Subject: [cabf_netsec] Test message for SMTP delivery Message-ID: <5AEA57B9-691F-483B-8D94-003021754E9C@cisco.com> Please ignore. -- 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 ndunbar at trustcorsystems.com Fri Dec 4 16:37:02 2020 From: ndunbar at trustcorsystems.com (Neil Dunbar) Date: Fri, 4 Dec 2020 16:37:02 +0000 Subject: [cabf_netsec] **NEW TIME** Agenda for NetSec meeting - 2020-12-08 1100 PST/1400 EST/1900 UTC/2000 CET Message-ID: <7899e38e-dc06-a3ba-2fcf-3d28249f15a6@trustcorsystems.com> All, This is the agenda planned for next Tuesday's meeting. Any changes required, let me know. Thanks, Neil +------+-------+-------+------+--------------------------------+---------+ | Time | Start | Stop? | Item | Description|Presenter| +------+-------+-------+------+--------------------------------+---------+ | 0:02 | 17:00 | 17:02 |??? 1 | Review Agenda????????????????? |Neil???? | +------+-------+-------+------+--------------------------------+---------+ | 0:03 | 17:02 | 17:05 |??? 2 | Agree Minutes (x3)??? ? ? ? ?? |Neil???? | +------+-------+-------+------+--------------------------------+---------+ | 0:05 | 17:05 | 17:10 |??? 3 | Cloud Services Group Update??? |David??? | +------+-------+-------+------+--------------------------------+---------+ | 0:05 | 17:10 | 17:15 |??? 5 | Document Structuring SG Update |Ben????? | +------+-------+-------+------+--------------------------------+---------+ | 0:05 | 17:15 | 17:20 |??? 6 | SC38 Update |Neil???? | +------+-------+-------+------+--------------------------------+---------+ | 0:05 | 17:20 | 17:25 |??? 7 | SC39 Update |Neil???? | +------+-------+-------+------+--------------------------------+---------+ | 0:10 | 17:25 | 17:35 |?? 8 | Any Other Business???????????? |???????? | +------+-------+-------+------+--------------------------------+---------+ |????? |?????? | 17:35 |?? 9 | Adjourn??????????????????? ??? |???????? | +------+-------+-------+------+--------------------------------+---------+ From ndunbar at trustcorsystems.com Fri Dec 4 17:28:02 2020 From: ndunbar at trustcorsystems.com (Neil Dunbar) Date: Fri, 4 Dec 2020 17:28:02 +0000 Subject: [cabf_netsec] Meeting invitation for new time Message-ID: <2d92976c-48e2-533f-eb1b-9cb2417197e3@trustcorsystems.com> All, I sent out a meeting invitation to the netsec-management list (to which all of you should be subscribed), but so far the email has not appeared. It's possible this could be an artifact of the migration of mailing lists to the new structures, so I'm following this up with Jos to see if I've done something amiss, or if it's just a temporary glitch. Thanks, Neil From ndunbar at trustcorsystems.com Wed Dec 9 15:38:04 2020 From: ndunbar at trustcorsystems.com (Neil Dunbar) Date: Wed, 9 Dec 2020 15:38:04 +0000 Subject: [cabf_netsec] NetSec meeting minutes from 2020-12-08 Message-ID: All, I've attached the minutes from Tuesday, 2020-12-08's meeting. Please review and suggest any changes. Note that there will not be a meeting on 2020-12-22, since there is no CA/B Forum meeting that week: we'll reconvene in early January. Cheers, Neil -------------- next part -------------- Network Security Subcommittee Meeting 2020-12-08 Attendees Neil Dunbar (TrustCor) [Chair] Ben Wilson (Mozilla) Cezary Cerekwicki (Opera) Mariusz Kondratowicz (Opera) David Kluge (Google) Tim Hollebeek (DigiCert) Corey Bonnell (DigiCert) Core Rasmussen (OATI) Aaron Poulsen (DigiCert) 1. Review Agenda The agenda was approved. 2. Agree Minutes The minutes from the previous three meetings were approved. 3. Cloud Services Group Update David reported that the group had met on the Monday (2020-12-07) and said that they had continued to work on the slide deck for the various service components that CAs could (or already do) use Cloud Services to sustain their business offerings. Considerable progress has been made on the risks analysis for the validation store and certificate database. The plan for the next call is to continue this work, so that it can be finished in January 2021. An ongoing piece of work is an attempt to map the existing NCSSRs against known Cloud standards documents, similar to what was done in Document Structuring. The output of that excercise will be used once the service components work is complete; and this mapping can be used to cross reference any new cloud service rules work against the NCSSRs. Ben commented that he was pleased to see the slide deck was progressing, allowing a better breakdown of what the CAs are doing or planning within the cloud space, and to measure the risks and evaluate controls from those actions or plans. Neil also said he liked the service component description; taking the example of OCSP responders, acknowledging that CAs are doing this already, but now overlaying consideration of risk measurement onto that activity. 5. Document Structuring SG Update The DSG is temporarily paused until January, but Ben asked for some time to discuss the Offline CAs ballot, the summary of which is under "Any Other Business". 6. SC38 Update Neil reported that, having circulated the draft ballot around the SCWG and got no major feedback, he would begin the discussion phase on 2020-12-09. 7. SC39 Update Neil reported that the ballot was ready to go if a second endorser could be found. Ben offered to endorse, so Neil said that he would begin the discussion phase tomorrow. Neil thought that this ballot would be uncontroversial, since it is just correcting a definition, rather than proposing new rules or modifying any practices. 8. Any Other Business Neil mentioned that as Mariusz would be leaving Opera, he would transition away from his role as lead of the Threat Modelling Group. Mariusz commented that, although he was leaving Opera, his intention was to remain within the CA/B Forum as an Interested Party, and as such would rejoin the NetSec group. Cezary Cerekwicki will take Mariusz's place as one of Opera's representatives. Ben began a discussion based on Wayne (Thayer)'s feedback on the Offline CAs ballot proposal. The team went through each of the notes submitted and suggested alternative text for each point, which Ben would then consider amending the ballot proposal. The central points were: - removal of the word "static" in "static configuration" - maintain an annual review of configuration - adjust the text of "Trusted Roles *who* are authorized" to "which are authorized" in order to remove ambuguity - removal of "separation of duties" with regard to Trusted Roles ( in order to establish that the point of the roles is to provide multi-person control; which might provide separation of duties or it might not) - make clear that access control lists review only applies to to physical systems and to avoid overly detailed requirements in that sector [David brought up the example of a PIN coded safe, which has logged access; actually validating the PIN code should not be needed, or even desired, if the logs show no ingress or egress to that secured environment] 9. Adjourn The meeting was adjourned. The consensus was that, as the late December CA/B Forum meeting has been postponed until January, NetSec will do the same. The group will reconvene on 2020-01-05. From ndunbar at trustcorsystems.com Wed Dec 16 12:26:43 2020 From: ndunbar at trustcorsystems.com (Neil Dunbar) Date: Wed, 16 Dec 2020 12:26:43 +0000 Subject: [cabf_netsec] SC28 - improvements? Message-ID: <7821f90b-a18e-cc38-7464-3c507159f6bc@trustcorsystems.com> All, As Ryan properly captured during the last SCWG meeting, the "simple" reduction of 7 -> 2 years for section 5.5.2 actually does have some potential interplay with other sections. Specifically, sections 1.3.2 (which deals with Delegated Third Parties) and section 4.1.1 (dealing with who can apply for a certificate). My take is this: an _archive_ is not a live database, and any attempt to force it to have such characteristics is simply an abuse of the term. An _audit log_ (to my mind) is something which a CA should be able to access on a near instant basis to determine what event or set of events have happened in the recent-ish past. An _archive_ is something which is retained to perform deep dive investigation to determine systemic issues which might be affecting the CA. So my suggestion is to call out exactly what is being required to be stored and impose retention timelines based on that specific data, rather than use 5.5.2 as a "catch all". 1.3.2 - Registration Authorities 1.3.2 simply says that before any CA allows an DTP to act on its behalf, it must (amongst other things) retain records per section 5.5.2. There is an argument to say that 2-3 years worth of issuance records isn't really enough to make a solid judgment about whether an DTP is up to the job. But, rather than referencing 5.5.2, it might be worth explicitly stating in 1.3.2(2) that an external DTP should retain issuance/authentication/validation/revocation records for longer than the {certificate life}+2 years. It's quite possible that an DTP operating entity is performing this function on behalf of more than one CA, so the consequences of misbehaviour by that RA contaminate more than the heirarchies operated by a single CA. If I were wanting an RA to act on my behalf, I think that only having a 2 year record retention policy would give me pause. In other words, an RA has a higher duty of retention than a CA, because it operates at "arms length" from the CA. Suggested text: "1.3.2 Registration Authorities ?... ? 2. Retain all documentation pertaining to certificate requests, verification of certificate requests, issuance of Certificates and revocation of Certificates. If a certificate request does not result in the issuance of a Certificate, the request related documentation shall be retained for at least seven years. If a request results in the issuance of a Certificate, the documentation shall be retained for at least seven years after the Certificate ceases to be valid." 4.1.1 - Who can submit a certificate application For 4.1.1, the position of 5.5.2 is even shakier, IMO. Currently it imposes a duty on CAs to maintain a database of certificates revoked, and certificate requests denied, on the basis of phishing or other fraud related activities. A _database_ is quite clearly a live, queriable object. An archive is simply a dump of documents, whether structured or not. [Note: It's not at all clear if all CAs actually _do_ operate a database for the purpose of identification of suspicious certificate requests - certainly many CPS documents make no reference to it in 4.1.1. In particular, Let's Encrypt in https://letsencrypt.org/2015/10/29/phishing-and-malware.html state that they no longer attempt to scan for phishing, so it's not clear if they store such data] It's also important to note that no duty is imposed on a CA to block entities who have been identified as suspicious. In other words, you must attempt to identify whether a certificate request is dodgy, but you don't actually need to do anything about it! Would this not make more sense to explicitly require a timescale in 4.1.1? Something like: "The CA SHALL maintain an internal database of all previously revoked Certificates and previously rejected certificate requests, where the revocation or rejection was caused by suspected phishing or other fraudulent usage or concerns. The CA SHALL use this information to identify subsequent suspicious certificate requests. This information shall be retained for a minimum of seven years after the revocation of Certificates stored within, or seven years after the request was rejected" The reason is this: this is probably a small set of data to be maintained; it also seems clear to me that storing certificate requests and certificates is pretty useless without the customer information which goes with it. But record archival in general is a huge chunk of data. So extending the retention needs for all data just for the sake of that small data set of rejected requests seems silly. I would like to impose an actual duty to _use_ this information, but that's going beyond the purpose of SC28. What those changes would do is break the link from 1.3.2 and 4.1.1 to 5.5.2, which I don't believe to be well founded. 5.5.2 imposes a duty on _the CA_, but 1.3.2 imposes a duty on the CA to validate the record keeping of the RA. 4.1.1 creates the need for a database and links to 5.5.2 to say how long that data should be retained, but 5.5.2 is about how long data should be archived, rather than maintained in a queriable form. If that link were broken, the archive retention time could be brought down to 2 years after certificate validity as per the original text. I'd really welcome team thoughts here. Neil From tcrawford at bdo.com Thu Dec 17 17:38:24 2020 From: tcrawford at bdo.com (Tim Crawford) Date: Thu, 17 Dec 2020 17:38:24 +0000 Subject: [cabf_netsec] Netsec Digest, Vol 41, Issue 4 In-Reply-To: <01000176709246ba-f267e43d-d2a3-458b-bca4-bfb195e5ca8b-000000@email.amazonses.com> References: <01000176709246ba-f267e43d-d2a3-458b-bca4-bfb195e5ca8b-000000@email.amazonses.com> Message-ID: Neil and all, I appreciate an external RA serving multiple CAs creates a different risk profile than a CA's internal RA services. It is important to point out external RA would only be performing the validation activity to elevate the certificate from a DV to OV or EV, because the CA must still perform the DV work. I feel this changes the risk profile a bit. I would also note the discussion below seems to indicate the external RA would use 2, 3, or 7 years of activity to evaluate the RA's capabilities. The requirement is the RA would be contractually required to retain data going forward, but does not speak to having a history for initial assessment by a CA. Either way, I have no issue with the suggested change to 1.3.2. These types of situations seem to be becoming rare. I do have a concern with the changes to 4.1.1. It would be easier on include all retention requirement in section 5.4.3. A separate section it is likely to get overlooked. I would recommend listing rejected certificate requests as a separate line item in 5.4.1 and define the longer retention requirement in 5.4.3. Thank you, Tim -----Original Message----- From: Netsec On Behalf Of netsec-request at cabforum.org Sent: Thursday, December 17, 2020 6:00 AM To: netsec at cabforum.org Subject: Netsec Digest, Vol 41, Issue 4 Attention: This email was sent from someone outside of BDO USA. Always use caution when opening attachments or clicking links from unknown senders or when receiving unexpected emails. Send Netsec mailing list submissions to netsec at cabforum.org To subscribe or unsubscribe via the World Wide Web, visit https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fnetsec&data=04%7C01%7Ctcrawford%40bdo.com%7Cf6b410b3710342b22e3608d8a2834a44%7C6e57fc1a413e405091da7d2dc8543e3c%7C0%7C0%7C637438032080910333%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9tGZnMxBsc%2BM7oUrZQTWKmS7Aa13zFoNuD93JKMGOGU%3D&reserved=0 or, via email, send a message with subject or body 'help' to netsec-request at cabforum.org You can reach the person managing the list at netsec-owner at cabforum.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Netsec digest..." Today's Topics: 1. SC28 - improvements? (Neil Dunbar) ---------------------------------------------------------------------- Message: 1 Date: Wed, 16 Dec 2020 12:26:43 +0000 From: Neil Dunbar To: CABF Network Security List Subject: [cabf_netsec] SC28 - improvements? Message-ID: <7821f90b-a18e-cc38-7464-3c507159f6bc at trustcorsystems.com> Content-Type: text/plain; charset=utf-8; format=flowed All, As Ryan properly captured during the last SCWG meeting, the "simple" reduction of 7 -> 2 years for section 5.5.2 actually does have some potential interplay with other sections. Specifically, sections 1.3.2 (which deals with Delegated Third Parties) and section 4.1.1 (dealing with who can apply for a certificate). My take is this: an _archive_ is not a live database, and any attempt to force it to have such characteristics is simply an abuse of the term. An _audit log_ (to my mind) is something which a CA should be able to access on a near instant basis to determine what event or set of events have happened in the recent-ish past. An _archive_ is something which is retained to perform deep dive investigation to determine systemic issues which might be affecting the CA. So my suggestion is to call out exactly what is being required to be stored and impose retention timelines based on that specific data, rather than use 5.5.2 as a "catch all". 1.3.2 - Registration Authorities 1.3.2 simply says that before any CA allows an DTP to act on its behalf, it must (amongst other things) retain records per section 5.5.2. There is an argument to say that 2-3 years worth of issuance records isn't really enough to make a solid judgment about whether an DTP is up to the job. But, rather than referencing 5.5.2, it might be worth explicitly stating in 1.3.2(2) that an external DTP should retain issuance/authentication/validation/revocation records for longer than the {certificate life}+2 years. It's quite possible that an DTP operating entity is performing this function on behalf of more than one CA, so the consequences of misbehaviour by that RA contaminate more than the heirarchies operated by a single CA. If I were wanting an RA to act on my behalf, I think that only having a 2 year record retention policy would give me pause. In other words, an RA has a higher duty of retention than a CA, because it operates at "arms length" from the CA. Suggested text: "1.3.2 Registration Authorities ?... ? 2. Retain all documentation pertaining to certificate requests, verification of certificate requests, issuance of Certificates and revocation of Certificates. If a certificate request does not result in the issuance of a Certificate, the request related documentation shall be retained for at least seven years. If a request results in the issuance of a Certificate, the documentation shall be retained for at least seven years after the Certificate ceases to be valid." 4.1.1 - Who can submit a certificate application For 4.1.1, the position of 5.5.2 is even shakier, IMO. Currently it imposes a duty on CAs to maintain a database of certificates revoked, and certificate requests denied, on the basis of phishing or other fraud related activities. A _database_ is quite clearly a live, queriable object. An archive is simply a dump of documents, whether structured or not. [Note: It's not at all clear if all CAs actually _do_ operate a database for the purpose of identification of suspicious certificate requests - certainly many CPS documents make no reference to it in 4.1.1. In particular, Let's Encrypt in https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fletsencrypt.org%2F2015%2F10%2F29%2Fphishing-and-malware.html&data=04%7C01%7Ctcrawford%40bdo.com%7Cf6b410b3710342b22e3608d8a2834a44%7C6e57fc1a413e405091da7d2dc8543e3c%7C0%7C0%7C637438032080910333%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2Bdn1kusK8i1HIImS0phwyZ1FnDfyX79xvzg1tjzfbOg%3D&reserved=0 state that they no longer attempt to scan for phishing, so it's not clear if they store such data] It's also important to note that no duty is imposed on a CA to block entities who have been identified as suspicious. In other words, you must attempt to identify whether a certificate request is dodgy, but you don't actually need to do anything about it! Would this not make more sense to explicitly require a timescale in 4.1.1? Something like: "The CA SHALL maintain an internal database of all previously revoked Certificates and previously rejected certificate requests, where the revocation or rejection was caused by suspected phishing or other fraudulent usage or concerns. The CA SHALL use this information to identify subsequent suspicious certificate requests. This information shall be retained for a minimum of seven years after the revocation of Certificates stored within, or seven years after the request was rejected" The reason is this: this is probably a small set of data to be maintained; it also seems clear to me that storing certificate requests and certificates is pretty useless without the customer information which goes with it. But record archival in general is a huge chunk of data. So extending the retention needs for all data just for the sake of that small data set of rejected requests seems silly. I would like to impose an actual duty to _use_ this information, but that's going beyond the purpose of SC28. What those changes would do is break the link from 1.3.2 and 4.1.1 to 5.5.2, which I don't believe to be well founded. 5.5.2 imposes a duty on _the CA_, but 1.3.2 imposes a duty on the CA to validate the record keeping of the RA. 4.1.1 creates the need for a database and links to 5.5.2 to say how long that data should be retained, but 5.5.2 is about how long data should be archived, rather than maintained in a queriable form. If that link were broken, the archive retention time could be brought down to 2 years after certificate validity as per the original text. I'd really welcome team thoughts here. Neil ------------------------------ Subject: Digest Footer _______________________________________________ Netsec mailing list Netsec at cabforum.org https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fnetsec&data=04%7C01%7Ctcrawford%40bdo.com%7Cf6b410b3710342b22e3608d8a2834a44%7C6e57fc1a413e405091da7d2dc8543e3c%7C0%7C0%7C637438032080920327%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0vjpayf01rgn6TrnKmFw6fAxdC8kOFw7mUafUa4%2FgVg%3D&reserved=0 ------------------------------ End of Netsec Digest, Vol 41, Issue 4 ************************************* The health and safety of our people and communities is our top priority, as we all do our part to help stop the spread of COVID-19. All BDO USA offices will be closed until further notice. While we will be working from home, our already-flexible work environment enables us to make this transition seamlessly and we have the technology in place to continue to provide the same excellent level of service our clients are accustomed to. We are here if you need us, just as before, and if we can be helpful as you navigate the uncertainty, we stand ready. BDO USA, LLP, a Delaware limited liability partnership, is the U.S. member of BDO International Limited, a UK company limited by guarantee, and forms part of the international BDO network of independent member firms. BDO is the brand name for the BDO network and for each of the BDO Member Firms. IMPORTANT NOTICES The contents of this email and any attachments to it may contain privileged and confidential information from BDO USA, LLP. This information is only for the viewing or use of the intended recipient. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of, or the taking of any action in reliance upon, the information contained in this e-mail, or any of the attachments to this e-mail, is strictly prohibited and that this e-mail and all of the attachments to this e-mail, if any, must be immediately returned to BDO USA, LLP or destroyed and, in either case, this e-mail and all attachments to this e-mail must be immediately deleted from your computer without making any copies hereof. If you have received this e-mail in error, please notify BDO USA, LLP by e-mail immediately. From ndunbar at trustcorsystems.com Fri Dec 18 09:33:54 2020 From: ndunbar at trustcorsystems.com (Neil Dunbar) Date: Fri, 18 Dec 2020 09:33:54 +0000 Subject: [cabf_netsec] SC28 improvements (was: Netsec Digest, Vol 41, Issue 4) In-Reply-To: <0100017671c81d41-c3573bf0-2269-4334-b7b2-d7c68bd7b14d-000000@email.amazonses.com> References: <01000176709246ba-f267e43d-d2a3-458b-bca4-bfb195e5ca8b-000000@email.amazonses.com> <0100017671c81d41-c3573bf0-2269-4334-b7b2-d7c68bd7b14d-000000@email.amazonses.com> Message-ID: <4967778c-6469-8404-86e0-79142d7f9095@trustcorsystems.com> Re: rarity of external OV/EV RAs - yes, I tend to agree. It seems to me that the text of 5.5.2 explicitly lays a duty on the *CA*to retain rejected certs/request info for 7 years; but 1.3.2 extends that implicitly to cover the RA. Note: implicitly - it simply says that the contract between CA and RA will require documentation in accordance with 5.5.2. But the RA could say that 5.5.2 binds the CA, not the RA at all. Perverse, of course, but the current text is actually pretty poorly expressed. Either way, I think that simply requiring the RA to retain documentation for longer seems a decent compromise. So perhaps the answer would be to have 5.4.1 have a special section (4) which lists as "information to record" 1. All Certificates which were revoked as a result of suspected phishing or other fraudulent usage or concerns 2. All certificate requests which were rejected as a result of suspected phishing or other fraudulent usage or concerns Then 5.4.3 would be extended to say * Any suspicious events (as set forth in Section 5.4.1(4)) after the event occurred. Meaning that the CA (but not an RA because of the reworking of 1.3.2) can discard the suspicious flagged information after 2 years, like the other information. If there is true value in retaining that for longer, then 5.4.3 can be extended to particularize 5.4.1(4) for a longer retention time. Section 4.1.1 could then be amended to say In accordance with Sections 5.4.1(4) and 5.4.3, the CA SHALL maintain an internal database of all previously revoked Certificates and previously rejected certificate requests due to suspected phishing or other fraudulent usage or concerns. The CA SHALL use this information to identify subsequent suspicious certificate requests. And then we could simply get rid of 5.5.2 completely, since nothing would refer to it, and its provisions would be entirely subsumed in 1.3.2, 4.1.1, 5.4.1 and 5.4.3. Would this make things cleaner? Neil On 17/12/2020 17:38, Tim Crawford via Netsec wrote: > Neil and all, > > I appreciate an external RA serving multiple CAs creates a different risk profile than a CA's internal RA services. It is important to point out external RA would only be performing the validation activity to elevate the certificate from a DV to OV or EV, because the CA must still perform the DV work. I feel this changes the risk profile a bit. I would also note the discussion below seems to indicate the external RA would use 2, 3, or 7 years of activity to evaluate the RA's capabilities. The requirement is the RA would be contractually required to retain data going forward, but does not speak to having a history for initial assessment by a CA. Either way, I have no issue with the suggested change to 1.3.2. These types of situations seem to be becoming rare. > > I do have a concern with the changes to 4.1.1. It would be easier on include all retention requirement in section 5.4.3. A separate section it is likely to get overlooked. I would recommend listing rejected certificate requests as a separate line item in 5.4.1 and define the longer retention requirement in 5.4.3. > > Thank you, > Tim > > > -----Original Message----- > From: Netsec On Behalf Of netsec-request at cabforum.org > Sent: Thursday, December 17, 2020 6:00 AM > To: netsec at cabforum.org > Subject: Netsec Digest, Vol 41, Issue 4 > > Attention: This email was sent from someone outside of BDO USA. Always use caution when opening attachments or clicking links from unknown senders or when receiving unexpected emails. > > Send Netsec mailing list submissions to > netsec at cabforum.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fnetsec&data=04%7C01%7Ctcrawford%40bdo.com%7Cf6b410b3710342b22e3608d8a2834a44%7C6e57fc1a413e405091da7d2dc8543e3c%7C0%7C0%7C637438032080910333%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9tGZnMxBsc%2BM7oUrZQTWKmS7Aa13zFoNuD93JKMGOGU%3D&reserved=0 > or, via email, send a message with subject or body 'help' to > netsec-request at cabforum.org > > You can reach the person managing the list at > netsec-owner at cabforum.org > > When replying, please edit your Subject line so it is more specific than "Re: Contents of Netsec digest..." > > > Today's Topics: > > 1. SC28 - improvements? (Neil Dunbar) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 16 Dec 2020 12:26:43 +0000 > From: Neil Dunbar > To: CABF Network Security List > Subject: [cabf_netsec] SC28 - improvements? > Message-ID: <7821f90b-a18e-cc38-7464-3c507159f6bc at trustcorsystems.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > All, > > As Ryan properly captured during the last SCWG meeting, the "simple" > reduction of 7 -> 2 years for section 5.5.2 actually does have some potential interplay with other sections. > > Specifically, sections 1.3.2 (which deals with Delegated Third Parties) and section 4.1.1 (dealing with who can apply for a certificate). > > My take is this: an _archive_ is not a live database, and any attempt to force it to have such characteristics is simply an abuse of the term. An _audit log_ (to my mind) is something which a CA should be able to access on a near instant basis to determine what event or set of events have happened in the recent-ish past. An _archive_ is something which is retained to perform deep dive investigation to determine systemic issues which might be affecting the CA. > > So my suggestion is to call out exactly what is being required to be stored and impose retention timelines based on that specific data, rather than use 5.5.2 as a "catch all". > > 1.3.2 - Registration Authorities > > 1.3.2 simply says that before any CA allows an DTP to act on its behalf, it must (amongst other things) retain records per section 5.5.2. There is an argument to say that 2-3 years worth of issuance records isn't really enough to make a solid judgment about whether an DTP is up to the job. But, rather than referencing 5.5.2, it might be worth explicitly stating in 1.3.2(2) that an external DTP should retain issuance/authentication/validation/revocation records for longer than the {certificate life}+2 years. It's quite possible that an DTP operating entity is performing this function on behalf of more than one CA, so the consequences of misbehaviour by that RA contaminate more than the heirarchies operated by a single CA. If I were wanting an RA to act on my behalf, I think that only having a 2 year record retention policy would give me pause. In other words, an RA has a higher duty of retention than a CA, because it operates at "arms length" from the CA. > > Suggested text: > > "1.3.2 Registration Authorities > > ?... > > ? 2. Retain all documentation pertaining to certificate requests, verification of certificate requests, issuance of Certificates and revocation of Certificates. If a certificate request does not result in the issuance of a Certificate, the request related documentation shall be retained for at least seven years. If a request results in the issuance of a Certificate, the documentation shall be retained for at least seven years after the Certificate ceases to be valid." > > 4.1.1 - Who can submit a certificate application > > For 4.1.1, the position of 5.5.2 is even shakier, IMO. Currently it imposes a duty on CAs to maintain a database of certificates revoked, and certificate requests denied, on the basis of phishing or other fraud related activities. A _database_ is quite clearly a live, queriable object. An archive is simply a dump of documents, whether structured or not. > > [Note: It's not at all clear if all CAs actually _do_ operate a database for the purpose of identification of suspicious certificate requests - certainly many CPS documents make no reference to it in 4.1.1. In particular, Let's Encrypt in > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fletsencrypt.org%2F2015%2F10%2F29%2Fphishing-and-malware.html&data=04%7C01%7Ctcrawford%40bdo.com%7Cf6b410b3710342b22e3608d8a2834a44%7C6e57fc1a413e405091da7d2dc8543e3c%7C0%7C0%7C637438032080910333%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2Bdn1kusK8i1HIImS0phwyZ1FnDfyX79xvzg1tjzfbOg%3D&reserved=0 state that they no longer attempt to scan for phishing, so it's not clear if they store such data] > > It's also important to note that no duty is imposed on a CA to block entities who have been identified as suspicious. In other words, you must attempt to identify whether a certificate request is dodgy, but you don't actually need to do anything about it! > > Would this not make more sense to explicitly require a timescale in 4.1.1? Something like: > > "The CA SHALL maintain an internal database of all previously revoked Certificates and previously rejected certificate requests, where the revocation or rejection was caused by suspected phishing or other fraudulent usage or concerns. The CA SHALL use this information to identify subsequent suspicious certificate requests. This information shall be retained for a minimum of seven years after the revocation of Certificates stored within, or seven years after the request was rejected" > > The reason is this: this is probably a small set of data to be maintained; it also seems clear to me that storing certificate requests and certificates is pretty useless without the customer information which goes with it. But record archival in general is a huge chunk of data. So extending the retention needs for all data just for the sake of that small data set of rejected requests seems silly. > > I would like to impose an actual duty to _use_ this information, but that's going beyond the purpose of SC28. > > What those changes would do is break the link from 1.3.2 and 4.1.1 to 5.5.2, which I don't believe to be well founded. 5.5.2 imposes a duty on _the CA_, but 1.3.2 imposes a duty on the CA to validate the record keeping of the RA. 4.1.1 creates the need for a database and links to > 5.5.2 to say how long that data should be retained, but 5.5.2 is about how long data should be archived, rather than maintained in a queriable form. > > If that link were broken, the archive retention time could be brought down to 2 years after certificate validity as per the original text. > > I'd really welcome team thoughts here. > > Neil > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Netsec mailing list > Netsec at cabforum.org > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fnetsec&data=04%7C01%7Ctcrawford%40bdo.com%7Cf6b410b3710342b22e3608d8a2834a44%7C6e57fc1a413e405091da7d2dc8543e3c%7C0%7C0%7C637438032080920327%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0vjpayf01rgn6TrnKmFw6fAxdC8kOFw7mUafUa4%2FgVg%3D&reserved=0 > > > ------------------------------ > > End of Netsec Digest, Vol 41, Issue 4 > ************************************* > > > The health and safety of our people and communities is our top priority, as we all do our part to help stop the spread of COVID-19. All BDO USA offices will be closed until further notice. While we will be working from home, our already-flexible work environment enables us to make this transition seamlessly and we have the technology in place to continue to provide the same excellent level of service our clients are accustomed to. We are here if you need us, just as before, and if we can be helpful as you navigate the uncertainty, we stand ready. > > BDO USA, LLP, a Delaware limited liability partnership, is the U.S. member of BDO International Limited, a UK company limited by guarantee, and forms part of the international BDO network of independent member firms. > > BDO is the brand name for the BDO network and for each of the BDO Member Firms. > > IMPORTANT NOTICES > > The contents of this email and any attachments to it may contain privileged and confidential information from BDO USA, LLP. This information is only for the viewing or use of the intended recipient. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of, or the taking of any action in reliance upon, the information contained in this e-mail, or any of the attachments to this e-mail, is strictly prohibited and that this e-mail and all of the attachments to this e-mail, if any, must be immediately returned to BDO USA, LLP or destroyed and, in either case, this e-mail and all attachments to this e-mail must be immediately deleted from your computer without making any copies hereof. If you have received this e-mail in error, please notify BDO USA, LLP by e-mail immediately. > > _______________________________________________ > Netsec mailing list > Netsec at cabforum.org > https://lists.cabforum.org/mailman/listinfo/netsec -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndunbar at trustcorsystems.com Mon Dec 21 18:26:52 2020 From: ndunbar at trustcorsystems.com (Neil Dunbar) Date: Mon, 21 Dec 2020 18:26:52 +0000 Subject: [cabf_netsec] Reminder: No NetSec meeting 2020-12-22 Message-ID: <20110d1b-0a52-2584-9258-90a68d41cfe6@trustcorsystems.com> All, Just a reminder: the NetSec meeting this week (Tuesday, 22nd December 2020) is cancelled for the holidays. We'll reconvene on January 5th, 2020. Enjoy the holiday season, all - see you back in the New Year. Cheers, Neil