x509 Certificate Attributes¶
See RFC 5280.
Subject Alternative Name¶
- email (an email address)
- URI (uniform resource indicator)
- DNS (a DNS domain name)
- RID (a registered ID: OBJECT IDENTIFIER)
- IP (an IPv4 or IPv6 address)
- dirName (a distinguished name)
- otherName (arbitrary data associated with an OID)
XMPP addresses in Certificates¶
RFC RFC 6120 “Extensible Messaging and Presence Protocol (XMPP): Core”
Section 126.96.36.199. “Server Certificates” defines what to include in certificates for XMPP servers.
Section 188.8.131.52. “Client Certificates” defines how XMPP addresses are to be added to client certificates.
Section 13.7.2. “Certificate Validation” describe how these certificates are validated by clients and servers.
The RFC defines new OIDs (Object Identifiers) which should be induced as attributes in the SubjAltName part of a certificate as OtherName:
Current versions of OpenSSL (1.0.1) don’t yet support the xmppAddr OID natively, but new OIDs can be defined to the configuration:
oid_section = new_oids [ new_oids ] id-on-xmppAddr = 184.108.40.206.220.127.116.11.5 id-on-dnsSRV = 18.104.22.168.22.214.171.124.7
Once defined they can be added to client certificates as follows:
[ subject_alt_name ] otherName = id-on-xmppAddr;UTF8:firstname.lastname@example.org
[ subject_alt_name ] otherName = SRVName;UTF8:_xmpp-client.example.net otherName = SRVName;UTF8:_xmpp-server.example.net dNSName = otherName = id-on-xmppAddr;UTF8:email@example.com
This should be added to OpenSSL all configurations used for creating requests (CSR) and of the CA signing the certificates.
The public key is of the certificate will be used for verification of digital signatures.
This might be signed content of an email message or a file signature or data requested by a client from server.
This does not include verification of signatures typically issued by CAs, like the signatures of certificates and CRLs.
Useful for mail clients, websites and other servers
Lately renamed to contentCommitment. The public key of the certificate will be used to verify the digital signature of a message by a trusted third party.
The trusted third party might store this as proof, that a particular message has been sent by the certificate owner at a particular time.
The idea here is to make it impossible for the sending party to later deny that it had sent a particular message.
Rarely used. We don’t know any useful application.
The public key of a certificate can be used to encrypt another key for subsequent communication.
This usually happens during a TLS handshake.
The connecting party knows the other party’s public key, which allows it to send encrypted data which only the owner of the private key of the certificate can decipher.
But since this is slow, and keys are big (private keys should be between 2048 to 4096 bits) the parties agree on a symmetric encryption which works both ways, is faster and provides equal security with smaller keys (128 or 256 bits).
This symmetric key is encrypted with the public key of the certificate before it is sent to the other party. As only the certificate owner can decrypt it, the key used for symmetric encryption remains a secret only the two parties know of.
Used by servers who use certificates with RSA keys.
The public key of the certificate can be used to directly encrypt data, without going trough the step of encrypting a symmetric key to be used later for the data encryption, as with keyEncipherment.
Since is this is usually slower and needs more resources it is rarely used.
The public key of this certificate can be used for Diffie-Hellman key exchange (DHE).
Certificates who use DHE key-pairs use a different approach them RSA certificates. But the goal remains the same: Share a key with the other party, which then can be used to securely encrypt the actual communication data.
Use by clients or servers who use certificates with DHE keys.
The public key of this certificate can be used to verify signatures of other certificates.
Mandatory for certificate authorities.
The public key of this certificate can be used to verify signatures of certificate reudation lists (CRLs).
Mandatory for certificate authorities.
The public key of a certificate with DHE keys can be used to send encrypted data, while a key agreement between the two parties is in progress.
It excludes the use of digitalSignature and nonRepudiation.
Only used if keyAgreement is also set, thus only useful for certificates with DHE keys.
Might be used by websites and other servers who use certificates with DHE keys.
Recommended Certificate KeyUsage and ExtendedKeyUsage combinations:
|Mail Client||DHE||digitalSignature, keyAgreement||clientAuth, emailProtection|
|Mail Client||ECDHE||digitalSignature, keyAgreement||clientAuth, emailProtection|
|Mail Client||RSA||digitalSignature||clientAuth, emailProtection|
|TLS Client||DHE||digitalSignature, keyAgreement||clientAuth|
|TLS Client||ECDHE||digitalSignature, keyAgreement||clientAuth|
|TLS Server||DHE||digitalSignature, keyAgreement||clientAuth, serverAuth|
|TLS Server||DHE||keyAgreement, encipherOnly||clientAuth, serverAuth|
|TLS Server||ECDHE||digitalSignature, keyAgreement||clientAuth, serverAuth|
|TLS Server||ECDHE||keyAgreement, encipherOnly||clientAuth, serverAuth|
|TLS Server||RSA||digitalSignature, keyEncipherment||clientAuth, serverAuth|