[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: USENIX PGP key signing service
Carl Ellison <cme@cybercash.com> wrote:
At 02:20 PM 5/29/96 +1000, Greg Rose wrote:
>USENIX is setting up a PGP key-signing service,
>intended to go live at the 6th USENIX Security
>Symposium in July. A description of it is up on
>the Web at http://www.usenix.org/pgpkey.html .
>I'd appreciate any comments, particularly
>about the way we handle people who don't have
>their key fingerprints available at the time.
this effort mimics the X.509 CAs and has some of their flaws.
Yes indeedy. While I agree with your comments
generally, in context they are not what the
service is about. While I think we would all
applaud a new standard for certificates when it
appears, we would then be faced with the problem
of getting CAs (or non-authoritative equivalents,
like what we're trying to do at USENIX) set up.
What USENIX is doing is trying to get some
infrastructure going based around the currently
deployed technology, warts and all. Then, when
spki bears fruit, or SDSI is ready for prime time,
we can (and almost certainly will) add those
forms. In the meantime we are adding a modest
service to the PGP community.
1. There's no way specified for the user to know what USENIX certifies
with that binding. That is, PGP provides no Meaning field. It could --
since USENIX could generate its own UserID for a key, giving the meaning "we
saw 2 forms of ID for this USENIX member", and sign that -- but I tried that
and the new Meaning non-user-ID showed up as the primary ID for the key once
it was added to the PGP key server at MIT. Bummer.
We've finessed this by effectively saying (via our
web pages) what the meaning is, without attempting
to state it in the certificate itself. I consider
the common usage of PGP to be an implementation
constraint.
2. The lack of global names isn't addressed. At the least, we should
find a way to implement a trial of the Rivest & Lampson SDSI. This too
could be accomplished if PGP were extended to have Meaning fields. In that
case, USENIX could sign an ID record of the form "I know this person as
USENIX member Greg Rose".
Ditto.
3. You have made no provision for verifying that the user whose key
you're signing can, in fact, exerecise the associated private key. You
should include his signing a random challenge message in your presence as
part of the process.
"In our presence"? We aren't even asking that they
actually have a fingerprint with them when we do
the identification (or even have created the key),
so this is a bit crippling. (In my experience at
many PGP-key-signings, there are a lot of people
who are interested and want to participate, but
aren't quite there yet -- they always feel left
out, and may not get another chance straight away.
That's why we've designed the "shared secret"
mechanism.)
Neal McBurnett <nealmcb@lucent.com> wrote (in
private email but I assume he won't mind me
quoting):
Neal>But it doesn't really verify the most important bit of identity which
Neal>was signed - the email address! You also don't give a procedure
Neal>for getting a signature on a new email address, which would be
Neal>very useful.
Neal>
Neal>I really think it will have more integrity if you make
Neal>sure that the email address which is signed is correct.
Neal>To do this you need to send some secret info to that address
Neal>and have them respond with that secret info as well as the
Neal>shared secret given to them at the conference. You should
Neal>do this each year at renewal, also.
I was of a mind that getting the shared secret
(which doubles as a random challenge) from the
email address was good enough, but maybe not. I'll
think more on this but probably implement Neal's
suggestion. It's important for the other case,
where we are given a fingerprint over the counter,
anyway.
This can be done for a near-term experiment with UserID records. However, a
small change to PGP would allow it to be done right -- making a key
signature record which carries its own meaning field.
There's another possibility. USENIX could generate normal signed PGP
messages of the form:
[...]
Again, yes, we could do this, but PGP as deployed
wouldn't know anything about it, wouldn't consider
it in the Web of Trust, and so on. Certainly worth
considering for new versions of PGP, and then we
could incorporate it. We do do something like this
already, when (for whatever reason) we have revoked
a signature. Since PGP doesn't support it, we did
the next best thing.
Thanks, all, for comments,
Greg
Greg Rose INTERNET: ggr@usenix.org (Joining Qualcomm July 1)
Sterling Software VOICE: +61-2-9975 4777 FAX: +61-2-9975 2921
28 Rodborough Rd. <A HREF="http://usenix.org/~ggr/">homepage</A>
French's Forest 35 0A 79 7D 5E 21 8D 47 E3 53 75 66 AC FB D9 45
NSW 2086 Australia. co-mod sci.crypt.research, USENIX Director.
Follow-Ups: