problems with X.509 certs + KDE 3.1 + KMail ??

[Bernhard Reiter]

--3Gf/FFewwPeBMqCJ
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 14, 2003 at 04:21:50PM +0100, Zdenek Pizl wrote:
> Dne p=E1tek, 14. =FAnor. 2003 12:07 Bernhard Reiter <bernhard@intevation.=
de>=20
> napsal(a):
> > > > The SPHINX specification (and others)
> > > > requires the e-mail-address to be in the extention like
> > > >             X509v3 Subject Alternative Name:
> > > >                 email:bernhard@intevation.de
> > > aha, I am sure enough that our certificates don't have altName featur=
e.
> > > OK, I'll check it ...
> > >
> > > But I can't understand it,
> > > why it rely on (optional) altName when email can be
> > > obtained from the standard DN ??
> > Because that is the required method according to the standard.
> > http://www.ietf.org/rfc/rfc2459.txt
> > 4.1.2.6  Subject
>=20
> hmm, I've carefuly read it, and there is no MUST. No requirement about it=
.=20

How do you interpret:

   Conforming implementations generating new certificates with
   electronic mail addresses MUST use the rfc822Name in the subject
                             ^^^^
   alternative name field (see sec. 4.2.1.7) to describe such
   identities.

> As=20
> I've spoken to some people from an certification authority, there is no n=
eed=20
> (it is not requested by any standard) to include Altname.
>=20
> Other clients (MS Outlook, Outlook Express, Mozilla) work without it. Onl=
y=20
> "aegypten-ized" clients have those problems ... Hmm, I am confused.=20
>=20
> It is true that with Altname feature in cert, KMail works fine.
> But as I said, it's functionality rely on OPTIONAL extension, and
> I feel it is wrong way.

I've talked to the experts at the BSI and g10code.
They assured my that my interpretation is fine.

--3Gf/FFewwPeBMqCJ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE+TQ3lh9ag3dpKERYRAg6NAJ43wscDSCujmcQBQUNd5icIQ5Jx0ACgy/rs
QUZwQUT1++0yP7ZZomisvhk=
=8x4V
-----END PGP SIGNATURE-----

--3Gf/FFewwPeBMqCJ--