[cabf_netsec] SC28 - improvements?

[Neil Dunbar]

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