Michael Bell wrote:
>
> Hi,
Hi,
> here is an idea how to support PIN-based revocation.
>
> We could identify the request (from which a certificate was generated)
> via the public key but of cause there are some problems:
>
> 1. the public keys of the certificates are not searchable
> 2. the public keys of the requests are not searchable
> 3. the public keys must not be unique
The public key is not required to be unique if you plan to be able
to renew a certificate (the new issued certificate has obviously
the same public key).
> The changes would affect:
> * OpenCA::REQ (find the public key of the request)
> * OpenCA::DB and OpenCA::DBI (two new searchable attributes)
> * issueCertificate (must check the public key)
> * spkac_confirm, ie_confirm, pkcs10_confirm (must check the public key)
> * appReq and confirmReq (must check the public key)
The checking for the public key could be used only when issuing a new
certificate (not from a renew request). This could be added but it would
require some changes. We could add the search for the public key into
the DB and adding the check into the request generation scripts: if
an existing key is received && it is not a renew request -> reject the
request.
> So I think it is relatively easy to fix the three problems. What do you
> think? The code for the PIN-based revocation itself is very easy because
I would use another code. This because the revokation of a certificate should
be traceable (It could be requested to know if the certificate was revoked
by an Operator/CA or on user's request). Because of this I would suggest
the following:
1. When the CA issues a certificate it generates a CRIN
(Certificate Revocation PIN) and generates a smime encrypted
e-mail using the newly issued certificate to encrypt it.
2. In the CA's dB it should be stored only the HASH of the
CRIN.
3. Exporting Certificates should also include exporting these
generated e-mails.
4. On the RAServer for each issued certificates two e-mails have
to be sent to the certificate's owner: one with all the infos
on where to get the certificate (as we do already) and the
other that was generated automatically on the CA when the
certificate was issued.
In this way the only person able to use this CRIN should be the certificate's
owner. A variant of this could be exporting the HASH of the CRIN into the
RAServer's DB so the RAOperator could check the request directly on the
RAServer and will not export "faked" pin based requests...
> we have only to compare some message digests and modify the code for the
> RAServer to handle signed CRRs and not signed CRRs (PIN-based).
I think that not signed CRRs by users should be signed by an RA Operator
(so that the CRIN has been verified before the request get to the CA).
This verification could also be done automatically when receiving the
request (either on signed or unsigned requests). If this is to be done
automatically to speed up revokation process, some points about managing
the request could be:
1. On Request Receiving check for a signature, if found check
if the signature/certificate is valid, if it is check if the
signer's certificate corresponds to the certificate requested
for revokation --> request is approved for exporting to the
CA (and will be listed on the approved CRRs);
2. If no signature is found -> check the CRIN reported -> check
the CRIN on the request (for the certificate reported in the
request) against the DB (using the hash function) -> if it
pass the check the request is approved for exporting to the
CA (and will be listed on the approved CRRs) otherwise it
will be rejected and (optionally) an e-mail could be sent to
the certificate user stating someone has tried to revoke
the certificate without success (this could be useful to
the user).
Let me know about it.
--
C'you,
Massimiliano Pala
--o-------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.openca.org Tel.: +39 (0)59 270 094
http://openca.sourceforge.net Mobile: +39 (0)347 7222 365
S/MIME Cryptographic Signature
