DSA and RSA Key and Signature Encoding for the KeyNote Trust Management System
How KeyNote writes down RSA and DSA keys and signatures, so that every implementation reads them the same way.
Blaze, M., Ioannidis, J., and A. Keromytis, "DSA and RSA Key and Signature Encoding for the KeyNote Trust Management System", RFC 2792, DOI 10.17487/RFC2792, March 2000, <https://www.rfc-editor.org/info/rfc2792>.
@misc{rfc2792,
series = {Request for Comments},
number = 2792,
howpublished = {RFC 2792},
publisher = {RFC Editor},
doi = {10.17487/RFC2792},
url = {https://www.rfc-editor.org/info/rfc2792},
author = {M. Blaze and J. Ioannidis and A. Keromytis},
title = {{DSA and RSA Key and Signature Encoding for the KeyNote Trust Management System}},
pagetotal = 7,
year = 2000,
month = mar,
} RFC text
Contents
Network Working Group M. Blaze
Request for Comments: 2792 J. Ioannidis
Category: Informational AT&T Labs - Research
A. Keromytis
U. of Pennsylvania
March 2000
DSA and RSA Key and Signature Encoding for the
KeyNote Trust Management System
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This memo describes RSA and DSA key and signature encoding, and
binary key encoding for version 2 of the KeyNote trust-management
system.
1. Introduction
KeyNote is a simple and flexible trust-management system designed to
work well for a variety of large- and small-scale Internet-based
applications. It provides a single, unified language for both local
policies and credentials. KeyNote policies and credentials, called
`assertions', contain predicates that describe the trusted actions
permitted by the holders of specific public keys. KeyNote assertions
are essentially small, highly-structured programs. A signed
assertion, which can be sent over an untrusted network, is also
called a `credential assertion'. Credential assertions, which also
serve the role of certificates, have the same syntax as policy
assertions but are also signed by the principal delegating the trust.
For more details on KeyNote, see [BFIK99]. This document assumes
reader familiarity with the KeyNote system.
Cryptographic keys may be used in KeyNote to identify principals. To
facilitate interoperation between different implementations and to
allow for maximal flexibility, keys must be converted to a normalized
canonical form (depended on the public key algorithm used) for the
purposes of any internal comparisons between keys. For example, an
RSA [RSA78] key may be encoded in base64 ASCII in one credential, and
in hexadecimal ASCII in another. A KeyNote implementation must
internally convert the two encodings to a normalized form that allows
for comparison between them. Furthermore, the internal structure of
an encoded key must be known for an implementation to correctly
decode it.
In some applications, other types of values, such as a passphrase or
a random nonce, may be used as principal identifiers. When these
identifiers contain characters that may not appear in a string (as
defined in [BFIK99]), a simple ASCII encoding is necessary to allow
their use inside KeyNote assertions. Note that if the identifier
only contains characters that can appear in a string, it may be used
as-is. Naturally, such identifiers may not be used to sign an
assertion, and thus no related signature encoding is defined.
This document specifies RSA and DSA [DSA94] key and signature
encodings, and binary key encodings for use in KeyNote.
2. Key Normalized Forms
2.1 DSA Key Normalized Form
DSA keys in KeyNote are identified by four values:
- the public value, y
- the p parameter
- the q parameter
- the g parameter
Where the y, p, q, and g are the DSA parameters corresponding to the
notation of [Sch96]. These four values together make up the DSA key
normalized form used in KeyNote. All DSA key comparisons in KeyNote
occur between normalized forms.
2.2 RSA Key Normalized Form
RSA keys in KeyNote are identified by two values:
- the public exponent
- the modulus
These two values together make up the RSA key normalized form used in
KeyNote. All RSA key comparisons in KeyNote occur between normalized
forms.
2.3 Binary Identifier Normalized Form
The normalized form of a Binary Identifier is the binary identifier's
data. Thus, Binary Identifier comparisons are essentially binary-
string comparisons of the Identifier values.
3. Key Encoding
3.1 DSA Key Encoding
DSA keys in KeyNote are encoded as an ASN1 SEQUENCE of four ASN1
INTEGER objects. The four INTEGER objects are the public value and
the p, q, and g parameters of the DSA key, in that order.
For use in KeyNote credentials, the ASN1 SEQUENCE is then ASCII-
encoded (e.g., as a string of hex digits or base64 characters).
DSA keys encoded in this way in KeyNote must be identified by the
"dsa-XXX:" algorithm name, where XXX is an ASCII encoding ("hex" or
"base64"). Other ASCII encoding schemes may be defined in the
future.
3.2 RSA Key Encoding
RSA keys in KeyNote are encoded as an ASN1 SEQUENCE of two ASN1
INTEGER objects. The two INTEGER objects are the public exponent and
the modulus of the DSA key, in that order.
For use in KeyNote credentials, the ASN1 SEQUENCE is then ASCII-
encoded (e.g., as a string of hex digits or base64 characters).
RSA keys encoded in this way in KeyNote must be identified by the
"rsa-XXX:" algorithm name, where XXX is an ASCII encoding ("hex" or
"base64"). Other ASCII encoding schemes may be defined in the
future.
3.3 Binary Identifier Encoding
Binary Identifiers in KeyNote are assumed to have no internal
encoding, and are treated as a sequence of binary digits. The Binary
Identifiers are ASCII-encoded, similarly to RSA or DSA keys.
Binary Identifiers encoded in this way in KeyNote must be identified
by the "binary-XXX:" algorithm name, where XXX is an ASCII encoding
("hex" or "base64"). Other ASCII encoding schemes may be defined in
the future.
4. Signature Computation and Encoding
4.1 DSA Signature Computation and Encoding
DSA signatures in KeyNote are computed over the assertion body
(starting from the beginning of the first keyword, up to and
including the newline character immediately before the "Signature:"
keyword) and the signature algorithm name (including the trailing
colon character, e.g., "sig-dsa-sha1-base64:")
DSA signatures are then encoded as an ASN1 SEQUENCE of two ASN1
INTEGER objects. The two INTEGER objects are the r and s values of a
DSA signature [Sch96], in that order.
For use in KeyNote credentials, the ASN1 SEQUENCE is then ASCII-
encoded (as a string of hex digits or base64 characters).
DSA signatures encoded in this way in KeyNote must be identified by
the "sig-dsa-XXX-YYY:" algorithm name, where XXX is a hash function
name ("sha1", for the SHA1 [SHA1-95] hash function is currently the
only hash function that may be used with DSA) and YYY is an ASCII
encoding ("hex" or "base64").
4.2 RSA Signature Computation and Encoding
RSA signatures in KeyNote are computed over the assertion body
(starting from the beginning of the first keyword, up to and
including the newline character immediately before the "Signature:"
keyword) and the signature algorithm name (including the trailing
colon character, e.g., "sig-rsa-sha1-base64:")
RSA signatures are then encoded as an ASN1 OCTET STRING object,
containing the signature value.
For use in KeyNote credentials, the ASN1 OCTET STRING is then ASCII-
encoded (as a string of hex digits or base64 characters).
RSA signatures encoded in this way in KeyNote must be identified by
the "sig-rsa-XXX-YYY:" algorithm name, where XXX is a hash function
name ("md5" or "sha1", for the MD5 [Riv92] and SHA1 [SHA1-95] hash
algorithms respectively, may be used with RSA) and YYY is an ASCII
encoding ("hex" or "base64").
4.3 Binary Signature Computation and Encoding
Binary Identifiers are unstructured sequences of binary digits, and
are not associated with any cryptographic algorithm. Thus, they may
not be used to validate an assertion.
5. Security Considerations
This document discusses the format of RSA and DSA keys and signatures
and of Binary principal identifiers as used in KeyNote. The security
of KeyNote credentials utilizing such keys and credentials is
directly dependent on the strength of the related public key
algorithms. On the security of KeyNote itself, see [BFIK99].
6. IANA Considerations
Per [BFIK99], IANA should provide a registry of reserved algorithm
identifiers. The following identifiers are reserved by this document
as public key and binary identifier encodings:
- "rsa-hex"
- "rsa-base64"
- "dsa-hex"
- "dsa-base64"
- "binary-hex"
- "binary-base64"
The following identifiers are reserved by this document as signature
encodings:
- "sig-rsa-md5-hex"
- "sig-rsa-md5-base64"
- "sig-rsa-sha1-hex"
- "sig-rsa-sha1-base64"
- "sig-dsa-sha1-hex"
- "sig-dsa-sha1-base64"
Note that the double quotes are not part of the algorithm
identifiers.
7. Acknowledgments
This work was sponsored by the DARPA Information Assurance and
Survivability (IA&S) program, under BAA 98-34.
References
[Sch96] Bruce Schneier, Applied Cryptography 2nd Edition, John
Wiley & Sons, New York, NY, 1996.
[BFIK99] Blaze, M., Feigenbaum, J., Ioannidis, J. and A. Keromytis,
"The KeyNote Trust-Management System Version 2", RFC 2704,
September 1999.
[DSA94] NIST, FIPS PUB 186, "Digital Signature Standard", May 1994.
[Riv92] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RSA78] R. L. Rivest, A. Shamir, L. M. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key Cryptosystems",
Communications of the ACM, v21n2. pp 120-126, February
1978.
[SHA1-95] NIST, FIPS PUB 180-1, "Secure Hash Standard", April 1995.
http://csrc.nist.gov/fips/fip180-1.txt (ascii)
http://csrc.nist.gov/fips/fip180-1.ps (postscript)
Contacts
Comments about this document should be discussed on the
keynote-users@nsa.research.att.com mailing list.
Questions about this document can also be directed to the authors as
a group at the keynote@research.att.com alias, or to the individual
authors at:
Matt Blaze
AT&T Labs - Research
180 Park Avenue
Florham Park, New Jersey 07932-0000
EMail: mab@research.att.com
John Ioannidis
AT&T Labs - Research
180 Park Avenue
Florham Park, New Jersey 07932-0000
EMail: ji@research.att.com
Angelos D. Keromytis
Distributed Systems Lab
CIS Department, University of Pennsylvania
200 S. 33rd Street
Philadelphia, Pennsylvania 19104-6389
EMail: angelos@cis.upenn.edu
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
ISO Plain Language
On this page
§1Why Keys Need an Encoding
KeyNote is a simple and flexible trust-management system designed to work well for a variety of large- and small-scale Internet-based applications. It provides a single, unified language for both local policies and credentials. KeyNote policies and credentials, called assertions, contain predicates that describe the trusted actions permitted by the holders of specific public keys. A signed assertion, which can be sent over an untrusted network, is also called a credential assertion. Credential assertions, which also serve the role of certificates, have the same syntax as policy assertions but are also signed by the principal delegating the trust. The KeyNote system itself is defined in RFC 2704, and this memo assumes reader familiarity with it.
Cryptographic keys may be used in KeyNote to identify principals. To facilitate interoperation between different implementations and to allow for maximal flexibility, keys must be converted to a normalized canonical form, which depends on the public key algorithm used, for the purposes of any internal comparisons between keys. An RSA key may be encoded in base64 ASCII in one credential and in hexadecimal ASCII in another, and an implementation must internally convert the two encodings to a normalized form that allows comparison between them. Furthermore, the internal structure of an encoded key must be known for an implementation to correctly decode it.
In some applications, other types of values, such as a passphrase or a random nonce, may be used as principal identifiers. When these identifiers contain characters that may not appear in a string, a simple ASCII encoding is necessary to allow their use inside KeyNote assertions. If the identifier only contains characters that can appear in a string, it may be used as it is. Such identifiers may not be used to sign an assertion, and so no related signature encoding is defined.
A public key is a long number, and there are several ways to write a long number down as text. This memo picks one structure for each kind of key and one way of writing it, so that a program can take apart what it reads and compare it with another key.
§2Normalized Forms
Comparisons always happen between normalized forms, and the memo defines three of them.
- A DSA key is identified by four values: the public value y, and the p, q and g parameters. These four values together make up the DSA key normalized form used in KeyNote, and all DSA key comparisons occur between normalized forms.
- An RSA key is identified by two values: the public exponent and the modulus. These two values together make up the RSA key normalized form, and all RSA key comparisons occur between normalized forms.
- A binary identifier has as its normalized form the identifier's data itself, so binary identifier comparisons are essentially binary-string comparisons of the identifier values.
Each kind of key has a short list of numbers that really defines it. Two keys are the same when those numbers match, however they were written down. For a passphrase, the data itself is the definition, so two binary identifiers are compared as plain strings.
§3Key Encoding
A DSA key is encoded as an ASN1 SEQUENCE of four ASN1 INTEGER objects: the public value, then the p, q and g parameters of the DSA key, in that order. For use in KeyNote credentials, the ASN1 SEQUENCE is then ASCII-encoded, for example as a string of hex digits or base64 characters. DSA keys encoded this way in KeyNote must be identified by the dsa-XXX: algorithm name, where XXX is the ASCII encoding, either hex or base64. Other ASCII encoding schemes may be defined in the future.
An RSA key is encoded as an ASN1 SEQUENCE of two ASN1 INTEGER objects: the public exponent and the modulus, in that order. The memo's text here calls the modulus part of the DSA key, which appears to be a slip. The ASN1 SEQUENCE is then ASCII-encoded in the same way, and such keys must be identified by the rsa-XXX: algorithm name, where XXX is hex or base64.
Binary identifiers are assumed to have no internal encoding and are treated as a sequence of binary digits. They are ASCII-encoded similarly to RSA and DSA keys, and must be identified by the binary-XXX: algorithm name, where XXX is hex or base64.
Each key becomes a short list of big numbers, written in a standard structured form and then turned into letters and digits. A label at the front says what kind of key it is and which alphabet was used, so a reader knows how to undo the transformation.
| Key type | ASN.1 form | Values in order | Algorithm name |
|---|---|---|---|
| DSA | SEQUENCE of four INTEGERs | y, p, q, g | dsa-hex or dsa-base64 |
| RSA | SEQUENCE of two INTEGERs | exponent, modulus | rsa-hex or rsa-base64 |
| Binary identifier | No internal structure | the identifier data itself | binary-hex or binary-base64 |
§4Signatures
Both DSA and RSA signatures are computed over the assertion body, which starts at the beginning of the first keyword and runs up to and including the newline character immediately before the Signature: keyword, and over the signature algorithm name, including its trailing colon character, for example sig-dsa-sha1-base64:. Including the algorithm name in what is signed means a signature cannot be moved from one algorithm to another.
A DSA signature is encoded as an ASN1 SEQUENCE of two ASN1 INTEGER objects, the r and s values of a DSA signature, in that order. The ASN1 SEQUENCE is then ASCII-encoded as a string of hex digits or base64 characters, and must be identified by the sig-dsa-XXX-YYY: algorithm name, where XXX is a hash function name and YYY is the ASCII encoding. SHA1 is currently the only hash function that may be used with DSA.
An RSA signature is encoded as an ASN1 OCTET STRING object containing the signature value. The OCTET STRING is then ASCII-encoded in the same way, and must be identified by the sig-rsa-XXX-YYY: algorithm name, where XXX is a hash function name and YYY is the ASCII encoding. Either MD5 or SHA1 may be used with RSA.
Binary identifiers are unstructured sequences of binary digits and are not associated with any cryptographic algorithm, so they may not be used to validate an assertion. That is why the memo defines no signature encoding for them.
A signature covers the text of the credential and the name of the algorithm that produced it. It is then written down in the same structured form as a key, and its name says which hash function was used and which alphabet the result is in. Because a passphrase has no algorithm behind it, it cannot sign anything.
| Signature type | ASN.1 form | Hash functions | Algorithm names |
|---|---|---|---|
| DSA | SEQUENCE of two INTEGERs, r then s | sha1 only | sig-dsa-sha1-hex, sig-dsa-sha1-base64 |
| RSA | OCTET STRING | md5 or sha1 | sig-rsa-md5-hex, sig-rsa-md5-base64, sig-rsa-sha1-hex, sig-rsa-sha1-base64 |
§6Reserved Identifiers and Security
Following the KeyNote specification, IANA should provide a registry of reserved algorithm identifiers. This memo reserves six as public key and binary identifier encodings: rsa-hex, rsa-base64, dsa-hex, dsa-base64, binary-hex and binary-base64. It reserves six more as signature encodings: sig-rsa-md5-hex, sig-rsa-md5-base64, sig-rsa-sha1-hex, sig-rsa-sha1-base64, sig-dsa-sha1-hex and sig-dsa-sha1-base64. The double quotes used in the memo are not part of the algorithm identifiers.
The security section is short. The security of KeyNote credentials that use these keys depends directly on the strength of the underlying public key algorithms. On the security of KeyNote itself, the reader is referred to RFC 2704.
The authors asked for the label names to be written into an official list so that nobody uses the same label for something else. As for security, the memo says nothing beyond what the key algorithms already provide, and points at the KeyNote specification for the rest.
- rsa-hexKey — An RSA key written as hexadecimal digits.
- rsa-base64Key — An RSA key written as base64 characters.
- dsa-hexKey — A DSA key written as hexadecimal digits.
- dsa-base64Key — A DSA key written as base64 characters.
- binary-hexIdentifier — A binary identifier written as hexadecimal digits.
- binary-base64Identifier — A binary identifier written as base64 characters.
- sig-rsa-md5-hexSignature — An RSA signature over MD5, in hexadecimal.
- sig-rsa-md5-base64Signature — An RSA signature over MD5, in base64.
- sig-rsa-sha1-hexSignature — An RSA signature over SHA1, in hexadecimal.
- sig-rsa-sha1-base64Signature — An RSA signature over SHA1, in base64.
- sig-dsa-sha1-hexSignature — A DSA signature over SHA1, in hexadecimal.
- sig-dsa-sha1-base64Signature — A DSA signature over SHA1, in base64.