Blake,
Blake Ramsdell wrote on 08/08/2003, 20:44:
This seems to be a question of certificate policies and mapping those to
the content being protected. That is, if the message being signed is
just casual communication, use one certificate, and if it's a purchase
order, use another one. Right now, I think that most clients pretty
much allow the user to pick. Further, I think that a lot of folks just
have one, so you'd better like it.
It is indeed a question of policy, and the example you point out is a
good one. Similarly, for internal communications within a company, I
shouldn't use my freemail Thawte cert. The internal SSL web servers
which require client auth don't accept that certs.
Yet mail client accept it just fine.
The specific application I'm interested in is e-mail spam filtering
based on certificates. You could choose to trust some free CAs (such as
Thawte) if you like to receive anonymous email, otherwise restrict to a
set of CAs with a more stringent policy (eg. those that require you to
pay for the certificate).
As far as the number of certificates, I think most folks have zero
today, not one. Some will have one, issued by their employer (corporate,
or government/military typically). Then there are hobbyists or security
professionals like us who may have dozens of certificates. Nowhere does
Joe User fit today, because PKI is not widely deployed. Most questions
I'm asking are in the context of a very large-scale PKI deployment
happening. The problems may not be so obvious unless you get to that point.
Well, I'm not sure that the semantic of multiple SignerInfos is that "if
you verify them, you must verify all of them, and if you don't like any
of them, freak out". I think it's more along the lines of "these are
all equivalent, so go ahead and choose which one you like and run with
it".
Where would that be specified ? I would think this would be completely
up to the application. If I chose to sign mail with both my personal
cert and corporate cert, I know I wouldn't treat each signature in the
same way. Eg. if I am an employee, I might not care about the personal
cert's signature failing, but care about the corporate cert signature.
This might be interesting to discuss. You could make a capabilities
extension where you could identify your roots (off the top of my head,
I'd say using a hash of the certificate would work) and go from there.
One concern is bloat -- I have over 100 roots on my machine configured
with Outlook 2002 and IE6 that are all marked as suitable roots for
"Secure email" (in the "secure email" trust domain, using your terms).
Sending this stack of hashes with every signed message might make the
world a worse place to address this issue.
I think it would be a very bad thing to embed all the root certificates
in each S/MIME signature. The signatures are already quite big enough as
they are. I know the number of trusted roots can be quite high - it is
also high in Netscape products.
What I'm getting to is more along the lines of :
1) defining a standard ASN.1 structure to define the user's trusted
roots policy WRT email. That structure will most likely be too large to
embed in signatures.
2) there may be a set of rules that goes along with the roots. Just
having roots trusted may not be right. Eg. my colleagues shouldn't trust
email signed with my Thawte cert with jpierre(_at_)netscape(_dot_)com in it, it
should be signed with the Netscape CA ... This one I really haven't
given much thought to.
3) Some mechanism for transporting that trust structure. I would suggest
LDAP, but that requires a standard mechanism to get to it, just like we
need a standard means for disseminating certificates
I think the principle is the same, though.
It's very similar, with the possible exceptions of the rules (see above).
In the case of S/MIME, it's
"sign with all of your certs". One problem is that you're going to
potentially cart around a large number of certs -- each of your
individual certs as well as the intermediate certs that go with them.
And I'm not sure that there's enough experience with clients handling
multiple signers to tell you what would happen if you used that feature.
Definitely not today - multiple signatures is something that would need
to be added to most S/MIME software and would hamper deployment.
From what I can tell, today we solve the problem by having clients
include every root key under the sun,
It's worse than that, some SSL intermediate certs are also included with
some software (IE) ... Many SSL servers are misconfigured and don't send
their intermediate certs.
and most certificates of
significant public value are issued under those roots. Certificates
that aren't issued under those roots are most likely corporate CA
certificates, and typically folks just have to hunt around to find the
right corporate root to install in order to verify the signatures.
Peter Hesse and Sharon Boeyen have recently illustrated this problem on
the PKIX list -- not directly, but by sending signed messages for which
people don't have the root keys.
This is a case where the trust domain could be useful. Eg. the mailing
list alias could have a defined trust domain, and their software would
know not to use that private cert when posting to the list.
--
I am the dog in dogfood
smime.p7s
Description: S/MIME Cryptographic Signature