Reasons for treating online CAs differently will be presented. We will proceed to discuss changes to min requirements for traditional CAs.
The class of short-lived certs includes both KCA issued certs and proxy certs.
The aim of Friday's discussion is to start progress, but not to make
all the decisions. Generate ideas for good ways
to run online services.
It may make sense to scope the discussion to EDG, LCG and CrossGrid.
For the rest of this year at least, we will use the PKI we have. Although other authentication mechanisms might be used.
Requirements should be released for EDG TB2/3 and LCG-1.
Change needed: allow offline or HSM of FIPS-140 level 3 or above.
Keeping the original key pair allows for continuity for encryption, etc. But it gives time to crack the key, or indeed the pass-phrase. But a user may chose the same pass-phrase for a new key pair.
Minimum would be to change the pass-phrase of the user, but there is no way for the CA to verify this.
Maybe it is up to the CA and we should make no recommendation. If using a cert for encryption, it should not be your authentication cert. Encryption cert may need to be escrowed, to avoid the chance of forgetting the pass-phrase, etc. Grid just uses certs for authentication. If this is the case then we can easily change private key, and that is good practice.
If the private key is typically not changed on renewal, then this private key may well get incorporated into procedures etc. Then when a private key change is really required, say there is a compromise, things will be very difficult.
The CP should specify a renewal policy. You should certainly not renew with the same pair for 10 years! So a limit should be specified.
It may make things difficult for the user if they have to back to the RA, or force the browser to regenerate keys, etc. However, ease of use requirements should not substantially diminish security.
Perhaps some of this should go into a Best Practices
document. Over time,
best practices may become minimum requirements.
Proposal: treat this as a best practice, but require an upper limit.
Certs should never be renewed beyond the end of the life of the CA! There could be a requirement that, say, a re-keying is required after 2 years.
Proposal: Re-keying stays as a requirement.
Some CA software does not have re-keying support!
DN must be unique as some software doesn't allow multiple certs with same DN, e.g., openssl, globus.
Best way to get around this is to set the previous cert as expired by editing the openssl configuration file. Then a new cert can be issued. This is just a workaround for openssl.
Requirement: DN is unique to the individual, and is reused for renewed certs.
Some people would like to have an RA in a VO to determine if the user is allowed to have the cert. Part of the reason for the renewal is to check that the person is still entitled to it.
If the cert is just binding a key to a random string, then there is no real information in it.
How do we get rid of people? The revocation does not revoke that the cert still refers to the same person. Need some way to revoke the users affiliation.
By revoking the cert he will have to reapply for a cert which allows a chance to update contact info.
It is the responsibility of the CA to check that they user has the affiliation they claim. Do we renew forever if the membership was accepted at the initial request?
Current practice in CESNET CA: Identity is checked based on old cert, but affiliation is checked by getting official documents from institution.
Must know this affiliation information for renewal especially since we do not have a direct connection with the institution.
Stay with 1-year certs for both users and hosts.
Have a separate CP for each CA that has a different policy. Since KCA doesn't meet current min requirements it should be split out as it is in a different class.
It might make sense to get separate OIDs for each practices. A paragraph could indicate that each OID refers to a particular practice/CA.
However, a single document with two classes of CA is in some sense contaminated as it is difficult to accept the whole document under current requirements.
If the online CA part
was separate, the traditional part
of the document
could be accepted easily.
Proposal: a requirement that each CA has its own CPS with its own OID. It doesn't matter if these are included in one document.
There are currently CP/CPSs covering multiple CAs.
*Proposal: *make this split a recommendation. Pragmatically it will be easier to handle as two documents.
The purpose of the CPS is to unambiguously define the practices of a given CA. If multiple CPSs are contained in one document it must be clearly noted what practice matches which OID.
If a CP covers separately CPSs then an update to the CP requires an update of CPSs version.
*Proposal: *Split Dane's CP/CPS into two documents: one for traditional CAs and one for new CA. One OID for each document.
Agreed
According to the existing min requirements user has given up control of private key.
Min Requirements says that the user must generate the private key and that the key
must be kept private and secure
. If the credential repository ensures
that the user maintains control of the key.
What about sysadmin? If the encryption key for the private key is outside the control of the sysadmin, then this isn't a problem.
Repository helps to enforce password hygiene, etc.
It could be more secure to generate the key elsewhere, on the credential store.
What we're trying to say is that the CA doesn't generate the private key. Suggest: Users or a credential repository acting on their behalf must generate the private key.
The MyProxy server is intended to store proxy certs, but some users are uploading their private keys! Is this a compromise?
If the key is generated by the credential repository the user isn't generating the key, just as when they generate key in their browser, etc.
Change i.e. the RA or CA must not generate the private key
to
The RA or CA must not generate the private key
.
If the encrypted key is stolen, is that compromise? If there is no check on the strength of the pass-phrase then yes!
If the private key is stored on NFS, then someone with root access can get the keys. This is a compromise for these keys. It may not be possible to tell if a connection is made for a short period.
What does the CPS say about conditions for reporting compromises? There could be a denial of service by reporting keys as compromised.
We need to review the revocation requirements. Who can ask for revocation? Anyone who can prove compromise. Certainly anyone who presents the unencrypted private key. Also, anyone who can show that the information in the cert is wrong.
"We require an acceptable revocation policy to be stated in the CP/CPS. Revocation can be accepted by the RA who approved the cert or the User, and the CA must accept the RAs request or proof of compromise."
When someone leaves an organisation, then the site could request revocation? Users should not pass a renewal if their affiliation changes.
CRLs essentially expire as soon as they're issued. OCSP support being added for DOE grid. CRLs must be issued 7 days before expiry, so the lifetime must be at least 7 days.
What happens with the DOE vaulted offline Root CA, should it have to provide
regular CRLs for something that rarely changes. Especially when there
will be an emergency
CRLs issued at any revocation.
Another class for CAs that don't store Root CA key on electronic storage.
So, on offline Root CAs that do not sign end entity certs, there is no requirement for regular CRLs. But there must be a CRL.
Perhaps a CRL should be issued every time the key is reassembled, and a minimum time between issue partly to prove that the key can still be reassembled.
Proposal: Maximum life of CRL for Root CAs six months.
Add to min requirements.
Some sites have services that run over whole clusters of machines. User certs should not be allowed to use wild-cards. However, on hosts the private keys are unencrypted so to limit risk they should not be spread.
Need other protections, such as limiting access to administrator.
It has been suggested that there is another class of cert required for automatic clients. This might be solved by a local CA, which means that they will not be widely trusted and this won't affect others.
This seems to be a future suggestion, not a current requirement. So this should not be added to the minimum requirements.
This might be useful for a host with several names. However, any host that matches could use the key.
An end-entity may have several certificates, with the same key-pair, so a revocation of one requires the revocation of another. This correlation would have to be recorded.
It would be sensible to automatically detect request with same public key. Presumably this is enough to determine reuse even without the private key.
Do we need a preamble to state the intentions. These are future suggestions and don't need any current requirements.