"David P. Kemp" <dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil> writes:
From: Paul Hoffman / IMC <phoffman(_at_)imc(_dot_)org>
Exactly right. And, as Peter has pointed out yet again, there is a business
desire for "trust me after some out-of-band validation" certs that is so
strong, there are many examples IN USE TODAY of them. I'll trust him when
he says they are not interoperable; that certainly sounds likely to me.
Telling these people "don't use PKIX" is silly. We want as many people
using PKIX as possible so that application vendors don't have to support
two different cert formats to hold keys that are being used in the same way.
I'm confused about exactly what the "strong business desire" is for, and how
it relates to the proposed solutions.
Since the distribution now includes new people (ietf-smime) I'll give the
Readers Digest version of what I said in an earlier message:
1. Free or low-cost certificate tools are becoming more and more widespread.
2. Businesses are using these more and more: "The software's free, we have
the expertise to do it in-house, why do we need to pay a CA for it?"
(Classical manglement thinking at work).
The problem with this approach is that X.509 doesn't define a format for:
1. A standalone end-entity certificate verified using out-of-band means.
2. An encryption-only cert signed with an end-entity signature-only cert
verified via the usual CA mechanism.
Both of these results are what businesses are trying to do based on the
manglement thinking presented above, with the result that you end up with
whatever cert kludges are required by the toolkit they're using to make this
possible (eg everyone is a CA and signs their own certs, a single certificate
vending machine-type app is used to sign everyone's certs just to get the
public key into X.509 format, someone is appointed to generate everyone's keys
for them so they can sign the public portion with a fixed CA cert before they
send them out to the users(!!!), etc etc etc).
The result was a thread containing various ways to achieves this, with no
clear consensus being reached (several people had done it, but their ways
of doing it were all different).
Here's a simple proposal, involving the addition of one signed attribute to
CMS section 11:
That's a nice way to do it using existing mechanisms, but it's almost but not
quite completely unlike the required solution :-). What people are trying to
do is create certs managed through means other than the full CA
infrastructure, and use the resulting certs (full certs, not just raw public
keys) with web servers, in custom signing applications, in EDI software, and
God knows what else (for example I know of one company who do a web-browser
plugin which signs data sent from the user back to a central server where
noone's going to pay a CA for a cert when the entire app with an infinite-user
license sells for a few hundred dollars. In this case they're going to set up
every user as a CA with their own self-signed CA cert, and the software is
coded to treat them as EE certs. The reason I know about this particular case
is that they're using my software to do it, and since I'm pretty picky about
doing things the way PKIX requires the only way they could get self-issued
certs to work is to make everyone a CA. I don't know whether they've released
this yet, but from talking to them in the past they're going to end up with a
fair number of users, and there are many other companies doing things this way
as well).
As I see it, there are three options:
1. Define a format for the two cases described above and try and get
developers of toolkits and whatnot to stick with it, so that when people
do employ these certs you can identify them and work with them as required
(which could include just refusing to handle them if you feel so inclined).
2. Educate every IT person on the planet about the wonders of X.509 and
convince them all to do it the way they're supposed to do it rather than in
a way where they can ship a product as quickly and cheaply as possible.
3. Continue to ignore the issue and end up with an ever-increasing number of
homegrown kludges which at best won't interoperate with anything else and
at worst will severely screw up any other software which tries to use it.
Peter.