Re: [Curdle] WG status

Румен Петров <pkixssh@roumenpetrov.info> Mon, 17 April 2017 10:02 UTC

Return-Path: <pkixssh@roumenpetrov.info>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA5512EAF6 for <curdle@ietfa.amsl.com>; Mon, 17 Apr 2017 03:02:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgtE03DgEwrW for <curdle@ietfa.amsl.com>; Mon, 17 Apr 2017 03:02:26 -0700 (PDT)
Received: from rila.superhosting.bg (rila.superhosting.bg [91.196.125.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE63712EAE6 for <curdle@ietf.org>; Mon, 17 Apr 2017 03:02:25 -0700 (PDT)
Received: from [78.128.48.21] (port=57598 helo=[192.168.0.10]) by rila.superhosting.bg with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <pkixssh@roumenpetrov.info>) id 1d03UE-000s7B-Dl for curdle@ietf.org; Mon, 17 Apr 2017 13:02:22 +0300
Message-ID: <58F492AF.3050100@roumenpetrov.info>
Date: Mon, 17 Apr 2017 13:02:23 +0300
From: =?UTF-8?B?0KDRg9C80LXQvSDQn9C10YLRgNC+0LI=?= <pkixssh@roumenpetrov.info>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30
MIME-Version: 1.0
To: curdle <curdle@ietf.org>
References: <CADZyTkkd-JpsE89z=P10Y0esc1NCZydD5NqMTs8E5xUz-DMT_g@mail.gmail.com> <58F475B5.4090504@roumenpetrov.info> <CADPMZDBjgpzMKp1UJqWMC_xRZpfce=wOOsE51HwY2dEO73kKeA@mail.gmail.com> <CADPMZDBS3yFxWmioNRV+Vx-ThTPW636ydr1fz76vNP52DjAtZA@mail.gmail.com>
In-Reply-To: <CADPMZDBS3yFxWmioNRV+Vx-ThTPW636ydr1fz76vNP52DjAtZA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - rila.superhosting.bg
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - roumenpetrov.info
X-Get-Message-Sender-Via: rila.superhosting.bg: authenticated_id: master78@roumenpetrov.info
X-Authenticated-Sender: rila.superhosting.bg: master78@roumenpetrov.info
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/Lyyvt06EsPJWpvUkDY4TszsiDWc>
Subject: Re: [Curdle] WG status
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Apr 2017 10:02:28 -0000

denis bider wrote:
> OK, that was a bit harsh.
>
> From my perspective, this objection is exceptionally annoying because 
> it's a single person requesting a rework of the entire document in 
> order to change terminology in a way that in my view does not improve 
> clarity, and does not impact mechanics.
It is because few secsh implementation support extension. I know only 
four. Next point is that existence of one implementation is not argument 
for acceptance. In current case is not used locally defined name with 
"at-sign" and etc.
It is not first time that someone say but foo is already implemented and 
we cannot change this. Why? First precedent is why something is 
implemented as public name foo instead as locally defined foo@bar?


I wonder what you would like IANA to register .
Lest check following  rfc/chapters:

- 4250 / 4.11.3.  Public Key Algorithm Names
Public Key Algorithm Name                 Reference
          -------------------------                 ---------
          ssh-dss                            [SSH-TRANS, Section 6.6]
          ssh-rsa                            [SSH-TRANS, Section 6.6]
          pgp-sign-rsa                       [SSH-TRANS, Section 6.6]
          pgp-sign-dss                       [SSH-TRANS, Section 6.6]

- 5656/ 11.  IANA Considerations
    Consistent with Section 8 of [RFC4251] and Section 4.6 of [RFC4250],
    this document makes the following registrations:
    In the Public Key Algorithm Names registry: The family of SSH public
    key algorithm names beginning with "ecdsa-sha2-" and not containing
    the at-sign ('@'), to name the public key algorithms defined in
    Section 3.

- 6187 / 6.  IANA Considerations
    Consistent with Section 8 of [RFC4251] and Section 4.6 of [RFC4250],
    this document makes the following registrations:
    In the Public Key Algorithm Names registry:
    o  The SSH public key algorithm "x509v3-ssh-dss".
    o  The SSH public key algorithm "x509v3-ssh-rsa".
    o  The SSH public key algorithm "x509v3-rsa2048-sha256".
    o  The family of SSH public key algorithm names beginning with
       "x509v3-ecdsa-sha2-" and not containing the at-sign ('@').

There is no request for signature algorithm.

Please note and "not containing the at-sign ('@')"! Good practice to 
implement new feature and the to ask for acceptance.

Plus the fact that five "Public Key Algorithm" x509v3-ssh-* and 
x509v3-ecdsa-* reuse signature algorithm ...


[SNIP]

Regards,
Roumen Petrov