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

[Bernhard Reiter]

--GvXjxJ+pjyke8COw
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 14, 2003 at 09:30:05AM +0100, Zdenek Pizl wrote:
> Dne p=E1tek, 7. =FAnor. 2003 17:00 Bernhard Reiter <bernhard@intevation.d=
e>=20
> napsal(a):
> > There are several options to openssl.
> > It really is complex and I'm not an expert.
>=20
> > This is fine:
> >
> > The SPHINX specification (and others)
> > requires the e-mail-address to be in the extention like
> >             X509v3 Subject Alternative Name:
> >                 email:bernhard@intevation.de
>=20
> aha, I am sure enough that our certificates don't have altName feature. O=
K,=20
> I'll check it ...
>=20
> But I can't understand it,=20
> why it rely on (optional) altName when email can be=20
> 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

[...]

   In addition, legacy implementations exist where an RFC 822 name is
   embedded in the subject distinguished name as an EmailAddress
   attribute.  The attribute value for EmailAddress is of type IA5String
   to permit inclusion of the character '@', which is not part of the
   PrintableString character set.  EmailAddress attribute values are not
   case sensitive (e.g., "fanfeedback@redsox.com" is the same as=20
   "FANFEEDBACK@REDSOX.COM").

   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  =20
   identities.  Simultaneous inclusion of the EmailAddress attribute in
   the subject distinguished name to support legacy implementations is
   deprecated but permitted.


> > 	subjectAltName=3Demail:intevation@intevation.de,URI:http://intevation.=
net
> > 	issuerAltName=3Demail:intevation@intevation.de,URI:http://intevation.n=
et
>=20
> this is your personalized openssl.conf settings , isn't it?

Yes.

--GvXjxJ+pjyke8COw
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE+TM3Xh9ag3dpKERYRAkJcAKCGr2GPmTmmRVJkAID4izXFe1KuUwCfUYcK
y7eZ6zaeI5JiVs6zCkP+2cI=
=XX/3
-----END PGP SIGNATURE-----

--GvXjxJ+pjyke8COw--