Subject: Fwd: I-D Action: draft-joseph-pkix-p6rsshextension-03.txt

From: Sean Turner <[email-masked]>
Date: Tue, 03 Sep 2013 09:57:45 -0400

This draft is going to be on an upcoming IESG telechat (as an ISE 
submission) and was wondering if somebody could have a look at it and 
provide comments.

Thanks,

spt

-------- Original Message --------
Subject: I-D Action: draft-joseph-pkix-p6rsshextension-03.txt
Date: Sun, 23 Jun 2013 11:27:34 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title           : P6R's Secure Shell Public Key Subsystem
	Author(s)       : Mark Joseph
                           Jim Susoy
	Filename        : draft-joseph-pkix-p6rsshextension-03.txt
	Pages           : 10
	Date            : 2013-06-23

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

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-joseph-pkix-p6rsshextension

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-joseph-pkix-p6rsshextension-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-joseph-pkix-p6rsshextension-03

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: t.petch <[email-masked]>
Date: Tue, 3 Sep 2013 18:13:20 +0100

A brief look makes me think that more work i needed.

 - Certifcate sometimes has two i, sometimes one i

 - why list-certificates with a  hyphen and listnamespaces without?

 -" This document defines version 3 of the new protocol.  We are using
   version 3 so that it can be backward compatible with the protocol
   defined by RFC 4819 [1]. "
  Um, seems a bit like namespace squatting which seems improper in an
Informational RFC

- " Examples of possible "certificate format name" are: "X509",
   "pgp-sign-rsa", and "pgp-sign-dss".  "
I would expect interoperability to require a defined list, the sort of
thing that IANA does rather well.
Also, the names would be more recognisable if there were something that
said certificate, rather than key types, eg cert-pgp-sign-rsa

- what happens if a removed certificate is in use? I am used to key
replacement protocols that have well-defined procedures about what
overlap there is and how it is managed.  A bald replace seems dodgy.

- is there any constraint about the relationship between a certificate
and the one that is replacing it? should the new one have anything in
common with the old, should it be more secure for some meaning of that
term?  To me, managing certificates should be more heavyweight than
managing public keys.

Tom Petch

----- Original Message -----
From: "Sean Turner" <[email-masked]>
To: <[email-masked]>;
<[email-masked]>
Sent: Tuesday, September 03, 2013 2:57 PM
Subject: Fwd: I-D Action: draft-joseph-pkix-p6rsshextension-03.txt