X.509 Key and Signature Encoding for the KeyNote Trust Management System
RFC 5708

Received changes through RFC Editor sync (changed abstract to 'This memo describes X.509 key identifiers and signature encoding for version 2 of the KeyNote trust-management system (RFC 2704). X.509 certificates (RFC 5280) can be directly used in the Authorizer or Licensees field (or in both fields) in a KeyNote assertion, allowing for easy integration with protocols that already use X.509 certificates for authentication.

In addition, the document defines additional signature types that use other hash functions (beyond the MD5 and SHA1 hash functions that are defined in RFC 2792). This document is not an Internet Standards Track specification; it is published for informational purposes.')

[Ballot discuss]
[edited]

The draft header says "Intended Status: Proposed". This should be Informational.

Section 7., paragraph 1:
>    Per [KEYNOTE], IANA should provide a registry of reserved algorithm
>    identifiers.  The following identifiers are reserved by this document
>    as public key identifier encodings:

  Does this registry exist or does this draft intend to remind IANA that
  this registry should still be created? If the latter, and assuming
  that IANA wants to do this for a non-IETF protocol, there is
  information missing here (and from [KEYNOTE]) as to what the
  allocation policies are.

IANA comments:


Upon approval of this document, IANA will make the following
assignments at
http://www.iana.org/assignments/keynote/keynote.xhtml

ACTION 1:

Registry Name: KeyNote Public Key Format Identifiers

Identifier Reference
----------- --------------------------
x509-hex [RFC-keromytis-keynote-x509-02]
x509-base64 [RFC-keromytis-keynote-x509-02]


ACTION 2:

Registry Name: KeyNote Signature Algorithm Identifiers

Identifier Reference
-------------------------- --------------------------
sig-x509-sha1-hex [RFC-keromytis-keynote-x509-02]
sig-x509-sha1-base64 [RFC-keromytis-keynote-x509-02]
sig-x509-sha256-hex [RFC-keromytis-keynote-x509-02]
sig-x509-sha256-base64 [RFC-keromytis-keynote-x509-02]
sig-x509-sha512-hex [RFC-keromytis-keynote-x509-02]
sig-x509-sha512-base64 [RFC-keromytis-keynote-x509-02]
sig-x509-ripemd160-hex [RFC-keromytis-keynote-x509-02]
sig-x509-ripemd160-base64 [RFC-keromytis-keynote-x509-02]
sig-rsa-sha256-hex [RFC-keromytis-keynote-x509-02]
sig-rsa-sha256-base64 [RFC-keromytis-keynote-x509-02]
sig-rsa-sha512-hex [RFC-keromytis-keynote-x509-02]
sig-rsa-sha512-base64 [RFC-keromytis-keynote-x509-02]
sig-rsa-ripemd160-hex [RFC-keromytis-keynote-x509-02]
sig-rsa-ripemd160-base64 [RFC-keromytis-keynote-x509-02]

[Ballot discuss]
This document is an example where there is no conflict and no need to clarify the relationship
with IETF specifications.  While I have proposed a standard 3932 IESG note in the tracker, I am
advocating publication without any IESG note whatsoever.

This document was submitted to the RFC Editor to be published as an
Informational Independent Submission:
draft-keromytis-keynote-x509-02.txt.

Please let us know if this document conflicts with the IETF standards
process or other work being done in the IETF community.

Four week timeout expires on 12 October 2009.


X.509 Key and Signature Encoding for the
KeyNote Trust Management System

This memo describes X.509 key identifiers and signature encoding
for version 2 of the KeyNote trust-management system [KEYNOTE].
X.509 certificates [RFC3280] can be directly used in the Authorizer
or Licensees field (or in both fields) in a KeyNote assertion,
allowing for easy integration with protocols that already use X.509
certificates for authentication.

In addition, the document defines additional signature types that
use other hash functions (beyond the MD5 and SHA1 hash functions
that are defined in [RFC2792]).


NOTE: The draft lists the intended status as "Proposed." However, the
document has been requested for publication as an Informational RFC.
We will update the document to reflect "Informational" when/if it is
accepted for publication.