634 lines
21 KiB
Plaintext
634 lines
21 KiB
Plaintext
\input texinfo @c -*- texinfo -*-
|
|
@c %**start of header
|
|
@c $Id: hx509.texi 22071 2007-11-14 20:04:50Z lha $
|
|
@setfilename hx509.info
|
|
@settitle HX509
|
|
@iftex
|
|
@afourpaper
|
|
@end iftex
|
|
@c some sensible characters, please?
|
|
@tex
|
|
\input latin1.tex
|
|
@end tex
|
|
@setchapternewpage on
|
|
@syncodeindex pg cp
|
|
@c %**end of header
|
|
|
|
@set UPDATED $Date: 2007-11-14 12:04:50 -0800 (Ons, 14 Nov 2007) $
|
|
@set VERSION 1.0
|
|
@set EDITION 1.0
|
|
|
|
@ifinfo
|
|
@dircategory Security
|
|
@direntry
|
|
* hx509: (hx509). The X.509 distribution from KTH
|
|
@end direntry
|
|
@end ifinfo
|
|
|
|
@c title page
|
|
@titlepage
|
|
@title HX509
|
|
@subtitle X.509 distribution from KTH
|
|
@subtitle Edition @value{EDITION}, for version @value{VERSION}
|
|
@subtitle 2007
|
|
@author Love Hörnquist Åstrand
|
|
@author last updated @value{UPDATED}
|
|
|
|
@def@copynext{@vskip 20pt plus 1fil@penalty-1000}
|
|
@def@copyrightstart{}
|
|
@def@copyrightend{}
|
|
@page
|
|
@copyrightstart
|
|
Copyright (c) 1994-2007 Kungliga Tekniska Högskolan
|
|
(Royal Institute of Technology, Stockholm, Sweden).
|
|
All rights reserved.
|
|
|
|
Redistribution and use in source and binary forms, with or without
|
|
modification, are permitted provided that the following conditions
|
|
are met:
|
|
|
|
1. Redistributions of source code must retain the above copyright
|
|
notice, this list of conditions and the following disclaimer.
|
|
|
|
2. Redistributions in binary form must reproduce the above copyright
|
|
notice, this list of conditions and the following disclaimer in the
|
|
documentation and/or other materials provided with the distribution.
|
|
|
|
3. Neither the name of the Institute nor the names of its contributors
|
|
may be used to endorse or promote products derived from this software
|
|
without specific prior written permission.
|
|
|
|
THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND
|
|
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE
|
|
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
SUCH DAMAGE.
|
|
|
|
@copynext
|
|
|
|
Copyright (C) 1990 by the Massachusetts Institute of Technology
|
|
|
|
Export of this software from the United States of America may
|
|
require a specific license from the United States Government.
|
|
It is the responsibility of any person or organization contemplating
|
|
export to obtain such a license before exporting.
|
|
|
|
WITHIN THAT CONSTRAINT, permission to use, copy, modify, and
|
|
distribute this software and its documentation for any purpose and
|
|
without fee is hereby granted, provided that the above copyright
|
|
notice appear in all copies and that both that copyright notice and
|
|
this permission notice appear in supporting documentation, and that
|
|
the name of M.I.T. not be used in advertising or publicity pertaining
|
|
to distribution of the software without specific, written prior
|
|
permission. M.I.T. makes no representations about the suitability of
|
|
this software for any purpose. It is provided "as is" without express
|
|
or implied warranty.
|
|
|
|
@copynext
|
|
|
|
Copyright (c) 1988, 1990, 1993
|
|
The Regents of the University of California. All rights reserved.
|
|
|
|
Redistribution and use in source and binary forms, with or without
|
|
modification, are permitted provided that the following conditions
|
|
are met:
|
|
|
|
1. Redistributions of source code must retain the above copyright
|
|
notice, this list of conditions and the following disclaimer.
|
|
|
|
2. Redistributions in binary form must reproduce the above copyright
|
|
notice, this list of conditions and the following disclaimer in the
|
|
documentation and/or other materials provided with the distribution.
|
|
|
|
3. Neither the name of the University nor the names of its contributors
|
|
may be used to endorse or promote products derived from this software
|
|
without specific prior written permission.
|
|
|
|
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
|
|
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
|
|
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
SUCH DAMAGE.
|
|
|
|
@copynext
|
|
|
|
Copyright 1992 Simmule Turner and Rich Salz. All rights reserved.
|
|
|
|
This software is not subject to any license of the American Telephone
|
|
and Telegraph Company or of the Regents of the University of California.
|
|
|
|
Permission is granted to anyone to use this software for any purpose on
|
|
any computer system, and to alter it and redistribute it freely, subject
|
|
to the following restrictions:
|
|
|
|
1. The authors are not responsible for the consequences of use of this
|
|
software, no matter how awful, even if they arise from flaws in it.
|
|
|
|
2. The origin of this software must not be misrepresented, either by
|
|
explicit claim or by omission. Since few users ever read sources,
|
|
credits must appear in the documentation.
|
|
|
|
3. Altered versions must be plainly marked as such, and must not be
|
|
misrepresented as being the original software. Since few users
|
|
ever read sources, credits must appear in the documentation.
|
|
|
|
4. This notice may not be removed or altered.
|
|
|
|
@copynext
|
|
|
|
IMath is Copyright 2002-2005 Michael J. Fromberger
|
|
You may use it subject to the following Licensing Terms:
|
|
|
|
Permission is hereby granted, free of charge, to any person obtaining
|
|
a copy of this software and associated documentation files (the
|
|
"Software"), to deal in the Software without restriction, including
|
|
without limitation the rights to use, copy, modify, merge, publish,
|
|
distribute, sublicense, and/or sell copies of the Software, and to
|
|
permit persons to whom the Software is furnished to do so, subject to
|
|
the following conditions:
|
|
|
|
The above copyright notice and this permission notice shall be
|
|
included in all copies or substantial portions of the Software.
|
|
|
|
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
|
|
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
|
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
|
|
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
|
|
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
|
|
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
|
|
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
|
|
|
@copyrightend
|
|
@end titlepage
|
|
|
|
@macro manpage{man, section}
|
|
@cite{\man\(\section\)}
|
|
@end macro
|
|
|
|
@c Less filling! Tastes great!
|
|
@iftex
|
|
@parindent=0pt
|
|
@global@parskip 6pt plus 1pt
|
|
@global@chapheadingskip = 15pt plus 4pt minus 2pt
|
|
@global@secheadingskip = 12pt plus 3pt minus 2pt
|
|
@global@subsecheadingskip = 9pt plus 2pt minus 2pt
|
|
@end iftex
|
|
@ifinfo
|
|
@paragraphindent 0
|
|
@end ifinfo
|
|
|
|
@ifnottex
|
|
@node Top, Introduction, (dir), (dir)
|
|
@top Heimdal
|
|
@end ifnottex
|
|
|
|
This manual is last updated @value{UPDATED} for version
|
|
@value{VERSION} of hx509.
|
|
|
|
@menu
|
|
* Introduction::
|
|
* What is X.509 ?::
|
|
* Setting up a CA::
|
|
* CMS signing and encryption::
|
|
|
|
@detailmenu
|
|
--- The Detailed Node Listing ---
|
|
|
|
Setting up a CA
|
|
|
|
@c * Issuing certificates::
|
|
* Creating a CA certificate::
|
|
* Issuing certificates::
|
|
* Issuing CRLs::
|
|
@c * Issuing a proxy certificate::
|
|
@c * Creating a user certificate::
|
|
@c * Validating a certificate::
|
|
@c * Validating a certificate path::
|
|
* Application requirements::
|
|
|
|
CMS signing and encryption
|
|
|
|
* CMS background::
|
|
|
|
@end detailmenu
|
|
@end menu
|
|
|
|
@node Introduction, What is X.509 ?, Top, Top
|
|
@chapter Introduction
|
|
|
|
hx509 is a somewhat complete X.509 stack that can handle CMS messages
|
|
(crypto system used in S/MIME and Kerberos PK-INIT) and basic
|
|
certificate processing tasks, path construction, path validation, OCSP
|
|
and CRL validation, PKCS10 message construction, CMS Encrypted (shared
|
|
secret encrypted), CMS SignedData (certificate signed), and CMS
|
|
EnvelopedData (certificate encrypted).
|
|
|
|
hx509 can use PKCS11 tokens, PKCS12 files, PEM files, DER encoded files.
|
|
|
|
@node What is X.509 ?, Setting up a CA, Introduction, Top
|
|
@chapter What is X.509, PKIX, PKCS7 and CMS ?
|
|
|
|
X.509 is from the beginning created by CCITT (later ITU) for the X.500
|
|
directory service. But today when people are talking about X.509 they
|
|
are commonly referring to IETF's PKIX Certificate and CRL Profile of the
|
|
X.509 v3 certificate standard, as specified in RFC 3280.
|
|
|
|
ITU continues to develop the X.509 standard together in a complicated
|
|
dance with IETF.
|
|
|
|
X.509 is public key based security system that have associated data
|
|
stored within a so called certificate. From the beginning X.509 was a
|
|
strict hierarchical system with one root. This didn't not work so over
|
|
time X.509 got support for multiple policy roots, bridges, and mesh
|
|
solutions. You can even use it as a peer to peer system, but this is not
|
|
very common.
|
|
|
|
@section Type of certificates
|
|
|
|
There are several flavors of certificate in X.509.
|
|
|
|
@itemize @bullet
|
|
|
|
@item Trust anchors
|
|
|
|
Trust anchors are strictly not certificate, but commonly stored in
|
|
certificate since they are easier to handle then. Trust anchor are the
|
|
keys that you trust to validate other certificate. This is done by
|
|
building a path from the certificate you wan to validate to to any of
|
|
the trust anchors you have.
|
|
|
|
@item End Entity (EE) certificates
|
|
|
|
End entity certificates is the most common type of certificate. End
|
|
entity certificates can't issue certificate them-self and is used to
|
|
authenticate and authorize user and services.
|
|
|
|
@item Certification Authority (CA) certificates
|
|
|
|
Certificate authority are certificates that have the right to issue
|
|
other certificate, they may be End entity certificates or Certificate
|
|
Authority certificates. There is no limit to how many certificates a CA
|
|
may issue, but there might other restrictions, like the maximum path
|
|
depth.
|
|
|
|
@item Proxy certificates
|
|
|
|
Remember that End Entity can't issue certificates by them own, it's not
|
|
really true. There there is an extension called proxy certificates,
|
|
defined in RFC3820, that allows certificates to be issued by end entity
|
|
certificates. The service that receives the proxy certificates must have
|
|
explicitly turned on support for proxy certificates, so their use is
|
|
somewhat limited.
|
|
|
|
Proxy certificates can be limited by policy stored in the certificate to
|
|
what they can be used for. This allows users to delegate the proxy
|
|
certificate to services (by sending over the certificate and private
|
|
key) so the service can access services on behalf of the user.
|
|
|
|
One example of this would be a print service. The user wants to print a
|
|
large job in the middle of the night when the printer isn't used that
|
|
much, so the user creates a proxy certificate with the policy that it
|
|
can only be used to access files related to this print job, creates the
|
|
print job description and send both the description and proxy
|
|
certificate with key over to print service. Later at night will the
|
|
print service, without the help of the user, access the files for the
|
|
the print job using the proxy certificate and print the job. Because of
|
|
the policy (limitation) in the proxy certificate, it can't be used for
|
|
any other purposes.
|
|
|
|
@end itemize
|
|
|
|
@section Building a path
|
|
|
|
Before validating a path the path must be constructed. Given a
|
|
certificate (EE, CA, Proxy, or any other type), the path construction
|
|
algorithm will try to find a path to one of the trust anchors.
|
|
|
|
It start with looking at whom issued the certificate, by name or Key
|
|
Identifier, and tries to find that certificate while at the same time
|
|
evaluates the policy.
|
|
|
|
@node Setting up a CA, Creating a CA certificate, What is X.509 ?, Top
|
|
@chapter Setting up a CA
|
|
|
|
Do not let this chapter scare you off, it's just to give you an idea how
|
|
to complicated setting up a CA can be. If you are just playing around,
|
|
skip all this and go to the next chapter, @pxref{Creating a CA
|
|
certificate}.
|
|
|
|
Creating a CA certificate should be more the just creating a
|
|
certificate, there is the policy of the CA. If it's just you and your
|
|
friend that is playing around then it probably doesn't matter what the
|
|
policy is. But then it comes to trust in an organisation, it will
|
|
probably matter more whom your users and sysadmins will find it
|
|
acceptable to trust.
|
|
|
|
At the same time, try to keep thing simple, it's not very hard to run a
|
|
Certificate authority and the process to get new certificates should
|
|
simple.
|
|
|
|
Fill all this in later.
|
|
|
|
How do you trust your CA.
|
|
|
|
What is the CA responsibility.
|
|
|
|
Review of CA activity.
|
|
|
|
How much process should it be to issue certificate.
|
|
|
|
Who is allowed to issue certificates.
|
|
|
|
Who is allowed to requests certificates.
|
|
|
|
How to handle certificate revocation, issuing CRLs and maintain OCSP
|
|
services.
|
|
|
|
@node Creating a CA certificate, Issuing certificates, Setting up a CA, Top
|
|
@section Creating a CA certificate
|
|
|
|
This section describes how to create a CA certificate and what to think
|
|
about.
|
|
|
|
@subsection Lifetime CA certificate
|
|
|
|
You probably want to create a CA certificate with a long lifetime, 10
|
|
years at the shortest. This because you don't want to push out the
|
|
certificate (as a trust anchor) to all you users once again when the old
|
|
one just expired. A trust anchor can't really expire, but not all
|
|
software works that way.
|
|
|
|
Keep in mind the security requirements might be different 10-20 years
|
|
into the future. For example, SHA1 is going to be withdrawn in 2010, so
|
|
make sure you have enough buffering in your choice of digest/hash
|
|
algorithms, signature algorithms and key lengths.
|
|
|
|
@subsection Create a CA certificate
|
|
|
|
This command below will create a CA certificate in the file ca.pem.
|
|
|
|
@example
|
|
hxtool issue-certificate \
|
|
--self-signed \
|
|
--issue-ca \
|
|
--generate-key=rsa \
|
|
--subject="CN=CertificateAuthority,DC=test,DC=h5l,DC=se" \
|
|
--lifetime=10years \
|
|
--certificate="FILE:ca.pem"
|
|
@end example
|
|
|
|
@subsection Extending lifetime of a CA certificate
|
|
|
|
You just realised that your CA certificate is going to expire soon and
|
|
that you need replace it with something else, the easiest way to do that
|
|
is to extend the lifetime of your CA certificate.
|
|
|
|
The example below will extend the CA certificate 10 years into the
|
|
future. You should compare this new certificate if it contains all the
|
|
special tweaks as the old certificate had.
|
|
|
|
@example
|
|
hxtool issue-certificate \
|
|
--self-signed \
|
|
--issue-ca \
|
|
--lifetime="10years" \
|
|
--template-certificate="FILE:ca.pem" \
|
|
--template-fields="serialNumber,notBefore,subject,SPKI" \
|
|
--ca-private-key=FILE:ca.pem \
|
|
--certificate="FILE:new-ca.pem"
|
|
@end example
|
|
|
|
@subsection Subordinate CA
|
|
|
|
This example create a new subordinate certificate authority.
|
|
|
|
@example
|
|
hxtool issue-certificate \
|
|
--ca-certificate=FILE:ca.pem \
|
|
--issue-ca \
|
|
--generate-key=rsa \
|
|
--subject="CN=CertificateAuthority,DC=dev,DC=test,DC=h5l,DC=se" \
|
|
--certificate="FILE:dev-ca.pem"
|
|
@end example
|
|
|
|
|
|
@node Issuing certificates, Issuing CRLs, Creating a CA certificate, Top
|
|
@section Issuing certificates
|
|
|
|
First you'll create a CA certificate, after that you have to deal with
|
|
your users and servers and issue certificate to them.
|
|
|
|
CA can generate the key for the user.
|
|
|
|
Can receive PKCS10 certificate requests from the users. PKCS10 is a
|
|
request for a certificate. The user can specified what DN the user wants
|
|
and what public key. To prove the user have the key, the whole request
|
|
is signed by the private key of the user.
|
|
|
|
@subsection Name space management
|
|
|
|
What people might want to see.
|
|
|
|
Re-issue certificates just because people moved within the organization.
|
|
|
|
Expose privacy information.
|
|
|
|
Using Sub-component name (+ notation).
|
|
|
|
@subsection Certificate Revocation, CRL and OCSP
|
|
|
|
Sonetimes people loose smartcard or computers and certificates have to
|
|
be make not valid any more, this is called revoking certificates. There
|
|
are two main protocols for doing this Certificate Revocations Lists
|
|
(CRL) and Online Certificate Status Protocol (OCSP).
|
|
|
|
If you know that the certificate is destroyed then there is no need to
|
|
revoke the certificate because it can not be used by someone else.
|
|
|
|
The main reason you as a CA administrator have to deal with CRLs however
|
|
will be that some software require there to be CRLs. Example of this is
|
|
Windows, so you have to deal with this somehow.
|
|
|
|
@node Issuing CRLs, Application requirements, Issuing certificates, Top
|
|
@section Issuing CRLs
|
|
|
|
Create an empty CRL with not certificates revoked. Default expiration
|
|
value is one year from now.
|
|
|
|
@example
|
|
hxtool crl-sign \
|
|
--crl-file=crl.der \
|
|
--signer=FILE:ca.pem
|
|
@end example
|
|
|
|
Create a CRL with all certificates in the directory
|
|
@file{/path/to/revoked/dir} included in the CRL as revoked. Also make
|
|
it expire one month from now.
|
|
|
|
@example
|
|
hxtool crl-sign \
|
|
--crl-file=crl.der \
|
|
--signer=FILE:ca.pem \
|
|
--lifetime='1 month' \
|
|
DIR:/path/to/revoked/dir
|
|
@end example
|
|
|
|
@node Application requirements, CMS signing and encryption, Issuing CRLs, Top
|
|
@section Application requirements
|
|
|
|
Application have different requirements on certificates. This section
|
|
tries to expand what they are and how to use hxtool to generate
|
|
certificates for those services.
|
|
|
|
@subsection HTTPS - server
|
|
|
|
@example
|
|
hxtool issue-certificate \
|
|
--subject="CN=www.test.h5l.se,DC=test,DC=h5l,DC=se" \
|
|
--type="https-server" \
|
|
--hostname="www.test.h5l.se" \
|
|
--hostname="www2.test.h5l.se" \
|
|
...
|
|
@end example
|
|
|
|
@subsection HTTPS - client
|
|
|
|
@example
|
|
hxtool issue-certificate \
|
|
--subject="UID=testus,DC=test,DC=h5l,DC=se" \
|
|
--type="https-client" \
|
|
...
|
|
@end example
|
|
|
|
@subsection 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
|
|
ways is in the subject distinguished name, this should not be used. The
|
|
new way is using a Subject Alternative Name (SAN).
|
|
|
|
But even though email address is stored in certificates, they don't need
|
|
to, email reader programs are required to accept certificates that
|
|
doesn't have either of the two methods of storing email in certificates.
|
|
In that case, they 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.
|
|
|
|
@example
|
|
hxtool issue-certificate \
|
|
--subject="UID=testus-email,DC=test,DC=h5l,DC=se" \
|
|
--type=email \
|
|
--email="testus@@test.h5l.se" \
|
|
...
|
|
@end example
|
|
|
|
An example of an certificate without and subject distinguished name with
|
|
an email address in a SAN.
|
|
|
|
@example
|
|
hxtool issue-certificate \
|
|
--subject="" \
|
|
--type=email \
|
|
--email="testus@@test.h5l.se" \
|
|
...
|
|
@end example
|
|
|
|
@subsection PK-INIT
|
|
|
|
How to create a certificate for a KDC.
|
|
|
|
@example
|
|
hxtool issue-certificate \
|
|
--type="pkinit-kdc" \
|
|
--pk-init-principal="krbtgt/TEST.H5L.SE@@TEST.H5L.SE" \
|
|
--hostname kerberos.test.h5l.se \
|
|
--hostname pal.test.h5l.se \
|
|
...
|
|
@end example
|
|
|
|
How to create a certificate for a user.
|
|
|
|
@example
|
|
hxtool issue-certificate \
|
|
--type="pkinit-client" \
|
|
--pk-init-principal="user@@TEST.H5L.SE" \
|
|
...
|
|
@end example
|
|
|
|
@subsection XMPP/Jabber
|
|
|
|
The jabber server certificate should have a dNSname that is the same as
|
|
the user entered into the application, not the same as the host name of
|
|
the machine.
|
|
|
|
@example
|
|
hxtool issue-certificate \
|
|
--subject="CN=xmpp1.test.h5l.se,DC=test,DC=h5l,DC=se" \
|
|
--hostname="xmpp1.test.h5l.se" \
|
|
--hostname="test.h5l.se" \
|
|
...
|
|
@end example
|
|
|
|
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 @kbd{--jid}.
|
|
|
|
@example
|
|
hxtool issue-certificate \
|
|
--subject="CN=Love,DC=test,DC=h5l,DC=se" \
|
|
--jid="lha@@test.h5l.se" \
|
|
...
|
|
@end example
|
|
|
|
|
|
@node CMS signing and encryption, CMS background, Application requirements, Top
|
|
@chapter CMS signing and encryption
|
|
|
|
CMS is the Cryptographic Message System that among other, is used by
|
|
S/MIME (secure email) and Kerberos PK-INIT. It's an extended version of
|
|
the RSA, Inc standard PKCS7.
|
|
|
|
@node CMS background, , CMS signing and encryption, Top
|
|
@section CMS background
|
|
|
|
|
|
@c @shortcontents
|
|
@contents
|
|
|
|
@bye
|