One or two people does not constitute a concensus, of course, so I would be
particularly interested in hearing from Ned, Steve Crocker, Jim Galvin, Steve
Dusse, and other known or potential implementors. Sead Muftic and Jeff
Schiller
haven't been heard from recently, and it would be nice to hear from Mike
Riordan well.
Jeff, my apologies for not answering this sooner. Although it was only a few
days
ago, a torrent of messages have intervened.
As an implementor on RIPEM I may be able to speak for Mark Riordan if
he isn't monitoring pem-dev right now. I would agree with Amanda
Walker that tracking X.509 to version 3 is inevitable. RIPEM already
uses version 1 X.509 of course.
I was just noting that the spec for classic PEM has not yet been updated to use
version 2, which includes the uniqueID feature to allow different certificates
for
the same user DN to be differentiated. If the spec doesn't include it, support
is
not necessarily a foregone conclusion.
I would also take Ned Freed's word
for it that referencing a non-existent document could delay MIME/PEM.
I understand and am sympathetic to Ned's point. I don't want to get caught up in
some form of a chicken and egg squabble between standards groups. However, I
strongly doubt that Ned, Amanda, or anyone else will be holding his/her breath
waiting for every last procedural detail to be completed on the final IETF
standards document before they ship the product, so I doubt that it matters all
that much.
Perhaps one way to proceed would be to simply copy the definition verbatim from
the
proposed X.509 draft, and co-opt it. After all, the relevant text is quite
short.
If some minor change is made, we could make the same minor correction later on,
once the dust settles. (I'm assuming that there isn't some big copyright problem
here.)
Alternatively, we could register the new attribute under a different OID, and
later
come to the happy realization that the ISO version and ours were really the
same,
and correct the OID at that time. If it would take too long to get that
registered
under the IANA, I would be happy to register the attribute under GTE Labs OID
and
assign it a unqiue number. That is the approach that the NADF has taken with
respect to useful attributes that other organizations have created and
registered
-- they simply reference the other organization's definition rather than
duplicating it.
I'd really like to hear from someone who is more familiar with the politics of
the
IETF as to how to creatively and aggressively move this item forward, rather
than
coming up more reasons why we shouldn't. From the standpoint of both the spec
and
the various implementations I can't imagine that this is a big deal if we do it
now, but it might be later on.
However, I want to ask, is there anything in particular you wanted
MIME/PEM to utilize explicitly from X.509 v3, rather than just waiting
for all the neat stuff to show up eventually as a natural upgrade?
Yes. By FAR the most important, in my judgment, is the ability to flag a new
attribute as critical, so that if an implementation doesn't understand or
support
the option, the user can be warned that the signature cannot be validated
completely.
As one example, one of the problems that I have repeatedly mentioned with
respect
to the use of a digital signature is the potentially unbounded nature of the
liabilities that might be faced if a user's keys were stolen or
misappropriated. In
the absence of specifc consumer protection legislation, no lawyer that I have
yet
talked to has been able to say convincingly that there is any finite limit to
the
liability, except for the fact that the larger the single transaction the more
the
buyer is responsible for exercising due diligence. That leaves me very
uncomfortable as to the amount of risk that I may be taking.
If I am going to use a digital signature for my private affairs, I want a way to
specify some upper limit to the amount that signature can be used to commit me
to,
even if the keys are stolen, just as many corporate checks state that the check
is
not valid for more than $1000 unless countersigned. Unfortunately, I probably
won't
be able to get the person who steals my key and forges my name to include that
caveat in the forged document!
Although we have explored the possibility of putting such limits in the policy
statement of the PCA and/or the CA (along the lines of "this certificate and any
digital signatures resulting from it, are absolutely worthless and null and
void,
_unless_ the following conditions are true."), there are some significant
issues as
to whether that would constitute adequate legal notice if it is merely
published as
part of the PCA's policy statement. It seems necessary to bring it to the
recipient's attention in a way that is inescapable, even if it is in fine print.
The most obvious place to put such a notice, therefore, is in the certificate
itself, with the critical flag turned on to ensure that the user's software is
cognizant of how to process that caveat.
Without the critical flag, and without the ability to add such an attribute to
the
certificate outside of the DN, I could force such a field into the certificate
by
adding something like a Description field to the DN. But even I would tend to
agree
that would be tacky, and worse yet might be ignored without notice, although
that
is what I'll do if I can't get anything better.
I'm going to assume that PEM/MIME will be a huge success, and that therefore
there
will be lots of the early implementations out there. Instead of slowing down the
entire standards process until we can argue through each of these potentially
useful new attributes, I would much rather see the v3 spec go forward. We can
later
add new attributes that can safely be ignored by back-level implementations, and
not risk misunderstanding of critical attributes by those same implementations
if
an attribute is really important.
For example, are you suggesting that we use the email name support
that X.509 v3 describes rather than using the <id-email> identifier
that the MIME/PEM draft defines? This is another case where I would
like to hear from the advocates that motivated MIME/PEM to define this
identifier. Would the email name support in X.509 v3 satisfy these
needs?
Aw, shucks, you saw through my diabolical scheme. I certainly think that it
should
suffice, and even if the die-hards insist on the current key selector form, the
users would eventually realize that it was redundant, and the usage would wither
away.
However, I want to stress that I am NOT suggesting that we wait for or
necessarily
buy into all of the various and neat attributes that Warwick and others are in
the
process of defining or recommending. Many of them, including ways to
administering
the chain of PCA-CA hierarchies, will turn out to be very valuable in the end,
but
extensive debate will probably be required before there is concensus on those
points.
I will therefore be quite happy if we can just agree on the basic format that
incldues the ability to define extensions as either optional or cirtical,
without
necessarily agreeing on precisely which set of attributes should be supported at
this time.
Bob
--------------------------------
Robert R. Jueneman
Staff Scientist
Wireless and Secure Systems Laboratory
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
Internet: Jueneman(_at_)gte(_dot_)com
FAX: 1-617-466-2603
Voice: 1-617-466-2820