Date: Tue, 07 Dec 93 11:54:00 EST
From: jueneman%wotan(_at_)gte(_dot_)com
Reply-To: Jueneman(_at_)GTE(_dot_)COM
...
1. Do you provide, or intend to provide, any mechanisms
to allow the user to control which PCAs, CAs, and/or
individual users are accepted without warning, accepted with
warning or manual intervention, or rejected?
Today PCAs are hardwired into the code. Hopefully in the future I can
reduce the number of hardwired PCAs when the IPRA goes online. In the
future I am planning to provide a mechanism for people to add PCAs to
the list (and remove the ones that are builtin) via a configuration
option. I have no plan to provide for specifically accepting or rejecting
particular CAs or End Users (beyond the normal PEM CRL mechanism).
2. If you do not provide any wild-card control mechanisms
of this type, do you provide or intend to provide any direct
indication to the user as to which PCA a given certificate has
as its root?
A future version will display the name of the PCA at the top of the
cert chain. The current version does not.
3. How do you handle the case where one CA is certified
by multiple CAs, if you do? If and when such certificates
are entered into an X.500 database, would you expect to
enter two certificates with an identical DN under a common
entry?
I currently support multiple certificates with a common Subject DN.
The only restriction is that two different certificates may not have
the same issuer DN *and* serial number. When verifying a certificate
chain, I will always select the correct certificate. If multiple
certificates exist under the same DN, then the one that "works" (or
the one that is most valid) will be used. However there is a
performance cost for having multiple certificates with the same DN
because the certificate verification code has to ponder more objects.
4. To what extent do you enforce name subordination?
The current version does not enforce name subordination. This is a *bug*
that will be fixed (I am not yet using the most recent RSA toolkit and need
to convert to that version as a prerequisite for this step).
The reason for these questions is that I am beginning to wonder
whether a CA should specify the name of the PCA hierarchy
as an OU under their organizational name, both to eliminate
the apparent ambiguity as to which certificate is to be used, and
to clarify to the user which trust hierarchy is in effect for a given
signature chain.
I believe this labeling of certificates can be handled as a "local matter."
In other words I don't believe that DNs within certificates should be
overloaded with this information.
I'm merely thinking out loud at this point, but I'm wondering whether
we should create a DN for our CA that would look like:
C=US, O=GTE Laboratories, OU=RSA Commercial Hierarchy CA.
Another CA, that might be used for noncommercial, casual e-mail
purposes, might be
C=US, O=GTE laboratories, OU=RSA Low Assurance CA.
Personally I think this is reasonable, but should not be necessary.
Random Observation
When verifying messages from others I hardly *ever* have all the material
I need to do a complete PEM certification. I am always missing necessary
CRLs (and people are *not* using the CRL respository) and in many instances
people send me messages with expired CA certificates (I am guilty of this
one as well).
Both my implementation and the TIS reference implementation generate warnings
under these circumstances. The problem is that if warnings are always being
generated, then users begin to view them as normal (as we know that everything
in California causes cancer and all business establishments have warnings
posted to this effect). At this point I can verify a "legitimate" PEM
message, but receive warnings. However I can also receive and verify a
PEM message which contains a certification path that ultimately works its
way back to a self-signed certificate of the senders choosing. with TIS/PEM
I get a very similar warning to the case where a CRL is missing!
This has led me to believe that we need a tuning knob on the PEM verification
rules. In this fashion we can give the end users control over how finiky they
wish to be. Levels of the (digital) know might be:
1) All certificates and CRLs are required.
2) CRLs are required but may be obsolete.
3) No CRLs are required.
3a) CRL required from first level CA but not from higher levels in
hierarchy.
4) CA certificates can be obsolete (and PCAs as well)
5) User certificates can be obsolete
6) Anything is ok (PEM becomes a no-op) or a printf("All OK");
Comments?
-Jeff