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

["Mark Joseph" <mark%p6r.com@localhost>]

>    - 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.
>
> <tp>
> the presence and absence of the hyphen will just cause coders, users and
> everyone else to make mistakes, forgetting that it is sometimes there
> and sometimes not.  Technically it makes no difference; in terms of
> producing a robust protocol, it does
I don't mind making this change as it is minor, however, I doubt it will save an coding errors.
>    -" 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).
>
> <tp>
> The IETF has produced a Standards Track V2 - I expect the numbers 3, 4,
> 5 etc to be implicitly at least reserved for IETF Standard Track use,
> not to be used for a private protocol, even if it does appear in an RFC.
> And since it is 'totally separate', then the use of 3 seems
> inappropriate.  With other, more recent protocols, fields like this have
> a defined range for IETF Standards and a separate one for other
> variants.
Again we are defining a new protocol one where the subsystem name is private
to us and thus it is easy to start at any number.
Since this is not related directly to any other protocol is it not relevant what version number
we start at.   So in this issue I disagree with the reviewers comment.

>   - " 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.
>
> <tp>
> I am surprised by this.  Interoperability, which is a usual requirement
> for an IETF protocol, requires that different implementors come up with
> solutions that can interwork, which means that they know what values of
> what parameters may be encountered, and what they mean.  An undefined
> list of potential certificate types seems not to meet that requirement.
I am not disagreeing that it should not have an IANA listing.   What I am saying is 
that certificate listings under IANA should either exist already or done by another 
RFC.   I would be glad to reference to whatever IANA definition of standard certs
that exists.
>   - 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.
>
> <tp>
> I find the Security Considerations weak, by the standards of 2013, and
> this is an area which I think that they should explore, pointing out the
> dangers.
Security such as this needs to be defined by a policy in the server not by a 
protocol.  That is the proper approach in 2013 as done by many other examples
one such is KMIP.   I have no problem adding a note with such a warning but
this protocol is again too low level to define such things.   It is a bad design to 
place policy at such a low level.  This is basic security system design.
So again I disagree with the reviewer.
>   - 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.
>
> <tp>
> I find the Security Considerations weak, by the standards of 2013, and
> this is an area which I think that they should explore, pointing out the
> dangers.
> Certificates are the crux of much security so replacing one by another
> seems like replacing the foundation stone of a building and whilst you
> may only be manufacturing the crowbar that makes this possible, I think
> that, in these times, it behoves you to point out that doing so may
> cause the building to collapase on you.
Same comments as the last comment.

Mark Joseph, Ph.D.
P6R, Inc



>  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