Subject: Re: Certificate requests for encryption keys

From: [email-masked] (Peter Gutmann)
Date: Thu, 10 Jun 1999 03:03:57 (NZST)

This is a general response to several messages which have pointed out that
self-signed EE certs don't fit into the X.509 theology[0]... this is a valid
point, however what people are trying to achieve with these certs is a means
of sharing keys without external certification and authentication and fuzzy
dice and chrome tailfins.  The X.509 format makes it impossible to just store
or communicate a key without carrying a vast mountain of other (often
unnecessary) baggage around with you.  I can't speak for others who have 
posted an opinion on this, but all I'm trying to do is get a key from A to B
without requiring a huge (and currently mostly nonexistant) infrastructure to
do it, the same thing which PGP has been doing very successfully for nearly a
decade.  All I want to do is store a key in a non-proprietary format, but 
X.509 (currently) doesn't let me do that unless I get a CA to sign it first.
What I'm proposing is a key bit-bagging scheme which isn't entirely dependent 
on the presence of a CA in order to function.

Peter.

[0] Whether X.509 is systematic or speculative theology is left for the reader
    to decide :-).

---

From: Stephen Kent <[email-masked]>
Date: Wed, 9 Jun 1999 11:32:06 -0400

Peter,

Your characterization of what you are trying to do is somewhat ncomplete, I
suspect.  You don't want to just transfer a public key; you want to
transfer it with some set of assurances, e.g., so that the recipient knows
whose public key it is.

X.509 defines a format and processing for representing a key within a
management infrastructure.  That infrastructure does not have to be global,
using formally approved CAs, etc.  It can be a closed PKI with small
extent. However, the goal of this WG is to facilitate Internet use of X.509
and that does argue for syntax and processing that does scale to large
groups, representative of the growth of the Internet.

Along those lines, maybe you should make use of some other syntax if your
goals for public key representation for transfer are not congurent with
those stated here.  We can't be everything to everyone.  One size rarely
fits all.

Steve

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 09 Jun 1999 08:59:02 -0700

>transfer it with some set of assurances, e.g., so that the recipient knows

I'll disagree with your characterization of what Peter has asked for. There 
are many good reasons to want to use the *format* described in PKIX for 
transporting public keys without being forced to use the systems associated 
with PKIX to process the certificates. Peter is (I believe) saying "I'll do 
the assurances out of band, just let me use your format".

>management infrastructure.

The format can be used outside of the management infrastructure.

>   That infrastructure does not have to be global,

I believe that it also argues for other Internet-related uses of X.509 
certs that may not have been envisioned by the directory-centric views of 
the X.509 folks.

>those stated here.  We can't be everything to everyone.  One size rarely

I don't think this WG should be that dismissive of a significant 
constituency. The fact that one gets X.509 self-signed root certs from a 
directory and then does out-of-band verification says to me that there is 
no good reason not to get self-signed EE certs from a directory if they are 
then followed by out-of-band verification. If we can set up a different 
profile of X.509 to allow the latter case, we should do so, given the 
obvious business desire for such a system.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Stephen Kent <[email-masked]>
Date: Wed, 9 Jun 1999 12:19:46 -0400

Paul,

I disagree strongly with almosty everything you said, even though you're a
nice guy :-).

We're not in the synatx-only business here.  Certificates are a powerful
tool for enabling secure applications.  However, security is a VERY HARD
problem and part of our task in this WG is to provide a context for
certificate use to minimize the risks attendant with the technology. There
are limits on how much of this we can do, since differentr contexts have
different security requirements.  However, in the same sense that the IESG
and the IAB have adopted a position that mandate strong encryption
algorithms as defaults for crypto protocols, I think it consistent to adopt
a posture that tries to establish secure management frameworks for use of
X.509 certificates. If one elects to employ some unspecified, out-of-band
management to validate certs, to revoke them, etc. then we have no idea
what security is provided by the resulting system, and that is not
consistent with the higher level goals cited above.

I certainly can't prevent anyone from using the X.509 format for any
purpose they wish, but I will resist the notion that this WG add work items
that facilitate such activities.

Steve

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 09 Jun 1999 15:09:54 -0700

>I disagree strongly with almosty everything you said, even though you're a

How much more strongly would you disagree with me if I were nasty? :-)

>certificate use to minimize the risks attendant with the technology.

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.

>  There

But this is exactly what PKIX is all about, given that we don't tell people 
how to "load" root certs for path validation. Trusting root certs is by 
definition out of scope, as it should be.

Let me put this another way. I can create a self-signed EE cert today by 
signing the cert with my own CA-formatted root cert, and telling the 
recipient "accept this root cert so you can trust my EE cert." Did reading 
that sentence send shivers up your spine? It should have. We do not want 
users willy-nilly adding root certs that might not be properly constrained. 
Quite frankly, we don't want them adding well-constrained root certs 
because we know in our heart of hearts that much of the path validation 
software in use today does not follow constraints correctly. (I have been 
told this by the folks who wrote the software for at least three different 
companies; they'll revise it to work better sometime this year, maybe.)

If you don't want that horror scenario, maybe you might want to help 
prevent it by coming up with a standard way to pass these certs so they can 
be used in future PKIX-compliant applications.

>that facilitate such activities.

Then you are fighting against something that I think is important for any 
IETF Working Group: helping interoperability by choosing one way to do 
things. I do not feel that we should be telling people "we don't want to do 
that, we'd rather spend our time arguing about minutae of timestamping and 
LDAP schema" if we could spend some effort and get a single interoperable 
solution that has all the necessary security caveats in it.

--Paul Hoffman, Director

---

From: Stephen Kent <[email-masked]>
Date: Wed, 9 Jun 1999 19:13:26 -0400

Paul,

>How much more strongly would you disagree with me if I were nasty? :-)

You don't want to know :-(

>two different cert formats to hold keys that are being used in the same way.

I'm all in favor of supporting folks who want to use X.509 certs, and the
PKIX profile, but that does not mean that we should change the profile just
to get a bigger "market share."  What I would suggest is explaining how to
use the existing profile to facilitate what you cite as the pressing
busines need.  It would seem pretty easy:

	- exchange, via some out of band means, public keys or
'fingerptints" thereof plus name info
	- use these as root CA keys in a simple 2-tier tree
	- issue one of more user certs under the CA
	- exchange user certs using existing mechanisms

This should work. There is often a perception that being a CA is something
special, but it ain't necessarily so, if one wanst just a simle, closed
system.  Also, there is no rule saying that you have to pay money to issue
or to get certs.  We see a growing number of products that provide for
unlimited cert issuance, with no per-cert fee.  the next version of
Windows, I am told, will contain CA code.  So, just be a CA and perform the
OOB exchange for a CA key.  That way you might even have a nice standard
way to revoke user keys if needed.

>companies; they'll revise it to work better sometime this year, maybe.)

Gee, you paint an interesting choice here: badly mamaged root CA certs vs.
badly managed EE certs.  I take door number three, better client software.
Ultimately there is no substitute for it.

>be used in future PKIX-compliant applications.

I presented one such way above.

>solution that has all the necessary security caveats in it.

Caveats are no substitute for good designs.  I'm more in favor of working
to satisfy a desire to use what we all hope will be a growing list of PKIX
compliant clients, both with CAs of broad scope and CAs of very local
scope.  However, if the clients are not compliant to begin with, then the
users are not making use of "PKIX" after all. I am not interested in
claiming market share (e.g., vs. OPGP) by saying that any code that does
some (lame) processing of an X.509 cert is PKIX and thus we have a big PKIX
community.

Steve