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