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

Document Type RFC - Informational (March 2000; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 2792 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
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.


   This memo describes RSA and DSA key and signature encoding, and
   binary key encoding for version 2 of the KeyNote trust-management

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

Blaze, et al.                Informational                      [Page 1]
RFC 2792         Key and Signature Encoding for KeyNote       March 2000

   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

Blaze, et al.                Informational                      [Page 2]
RFC 2792         Key and Signature Encoding for KeyNote       March 2000

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
Show full document text