Our responses below.
From: t.petch [mailto:ietfc%btconnect.com@localhost]
To: Sean Turner [mailto:turners%ieca.com@localhost], ietf-ssh%NetBSD.org@localhost, draft-joseph-pkix-p6rsshextension%tools.ietf.org@localhost
Sent: Tue, 03 Sep 2013 10:13:20 -0800
Subject: Re: I-D Action: draft-joseph-pkix-p6rsshextension-03.txt
A brief look makes me think that more work i needed.
- Certifcate sometimes has two i, sometimes one i
Sorry but this is not clear, can you please explain.
- why list-certificates with a hyphen and listnamespaces without?
Yes we could make that change thought I don't see how it is really significant.
-" 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
Our document actually defines a totally separate protocol from RFC 4819.
In section 3 of our document we state that we use a different subsystem name:
"publickey%p6r.com@localhost". We can start the version number at
anything. The benefit of starting with Version 3 is that software
used to build RFC 4819 implemenations could be extended easily
to add the functionality we have defined (since that is what we did).
- " 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
A previous reviewer had us add the PGP reference since it comes from RFC 4253 SSH Transport layer
protocol (Section 6 Public Key Algorithms). Frankly I don't see the benefit of doing an IANA of certificate types
for this RFC since there has to be an existing one already for X509 and PGP certs.
Seems redundant.
- 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.
In reality, systems will use a key or cert for an existing session even if it gets
deleted since it has already been loaded into the protocol software (e.g., openSSL)
Any new session that tries to use the key or cert while it is being changed should not be able to.
This is am implementation on the server side and not appropriate for a protocol definition.
If we add that it cannot be deleted while in use then likely it can be held far longer
than desired. An administrator who wants or even needs to remove a cert should
be able to do so immediately for all new sessions.
- 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.
Interesting point but I don't see the relevance to this work. All we are describing
is a mechanism to modify both keys and certificates. What you mention seems like
a discussion of what sits on top of our mechanism. If you look at KMIP the server
can define policies and yet KMIP is a much more than what we describe.
Tom Petch
----- Original Message -----
From: "Sean Turner" <turners%ieca.com@localhost>
To: <ietf-ssh%NetBSD.org@localhost>;
<draft-joseph-pkix-p6rsshextension%tools.ietf.org@localhost>
Sent: Tuesday, September 03, 2013 2:57 PM
Subject: Fwd: I-D Action: draft-joseph-pkix-p6rsshextension-03.txt
> 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: internet-drafts%ietf.org@localhost
> Reply-To: internet-drafts%ietf.org@localhost
> To: i-d-announce%ietf.org@localhost
>
>
> 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
> I-D-Announce%ietf.org@localhost
> 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
>
>
>
>