[cabf_netsec] SC28 improvements (was: Netsec Digest, Vol 41, Issue 4)

[Neil Dunbar]

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 <netsec-bounces at cabforum.org> 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 <ndunbar at trustcorsystems.com>
> To: CABF Network Security List <netsec at cabforum.org>
> 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: <http://lists.cabforum.org/pipermail/netsec/attachments/20201218/07c785ab/attachment-0001.html>