Christian,
There is a very interesting follow-up to your view of PCAs. If the
signature of a certificate by a PCA merely is the assertion
"Me, PCA named so and so, hereby testify that the entity named this
and that is in possession of the RSA key number N", then, we have to
change a couple of details:
A CA, in signing an X.509 certificates asserts exactly this. A PCA,
through its policy statement, tells the user community under what
circumstances the PCA certifies CAs, e.g., what effort it makes to
verify the CA's identity, and, transitively, what effort the CA makes
to verify the identity of the entities to whom it issues certificates.
Other aspects of the PCA policy detail what precautions the PCA and
the CAs take to protect their private keys, how frequently they issues
CRLs, etc. So a PCA, and the CAs it certifies, do provide more
semantic context in the course of signing certificates than indicated
by your concise charecterization. A PCA policy MIGHT (but need not)
also make statements about the implications of the level of security
afforded by the PCA, CAs, and users. I believe the COST folks are
planning to offer one PEM PCA that requires the use of smart cards to
protect user private keys. The policy statement from that COST PCA
should cite that technical feature and might make claims about the
suitability of the resulting signatures for business purposes. But
this is a decision that each PCA makes independently.
1) We should consider the certificates as mere "snapshots" of
the key bindings, and stop believing they are related to any form
of policy. After all, this would be consistent with the
current practice of only asserting "weak" policies.
Since PCAs MAY elect to adopt and publish strong (vs. weak) policies,
I think it would be inappropriate to make a blanket statement about
how we should treat certificates in light of weak policies. Also,
strong and weak are relative terms anyway so ...
2) We should only have a date of issuing, and not a date of
validity. Who are you to say that this entity will have retain
its key next year? Just because a person wears long hairs on a
snapshot does not mean he will not get shaved next day.
There are a variety of reasons for choosing short or long validity
intervals, as discussed in 1422. Again, since the strength of the
policy may vary for different PCAs, it seems inappropriate to make any
sort of blanket statement about validity intervals. The idea of a
validity interval here is quite analogous to that on many forms of ID,
and certificates are a form of electronic ID, so I don't see why we
should discriminate against certificates, e.g., as compared to
passports.
3) We should display the date of issuing of the certificates
used in the certification path, as old certifcates are much
more likely to be stale. Maybe we could use the date in some
form of "path metric".
I assume here that you are referring to display for a user. I think
this would be confusing in general, i.e., information overload.
Besides, old certificates for CAs and PCAs may accurately reflect good
security practices and no need to reissue them frequently. I don't
believe one can make a general, valid statement about the level of
trust accorded to a certificates based on its age. CRLs have a next
issue date to help a user determine if the CRL he has is old, and thus
a less relaible indication of revoked certificates, but the semantics
of CRL issuance don't match those of certificate issuance.
Which indeed does not reliev the necessity to somehow
propagate lists of stolen keys. But we all know that the CRL approach
is very weak -- there is no way to be sure one has got the last, up to
date, CRL...
Well, yes, we never know if the CRL we have is absolutely the most
current one due to the possibility of emergency CRL issuance, but I
think experience will show that reliance on the next scheduled issue
date will suffice for most applications, and for very stringent
non-repudiation applications you need to wait for the CRL that is
issued after the "transaction" anyway.
Steve