Bob,
I a reply to Sead last month, you became enthusiastic about
an optional, elaborate CRL time-stamping, etc. service involving
the CAs in real-time communication. Given earlier discussions
about the increased vulnerability of a CA which is on-line, I
cannot be enthusiastic about any operational model that requires
that. Also, the suggestion that each CA provide a time stamping
service may be inappropriate, because one may often wish to have a
neutral, third-party provide the timestamp service for messages.
Finally, the suggestion that the CA be on-line and in the loop for
message transmission with non-repudiation is just the sort of
thing that imposes very high availability requirements on CAs, and
makes them single points of failure. To avoid these problems
requires polyinstantiation of CA keying material, which further
increase the vulnerability of that material unless it is very
carefully implemented. Your final suggestion seems to overlook
the certification path issue. It provides real-time verification
of the users certificate validity by the CA, but what about the
CA's validity? This would require getting the PCA into the loop,
with a greater volume of traffic (aggregated from all subordinate
CAs) and requires use of PCA keying material to sign these
responses, etc. I don't think this is a great approach.
Steve
==========================
================ and another reesponse ===============
To: jueneman%wotan(_at_)gte(_dot_)com
Subject: Re: Re: Corporate Identity = Personal Identity
Cc: pem-dev(_at_)tis(_dot_)com
------------
Bob,
In your response to Mark's message about use of organizational
roles I think you went pretty far afield. First, with regard to
who would have access to the private keys that represent the
organizational roles, I think the answer is that they are
accessible to the company. Note that you may even poly-
instantiate the keys, so that multiple individuals would have
access to incoming, encrypted mail directed to a role. Thus there
need not be a one-to-one correspondence between these externally
visible roles and the folks who respond. This is not a security
problem in this context. Note that responses to these message
could be signed using separate keys, representing the specific
individual who responded, providing individual accountability.
This works well without using separate keys for signature and
encryption (though there might be other reasons for that feature).
We agree that a user probably will hold, or have access to, a
variety of DNs for home and business use. However, we probably
disagree about the implication of this for attribute types in DNs.
For example, at BBN I expect that my DN will be [C=US, S=
Massachusetts, O= Bolt Beranek and Newman Inc., CN= Stephen T.
Kent]. (We're just about to get our RSADSI CIS software and begin
operation as a CA under the RSA commercial hierarchy, so I'll soon
be able to say what this DN is definitively!) This DN establishes
me as an employee of BBN but does not state my title. That's
fine, because a separate DN that I should have access to in my
current role might be [C=US, S= Massachusetts, O= Bolt Beranek and
Newman Inc., CN= Chief Scientist- Security Technology]. This DN
does not identify me as the role occupant, but that's OK too in
many circumstances where traffic is directed to or signed by role,
irrespective of the identity of the current role occupant.
So, your pseudo-DN examples, with the roleName attribute
creatively misused, are not needed to address the problem
described in your message. We do agree, however, on the value of
not mixing mailbox addresses with DNs.
Steve