[Top] [All Lists]

Re: The address-in-certs issue

1997-12-23 08:08:56
From: John Gardiner Myers <jgmyers(_at_)netscape(_dot_)com>
Date: Fri, 19 Dec 1997 14:50:07 -0800

David P. Kemp wrote:
Reasons include 1) the more information that goes into a cert, the shorter
the expected lifetime,

Then take out other information.  RFC822 identities are what are used in
Internet Mail, and if you're securing Internet Mail objects, those are
the identities you need to certify.

  --- and ---

From: John Gardiner Myers <jgmyers(_at_)netscape(_dot_)com>
Date: Mon, 22 Dec 1997 18:09:51 -0800

Even simpler, I could have a certificate with both
12345,3924(_at_)compuserve(_dot_)com and "John Gardiner Myers" 

Is it too much to ask that your arguments at least be self-consistent?
You can't simultaneously take extra information out of and put extra
information into a certificate.

If we agree that relatively long-lived stable identities are a goal,
and that accommodating environments where mail can reach a given user
by multiple and occasionally or frequently changing addresses is also
a goal, then we can't reach both goals by putting all the delivery
addresses into a cert.

   [address-book-subversion discussion]

Paul needs to send you an important, private message.  Paul is a busy
person.  He's the co-founder of an industry consortium for Internet
mail.  Having much familiarity with Internet mail, he uses the same,
simple, interface he has always used for informing his UA to whom the
mail is intended: he types "dkemp(_at_)missi(_dot_)ncsc(_dot_)mil" into the 
To: field of
his compose window.

Paul is a busy person, so he types "kemp" into his compose window.  His
MUA has a database of certificates, each of which has a subject name
bound to a public key.  The list of subjects matching "kemp" pops up,
and Paul clicks on the correct one.  If there is only one match, the
MUA displays the full name and either asks for confirmation if Paul has
previously checked the "always ask" option, or proceeds if the option is

That is because Paul, being a busy person, doesn't have the time to
parse the DN for every message he receives.  Being an Internet mail kind
of person, he thinks in terms of RFC822 syntax.
Most Internet mail users can't distinguish a DN from base64-encoded
line noise.

That is a remarkably insulting statement - I'm glad you said it about
Paul and not me :-).  I give even computer-using mothers-in-law* credit
for being able to recognize ", CN=Paul Hoffman" as easily as
they would "Paul Hoffman / IMC <phoffman(_at_)imc(_dot_)org>".

And I give credit to MUA designers to be able to present "Paul Hoffman"
to the user given either form as input, and allow the curious to
explicitly seek further details.

* I love my mother-in-law, really!  And she does use a computer.

<Prev in Thread] Current Thread [Next in Thread>