Internet-Draft J. Marchioni Working Group: Individual ARX, Inc draft-marchioni-itzhaki-ds-system-deployment-00.txt Y. Itzhaki Category: Informational Algorithmic Research, Ltd Obsoletes: none 14 August 2008 Expires: March 2009 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Approach to Digital Signature Systems Deployment Status of This Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Abstract Most digital-signature system deployments require dedicated and solution-specific user-enrollment procedures and user-enrollment software[1], and mandate provisioning and distribution of physical or software-based signature-key tokens to end users. As deployed such approaches create a high burden in logistics, cost, and help-desk support. They also introduce training obstacles for users and systems administrators. This document describes the deployment architecture approach used by ARX to provide secure and efficient digital signature services based on its CoSign(r) solution. The security solution's deployment architecture is documented in the hope that other digital-signature and PKI deployment efforts will deliver comparable efficiencies. [1] This is also true for deployments of non-standard proprietary electronic signature solutions. Table of Contents. 1. Introduction. 1 2. The Digital Signature Solution Deployment. 2 2.1. Operations and Infrastructure. 2 2.1.1. Identity Proofing. 2 2.1.2. Signature-User Enrollment. 2 2.1.3. RA Proxy. 2 2.1.4. Key and Certificate Management. 2 2.1.5. Certificate Management Options. 3 2.1.6. Revocation, CRLs and OCSP. 3 2.1.7. Automatic Refresh: Keys and/or Certificates. 4 2.1.8. Re-keying. 4 2.2. Applications and User Authentication. 5 2.2.1. Key and Signature Services for the Application. 5 2.2.2. Signature and Verification Process. 5 2.2.3. User Authentication. 6 2.2.4. Interfaces for Application Customization. 6 Conclusion. 7 Informative References. 7 IPR Statement. 10 Acknowledgement. 11 Authors Addresses. 11 Copyright Notice 11 Marchioni & Itzhaki Informational [Page 1] Internet-Draft Digital Signature System Deployment 11 August 2008 1. Introduction This document presents an approach to deploying digital signature solutions or services that does not mandate use of a solution- specific or PKI-specific identity proofing policy, or enrollment software. Rather the approach leverages an organization's pre- established user and authentication policies, procedures, systems and infrastructure to drive the management of end-user signature credentials i.e., management of signature keys and certificates. This document describes a deployment scheme implemented by Algorithmic Research, Ltd (ARX) to provide secure, efficient deployment of digital-signature capabilities that has a low administrative burden, and minimum impact on end-users and operations. The security solution employs: o a NIST FIPS 140-2 level 3 certified server to provide physical and programmatic confidentiality and integrity protection for private keys and digital-signature operations; o SHS to provide integrity protection of signed objects (documents or data); o triple-DES/AES to provide confidentiality and integrity protection of private keys; o X.509 v3 certificates and CRLs to ensure signature verification and non-repudiation under 3rd-party applications; o RSA (1024 to 4096-bit) to provide integrity and non-repudiation protection of digital signatures on user-sign data, and certificates and CRLs; o TLS to provide confidentiality and integrity protection of signature object hash values and signature blocks sent between the application and FIPS server; o PKCS#1 signature scheme to enable signature verification by 3rd-party applications; o PKCS#7 signature scheme to enable signature verification by 3rd-party applications; o PKCS#10 public-key certification requests to enable cross certification or subordinate CA operation with 3rd-party CAs; o PKCS#11, OASIS DSS, ASSP and CAPI interface options to allow a diversity of 3rd party applications access to secure digital signature services. Marchioni & Itzhaki Informational [Page 2] Internet-Draft Digital Signature System Deployment 11 August 2008 2. The Digital Signature Solution Deployment. 2.1. Operations and Infrastructure. +-------------+ +------------------+ +--------------------+ | | | | | | | Established | | Established +---/ | FIPS 140-2 level 3 | | ID-Proofing +=====+ User-Management | / | Server (like the | | Procedure | ^ | System | /---+ CoSign appliance) | | | | | | ^ | | +-------------+ | +------------------+ | +--------------------+ | | Domain-Established LDAP/Active Directory Standard Operating Procedure Protocol Figure 1. Enrollment, and Key and Certificate Management Example. 2.1.1. Identity Proofing. Most organizations have an established, documented and standard operating procedure for identity proofing that requires in-person verification. These procedures are typically under the control of either, e.g., the human-resources department, or the supplier or customer screening departments. When a person's identity is verified (proofed) that person is enrolled in the organization's established user/supplier/customer database, typically either Microsoft Active Directory or other LDAP-enabled database, and an identity credential is issued. The digital- signature capability deployment solution must not disrupt these established policies, procedures and infrastructure. 2.1.2. Signature-User Enrollment. The deployment virtualizes an organization's established identity-directory services as the registration authority (RA) (i.e., RA proxy) for the signature PKI. [Note the deployment described here leverages a range of pre-existing identity-credentialing systems to authenticate users and manage their digital-signature credentials, i.e., signature key pair and signature certificate]. All signature-key and signature-certificate provisioning and management functions must be performed transparently and securely for the end user and systems administrator by a FIPS 140-2 level 3 server like the CoSign appliance. 2.1.3. Registration Authority (RA) Proxy. The appliance must listen to a set of events on the user directory (e.g., new user, remove user, change user details, etc.) and translate these routine administrative operations into signature-key and certificate-management events (e.g., generate key pair, revoke private key, issue/revoke certificate, etc.), without the need for additional PKI-specific administrator intervention. Marchioni & Itzhaki Informational [Page 3] Internet-Draft Digital Signature System Deployment 11 August 2008 2.1.4. Key and Certificate Management. The deployment provides a FIPS 140-2 level 3 network-attached multi-user server, like the CoSign appliance. Signature keys and certificates are generated stored and managed inside the server, and private keys are never exposed outside the secure enclosure. The server can be viewed as a large network-attached smart card that secures all users' signature credentials and signature operations. The FIPS server provides hardware security for all the private keys and all private-key operations without the need for personal-hardware tokens. Furthermore users (and administrators) can only use their own signature key(s) and have access to none other. Access for key usage is controlled by the authentication scheme chosen [see sec 2.2.3] and the FIPS 140-2 level 3 server. The operational impact is an elimination of the high burden in logistics, cost, help-desk support and lack of user acceptance, associated with the purchase, provisioning, distribution and management of individual public-key hardware or software tokens. 2.1.5. Certificate Management Options. Certificate management is provided either by the FIPS appliance-embedded Certification Authority (CA) or by one of two optional secure interfaces between the appliance and a 3rd party CA. There is an interface option allows the embedded CA to be deployed as a subordinate CA via a root signing procedure; and second option that allows the FIPS appliance to act as an RA Proxy between the company's user management infrastructure and the 3rd party CA. Organizations then have the option to securely and transparently manage and control their own CA or get certificate-management services from a 3rd party CA/PKI. Furthermore the systems administrator and users have no training obstacles or added burdens related to PKI-service management or use, no matter which CA option is deployed. Under this approach the organization need not change their current policies, procedures, and systems for (a) identity proofing and management, and (b) user enrollment/revocation. Thus the deployment of the digital-signature system and PKI does not negatively impact established policy and infrastructure nor end-user and administrative routines. 2.1.6. Revocation, CRLs and OCSP. This approach mandates a user is revoked by revoking their private key, i.e., their private key is immediately deleted by the FIPS server. Therefore, at the time of revocation the user no longer has a capability to make even one more signature, and so all signatures that verify with that user's certificate are known to have been made when the user had valid signature privileges, and not after. At the time the private key is revoked the user's certificate is also revoked and placed on the CRL. However, the need to manage and reconcile CRLs under this approach is less important resulting in a savings of processing, administrative, and CRL-distribution overhead, and furthermore Marchioni & Itzhaki Informational [Page 4] Internet-Draft Digital Signature System Deployment 11 August 2008 eliminating the need for OCSP responders. This has an added benefit in signature verification; the user need not be online to verify signatures (see section 2.2.2. below). 2.1.7 Automatic Refresh: Keys and/or Certificates. Since keys and certificates are managed centrally the FIPS server can automatically refresh keys (i.e., revoke old and generate new) and certificates (i.e., issue new certificate with new validity period) upon expiration without the delays or logistics issues associated with key and certificate as managed on personal hardware tokens such as smart cards or USB sticks. 2.1.8. Re-keying. As security policies evolve it may become necessary to migrate from 1024-bit RSA to 2048-bit RSA, or, from RSA to Elliptic Curve DSS. Other deployment approaches mandate the provisioning and distribution of physical personal signature-key media, like smart cards and USB sticks. These deployments leave the administrator with a serious logistics burden for re-keying. Under such deployments the administrator would need to provision new key tokens for each user and then carefully manage the timing of their activation and swapping with tokens already in the hands of the end users. In the event that re-keying is required for signature keys the deployment approach offers a most efficient method to re- keying the user community. Since no personal signature-key media has been distributed (see section 2.2.1. below), all users can be re-keyed at once from the central network-attached FIPS server without delay or logistical issues. Marchioni & Itzhaki Informational [Page 5] Internet-Draft Digital Signature System Deployment 11 August 2008 2.2. Applications and User Authentication. +---------------+ +---------------+ +--------------------+ | | | | | | | Application +=====+ Desktop CSP +---/ | FIPS 140-2 level 3 | | Desktop | ^ | | /---+ Server | | | | | | ^ | | +---------------+ | +---------------+ | +--------------------+ | | CAPI Authenticated Interface TLS (SSL) Figure 2. Deployment Under the Desktop or Server Application. +---------------+ +----------------------+ | | | | | Application | | FIPS 140-2 level 3 | | Web Browser +---/ | Server with | | | /---+ Web Services | | | ^ | | +---------------+ | +----------------------+ | Authenticated TLS (SSL) Figure 3. Deployment Under the Web Application. 2.2.1. Key and Signature Services for the Application. The FIPS server 'appears' either as a local CSP key media (i.e., USB stick or smart card) to 3rd party desktop applications, or as a Web service to any Web application. The FIPS server must present itself to the desktop application as either as a standard CAPI cryptographic service provider (CSP), or a Web service, or a PKCS#11 signature and key-service provider. Standard Web service options include either OASIS digital signatures service (DSS) or Adobe Signature Service Protocol (ASSP). The functions normally provided by a software token, public-key smart card or USB stick, (i.e., secure key generation, key storage, RSA signature operation, certificate storage, etc.) are provided by the FIPS 140-2 level 3 network-attached server via the interfaces indicated above. Marchioni & Itzhaki Informational [Page 6] Internet-Draft Digital Signature System Deployment 11 August 2008 2.2.2. Signature and Verification Process. Documents (or data) may be hashed on the user's personal computer, or optionally, within the FIPS server. At the initiation of a signature operation an authenticated TLS session is established between the user's PC and the FIPS server. A TLS session is established only after the user (i.e., the signer) has been authenticated by answering an identity challenge. The TLS session protects the confidentiality and integrity of the hash sent to the server and the signature block and certificate returned to user's application. The signature block and certificate are then embedded in the signed document so that when the signature needs to be validated all that is needed is the signed document itself and the software (e.g., Adobe Reader) to calculate signature verification. 2.2.3. User Authentication. A number of options for identity challenge must be supported, this to avoid disruption in pre-existing user authentication policy and infrastructure, the options must include: (a) Kerberos SSO,(b) simple username/password-PIN, and (c) the following two-factor authentication options: (i) RADIUS protocol with one-time password token, (ii) challenge-response protocol with identity smart card, and (iii) biometrics. The organization can therefore choose a level of user-authentication security that matches the requirements of their application but nothing less secure than what is needed is made available under the deployment. 2.2.4. Programmatic Interfaces for Application Customization. Standard interfaces and APIs provided by the deployment mean deployments cost-effectively fit digital signature capabilities into pre- existing and new applications and identity-management infrastructures. Another advantage is standard interfaces allow one vendor's solution to be replaced with another with less disruption. The deployment must also consider what is familiar to end-users in terms of visual indication of a signature. Therefore there must be support for a one-time capture and centrally stored handwritten graphical-electronic signature image(s) (e.g., from an electronic-signature-pad interface or by loading the image from a .jpg or .bmp file) for placement with every digital signature. This to provide an added visual convenience to end users, and more importantly further encourage user adoption and routine use of standard digital signatures. When needed standard APIs and Web services provide the following functions for customized signature-enabled application development: - Sign/validate signatures within supported applications - Sign/validate a single file or data buffer - Check certificate validity - Enumerate/manage certificates - Manage graphical electronic signatures - Manage users Marchioni & Itzhaki Informational [Page 7] Internet-Draft Digital Signature System Deployment 11 August 2008 Conclusion. Deployment and management of large distributed systems of any kind is extremely hard and digital-signature systems are no exception. PKI technology remains wanting for affordable deployment recipes that also consider pre-existing user-management and application infrastructure. The expected outcome of using the approach presented here is the gap between PKI-driven applications and the mass market will be further narrowed. Informative References. [AES] National Institute of Standards and Technology (NIST), 'FIPS Publication 197: Advanced Encryption Standard', http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf, 2001 November 26. [ASSP] 'Adobe Signature Services Protocol' (ASSP), Available only from Adobe Systems, Inc. See contact information at http://www.adobe.com. [CAPI] R. Coleridge, 'The Cryptography API, or How to Keep a Secret', http://msdn2.microsoft.com/en-us/library/ms867086.aspx, August 1996. [CMS] R. Housley, 'Cryptographic Message Syntax', IETF RFC 3852, http://www.ietf.org/rfc/rfc3852.txt, July 2004. [Ellison] C. Ellison, 'Improvements on Conventional PKI Wisdom', Proceedings of the 1st Annual PKI Research Workshop, pp. 165-176, August 2002. [FIPS140] National Institute of Standards and Technology (NIST), 'FIPS Publication 140-2: Security Requirements for Cryptographic Modules', http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf, May 2001. [Gupta] S. Gupta, 'Security Characteristics of Cryptographic Mobility Solutions', Proceedings of the 1st Annual PKI Research Workshop, pp. 117-126, August 2002. [Gutmann] P. Gutmann, 'Plug-and-Play PKI: A PKI your Mother can Use', Proceedings of the 12th USENIX Security Symposium, pp. 45-58, August 2003. [IPSEC] S. Kent and R. Atkinson, 'Security Architecture for the Internet Protocol', IETF RFC 2401, http://www.ietf.org/rfc/rfc2401.txt, November 1998. [JCA] Sun Microsystems, Inc., 'Java Cryptography Architecture, API Specification & Reference', http://java.sun.com/j2se/1.4.2/docs/guide/ security/CryptoSpec.html, August 2002. Marchioni & Itzhaki Informational [Page 8] Internet-Draft Digital Signature System Deployment 11 August 2008 [Kerberos] Microsoft Corp., 'Windows 2000 Kerberos Authentication', http://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/con feat/kerberos.mspx [LDAP] K. Zeilenga, 'Lightweight Directory Access Protocol', IETF RFC 4510, http://www.ietf.org/rfc/rfc4510.txt, June 2006. [Lorch] M. Lorch, J. Basney and D. Kafura, 'A Hardware-secured Credential Repository for Grid PKIs', 4th IEEE/ACM International Symposium on Cluster Computing and the Grid, pp. 640-647, April 2004. [Marchesini] J. Marchesini, S.W. Smith, M. Zhao, 'Keyjacking: Risks of the Current Client-side Infrastructure', Proceedings of the 2nd Annual PKI Research Workshop, pp. 128-144, April 2003. [NAMU] S. Turner and R. Housley, 'Implementing Email Security and Tokens: Current Standards, Tools, and Practices' pp.159-160, Wiley Publishing, 2008. [Nielsen] R. Nielsen, 'Observations from the Deployment of a Large Scale PKI', Proceedings of the 4th Annual PKI Research Workshop, pp. 159-165, August 2005. [NTP] D. L. Mills, 'Network Time Protocol', IETF RFC 1305, http://www.ietf.org/rfc/rfc1305.txt, March 1992. [OASIS] S. Drees et al, 'Digital Signature Service Core Protocols, Elements, and Bindings', OASIS Digital Signature Services Technical Committee Draft, http://docs.oasis-open.org/dss/v1.0/oasis-dss-1.0- core-spec-cd-r5.pdf, August 2006. [PKCS1] RSA Laboratories, 'PKCS #1 v.21: RSA Cryptography Standard', ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf, June 2002. [PKCS7] RSA Laboratories, 'PKCS #7 v.1.6: 'Cryptographic Message Syntax Standard', ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-7/pkcs- 7v16.pdf, May 1997. [PKCS10] RSA Laboratories, 'PKCS #10 v.1.7: 'Certification Request Syntax Standard,', ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-10/pkcs- 10v1_7d1.pdf, March, 2000 [PKCS11] RSA Laboratories, 'PKCS #11 v2.20: Cryptographic Token Interface Standard', ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2- 20/pkcs-11v2-20.pdf, June 2004. Marchioni & Itzhaki Informational [Page 9] Internet-Draft Digital Signature System Deployment 11 August 2008 [Perrin] T. Perrin, L. Bruns, J. Moreh and T. Olkin, 'Delegated Cryptography, Online Trusted Third Parties, and PKI', Proceedings of the 1st Annual PKI Research Workshop, pp. 97-116, August 2002. [Pope] N. Pope, J. C. Cruellas, "Oasis Digital Signature Services: Digital Signing without the Headaches," IEEE Internet Computing, vol. 10, no. 5, pp. 81-84, September/October 2006. [RADIUS] C. Rigney et al, 'Remote Authentication Dial In User Service', IETF RFC 2865, http://www.ietf.org/rfc/rfc2865.txt, June 2000. [Resnitzky] U. Resnitzky, 'The Directory-Enabled PKI Appliance: Digital Signatures Made Simple, Approach and Real World Experience' Feb 2007. [RSA] R.L. Rivest, A. Shamir and L. Adleman, 'A method for obtaining digital signatures and public-key cryptosystems', Communications of the ACM, vol. 21, no. 2, pp. 120-126, February 1978. [SAPI] ARX, 'SAPI(r) Signature API Programmer's Guide Version 4.1', Pub. No. CSN.SAPI.V32.1206, Available on request from info@arx.com, December 2006. [Sandhu] R. Sandhu, M Bellare and R. Ganesan, 'Password-Enabled PKI: Virtual Smartcards versus Virtual Soft Tokens', Proceedings of the 1st Annual PKI Research Workshop, pp. 89-96, August 2002. [Schneier] B. Schneier, 'Security Risks of Centralization', Crypto-Gram, http://www.schneier.com/crypto-gram-0403.html#11, March 2004. [SHS] National Institute of Standards and Technology (NIST), 'FIPS Publication 180-2: Secure Hash Standard', http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf, August 2002. [TLS] T. Dierks and E. Rescorla, 'The Transport Layer Security (TLS) Protocol', IETF RFC 4346, http://www.ietf.org/rfc/rfc4346.txt, April 2006. [Whitten] A. Whitten and J.D. Tygar, 'Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0', Proceedings of the 8th USENIX Security Symposium, pp. 169-184, August 1999. Marchioni & Itzhaki Informational [Page 10] Internet-Draft Digital Signature System Deployment 11 August 2008 Intellectual Property. The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Marchioni & Itzhaki Informational [Page 11] Internet-Draft Digital Signature System Deployment 11 August 2008 Acknowledgement. Development of this informational RFC was sponsored by ARX, Inc. and Algorithmic Research, Ltd. Authors' Addresses John Marchioni ARX, Inc. 855 Folsom Street Suite 939 San Francisco, CA 94107 USA EMail: johnmarc@arx.com Yair Itzhaki Algorithmic Research, Ltd. 10 Nevatim Street Petach Tikva, 49561 Israel EMail: yair@arx.com Copyright (C) The IETF Trust (2008). This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.