[13479] in cryptography@c2.net mail archive
Re: Maybe It's Snake Oil All the Way Down
daemon@ATHENA.MIT.EDU (Eric Rescorla)
Fri Jun 6 15:02:54 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
To: Derek Atkins <derek@ihtfp.com>
Cc: Eric Murray <ericm@lne.com>,
Peter Gutmann <pgut001@cs.auckland.ac.nz>, jamesd@echeque.com,
bill.stewart@pobox.com, cryptography@metzdowd.com,
cypherpunks@lne.com, rsalz@datapower.com, sguthery@mobile-mind.com
Reply-To: EKR <ekr@rtfm.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: 05 Jun 2003 17:57:18 -0700
In-Reply-To: <sjmisrkoxmp.fsf@kikki.mit.edu>
Derek Atkins <derek@ihtfp.com> writes:
> Eric Murray <ericm@lne.com> writes:
>
> > Too often people see something like Peter's statement above and say
> > "oh, it's that nasty ASN.1 in X.509 that is the problem, so we'll just
> > do it in XML instead and then it'll work fine" which is simply not true.
> > The formatting of the certificates is such a minor issue that it is lost
> > in the noise of the real problems. And Peter publishes a fine tool
> > for printing ASN.1, so the "human readable" argument is moot.
>
> Actually, the ASN.1 part is a major factor in the X.509
> interoperability problems. Different cert vendors include different
> extensions, or different encodings. They put different information
> into different parts of the certificate (or indeed the same
> information into different parts). Does the FQDN for a server cert
> belong in the DN or some extension? What about the email address for
> a user cert?
This isn't really true in the SSL case:
To a first order, everyone ignores any extensions (except sometimes
the constraints) and uses the CN for the DNS name of the server.
-Ekr
--
[Eric Rescorla ekr@rtfm.com]
http://www.rtfm.com/
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
