Amanda, let me clarify my position, as I tried to do previously in a private
message. I don't think we are quite as far apart as you think.
My own goals would be just as well served, in the absence of something
resembling an Internet standard, by using PKCS7 with the representation in
the current proposal. This is in fact even easier than trying to stay
aligned with RFC 1421, and makes some non-PEM interoperabilty problems
become much easier. In addition, I fully expect to be supporting multiple
security frameworks, just as I currently support multiple text formats,
graphics formats, authentication schemes, and so on. This is something
to keep in mind while reading the rest of this note.
Actually, I rather agree with you. PKCS7 wouldn't be a bad jumping off place, I
don't think, although I haven't been party to any of the critical review
process and may be missing some of the fine points of potential disagreement.
Surprisingly, as I learn more about PGP, I might not be so opposed to using it,
either.
The key selector issue seems to have mutated into the question of whether
or not the use of the X.509 certificate syntax should be mandated as the
only public key distribution syntax. I understand Bob (and some others)
as answering this with "yes," and Jim, Ned, and others as answering it with
"no."
Actually, let me restate my position on that as well. Obviously X.509 is THE
front-runner for honors among certificate-based systems, but it is not the only
one. PKCS is a very interesting varient, in that it attempts to provide some of
the options that now being introduced in v3. PGP is certificate based, although
incompatible with X.509 certificates at present. X.9 is developing a series of
certificates, most of which have more to do with authority and capability than
identity, bu there may be some overlap and multiple ways of accomplishing the
same objectives, especially with X.509 v3. The European EDI community
apparently has a different certificate scheme more or less in place, although I
don't know the details.
At the risk of overgeneralization, I would claim that what all of these systems
have in common is the fact that some third partyor parties has endorsed a
user's public and associated it or bound to it some information claimed to
pertain to the user -- typically his identity, but perhaps other information as
well.
In addition, all of the certificate-based systems that I am aware of include
some provision for offline CRLs, so that the binding between a "user" and his
key can be disclaimed prior to the certificate's expiration date, either
becasue the user alleges that his key has been compromised, or because the
statements made about the user -- his affiliation with a particular company,
for example -- are no longer true.
A CRL server is not the onlly way that certificates could effectively be
revoked, however. As Sead Muftic and I have discussed, it would be possible for
the reicipient of a document to call up the CA that certified the user who was
allegedly the originator of that document, and ask whether at this instant that
certificate is deemed still valid. Alternately, the originator could send the
document to the intended recipient via the CA, who would attach a cachet of
authenticity to the document or message as of the time of forwarding, attesting
to the fact that the originator's certificate was still valid.
Systems that do not provide some means of invalidating previously issued
certificates become quite troublesome to use. About all that can be done is to
limit the expiry interval to a very short time, perhaps as little as a few
days, so that the window of their acceptance limits the risk to both the
originator and recipient of a document.
Assuming the public disclosure of a certificate, however, it should be possible
to build a repository of known CRLs which revoke those keys, and there a large
number of distributed database designs that would serve the purpose. Assuming
that the certificate contains some minimal amount of information that makes it
possible to identity it relatively easily, normally the certificate issuer's ID
and serial number.
The case of a bare public key is quite different, however. If someone sends you
his key without any kind of a certificate, the YOU are responsible for binding
the claimed identity or other information to that public key. You could do it
by creating a certificate yourself and signing it, and hopefully the user has
signed some kind of a test innocuous message to convince you that he actually
possess the corresponding private key.
Now lets assume that the originating user's private key is compromised, or that
the binding is no longer valid. How does the originating user know who has
bound to that key? If knowledge of someone's public key and claimed identity
has been passed around to others, the originator may not even know who now has
that knowledge, and thus he has no way to track down all the copies of that key
and disavow it. At a minimum, he has to keep a rather extensive database of all
those keys, adn who he has given them to, and hope that the recipients of that
key will in turn notify anyone they gave the information to. This seems quite
cumbersome and failure-prone, at best.
Worse yet, suppose that the information that is being bound has something to do
with the company for which the user works. He leaves the company, and the
company would like to revoke the binding between the key and the information,
so that the user can no longer pretend to represent that comapnmy or have
access to its resourced. without SOME kind of a CA structure this is
effectively impossible, and that is one of the major problems facing PGP, IMHO,
even though they make use of a certificate format.
My own point of view is that this is the wrong question. I think the
question is actually "should operation without certificates be allowed
to be called PEM?"
Well, that's a good question. Of course, classic PEM includes some support for
symmetric key operation, and somewhere there might even be someone who thinks
that is worthwhile. :-) One varient of your question might be, "should
operation with certificates that are not X.509 be considered PEM." In the
strict sense of the current RFC 1421-4, probably not, but in the broader sense
of being endorsed by the technical community that makes up this working group,
I ma certainly prepared to consider such an option.
Personally, I don't care. I'd be happy to have an
"application/pem-keys" which has a PEM certificate, an "application/pgp-keys"
which has a PGP key (perhaps signed), an "application/rsa-keys" which has
bare keys, and so on--whatever people actually want to use. From an
implementation standpoint, as long as the syntax for the actual algorithms
and keys is constant, this is all just tuning the user interface. This is
not to say it's not important--much of my job is designing and analyzing
user interfaces :). However, the question of whether or not to mandate
X.509 is to me very much a policy issue.
Actually, I would agree with you, up to the point of the rsa bare keys without
any supporting infrastructure, including some kind of a certificate revocation
mechanism, not necessarily the currently defined CRL mechanism.
And as a policy issue, I find a number of arguments I've seen go past
recently to be specious. For example, X.509 is not going to die. Clearly,
many environments are well served by the PCA/CA framework, and more will
be as CAs come on line, ranging from the RSA Commercial and Unaffiliated
User CAs to the CAs that the U.S. Postal Service is bringing on line.
I fully expect X.509 to become the standard electronic form of identification,
analogous to drivers licenses, check cashing cards, and the like in
phsyical interchange. X.509 certainly doesn't somehow "need" our support
in a political sense. It simply exists, and we need to be able to support
operation in its framework (as the current draft does).
Actually, I am delighted to hear you say that. If I were convinced that were
true beyond any reasonable doubt, I wouldn't be nearly so nervous about
supporting alternative structures such as the bare key option, as I would
suspect their usage would wither and die, and not be a problem. But I very much
doubt that you have a concensus on that point with your co-authors, Ned and Jim
having been extremely dogmatic about the general un-workability of the
certificate structure, the difficult of getting it started, etc. At least a
year ago I was beginning to have some serious doubts as to whether public-key
cryptography was ever going to get out of the starting blocks, but recently
things are looking up. if you could convince Ne and Jim or your point of view,
perhaps they wouldn't be arguing so hard! :-)
Ned's recent discussion and understanding of distinguished names is so far
apart from my own, and I think most of the rest of this WG, that I really
wonder how we got this far along in the discussion. It would seem that we have
been on separate planets.
However, although I might disagree with him from time to time, Ned is
obviously no dummy, and I will take the time to read what he has said carefully
and try to respond equally carefully. Hopefully one of us will end up educating
the other, or perhaps both of us will learn something. I will say that if those
are his perceptions as to what a distinguished name ought to look like, no
wonder he has trouble building a certificate structure! I don't think I could
either, given his self-imposed constraints.
However, certificates are not necessary for all contexts, and simply for the
sake of parsimony I see no reason to mandate their use even where they are
irrelevant. Certificates are not the only way to verify public keys. If
I want to exchange private email with my mom, for example, all we'll do is
verify key hash values during a visit or over the phone. There is no
need for *any* certification infastructure in such a case. We just treat
it the same way as we do the exchange of postal addresses, new phone numbers,
or what have you. The same is true for interchange that involves formal
bilateral agreements as well as implicit ones. A contract may specify the
keys to be used in the course of the business governed by it, for example.
Getting a message encrypted with one of those keys is ipso facto certified.
I was and am in favor of parsimony, as you put it, just from the standpoint of
having a small and consistant architecture, with a minimum number of features.
I think that is consistant with the overall approach taken within the IETF.
(And I thank Dave Crocker for forwarding his well-written ACM article
discussing the Internet standards process.)
More important, in the area of security it is vital that we throw out
EVERYTHING except for the minimum amount necessary to make the function work.
That has been clearly demonstrated over the last 30 years of building trusted
systems based on a security kernel, and is perhaps even more clearly
demonstrated in cryptographic protocols and systems. The more functions and
features are provided, the greater the possibility that there is a significant
weakness or blunder that could be exploited.
That is why I suggested the use of self-signed certificates as a way of
bootstrapping the system and supporting the direct trust model. the direct
trust model is unavoidable at the top or tops of the system. You either trust
the IPRA, or you trust one or more PCAs and their hierarchies, or you trust
individual CAs and their users, or you trust individual users. Whether you call
it a key ring or a cache of trusted certificates, all signed documents must be
validated by climbing the chain back to one of those trusted root keys. (At
present RFC1422 doesn't address that requirement well enough, but it should.)
Of course, the same applies to validating a user's certificate before sending
him an encrypted message -- at least if you care who you are sending it to.
On the other hand, It doesn't matter to me whether or not the certificate
and non-certificate based styles of operation use the same names for body
parts, or whether the certificate-less body parts have "pem" in their
names. If we want to make X.509 mandatory for something to be called "PEM,"
that's fine. It just means "PEM" will describe a smaller envelope.
That really isn't my concern, at least from the standpoint of putting the
current PEM/MIME RFC on a Proposed Standards track. Although it may be unusual,
I have been trying to move the entire issue forward while at the same time
trying to avoid setting up the less sophisticated users from hurting themselves
and thereby slowing down the overall process. Call me a self-appointed
omsbudsman or resident gadfly if you wish. My concern continues to be whether
the IETF, in giving the current RFC the imprimature of a Proposed Standard,
Draft Standard, or Standard, eventually, would end up disrupting other efforts
along these lines and compromise the emerging public-key infrastructure and a
potentially enormous suite of compatible applications.
Whether this is a bug or a feature depends on your point of view, I suppose.
To me, it literally doesn't matter. I'm already planning on supporting
RFC 1421, the MIME/PEM draft, PKCS7, and probably even PGP. Tracking
moving targets is nothing new to most Internet software developers :).
I was thinking this morning about the possiiblity of reworking RFC1422 to
minimalize it along those lines. If we described all of the syntax in terms of
OIDs and ASN.1, leaving out some of the implementation-specific syntax such as
Ooriginator_ID, etc. we could have a very compact spec that would apply to any
application that wanted to do "PEM-style" certificate authorization. Ideally, a
compatible API could be developed that would allow someone to rip out the PEM
functions and plug and play with PGP, PKCS, etc., or support multiple
certification mechanisms.
My entire reason for taking an active role in this discussion was in the
hope that a small investment of time now would result in a large savings
of both time and uncertainty later. I think I have failed, since it's
turned into a large investment of time now, with all too much uncertainty.
It'll be easier to just go back to watching and rev my software later if
necessary.
I am sympathetic, to a point. I have poured FAR too much time into these
discussions, and so far have nothing whatever to show for it. I know that the
subscription list to this board is probably in the thousands, but you wouldn't
know it by reading. You, Ned, Jim Galvin, Steve Crocker, and perhaps Rhys
Weatherley represent one point of view, while I and perhaps Jeff Thompson,
maybe Peter Williams (I can't always be sure) and at most one or two others
have represented another point of view. Steve Kent may file a minority report
disagreeing with everybody, and the other 990 people have hardly said boo.
(Maybe their 9600 bps lines are still catching up to the Christmas traffic. :-)
At this point, this WG is no longer at the leading edge.
The edge may be blunted and nicked a little, but who would you claim is moving
more rapidly towards a concensus in this area?
Even the Post Office is ahead of us.
I don't think so. The issues of what makes up a "good" distinguished name are
still going to be with us, as Ned's message illustrates. Just becasue the Post
Office is willing to act as a PCA or CA won't relieve the lawyer's from arguing
over who has the right to use a given name, and what the implications are of
identifying a user as an organizational person. and based on the discussions
within the NADF, I think they are as confused as anyone as to how to deal with
the issue of residential persons and some of the questions of privacy that have
arisen. I haven't seen any schema described for their X.500 directory yet (if
they intend to offer X.500).
Although Dick Rothwell and his folks have done an absoutely amazing job in
getting a 200 year old organization to take on such an initiative, I think they
are right in the middle of the pack with the rest of us. I wish them well, even
as a potential competitor, but I'm not conceding the playing field quite yet.
Bob
--------------------------------
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
FAX: 1-617-466-2603
Voice: 1-617-466-2820