Mr. Muftic:
Your message about certificate management seems to include several
assumptions which are not completely in line with the PEM design.
Thank you for your comments concerning our implementation of
COST-PEM and in particular CRLs. After studying them and
PEM RFCs carefully, we still believe that our COST-PEM
system is WORKABLE and COMPLIANT with PEM RFCs, although we
still believe that in order to perform certificate
validation the user does not need CRLs for each and every CA
in the partner's certification path.
Section 3.6.3 of RFC 1422 clearly states the need to check all
certificates in the certification path against corresponding CRLs.
So, on this point alone, the process you describe is non-compliant.
1. During generation of certificates, it is clear that
certificates migrate "downwards" through the hierarchy, i.e.
PCAs have the IPRA certificate, the lower level CAs have the
certificate of the IPRA and their PCA, and so on up to the
individual users, who accumulate initially (after their
registration) all certificates along their certification
path.
Certificates, as John Lowry pointed out, do not merely flow "downward"
but rather are freely distributed via various means, e.g., PEM
messages and directory queries. This is clearly described at several
points in RCC 1422, e.g., Section 3.4.1.4 describe the facility every
PEM UA must incorporate to permit sending a full certification path
in the header of a PEM message.
2. Because of 1., when some CA in the hierarchy generates a
new certificate (say with new private and public components,
for more general case), after receiving it signed, it must
re-sign certificates of its lower level CAs, store current
certificates in the CRL and SEND downwards the new
certificates. Because of 1., they must further "propagate"
through the subtree of the hierarchy all the way to all
individual users.
I don't fully understand this paragraph, perahps because it is founded
on the (non-compliant) assumption of strictly hierarchic certificate
distribution (vs. certification). If a CA does change its key pair,
then it would have to re-sign subordinate certificates, but there is
no need for CAs or users of these re-signed certificates to change
they key pairs, so the process does not propogate for more than one
tier. Also, there is not a requirement that the subordinate
certificates be immediately hot-listed. It depends on why the CA
changed its key pair. If there was no compromise, it is likely that
the reissuance process would be performed gracefully, with new
certificates issued well in advance of when they would be required
(the VALIDITY field in a certificate makes it easy to do that), to
smooth the transition.
3. RECEIVING LETTERS: When I receive the COST-PEM letter
from my partner, the letter will contain partner's
(Originator) and his/her CA's (Issuer) certificates. Lets
say that my partner is in the subtree with changed
(therefore revoked) certificates, as in 2. If I don't have
my partner's complete certification path (received earlier),
I will issue the request to his/her CA, get all the
currently VALID certificates and perform validation. If I
happen to have earlier all the certificates along his path
(some of them revoked !), my validation will FAIL, so I will
ask the new valid certificates again and successfully
validate his/her certificate.
This discussion does not address the central issue for certificate
revocation, as other have noted. If the sender's certificate has been
hot-listed (placed on a CRL) because of a compromise of a private key,
then processing of a signed message under the revoked certificate is
not detected by this procedure. As noted above, a compliant PEM
implementation requires CRL checking as part of certificate (and
signature) validation.
4. SENDING LETTERS: If I want to send the ENCRYPTED letter to my
partner, then [RFC 1422, section 2, fourth paragraph] "... prior to
sending an encrypted message (using PEM), an originator must acquire a
certificate for each recipient and must validate these certificates."
..... (*)
Yes, and validation of the certificates requires having the
corresponding CRLs. It is neither required, nor expected, that the
certificates will be retrieved from CAs. As noted above, they may be
acquired from PEM messages or directory entries, e.g., the DNS could
be augmented to contain user certificates (with real DNs) in new
record types. PCAs are required to provide access for ALL CRLs, using
the mechanisms described in RCC 1424, but they need not provide
repositories for CA or individual user certificates.
So, in all cases I can send and receive letters from my
partners and I can verify their certificates without having
locally all CRLs of all CAs along his/her certification
path. We run CRLs EXACTLY as described in RFC 1422,
3.4.1.3., second paragraph. We did not implement the "CRL"
type of PEM message [RFC 1421, 4.6.1.1.4], since we believe
that (1) it is not necessary to have locally all the CRLs in
order to perform validation, as explained in this letter,
and (2) we believe that our validation system is more
efficient that the one described in PEM standards. We
explicitelly state that in our COST-PEM policy.
Your scheme, because it seems to assume more restrictive forms of
certificate distrubution than are called for in 1421 and 1422, might
be "more efficient" in a more restricted context, but it not compliant
with all of the relevant sections of 1421 and 1422, and hence I would
suggest that it is inappropriate to state that the COST PEM
implementation is compliant.
We intend to implement the "CRL" type of the PEM message for
validation of outdated PEM letters, but in the next version
of the COST-PEM system.
Good start!
Therefore, we do not perform certificate validation BY
DEFINITION (probably you meant following blindly PEM RFCs),
but by the described procedure.
I don't fully understand this comment.
My statement that "... CRLs are not quite worked out in PEM
RFCs" meant our interpretation that if you follow the (*)
procedure, then we believe that you don't need locally CRLs,
and also that we couldn't find explicitly the mechanism in
RFC 1424 to perform step 2. described above.
Do we still missunderstand the essence of PEM certificate
validation ?
Yes, I fear so.
Regards,
Sead Muftic
COST Computer Security Technologies AB
Stockholm, Sweden
Steve Kent