Internet-Draft J. Marchioni
Working Group: Individual ARX, Inc
draft-digital-signature-system-deployment-00 Y. Itzhaki
Category: Informational T. Yas'ur
Obsoletes: None Algorithmic Research, Ltd
Expires: 29 March 2009 30 September 2008
Approach to Digital Signature Systems Deployment
Status of This Memo
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
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
Conventional deployments store keys on PC hard disks, application-
server hard disks, or in tokens, and also introduce complications
for user enrollment and management. User and administrator
frustration with the conventional approach has cramped development
of a market for PKI. As a result, PKI has not reached its
utilization potential and is far from becoming ubiquitous.
This document describes architecture for deployment of secure and
efficient digital signature capabilities based on a centralized key-
management approach and emphasizes the importance of not disrupting
existing identity and authentication management and application
infrastructure. An alternative architecture is documented here so
that PKI deployments will lower their associated administrative
burdens and deliver improved scalability.
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 3
2.1.4. Key and Certificate Management 3
2.1.5. Certificate Management Options 3
2.1.6. Revocation, CRLs and OCSP 4
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 6
2.2.3. User Authentication 6
2.2.4. Middleware and Programmatic Interfaces 6
3. Security Considerations 7
4. Conclusion 8
Informative References 8
IPR Statement 11
Acknowledgement 11
Authors Addresses 12
Copyright Notice 12
Marchioni & Itzhaki Informational [Page 1]
Internet-Draft Digital Signature System Deployment 30 September 2008
1. Introduction.
This document presents an approach to deploying digital signature
solutions, but does not mandate use of a solution-specific or PKI-
specific identity proofing policy, procedure, enrollment software,
or PKI-specific authentication scheme. The approach leverages an
organization's pre-established user and authentication
infrastructure to drive the management of end-user signature
credentials i.e., management of signature keys and certificates.
The described architecture results in minimum impact by the
signature PKI on business operations.
While the architecture mandates use of PKI and digital signature
standards, it also allows deployment of several optional security
and middleware components that can be used to meet requirements of
a broad diversity of security policies, applications, and business
processes, and include:
o FIPS-140 [REF] evaluated hardware options to provide extra
physical and programmatic access control and integrity
protection for private keys and digital-signature operations;
o SHS [REF] is mandated and provides integrity protection of
signed objects (documents or data);
o Triple-DES [REF] and AES [REF] are symmetric-cryptographic
options that provide confidentiality and integrity protection
of signature private keys;
o X.509 v3 certificates and X.509 v2 CRLs [REF] are mandatory to
ensure signature verification and support non-repudiation
under off the shelf applications;
o RSA (1024 to 4096-bit) [REF] and ECDSA [REF] are options that
provide integrity and non-repudiation protection of digital
signatures on user-signed data, certificates and CRLs;
o SSL/TLS [REF] options provide confidentiality and integrity
protection of signature object hash values and signature
blocks sent between the application and key server;
o PKCS#1 [REF] and PKCS#7 [REF] are used to enable signature
verification by off the shelf applications;
o PKCS#10 [REF] is used for public-key certification requests to
enable key certification operations;
o PKCS#11 [REF], OASIS DSS [REF], CAPI [REF], and ASSP [REF] are
middleware-interface options to allow a diversity of
applications access to signature services.
Marchioni & Itzhaki Informational [Page 2]
Internet-Draft Digital Signature System Deployment 30 September 2008
2. The Digital Signature Solution Deployment.
2.1. Operations and Infrastructure.
+-------------+ +------------------+ +--------------------+
| | | | | |
| Established | | Established +---/ | |
| ID-Proofing +=====+ User-Management | / | Key & Certificate |
| Procedure | ^ | System | /---+ Server |
| | | | | ^ | |
+-------------+ | +------------------+ | +--------------------+
| |
Domain-Established LDAP or Directory-Specific
Standard Operating Procedure Protocol
Figure 1. Example of Enrollment, Key and Certificate Management
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 screening departments such as human-
resources, or those that screen suppliers and/or customers. When
a person's identity is verified (proofed) that person is enrolled in
the organization's established user/supplier/customer database,
typically an LDAP-enabled directory or database, and an identity
credential is issued. The PKI or digital-signature system
deployed must not disrupt these established identity and
authentication management(IAM) policies, procedures and
infrastructure, rather the signature PKI must be driven by the
established infrastructure.
2.1.2. Signature-User Enrollment. The deployment virtualizes an
organization's established identity-directory (or database) services
as the registration authority (RA) (i.e., RA proxy) for the
signature PKI. [Note the deployment described here may leverage 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 (see next section).
Marchioni & Itzhaki Informational [Page 3]
Internet-Draft Digital Signature System Deployment 30 September 2008
2.1.3. Registration Authority (RA) Proxy. The key and certificate
server 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.
2.1.4. Key and Certificate Management. The deployment provides a
network-attached multi-user server for key and certificate
generation and storage, and for private-key operations. Such a
server can be any basic hardware server, or one that has undergone
FIPS-140 evaluation for higher assurance in key protection.
Signature keys and certificates are generated, stored and managed
inside the server, and private keys are never exposed outside this
server. If such a server has also been evaluated for FIPS 140
security, it can provide hardware security without the need
for personal-hardware tokens. In fact some servers, depending on
FIPS level (FIPS 140-2 defines four levels of security, simply named
"Level 1" to "Level 4"), can be viewed as a large network-attached
smart card that generates and stores all users' signature
credentials, and executes all signature (private-key) operations.
Furthermore, user (and administrator) can only use and access their
own signature key(s), and have access to none other. Access for key
usage is controlled by the authentication scheme chosen by the
organization, [see sec 2.2.3], and the specific server's protection
profile.
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 can be
provided either by an embedded Certification Authority (CA) in the
key and certificate server (the server), or by one of two optional
middleware (or procedural) interfaces between the server and an
external CA:
(i) a middleware interface that allows the server to act as an
RA Proxy between the organization's user management
infrastructure and the external CA by making PKCS#10 key-
certification requests from the server on behalf of each
user directly to the external CA;
(ii) a middleware (or procedure) can allow the embedded CA to be
established as a subordinate to a Root CA by exporting its
public key (e.g., subject = subordinate CA xyz) and
submitting a PKCS#10 key-certification request to an
external Root CA.
Marchioni & Itzhaki Informational [Page 4]
Internet-Draft Digital Signature System Deployment 30 September 2008
Organizations can then have the option to securely and transparently
manage and control their own CA or get certificate-management
services from an independent third party CA. Furthermore, the
systems administrator and users have no training obstacles or added
burdens related to PKI-service management and use, regardless of the
chosen CA option.
Under this approach (RA Proxy), 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 administrator routines or business operations.
2.1.6. Revocation, CRLs and OCSP. This approach mandates a user is
revoked by revoking his/her private key, i.e., the private key is
immediately deleted by the server. Therefore, at the time of
revocation the user no longer has a capability to make even one more
signature. Hence, all signatures that verify with that user's
certificate 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. Furthermore, if all
key management in the PKI followed a centralized approach the need
for OCSP responders might be eliminated, resulting in an added
efficiency in signature verification, i.e., those examining
signatures need not be online to verify signatures (see section
2.2.2. below). In any event, as long as the conventional approach
is used there will be a need for CRLs and OCSP.
2.1.7 Automatic Refresh: Keys and/or Certificates. Since keys and
certificates are managed centrally, the key-certificate server can
automatically refresh keys (i.e., generate new and revoke old
certificates (i.e., issue new certificate with new validity period)
upon expiration without the delays or logistics issues associated
with private keys and certificates managed on computer hard drives
or personal hardware tokens such as smart cards and 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 ECDSA.
Conventional deployment approaches mandate the provisioning and
distribution of physical personal signature-key media, either
software or hardware tokens. These deployments leave the
administrator with a serious logistical burden for re-keying. Under
such conventional deployments, the administrator first needs 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.
Marchioni & Itzhaki Informational [Page 5]
Internet-Draft Digital Signature System Deployment 30 September 2008
In the event that re-keying is required for signature keys, the
centralized approach offers an 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 key server without delay or
logistical issues.
2.2. Applications and User Authentication.
+---------------+ +---------------+ +--------------------+
| | | | | |
| Application +=====+ Desktop +---/ | Key & Certificate |
| Desktop | ^ | Middleware | /---+ Server |
| | | | | ^ | |
+---------------+ | +---------------+ | +--------------------+
| |
Middleware Interface Authenticated
e.g.,PKCS#11/CAPI SSL or TLS
Figure 2. Deployment Under the Desktop or Server Application
+---------------+ +----------------------+
| | | |
| Application | | Key & Certificate |
| Web Browser +---/ | Server with |
| | /---+ Web Services |
| | ^ | |
+---------------+ | +----------------------+
|
Authenticated
SSL or TLS
Figure 3. Deployment Under the Web Application
2.2.1. Key and Signature Services for the Application. The server
"appears" either as a local key media (e.g., USB stick or smart
card) to desktop applications, or as a Web-service key media to any
Web application.
The server must present itself to the application as a standard key
media using middleware that is compatible with the application.
Such middleware is typically based on either a PKCS#11, CAPI,
OASIS DSS Web Service, or other Web service interface like ASSP.
Marchioni & Itzhaki Informational [Page 6]
Internet-Draft Digital Signature System Deployment 30 September 2008
The functions normally provided by a software token, public-key
smart card or USB stick, (i.e., secure key generation, key storage,
signature operation, certificate storage, etc.) are provided by
the network-attached server via the middleware interfaces indicated
above.
2.2.2. Signature and Verification Process. Documents (or data) can be
hashed on the user's computer, this results in significant
savings of network bandwidth as compared to sending entire documents
to the server to be hashed. At the initiation of a signature
operation, an authenticated SSL/TLS session is established between
the user's computer and the server. A SSL/TLS session is
established only after the user (i.e., the signer) has been
authenticated by answering an identity challenge. The secure
session provides confidentiality and integrity for the hash sent to
the server, and for the signature block and certificate returned to
the user's application. The signature block and certificate are
then embedded in the document. When the signature needs to be
validated all that is needed is the signed document and the
application software to calculate signature verification.
2.2.3. User Authentication. A number of options for identity challenge
may be considered. To avoid disruption in pre-existing user
authentication policy and infrastructure, the options include:
(a) Kerberos SSO,(b) simple username/password-PIN, and (c) the
following two-factor authentication options: (i) RADIUS [REF] or
DIAMETER [REF] protocol with one-time password token, (ii)
challenge-response protocol with identity smart card, and (iii)
biometrics. Therefore, the organization can 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. Middleware and Programmatic Interfaces. Standard
interfaces allow deployments to cost-effectively dovetail
digital signature capabilities into pre-existing as well as new
applications, and identity-management infrastructures. Another
advantage of standard interfaces is allowing for one vendor's
solution to be replaced by a solution from another vendor with less
disruption, eliminating vendor lock.
The deployment also considers what is familiar to end-users in
terms of visual indication of a signature. Therefore, there is
consideration for a one-time capture and centrally stored
handwritten graphical signature image (e.g., from an electronic-
signature-pad or ePen interface, or by loading the image from
a .jpg or .bmp file) for placement with every digital signature.
This approach provides an added visual convenience to end users, and
encourages user adoption and routine use of standard digital
signatures.
Marchioni & Itzhaki Informational [Page 7]
Internet-Draft Digital Signature System Deployment 30 September 2008
When needed, middleware with standard and application-compatible
APIs and Web services can provide the following functions for
customized signature-enabled application development:
o Sign/validate signatures in application-specific document
types;
o Sign/validate a single file or data buffer;
o Check certificate validity;
o Enumerate/manage certificates;
o Manage graphical electronic signatures;
o Manage users.
3. Security Considerations.
The overall risk to a business process must be assessed and balanced
with scalability objectives before defining procedures or choosing
security-technology mechanisms. The goal is to deliver the needed
level of security from a business-needs perspective, but not less
(i.e., lowering security), or more (i.e., driving up costs),
resulting in a deployment that matches what is required.
The trust or security of any deployment is based first and foremost
on a documented operating procedure for user enrollment, identity,
and authentication management. An equally important security
consideration is the proper training of the stakeholders (e.g.,
systems administrators, security officers, and users). If a
stakeholder deviates from established procedure either because
he/she is poorly trained or does so intentionally, they may defeat
many security-technology countermeasures.
Time sources for document and certificate signing are provided
by the internal domain or an external source. Some external time
sources provide a higher reliability and level of trust, however,
they carry a cost overhead that may not be tolerable for all
businesses. Trust in internal-domain time sources can be increased
through management policy and security mechanisms. Policy and
security mechanisms can prohibit the use of PCs as time sources,
and prevent tampering with clocks. An effective option for raising
confidence in internal-domain time source is the clock of a FIPS-
evaluated secure key server. Since keys are securely accessed for
signature operations, time stamps can be provided from this
protected source from within the domain.
Concerning user authentication, simple user name and password
schemes provide less security than two-factor schemes like one-time
password tokens, identity smart cards, or biometrics. Furthermore,
server-based user authentication is generally viewed as more secure
because servers can be less vulnerable to trojan-horse or virus
software than the typical user's PC.
Marchioni & Itzhaki Informational [Page 8]
Internet-Draft Digital Signature System Deployment 30 September 2008
Hardware protection for keys can be provided at various levels
depending on the requirements of the business or the value of its
transactions. For example, key servers that have been evaluated for
FIPS 140-2 level 3 and smart cards provide hardware protection
for keys. The designers of such hardware consider such scenarios
in which hardware might fall into the hands of an attacker, or user
keys might be exposed to a systems administrator. As a precaution
countermeasures are built into their respective key-protection
hardware.
4. Conclusion.
Affordable and scalable PKI deployment strategies are needed. This
alternative approach emphasizes consideration for pre-existing user-
management, authentication, and application infrastructures and
offers more access to PKI than conventional methods.
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), 2007, Available only
from Adobe Systems, Inc. See Adobe 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.
[DIAMETER] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J. Arkko,
"Diameter Base Protocol", http://www.rfc-editor.org/rfc/rfc3588.txt,
September 2003.
[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.
Marchioni & Itzhaki Informational [Page 9]
Internet-Draft Digital Signature System Deployment 30 September 2008
[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.
[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.
Marchioni & Itzhaki Informational [Page 10]
Internet-Draft Digital Signature System Deployment 30 September 2008
[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.
[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.
[RSA] [ECDSA] National Institute of Standards and Technology (NIST),
"FIPS Publication 186-2: Digital Signature Standard (DSS)",
http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf,
January 2007
[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.
Marchioni & Itzhaki Informational [Page 11]
Internet-Draft Digital Signature System Deployment 30 September 2008
[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.
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.
Acknowledgement.
Development of this informational RFC was sponsored by ARX, Inc. and
Algorithmic Research, Ltd.
Marchioni & Itzhaki Informational [Page 12]
Internet-Draft Digital Signature System Deployment 30 September 2008
Authors' Addresses
John Marchioni
ARX, Inc.
855 Folsom Street Suite 939
San Francisco, CA 94107 USA
EMail: johnmarc@arx.com
Yair Itzhaki
Tal Yas'ur
Algorithmic Research, Ltd.
10 Nevatim Street
Petach Tikva, 49561 Israel
EMail: yair@arx.com
EMail: tal@arx.com
Copyright (C) The IETF Trust (2008).
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.