IETF conflict review for draft-joseph-pkix-p6rsshextension
conflict-review-joseph-pkix-p6rsshextension-01

The following approval message was sent
From: The IESG
To: "Nevil Brownlee" , draft-joseph-pkix-p6rsshextension@tools.ietf.org
Cc: The IESG , , 
Subject: Results of IETF-conflict review for draft-joseph-pkix-p6rsshextension-03

The IESG has completed a review of draft-joseph-pkix-p6rsshextension-03
consistent with RFC5742.


The IESG has no problem with the publication of 'P6R's Secure Shell
Public Key Subsystem'  as an
Informational RFC.


The IESG has concluded that this work is related to IETF work done in the
concluded WG secsh but that still has an active mailing list
(ietf-ssh@netbsd.org), but this relationship does not prevent publishing.

The IESG would also like the RFC-Editor to review the comments in the
datatracker related to this document and determine whether or not they
merit incorporation into the document. Comments may exist in both the
ballot and the history log.

The IESG review is documented at:
http://datatracker.ietf.org/doc/conflict-review-joseph-pkix-p6rsshextension/

A URL of the reviewed Internet Draft is:
http://datatracker.ietf.org/doc/draft-joseph-pkix-p6rsshextension/

The process for such documents is described at
http://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot discuss]
There is no secsh WG anymore, so the writeup can't be correct as it is. This sounds like it should get a straight "no conflict" message.

The draft draft-joseph-pkix-p6rsshextension-03
is ready for publication from the Independent Stream.
Please ask IESG to review it, as set out in RFC 5742.

The following is some background for this draft, please forward it
to IESG along with this request ...

Its abstract says:
"The Secure Shell Public Key Subsystem protocol defines a key
distribution protocol to provision an SSH server with user's public
keys. However, that protocol is limited to provisioning an SSH
server. This document describes a new protocol that builds on the
protocol defined in RFC 4819 to allow the provisioning of keys and
certificates to a server using the SSH transport.

The new protocol allows the calling client to organize
keys and certificates in different namespaces on a server. These
namespaces can be used by the server to allow a client to configure
any application running on the server (e.g., SSH, KMIP, SNMP).

The new protocol provides a server-independent mechanism for clients
to add public keys, remove public keys, add certificates, remove
certificates, and list the current set of keys and certificates
known by the server by namespace (e.g., list all public keys in the
SSH namespace).

Rights to manage keys and certificates in a specific namespace are
specific and limited to the authorized user and are defined as part
of the server's implementation. The described protocol is backward
compatible to version 2 defined by RFC 4819."

It was reviewed for me by Jim Schaad, who put a lot of effort into
working with its author to make it clear that this is a new protocol,
rather than an extension to that in RFC 4819.

I have asked IANA about the allocations it requests, but so far I
haven't had an answer from them to [IANA #700798].

Thanks, Nevil (ISE)