Browse Prior Art Database

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

IP.com Disclosure Number: IPCOM000003391D
Original Publication Date: 2000-Mar-01
Included in the Prior Art Database: 2019-Feb-10
Document File: 7 page(s) / 9K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

M. Blaze: AUTHOR [+2]

Related Documents

10.17487/RFC2792: DOI

Abstract

This memo describes RSA and DSA key and signature encoding, and binary key encoding for version 2 of the KeyNote trust-management system. This memo provides information for the Internet community.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 26% of the total text.

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

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

Processing...
Loading...