1\input texinfo @c -*- texinfo -*- 2@c $NetBSD: hx509.texi,v 1.1.1.3 2014/04/24 12:45:26 pettai Exp $ 3@c %**start of header 4@c Id 5@setfilename hx509.info 6@settitle HX509 7@iftex 8@afourpaper 9@end iftex 10@c some sensible characters, please? 11@tex 12\input latin1.tex 13@end tex 14@setchapternewpage on 15@syncodeindex pg cp 16@c %**end of header 17 18@include vars.texi 19 20@set VERSION @value{PACKAGE_VERSION} 21@set EDITION 1.0 22 23@ifinfo 24@dircategory Security 25@direntry 26* hx509: (hx509). The X.509 distribution from KTH 27@end direntry 28@end ifinfo 29 30@c title page 31@titlepage 32@title HX509 33@subtitle X.509 distribution from KTH 34@subtitle Edition @value{EDITION}, for version @value{VERSION} 35@subtitle 2008 36@author Love Hörnquist Åstrand 37 38@iftex 39@def@copynext{@vskip 20pt plus 1fil} 40@def@copyrightstart{} 41@def@copyrightend{} 42@end iftex 43@macro copynext 44@end macro 45@macro copyrightstart 46@end macro 47@macro copyrightend 48@end macro 49 50@page 51@copyrightstart 52Copyright (c) 1994-2008 Kungliga Tekniska Högskolan 53(Royal Institute of Technology, Stockholm, Sweden). 54All rights reserved. 55 56Redistribution and use in source and binary forms, with or without 57modification, are permitted provided that the following conditions 58are met: 59 601. Redistributions of source code must retain the above copyright 61 notice, this list of conditions and the following disclaimer. 62 632. Redistributions in binary form must reproduce the above copyright 64 notice, this list of conditions and the following disclaimer in the 65 documentation and/or other materials provided with the distribution. 66 673. Neither the name of the Institute nor the names of its contributors 68 may be used to endorse or promote products derived from this software 69 without specific prior written permission. 70 71THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND 72ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 73IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 74ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE 75FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 76DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 77OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 78HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 79LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 80OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 81SUCH DAMAGE. 82 83@copynext 84 85Copyright (c) 1988, 1990, 1993 86 The Regents of the University of California. All rights reserved. 87 88Redistribution and use in source and binary forms, with or without 89modification, are permitted provided that the following conditions 90are met: 91 921. Redistributions of source code must retain the above copyright 93 notice, this list of conditions and the following disclaimer. 94 952. Redistributions in binary form must reproduce the above copyright 96 notice, this list of conditions and the following disclaimer in the 97 documentation and/or other materials provided with the distribution. 98 993. Neither the name of the University nor the names of its contributors 100 may be used to endorse or promote products derived from this software 101 without specific prior written permission. 102 103THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND 104ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 105IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 106ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE 107FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 108DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 109OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 110HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 111LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 112OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 113SUCH DAMAGE. 114 115@copynext 116 117Copyright 1992 Simmule Turner and Rich Salz. All rights reserved. 118 119This software is not subject to any license of the American Telephone 120and Telegraph Company or of the Regents of the University of California. 121 122Permission is granted to anyone to use this software for any purpose on 123any computer system, and to alter it and redistribute it freely, subject 124to the following restrictions: 125 1261. The authors are not responsible for the consequences of use of this 127 software, no matter how awful, even if they arise from flaws in it. 128 1292. The origin of this software must not be misrepresented, either by 130 explicit claim or by omission. Since few users ever read sources, 131 credits must appear in the documentation. 132 1333. Altered versions must be plainly marked as such, and must not be 134 misrepresented as being the original software. Since few users 135 ever read sources, credits must appear in the documentation. 136 1374. This notice may not be removed or altered. 138 139@copynext 140 141IMath is Copyright 2002-2005 Michael J. Fromberger 142You may use it subject to the following Licensing Terms: 143 144Permission is hereby granted, free of charge, to any person obtaining 145a copy of this software and associated documentation files (the 146"Software"), to deal in the Software without restriction, including 147without limitation the rights to use, copy, modify, merge, publish, 148distribute, sublicense, and/or sell copies of the Software, and to 149permit persons to whom the Software is furnished to do so, subject to 150the following conditions: 151 152The above copyright notice and this permission notice shall be 153included in all copies or substantial portions of the Software. 154 155THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 156EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 157MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. 158IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY 159CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, 160TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE 161SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 162 163@copyrightend 164@end titlepage 165 166@macro manpage{man, section} 167@cite{\man\(\section\)} 168@end macro 169 170@c Less filling! Tastes great! 171@iftex 172@parindent=0pt 173@global@parskip 6pt plus 1pt 174@global@chapheadingskip = 15pt plus 4pt minus 2pt 175@global@secheadingskip = 12pt plus 3pt minus 2pt 176@global@subsecheadingskip = 9pt plus 2pt minus 2pt 177@end iftex 178@ifinfo 179@paragraphindent 0 180@end ifinfo 181 182@ifnottex 183@node Top, Introduction, (dir), (dir) 184@top Heimdal 185@end ifnottex 186 187This manual is for version @value{VERSION} of hx509. 188 189@menu 190* Introduction:: 191* What is X.509 ?:: 192* Setting up a CA:: 193* CMS signing and encryption:: 194* Certificate matching:: 195* Software PKCS 11 module:: 196* Creating a CA certificate:: 197* Issuing certificates:: 198* Issuing CRLs:: 199* Application requirements:: 200* CMS background:: 201* Matching syntax:: 202* How to use the PKCS11 module:: 203 204@detailmenu 205 --- The Detailed Node Listing --- 206 207Setting up a CA 208 209@c * Issuing certificates:: 210* Creating a CA certificate:: 211* Issuing certificates:: 212* Issuing CRLs:: 213@c * Issuing a proxy certificate:: 214@c * Creating a user certificate:: 215@c * Validating a certificate:: 216@c * Validating a certificate path:: 217* Application requirements:: 218 219CMS signing and encryption 220 221* CMS background:: 222 223Certificate matching 224 225* Matching syntax:: 226 227Software PKCS 11 module 228 229* How to use the PKCS11 module:: 230 231@end detailmenu 232@end menu 233 234@node Introduction, What is X.509 ?, Top, Top 235@chapter Introduction 236 237The goals of a PKI infrastructure (as defined in 238<a href="http://www.ietf.org/rfc/rfc3280.txt">RFC 3280</a>) is to meet 239@emph{the needs of deterministic, automated identification, authentication, access control, and authorization}. 240 241 242The administrator should be aware of certain terminologies as explained by the aforementioned 243RFC before attemping to put in place a PKI infrastructure. Briefly, these are: 244 245@itemize @bullet 246@item CA 247Certificate Authority 248@item RA 249Registration Authority, i.e., an optional system to which a CA delegates certain management functions. 250@item CRL Issuer 251An optional system to which a CA delegates the publication of certificate revocation lists. 252@item Repository 253A system or collection of distributed systems that stores certificates and CRLs 254and serves as a means of distributing these certificates and CRLs to end entities 255@end itemize 256 257hx509 (Heimdal x509 support) is a near complete X.509 stack that can 258handle CMS messages (crypto system used in S/MIME and Kerberos PK-INIT) 259and basic certificate processing tasks, path construction, path 260validation, OCSP and CRL validation, PKCS10 message construction, CMS 261Encrypted (shared secret encrypted), CMS SignedData (certificate 262signed), and CMS EnvelopedData (certificate encrypted). 263 264hx509 can use PKCS11 tokens, PKCS12 files, PEM files, and/or DER encoded 265files. 266 267@node What is X.509 ?, Setting up a CA, Introduction, Top 268@chapter What is X.509, PKIX, PKCS7 and CMS ? 269 270X.509 was created by CCITT (later ITU) for the X.500 directory 271service. Today, X.509 discussions and implementations commonly reference 272the IETF's PKIX Certificate and CRL Profile of the X.509 v3 certificate 273standard, as specified in RFC 3280. 274 275ITU continues to develop the X.509 standard together with the IETF in a 276rather complicated dance. 277 278X.509 is a public key based security system that has associated data 279stored within a so called certificate. Initially, X.509 was a strict 280hierarchical system with one root. However, ever evolving requiments and 281technology advancements saw the inclusion of multiple policy roots, 282bridges and mesh solutions. 283 284x.509 can also be used as a peer to peer system, though often seen as a 285common scenario. 286 287@section Type of certificates 288 289There are several flavors of certificate in X.509. 290 291@itemize @bullet 292 293@item Trust anchors 294 295Trust anchors are strictly not certificates, but commonly stored in a 296certificate format as they become easier to manage. Trust anchors are 297the keys that an end entity would trust to validate other certificates. 298This is done by building a path from the certificate you want to 299validate to to any of the trust anchors you have. 300 301@item End Entity (EE) certificates 302 303End entity certificates are the most common types of certificates. End 304entity certificates cannot issue (sign) certificate themselves and are generally 305used to authenticate and authorize users and services. 306 307@item Certification Authority (CA) certificates 308 309Certificate authority certificates have the right to issue additional 310certificates (be it sub-ordinate CA certificates to build an trust anchors 311or end entity certificates). There is no limit to how many certificates a CA 312may issue, but there might other restrictions, like the maximum path 313depth. 314 315@item Proxy certificates 316 317Remember the statement "End Entity certificates cannot issue 318certificates"? Well that statement is not entirely true. There is an 319extension called proxy certificates defined in RFC3820, that allows 320certificates to be issued by end entity certificates. The service that 321receives the proxy certificates must have explicitly turned on support 322for proxy certificates, so their use is somewhat limited. 323 324Proxy certificates can be limited by policies stored in the certificate to 325what they can be used for. This allows users to delegate the proxy 326certificate to services (by sending over the certificate and private 327key) so the service can access services on behalf of the user. 328 329One example of this would be a print service. The user wants to print a 330large job in the middle of the night when the printer isn't used that 331much, so the user creates a proxy certificate with the policy that it 332can only be used to access files related to this print job, creates the 333print job description and send both the description and proxy 334certificate with key over to print service. Later at night when the 335print service initializes (without any user intervention), access to the files 336for the print job is granted via the proxy certificate. As a result of (in-place) 337policy limitations, the certificate cannot be used for any other purposes. 338 339@end itemize 340 341@section Building a path 342 343Before validating a certificate path (or chain), the path needs to be 344constructed. Given a certificate (EE, CA, Proxy, or any other type), 345the path construction algorithm will try to find a path to one of the 346trust anchors. 347 348The process starts by looking at the issuing CA of the certificate, by 349Name or Key Identifier, and tries to find that certificate while at the 350same time evaluting any policies in-place. 351 352@node Setting up a CA, Creating a CA certificate, What is X.509 ?, Top 353@chapter Setting up a CA 354 355Do not let information overload scare you off! If you are simply testing 356or getting started with a PKI infrastructure, skip all this and go to 357the next chapter (see: @pxref{Creating a CA certificate}). 358 359Creating a CA certificate should be more the just creating a 360certificate, CA's should define a policy. Again, if you are simply 361testing a PKI, policies do not matter so much. However, when it comes to 362trust in an organisation, it will probably matter more whom your users 363and sysadmins will find it acceptable to trust. 364 365At the same time, try to keep things simple, it's not very hard to run a 366Certificate authority and the process to get new certificates should be simple. 367 368You may find it helpful to answer the following policy questions for 369your organization at a later stage: 370 371@itemize @bullet 372@item How do you trust your CA. 373@item What is the CA responsibility. 374@item Review of CA activity. 375@item How much process should it be to issue certificate. 376@item Who is allowed to issue certificates. 377@item Who is allowed to requests certificates. 378@item How to handle certificate revocation, issuing CRLs and maintain OCSP services. 379@end itemize 380 381@node Creating a CA certificate, Issuing certificates, Setting up a CA, Top 382@section Creating a CA certificate 383 384This section describes how to create a CA certificate and what to think 385about. 386 387@subsection Lifetime CA certificate 388 389You probably want to create a CA certificate with a long lifetime, 10 390years at the very minimum. This is because you don't want to push out the 391certificate (as a trust anchor) to all you users again when the old 392CA certificate expires. Although a trust anchor can't really expire, not all 393software works in accordance with published standards. 394 395Keep in mind the security requirements might be different 10-20 years 396into the future. For example, SHA1 is going to be withdrawn in 2010, so 397make sure you have enough buffering in your choice of digest/hash 398algorithms, signature algorithms and key lengths. 399 400@subsection Create a CA certificate 401 402This command below can be used to generate a self-signed CA certificate. 403 404@example 405hxtool issue-certificate \ 406 --self-signed \ 407 --issue-ca \ 408 --generate-key=rsa \ 409 --subject="CN=CertificateAuthority,DC=test,DC=h5l,DC=se" \ 410 --lifetime=10years \ 411 --certificate="FILE:ca.pem" 412@end example 413 414@subsection Extending the lifetime of a CA certificate 415 416You just realised that your CA certificate is going to expire soon and 417that you need replace it with a new CA. The easiest way to do that 418is to extend the lifetime of your existing CA certificate. 419 420The example below will extend the CA certificate's lifetime by 10 years. 421You should compare this new certificate if it contains all the 422special tweaks as the old certificate had. 423 424@example 425hxtool issue-certificate \ 426 --self-signed \ 427 --issue-ca \ 428 --lifetime="10years" \ 429 --template-certificate="FILE:ca.pem" \ 430 --template-fields="serialNumber,notBefore,subject,SPKI" \ 431 --ca-private-key=FILE:ca.pem \ 432 --certificate="FILE:new-ca.pem" 433@end example 434 435@subsection Subordinate CA 436 437This example below creates a new subordinate certificate authority. 438 439@example 440hxtool issue-certificate \ 441 --ca-certificate=FILE:ca.pem \ 442 --issue-ca \ 443 --generate-key=rsa \ 444 --subject="CN=CertificateAuthority,DC=dev,DC=test,DC=h5l,DC=se" \ 445 --certificate="FILE:dev-ca.pem" 446@end example 447 448 449@node Issuing certificates, Issuing CRLs, Creating a CA certificate, Top 450@section Issuing certificates 451 452First you'll create a CA certificate, after that you have to deal with 453your users and servers and issue certificates to them. 454 455@c I think this section needs a bit of clarity. Can I add a separate 456@c section which explains CSRs as well? 457 458 459@itemize @bullet 460 461@item Do all the work themself 462 463Generate the key for the user. This has the problme that the the CA 464knows the private key of the user. For a paranoid user this might leave 465feeling of disconfort. 466 467@item Have the user do part of the work 468 469Receive PKCS10 certificate requests fromusers. PKCS10 is a request for a 470certificate. The user may specify what DN they want as well as provide 471a certificate signing request (CSR). To prove the user have the key, 472the whole request is signed by the private key of the user. 473 474@end itemize 475 476@subsection Name space management 477 478@c The explanation given below is slightly unclear. I will re-read the 479@c RFC and document accordingly 480 481What people might want to see. 482 483Re-issue certificates just because people moved within the organization. 484 485Expose privacy information. 486 487Using Sub-component name (+ notation). 488 489@subsection Certificate Revocation, CRL and OCSP 490 491Certificates that a CA issues may need to be revoked at some stage. As 492an example, an employee leaves the organization and does not bother 493handing in his smart card (or even if the smart card is handed back -- 494the certificate on it must no longer be acceptable to services; the 495employee has left). 496 497You may also want to revoke a certificate for a service which is no 498longer being offered on your network. Overlooking these scenarios can 499lead to security holes which will quickly become a nightmare to deal 500with. 501 502There are two primary protocols for dealing with certificate 503revokation. Namely: 504 505@itemize @bullet 506@item Certificate Revocation List (CRL) 507@item Online Certificate Status Protocol (OCSP) 508@end itemize 509 510If however the certificate in qeustion has been destroyed, there is no 511need to revoke the certificate because it can not be used by someone 512else. This matter since for each certificate you add to CRL, the 513download time and processing time for clients are longer. 514 515CRLs and OCSP responders however greatly help manage compatible services 516which may authenticate and authorize users (or services) on an on-going 517basis. As an example, VPN connectivity established via certificates for 518connecting clients would require your VPN software to make use of a CRL 519or an OCSP service to ensure revoked certificates belonging to former 520clients are not allowed access to (formerly subscribed) network 521services. 522 523 524@node Issuing CRLs, Application requirements, Issuing certificates, Top 525@section Issuing CRLs 526 527Create an empty CRL with no certificates revoked. Default expiration 528value is one year from now. 529 530@example 531hxtool crl-sign \ 532 --crl-file=crl.der \ 533 --signer=FILE:ca.pem 534@end example 535 536Create a CRL with all certificates in the directory 537@file{/path/to/revoked/dir} included in the CRL as revoked. Also make 538it expire one month from now. 539 540@example 541hxtool crl-sign \ 542 --crl-file=crl.der \ 543 --signer=FILE:ca.pem \ 544 --lifetime='1 month' \ 545 DIR:/path/to/revoked/dir 546@end example 547 548@node Application requirements, CMS signing and encryption, Issuing CRLs, Top 549@section Application requirements 550 551Application place different requirements on certificates. This section 552tries to expand what they are and how to use hxtool to generate 553certificates for those services. 554 555@subsection HTTPS - server 556 557@example 558hxtool issue-certificate \ 559 --subject="CN=www.test.h5l.se,DC=test,DC=h5l,DC=se" \ 560 --type="https-server" \ 561 --hostname="www.test.h5l.se" \ 562 --hostname="www2.test.h5l.se" \ 563 ... 564@end example 565 566@subsection HTTPS - client 567 568@example 569hxtool issue-certificate \ 570 --subject="UID=testus,DC=test,DC=h5l,DC=se" \ 571 --type="https-client" \ 572 ... 573@end example 574 575@subsection S/MIME - email 576 577There are two things that should be set in S/MIME certificates, one or 578more email addresses and an extended eku usage (EKU), emailProtection. 579 580The email address format used in S/MIME certificates is defined in 581RFC2822, section 3.4.1 and it should be an ``addr-spec''. 582 583There are two ways to specifify email address in certificates. The old 584way is in the subject distinguished name, @emph{this should not be used}. The 585new way is using a Subject Alternative Name (SAN). 586 587Even though the email address is stored in certificates, they don't need 588to be, email reader programs are required to accept certificates that 589doesn't have either of the two methods of storing email in certificates 590-- in which case, the email client will try to protect the user by 591printing the name of the certificate instead. 592 593S/MIME certificate can be used in another special way. They can be 594issued with a NULL subject distinguished name plus the email in SAN, 595this is a valid certificate. This is used when you wont want to share 596more information then you need to. 597 598hx509 issue-certificate supports adding the email SAN to certificate by 599using the --email option, --email also gives an implicit emailProtection 600eku. If you want to create an certificate without an email address, the 601option --type=email will add the emailProtection EKU. 602 603@example 604hxtool issue-certificate \ 605 --subject="UID=testus-email,DC=test,DC=h5l,DC=se" \ 606 --type=email \ 607 --email="testus@@test.h5l.se" \ 608 ... 609@end example 610 611An example of an certificate without and subject distinguished name with 612an email address in a SAN. 613 614@example 615hxtool issue-certificate \ 616 --subject="" \ 617 --type=email \ 618 --email="testus@@test.h5l.se" \ 619 ... 620@end example 621 622@subsection PK-INIT 623 624A PK-INIT infrastructure allows users and services to pick up kerberos 625credentials (tickets) based on their certificate. This, for example, 626allows users to authenticate to their desktops using smartcards while 627acquiring kerberos tickets in the process. 628 629As an example, an office network which offers centrally controlled 630desktop logins, mail, messaging (xmpp) and openafs would give users 631single sign-on facilities via smartcard based logins. Once the kerberos 632ticket has been acquired, all kerberized services would immediately 633become accessible based on deployed security policies. 634 635Let's go over the process of initializing a demo PK-INIT framework: 636 637@example 638hxtool issue-certificate \ 639 --type="pkinit-kdc" \ 640 --pk-init-principal="krbtgt/TEST.H5L.SE@@TEST.H5L.SE" \ 641 --hostname=kerberos.test.h5l.se \ 642 --ca-certificate="FILE:ca.pem,ca.key" \ 643 --generate-key=rsa \ 644 --certificate="FILE:kdc.pem" \ 645 --subject="cn=kdc" 646@end example 647 648How to create a certificate for a user. 649 650@example 651hxtool issue-certificate \ 652 --type="pkinit-client" \ 653 --pk-init-principal="user@@TEST.H5L.SE" \ 654 --ca-certificate="FILE:ca.pem,ca.key" \ 655 --generate-key=rsa \ 656 --subject="cn=Test User" \ 657 --certificate="FILE:user.pem" 658@end example 659 660The --type field can be specified multiple times. The same certificate 661can hence house extensions for both pkinit-client as well as S/MIME. 662 663To use the PKCS11 module, please see the section: 664@pxref{How to use the PKCS11 module}. 665 666More about how to configure the KDC, see the documentation in the 667Heimdal manual to set up the KDC. 668 669@subsection XMPP/Jabber 670 671The jabber server certificate should have a dNSname that is the same as 672the user entered into the application, not the same as the host name of 673the machine. 674 675@example 676hxtool issue-certificate \ 677 --subject="CN=xmpp1.test.h5l.se,DC=test,DC=h5l,DC=se" \ 678 --hostname="xmpp1.test.h5l.se" \ 679 --hostname="test.h5l.se" \ 680 ... 681@end example 682 683The certificate may also contain a jabber identifier (JID) that, if the 684receiver allows it, authorises the server or client to use that JID. 685 686When storing a JID inside the certificate, both for server and client, 687it's stored inside a UTF8String within an otherName entity inside the 688subjectAltName, using the OID id-on-xmppAddr (1.3.6.1.5.5.7.8.5). 689 690To read more about the requirements, see RFC3920, Extensible Messaging 691and Presence Protocol (XMPP): Core. 692 693hxtool issue-certificate have support to add jid to the certificate 694using the option @kbd{--jid}. 695 696@example 697hxtool issue-certificate \ 698 --subject="CN=Love,DC=test,DC=h5l,DC=se" \ 699 --jid="lha@@test.h5l.se" \ 700 ... 701@end example 702 703 704@node CMS signing and encryption, CMS background, Application requirements, Top 705@chapter CMS signing and encryption 706 707CMS is the Cryptographic Message System that among other, is used by 708S/MIME (secure email) and Kerberos PK-INIT. It's an extended version of 709the RSA, Inc standard PKCS7. 710 711@node CMS background, Certificate matching, CMS signing and encryption, Top 712@section CMS background 713 714 715@node Certificate matching, Matching syntax, CMS background, Top 716@chapter Certificate matching 717 718To match certificates hx509 have a special query language to match 719certifictes in queries and ACLs. 720 721@node Matching syntax, Software PKCS 11 module, Certificate matching, Top 722@section Matching syntax 723 724This is the language definitions somewhat slopply descriped: 725 726@example 727 728expr = TRUE, 729 FALSE, 730 ! expr, 731 expr AND expr, 732 expr OR expr, 733 ( expr ) 734 compare 735 736compare = 737 word == word, 738 word != word, 739 word IN ( word [, word ...]) 740 word IN %@{variable.subvariable@} 741 742word = 743 STRING, 744 %@{variable@} 745 746@end example 747 748@node Software PKCS 11 module, How to use the PKCS11 module, Matching syntax, Top 749@chapter Software PKCS 11 module 750 751PKCS11 is a standard created by RSA, Inc to support hardware and 752software encryption modules. It can be used by smartcard to expose the 753crypto primitives inside without exposing the crypto keys. 754 755Hx509 includes a software implementation of PKCS11 that runs within the 756memory space of the process and thus exposes the keys to the 757application. 758 759@node How to use the PKCS11 module, , Software PKCS 11 module, Top 760@section How to use the PKCS11 module 761 762@example 763$ cat > ~/.soft-pkcs11.rc <<EOF 764mycert cert User certificate FILE:/Users/lha/Private/pkinit.pem 765app-fatal true 766EOF 767$ kinit -C PKCS11:/usr/heimdal/lib/hx509.so lha@@EXAMPLE.ORG 768@end example 769 770 771@c @shortcontents 772@contents 773 774@bye 775