Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
RFC 4055
| Document | Type |
RFC
- Proposed Standard
(June 2005)
Errata
Updated by RFC 5756
Updates RFC 3279
|
|
|---|---|---|---|
| Authors | Russ Housley , Jim Schaad, Burt Kaliski | ||
| Last updated | 2020-01-21 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Steven M. Bellovin | |
| Send notices to | (None) |
RFC 4055
maskGenFunc
The maskGenFunc field identifies the mask generation function.
The default mask generation function is MGF1 with SHA-1. For
MGF1, it is strongly RECOMMENDED that the underlying hash
function be the same as the one identified by hashFunc.
Implementations MUST support MGF1. MGF1 requires a one-way
hash function that is identified in the parameter field of the
MGF1 algorithm identifier. Implementations MUST support SHA-1
and MAY support any of the other one-way hash functions listed
in Section 2.1. The MGF1 algorithm identifier is comprised of
the id-mgf1 object identifier and a parameter that contains the
algorithm identifier of the one-way hash function employed with
MGF1. The SHA-1 algorithm identifier is comprised of the id-
sha1 object identifier and an (optional) parameter of NULL.
Implementations that perform encryption MUST omit the
maskGenFunc field when MGF1 with SHA-1 is used, indicating that
the default algorithm was used.
Although mfg1SHA1Identifier is defined as the default value for
this field, implementations MUST accept both the default value
encoding (i.e., an absent field) and the mfg1SHA1Identifier to
be explicitly present in the encoding.
pSourceFunc
The pSourceFunc field identifies the source (and possibly the
value) of the encoding parameters, commonly called P.
Implementations MUST represent P by an algorithm identifier,
id-pSpecified, indicating that P is explicitly provided as an
OCTET STRING in the parameters. The default value for P is an
empty string. In this case, pHash in EME-OAEP contains the
hash of a zero length string. Implementations MUST support a
zero length P value. Implementations that perform encryption
MUST omit the pSourceFunc field when a zero length P value is
used, indicating that the default value was used.
Implementations that perform decryption MUST recognize both the
id-pSpecified object identifier and an absent pSourceFunc field
as an indication that a zero length P value was used.
Implementations that perform decryption MUST support a zero
length P value and MAY support other values. Compliant
implementations MUST NOT use any value other than id-pSpecified
for pSourceFunc.
Schaad, et al. Standards Track [Page 12]
RFC 4055 Additional RSA Algorithms and Identifiers June 2005
If the default values of the hashFunc, maskGenFunc, and pSourceFunc
fields of RSAES-OAEP-params are used, then the algorithm identifier
will have the following value:
rSAES-OAEP-Default-Identifier AlgorithmIdentifier ::=
{ id-RSAES-OAEP,
rSAES-OAEP-Default-Params }
rSAES-OAEP-Default-Params RSASSA-OAEP-params ::=
{ sha1Identifier,
mgf1SHA1Identifier,
pSpecifiedEmptyIdentifier }
5. PKCS #1 Version 1.5 Signature Algorithm
RFC 2313 [P1v1.5] specifies the PKCS #1 Version 1.5 signature
algorithm. This specification is also included in PKCS #1 Version
2.1 [P1v2.1]. RFC 3279 [PKALGS] specifies the use of the PKCS #1
Version 1.5 signature algorithm with the MD2, MD5, and the SHA-1
one-way hash functions. This section specifies the algorithm
identifiers for using the SHA-224, SHA-256, SHA-384, and SHA-512
one-way hash functions with the PKCS #1 version 1.5 signature
algorithm.
The RSASSA-PSS signature algorithm is preferred over the PKCS #1
Version 1.5 signature algorithm. Although no attacks are known
against PKCS #1 Version 1.5 signature algorithm, in the interest of
increased robustness, RSASSA-PSS signature algorithm is recommended
for eventual adoption, especially by new applications. This section
is included for compatibility with existing applications, and while
still appropriate for new applications, a gradual transition to the
RSASSA-PSS signature algorithm is encouraged.
The PKCS #1 Version 1.5 signature algorithm with these one-way hash
functions and the RSA cryptosystem is implemented using the padding
and encoding conventions described in RFC 2313 [P1v1.5].
The message digest is computed using the SHA-224, SHA-256, SHA-384,
or SHA-512 one-way hash function.
The PKCS #1 version 1.5 signature algorithm, as specified in RFC
2313, includes a data encoding step. In this step, the message
digest and the object identifier for the one-way hash function used
to compute the message digest are combined. When performing the data
encoding step, the id-sha224, id-sha256, id-sha384, and id-sha512
object identifiers (see Section 2.1) MUST be used to specify the
SHA-224, SHA-256, SHA-384, and SHA-512 one-way hash functions,
respectively.
Schaad, et al. Standards Track [Page 13]
RFC 4055 Additional RSA Algorithms and Identifiers June 2005
The object identifier used to identify the PKCS #1 version 1.5
signature algorithm with SHA-224 is:
sha224WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 14 }
The object identifier used to identify the PKCS #1 version 1.5
signature algorithm with SHA-256 is:
sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 }
The object identifier used to identify the PKCS #1 version 1.5
signature algorithm with SHA-384 is:
sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 }
The object identifier used to identify the PKCS #1 version 1.5
signature algorithm with SHA-512 is:
sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 }
When any of these four object identifiers appears within an
AlgorithmIdentifier, the parameters MUST be NULL. Implementations
MUST accept the parameters being absent as well as present.
The RSA signature generation process and the encoding of the result
are described in detail in RFC 2313 [P1v1.5].
6. ASN.1 Module
PKIX1-PSS-OAEP-Algorithms
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-rsa-pkalgs(33) }
DEFINITIONS EXPLICIT TAGS ::= BEGIN
-- EXPORTS All;
IMPORTS
AlgorithmIdentifier
FROM PKIX1Explicit88 -- Found in [PROFILE]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18) } ;
Schaad, et al. Standards Track [Page 14]
RFC 4055 Additional RSA Algorithms and Identifiers June 2005
-- ============================
-- Basic object identifiers
-- ============================
pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) 1 }
-- When rsaEncryption is used in an AlgorithmIdentifier the
-- parameters MUST be present and MUST be NULL.
rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 }
-- When id-RSAES-OAEP is used in an AlgorithmIdentifier,
-- and the parameters field is present, it MUST be
-- RSAES-OAEP-params
id-RSAES-OAEP OBJECT IDENTIFIER ::= { pkcs-1 7 }
-- When id-pSpecified is used in an AlgorithmIdentifier the
-- parameters MUST be an OCTET STRING.
id-pSpecified OBJECT IDENTIFIER ::= { pkcs-1 9 }
-- When id-RSASSA-PSS is used in an AlgorithmIdentifier, and the
-- parameters field is present, it MUST be RSASSA-PSS-params.
id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
-- When id-mgf1 is used in an AlgorithmIdentifier the parameters
-- MUST be present and MUST be a HashAlgorithm.
id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 }
-- When the following OIDs are used in an AlgorithmIdentifier, the
-- parameters MUST be present and MUST be NULL.
sha224WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 14 }
sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 }
sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 }
sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 }
Schaad, et al. Standards Track [Page 15]
RFC 4055 Additional RSA Algorithms and Identifiers June 2005
-- When the following OIDs are used in an AlgorithmIdentifier the
-- parameters SHOULD be absent, but if the parameters are present,
-- they MUST be NULL.
id-sha1 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) oiw(14)
secsig(3) algorithms(2) 26 }
id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 4 }
id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 1 }
id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 2 }
id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 3 }
-- =============
-- Constants
-- =============
nullOctetString OCTET STRING (SIZE (0)) ::= ''H
nullParameters NULL ::= NULL
-- =========================
-- Algorithm Identifiers
-- =========================
sha1Identifier AlgorithmIdentifier ::= {
algorithm id-sha1,
parameters nullParameters }
sha224Identifier AlgorithmIdentifier ::= {
algorithm id-sha224,
parameters nullParameters }
sha256Identifier AlgorithmIdentifier ::= {
algorithm id-sha256,
parameters nullParameters }
Schaad, et al. Standards Track [Page 16]
RFC 4055 Additional RSA Algorithms and Identifiers June 2005
sha384Identifier AlgorithmIdentifier ::= {
algorithm id-sha384,
parameters nullParameters }
sha512Identifier AlgorithmIdentifier ::= {
algorithm id-sha512,
parameters nullParameters }
mgf1SHA1Identifier AlgorithmIdentifier ::= {
algorithm id-mgf1,
parameters sha1Identifier }
mgf1SHA224Identifier AlgorithmIdentifier ::= {
algorithm id-mgf1,
parameters sha224Identifier }
mgf1SHA256Identifier AlgorithmIdentifier ::= {
algorithm id-mgf1,
parameters sha256Identifier }
mgf1SHA384Identifier AlgorithmIdentifier ::= {
algorithm id-mgf1,
parameters sha384Identifier }
mgf1SHA512Identifier AlgorithmIdentifier ::= {
algorithm id-mgf1,
parameters sha512Identifier }
pSpecifiedEmptyIdentifier AlgorithmIdentifier ::= {
algorithm id-pSpecified,
parameters nullOctetString }
rSASSA-PSS-Default-Params RSASSA-PSS-params ::= {
hashAlgorithm sha1Identifier,
maskGenAlgorithm mgf1SHA1Identifier,
saltLength 20,
trailerField 1 }
rSASSA-PSS-Default-Identifier AlgorithmIdentifier ::= {
algorithm id-RSASSA-PSS,
parameters rSASSA-PSS-Default-Params }
rSASSA-PSS-SHA224-Identifier AlgorithmIdentifier ::= {
algorithm id-RSASSA-PSS,
parameters rSASSA-PSS-SHA224-Params }
Schaad, et al. Standards Track [Page 17]
RFC 4055 Additional RSA Algorithms and Identifiers June 2005
rSASSA-PSS-SHA224-Params RSASSA-PSS-params ::= {
hashAlgorithm sha224Identifier,
maskGenAlgorithm mgf1SHA224Identifier,
saltLength 20,
trailerField 1 }
rSASSA-PSS-SHA256-Identifier AlgorithmIdentifier ::= {
algorithm id-RSASSA-PSS,
parameters rSASSA-PSS-SHA256-Params }
rSASSA-PSS-SHA256-Params RSASSA-PSS-params ::= {
hashAlgorithm sha256Identifier,
maskGenAlgorithm mgf1SHA256Identifier,
saltLength 20,
trailerField 1 }
rSASSA-PSS-SHA384-Identifier AlgorithmIdentifier ::= {
algorithm id-RSASSA-PSS,
parameters rSASSA-PSS-SHA384-Params }
rSASSA-PSS-SHA384-Params RSASSA-PSS-params ::= {
hashAlgorithm sha384Identifier,
maskGenAlgorithm mgf1SHA384Identifier,
saltLength 20,
trailerField 1 }
rSASSA-PSS-SHA512-Identifier AlgorithmIdentifier ::= {
algorithm id-RSASSA-PSS,
parameters rSSASSA-PSS-SHA512-params }
rSSASSA-PSS-SHA512-params RSASSA-PSS-params ::= {
hashAlgorithm sha512Identifier,
maskGenAlgorithm mgf1SHA512Identifier,
saltLength 20,
trailerField 1 }
rSAES-OAEP-Default-Params RSAES-OAEP-params ::= {
hashFunc sha1Identifier,
maskGenFunc mgf1SHA1Identifier,
pSourceFunc pSpecifiedEmptyIdentifier }
rSAES-OAEP-Default-Identifier AlgorithmIdentifier ::= {
algorithm id-RSAES-OAEP,
parameters rSAES-OAEP-Default-Params }
rSAES-OAEP-SHA224-Identifier AlgorithmIdentifier ::= {
algorithm id-RSAES-OAEP,
parameters rSAES-OAEP-SHA224-Params }
Schaad, et al. Standards Track [Page 18]
RFC 4055 Additional RSA Algorithms and Identifiers June 2005
rSAES-OAEP-SHA224-Params RSAES-OAEP-params ::= {
hashFunc sha224Identifier,
maskGenFunc mgf1SHA224Identifier,
pSourceFunc pSpecifiedEmptyIdentifier }
rSAES-OAEP-SHA256-Identifier AlgorithmIdentifier ::= {
algorithm id-RSAES-OAEP,
parameters rSAES-OAEP-SHA256-Params }
rSAES-OAEP-SHA256-Params RSAES-OAEP-params ::= {
hashFunc sha256Identifier,
maskGenFunc mgf1SHA256Identifier,
pSourceFunc pSpecifiedEmptyIdentifier }
rSAES-OAEP-SHA384-Identifier AlgorithmIdentifier ::= {
algorithm id-RSAES-OAEP,
parameters rSAES-OAEP-SHA384-Params }
rSAES-OAEP-SHA384-Params RSAES-OAEP-params ::= {
hashFunc sha384Identifier,
maskGenFunc mgf1SHA384Identifier,
pSourceFunc pSpecifiedEmptyIdentifier }
rSAES-OAEP-SHA512-Identifier AlgorithmIdentifier ::= {
algorithm id-RSAES-OAEP,
parameters rSAES-OAEP-SHA512-Params }
rSAES-OAEP-SHA512-Params RSAES-OAEP-params ::= {
hashFunc sha512Identifier,
maskGenFunc mgf1SHA512Identifier,
pSourceFunc pSpecifiedEmptyIdentifier }
-- ===================
-- Main structures
-- ===================
-- Used in SubjectPublicKeyInfo of X.509 Certificate.
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER } -- e
Schaad, et al. Standards Track [Page 19]
RFC 4055 Additional RSA Algorithms and Identifiers June 2005
-- AlgorithmIdentifier parameters for id-RSASSA-PSS.
-- Note that the tags in this Sequence are explicit.
RSASSA-PSS-params ::= SEQUENCE {
hashAlgorithm [0] HashAlgorithm DEFAULT
sha1Identifier,
maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT
mgf1SHA1Identifier,
saltLength [2] INTEGER DEFAULT 20,
trailerField [3] INTEGER DEFAULT 1 }
HashAlgorithm ::= AlgorithmIdentifier
MaskGenAlgorithm ::= AlgorithmIdentifier
-- AlgorithmIdentifier parameters for id-RSAES-OAEP.
-- Note that the tags in this Sequence are explicit.
RSAES-OAEP-params ::= SEQUENCE {
hashFunc [0] AlgorithmIdentifier DEFAULT
sha1Identifier,
maskGenFunc [1] AlgorithmIdentifier DEFAULT
mgf1SHA1Identifier,
pSourceFunc [2] AlgorithmIdentifier DEFAULT
pSpecifiedEmptyIdentifier }
END
7. References
7.1. Normative References
[P1v1.5] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5",
RFC 2313, March 1998.
[P1v2.1] Jonsson, J. and B. Kaliski, "PKCS #1: RSA Cryptography
Specifications Version 2.1", RFC 3447, February 2003.
[PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo,
"Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC
3280, April 2002.
[SHA2] National Institute of Standards and Technology (NIST),
FIPS 180-2: Secure Hash Standard, 1 August 2002.
[SHA224] Housley, R., "A 224-bit One-way Hash Function: SHA-
224", RFC 3874, September 2004.
Schaad, et al. Standards Track [Page 20]
RFC 4055 Additional RSA Algorithms and Identifiers June 2005
[STDWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[X.208-88] CCITT Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1), 1988.
[X.209-88] CCITT Recommendation X.209: Specification of Basic
Encoding Rules for Abstract Syntax Notation One
(ASN.1), 1988.
[X.509-88] CCITT Recommendation X.509: The Directory -
Authentication Framework, 1988.
7.2. Informative References
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004.
[GUIDE] National Institute of Standards and Technology, Second
Draft: "Key Management Guideline, Part 1: General
Guidance." June 2002.
[http://csrc.nist.gov/encryption/kms/guideline-1.pdf]
[P1363A] IEEE Std 1363a-2004, Standard Specifications for
Public Key Cryptography - Amendment 1: Additional
Techniques, 2004.
[PKALGS] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 3279, April 2002.
[RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller,
"Randomness Recommendations for Security", RFC 1750,
December 1994.
[SHA-1-ATTACK] Wang, X., Yin, Y.L., and H. Yu, "Finding Collisions in
the Full SHA1", to appear, CRYPTO 2005. Preprint
available at
http://theory.csail.mit.edu/~yiqun/shanote.pdf.
8. Security Considerations
This specification supplements RFC 3280 [PROFILE]. The Security
Considerations section of that document applies to this specification
as well.
Schaad, et al. Standards Track [Page 21]
RFC 4055 Additional RSA Algorithms and Identifiers June 2005
Implementations must protect the RSA private key. Compromising the
RSA private key may result in the disclosure of all messages
protected with that key.
The generation of RSA public/private key pairs relies on a random
numbers. Using inadequate pseudo-random number generators (PRNGs) to
generate cryptographic keys can result in little or no security. An
attacker may find it much easier to reproduce the PRNG environment
that produced the keys and search the resulting small set of
possibilities, than to brute force search the whole key space. The
generation of quality random numbers is difficult and RFC 1750
[RANDOM] offers important guidance in this area.
Generally, good cryptographic practice employs a given RSA key pair
in only one scheme. This practice avoids the risk that vulnerability
in one scheme may compromise the security of the other, and may be
essential to maintain provable security. While PKCS #1 Version 1.5
[P1v1.5] has been employed for both key transport and digital
signature without any known bad interactions, such a combined use of
an RSA key pair is not recommended in the future. Therefore, an RSA
key pair used for RSASSA-PSS signature generation should not be used
for other purposes. For similar reasons, one RSA key pair should
always be used with the same RSASSA-PSS parameters (except possibly
for the salt length). Likewise, an RSA key pair used for RSAES-OAEP
key transport should not be used for other purposes. For similar
reasons, one RSA key pair should always be used with the same RSAES-
OAEP parameters.
This specification requires implementations to support the SHA-1
one-way hash function for interoperability, but support for other
one-way hash functions is permitted. Wang et al. [SHA-1-ATTACK] have
recently discovered a collision attack against SHA-1 with complexity
2^69. This attack, which can produce two new messages with the same
hash value, is the first attack on SHA-1 faster than the generic
attack with complexity 2^80, where 80 is one-half the bit length of
the hash value.
In general, when a one-way hash function is used with a digital
signature scheme, a collision attack is easily translated into a
signature forgery. Therefore, using SHA-1 in a digital signature
scheme provides a security level of no more than 69 bits if the
attacker can persuade the signer to sign a message resulting from a
collision attack. If the attacker can't persuade the signer to sign
such a message, however, then SHA-1 still provides a security level
of at least 80 bits since the best (known) inversion attack (which
produces a new message with a previous hash value) is the generic
attack with complexity 2^160. If a greater level of security is
desired, then a secure one-way hash function with a longer hash value
Schaad, et al. Standards Track [Page 22]
RFC 4055 Additional RSA Algorithms and Identifiers June 2005
is needed. SHA-256, SHA-384, and SHA-512 are reasonable choices
[SHA2], although their security needs to be reconfirmed in light of
the SHA-1 results.
The metrics for choosing a one-way hash function for use in digital
signatures do not directly apply to the RSAES-OAEP key transport
algorithm, since a collision attack on the one-way hash function does
not directly translate into an attack on the key transport algorithm,
unless the encoding parameters P vary (in which case a collision of
the hash value for different encoding parameters might be exploited).
Nevertheless, for consistency with the practice for digital signature
schemes, and in case the encoding parameters P is not the empty
string, it is recommended that the same rule of thumb be applied to
selecting a one-way hash function for use with RSAES-OAEP. That is,
the one-way hash function should be selected so that the bit length
of the hash value is at least twice as long as the desired security
level in bits.
The key size selected impacts the strength achieved when implementing
cryptographic services. Thus, selecting appropriate key sizes is
critical to implementing appropriate security. A 1024-bit RSA public
key is considered to provide a security level of about 80 bits. In
[GUIDE], the National Institute of Standards and Technology (NIST)
suggests that a security level of 80 bits is adequate for the
protection of sensitive information until 2015. This recommendation
is likely to be revised based on recent advances, and is expected to
be more conservative, suggesting that a security level of 80 bits is
adequate protection of sensitive information until 2010. If a
security level greater than 80 bits is needed, then a longer RSA
public key and a secure one-way hash function with a longer hash
value are needed. SHA-224, SHA-256, SHA-384, and SHA-512 are
reasonable choices for such a one-way hash function, modulo the
reconfirmation noted above. For this reason, the algorithm
identifiers for these one-way hash functions are included in the
ASN.1 module in Section 6.
Current implementations MUST support 1024-bit RSA public key sizes.
Before the end of 2007, implementations SHOULD support RSA public key
sizes of at least 2048 bits and SHOULD support SHA-256. This
requirement is intended to allow adequate time for users to deploy
the stronger digital signature capability by 2010.
When using RSASSA-PSS, the same one-way hash function should be
employed for the hashAlgorithm and the maskGenAlgorithm, but it is
not required. When using RSAES-OAEP, the same one-way hash function
Schaad, et al. Standards Track [Page 23]
RFC 4055 Additional RSA Algorithms and Identifiers June 2005
should be employed for the hashFunc and the maskGenFunc, but it is
not required. In each case, using the same one-way hash function
helps with security analysis and reduces implementation complexity.
9. IANA Considerations
Within the certificates and CRLs, algorithms are identified by object
identifiers. All object identifiers used in this document were
assigned in Public-Key Cryptography Standards (PKCS) documents or by
the National Institute of Standards and Technology (NIST). No
further action by the IANA is necessary for this document or any
anticipated updates.
Authors' Addresses
Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
USA
EMail: housley@vigilsec.com
Burt Kaliski
RSA Laboratories
174 Middlesex Turnpike
Bedford, MA 01730
USA
EMail: bkaliski@rsasecurity.com
Jim Schaad
Soaring Hawk Consulting
PO Box 675
Gold Bar, WA 98251
USA
EMail: jimsch@exmsft.com
Schaad, et al. Standards Track [Page 24]
RFC 4055 Additional RSA Algorithms and Identifiers June 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 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.
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
Funding for the RFC Editor function is currently provided by the
Internet Society.
Schaad, et al. Standards Track [Page 25]