RFC 2792 (rfc2792) - Page 2 of 7

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

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






Blaze, et al.                Informational