RFC 2792

RFC 2792 💖 Network Working Group · Category: Informational · Date: March 2000

Written by M. Blaze, J. Ioannidis (both AT&T Labs - Research) and A. Keromytis (U. of Pennsylvania). It doesn't obsolete or update anything listed in its header.

DSA and RSA Key and Signature Encoding for the KeyNote Trust Management System ✨

Status of This Memo 🎀

Okay so this memo is here to provide 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 covers RSA and DSA key and signature encoding, plus binary key encoding, for version 2 of the KeyNote trust-management system.

1. Introduction 🌸

KeyNote is a simple and flexible trust-management system, and it's designed to work really well for all kinds of large- and small-scale Internet-based apps. It gives you one unified language for both local policies and credentials, and it's giving clean. KeyNote policies and credentials, which are called "assertions", contain predicates that describe the trusted actions the holders of specific public keys are allowed to take. KeyNote assertions are basically small, highly-structured programs, so they're lowkey iconic. A signed assertion, which can be sent over an untrusted network, is also called a "credential assertion". Credential assertions also act as certificates. They have the same syntax as policy assertions, but they're also signed by the principal who is delegating the trust. For more details on KeyNote, check out [BFIK99]. This document assumes you already know the KeyNote system. 🫶

Cryptographic keys can be used in KeyNote to identify principals. To make different implementations play nicely together and to keep things maximally flexible, keys must be converted to a normalized canonical form (which depends on the public key algorithm being used) for any internal comparisons between keys. For example, an RSA [RSA78] key might be encoded in base64 ASCII in one credential and in hexadecimal ASCII in another. A KeyNote implementation must internally convert the two encodings into a normalized form so they can be compared. On top of that, the internal structure of an encoded key must be known for an implementation to decode it correctly. 🧚

In some apps, other kinds of values, like a passphrase or a random nonce, get 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 so they can be used inside KeyNote assertions. If the identifier only has characters that can appear in a string, it may be used as-is. Naturally, identifiers like these may not be used to sign an assertion, so no related signature encoding is defined for them. 🙈

This document specifies RSA and DSA [DSA94] key and signature encodings, along with 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

Here, y, p, q, and g are the DSA parameters that match the notation used in [Sch96]. Together these four values make up the DSA key normalized form used in KeyNote. Every DSA key comparison in KeyNote happens between normalized forms. 👑

2.2. RSA Key Normalized Form

RSA keys in KeyNote are identified by two values:

• the public exponent
• the modulus

Together these two values make up the RSA key normalized form used in KeyNote. Every RSA key comparison in KeyNote happens between normalized forms. ✨

2.3. Binary Identifier Normalized Form

The normalized form of a Binary Identifier is just the binary identifier's data. So comparing Binary Identifiers is basically a binary-string comparison 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 then gets 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 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 then gets ASCII-encoded (for example, as a string of hex digits or base64 characters).

RSA keys encoded 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, so they're treated as a sequence of binary digits. Binary Identifiers get ASCII-encoded, just like RSA or DSA keys. 🌸

Binary Identifiers encoded 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 two things: the assertion body (starting from the beginning of the first keyword, up to and including the newline character right before the "Signature:" keyword), and the signature algorithm name (including the trailing colon character, for example, "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 then gets ASCII-encoded (as a string of hex digits or base64 characters).

DSA signatures encoded this way in KeyNote must be identified by the "sig-dsa-XXX-YYY:" algorithm name, where XXX is a hash function name ("sha1", since 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 two things: the assertion body (starting from the beginning of the first keyword, up to and including the newline character right before the "Signature:" keyword), and the signature algorithm name (including the trailing colon character, for example, "sig-rsa-sha1-base64:"). 💖

RSA signatures are then encoded as an ASN1 OCTET STRING object that contains the signature value.

For use in KeyNote credentials, the ASN1 OCTET STRING then gets ASCII-encoded (as a string of hex digits or base64 characters).

RSA signatures encoded 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, which 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 aren't associated with any cryptographic algorithm. So they may not be used to validate an assertion. 🙈

---

Full Copyright Statement ✨

Okay, bestie, the legal bit 💅 Copyright (C) The Internet Society (2000). All Rights Reserved. 🎀

You're totally allowed to copy this document and pass it around to your friends 🦋 Translations count too. You can also write derivative works that comment on it, explain it, or help people implement it, and you can prepare, copy, publish, and distribute those in whole or in part with no restriction of any kind 🌈. The one catch is that the copyright notice and this paragraph have to be included on every single copy and every derivative work 🫶

BUT the document itself can't be modified in any way, so no removing the copyright notice or the references to the Internet Society or other Internet organizations 😭 The exceptions are when you're developing Internet standards (then the copyright procedures in the Internet Standards process must be followed) or when you're translating it into languages other than English 🍓

The permissions I just described are limited, but they're perpetual, and the Internet Society or its successors or assigns will not revoke them 💜

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. 🌸