3.4.2 HTTPS - client

3.4.3 S/MIME - email

There are two things that should be set in S/MIME certificates, one or
more email addresses and an extended eku usage (EKU), emailProtection.

The email address format used in S/MIME certificates is defined in
RFC2822, section 3.4.1 and it should be an “addr-spec”.

There are two ways to specifify email address in certificates. The old
way is in the subject distinguished name, this should not be used. The
new way is using a Subject Alternative Name (SAN).

Even though the email address is stored in certificates, they don't need
to be, email reader programs are required to accept certificates that
doesn't have either of the two methods of storing email in certificates
– in which case, the email client will try to protect the user by
printing the name of the certificate instead.

S/MIME certificate can be used in another special way. They can be
issued with a NULL subject distinguished name plus the email in SAN,
this is a valid certificate. This is used when you wont want to share
more information then you need to.

hx509 issue-certificate supports adding the email SAN to certificate by
using the –email option, –email also gives an implicit emailProtection
eku. If you want to create an certificate without an email address, the
option –type=email will add the emailProtection EKU.

3.4.4 PK-INIT

A PK-INIT infrastructure allows users and services to pick up kerberos
credentials (tickets) based on their certificate. This, for example,
allows users to authenticate to their desktops using smartcards while
acquiring kerberos tickets in the process.

As an example, an office network which offers centrally controlled
desktop logins, mail, messaging (xmpp) and openafs would give users
single sign-on facilities via smartcard based logins. Once the kerberos
ticket has been acquired, all kerberized services would immediately
become accessible based on deployed security policies.

The certificate may also contain a jabber identifier (JID) that, if the
receiver allows it, authorises the server or client to use that JID.

When storing a JID inside the certificate, both for server and client,
it's stored inside a UTF8String within an otherName entity inside the
subjectAltName, using the OID id-on-xmppAddr (1.3.6.1.5.5.7.8.5).

To read more about the requirements, see RFC3920, Extensible Messaging
and Presence Protocol (XMPP): Core.

hxtool issue-certificate have support to add jid to the certificate
using the option --jid.