IETF Logo Mail Archive

Re: [Curdle] Comments on draft-ietf-curdle-rsa-sha2

"denis bider \(Bitvise\)" <ietf-ssh3@denisbider.com> Sun, 26 March 2017 18:03 UTC

Return-Path: <ietf-ssh3@denisbider.com>
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 19A5D12967A for <curdle@ietfa.amsl.com>; Sun, 26 Mar 2017 11:03:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.com
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 2ZYbiSwUFYtc for <curdle@ietfa.amsl.com>; Sun, 26 Mar 2017 11:03:15 -0700 (PDT)
Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 943D6129493 for <curdle@ietf.org>; Sun, 26 Mar 2017 11:03:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to: references; bh=eZJrk2gVbiSK6KRp7cAvaWQAx1OMOVC2s1oWosQi/Gg=; b=bK/8wI3Aij509qye5RmImTT+KHDUAOccxJ4T/YCneMrF2Je2GHiVroJYyhQ+cINyMBE9EW+05eZD0 2Y3QC+gAQRTweX64Bo9e3+Cv2nKZ2mDUZGWaO4ef6DwANX01rLVAedxscmaXBAuT0NuRAQixLzm1qP AyCCIfgitfKtpZNiplVZh2H2GmQh5WZCIkEEqAoqrB54dkfN/sTwOEG8oRbNtHX9xx3eWodzgTORHz JDJfVQmdyhIylICzkvM3ZwgKGPPUE8tev7r4Ri5N1zRgKpkJViAaX/AF97xAuhUanteHc9TIb+xm+e 3POWQRNjUN8n+t2F4vjI29ymjHG0U/w==
X-Footer: ZGVuaXNiaWRlci5jb20=
Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com with ESMTPSA (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Sun, 26 Mar 2017 19:03:12 +0100
Message-ID: <16EFC4E5FC894A61BDE01CEC2EB869AE@Khan>
From: "denis bider (Bitvise)" <ietf-ssh3@denisbider.com>
To: Румен Петров <pkixssh@roumenpetrov.info>, curdle@ietf.org
References: <148823325745.13859.1818801191554779419.idtracker@ietfa.amsl.com> <58CCEF4F.7000902@roumenpetrov.info> <9EABA431E21041239B7D2B164FAA5AC3@Khan> <58CD46B0.9010902@roumenpetrov.info> <ADC444ABDBC64FF99D38E3708D91124A@Khan> <58D7A456.9040609@roumenpetrov.info>
In-Reply-To: <58D7A456.9040609@roumenpetrov.info>
Date: Sun, 26 Mar 2017 12:03:22 -0600
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D7_01D2A628.F7816240"
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3528.331
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/5JCuCI8eCb3UI8aZbuTid9hevm8>
Subject: Re: [Curdle] Comments on draft-ietf-curdle-rsa-sha2
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: Sun, 26 Mar 2017 18:03:17 -0000

Objection noted. I disagree. I have explained, I have addressed, and will not argue this further.


From: Румен Петров 
Sent: Sunday, March 26, 2017 05:21
To: curdle@ietf.org 
Subject: Re: [Curdle] Comments on draft-ietf-curdle-rsa-sha2

Hi Denis and members of curdle group,

denis bider (Bitvise) wrote:
> Hello Roumen:
>
>
>> Quote from rfc4252:
>> byte SSH_MSG_USERAUTH_REQUEST
>> [...]
>> string    public key algorithm name <<<<-----
>
> Thank you for pointing this out. This is an important point. The 
> document needs a more formal discussion to properly introduce the 
> concept for "signature algorithm".
>
> Draft submissions are currently off, but I have clarified this in my 
> local version with an additional section that discusses the terms 
> "public key algorithm" and "signature algorithm" in detail. It also 
> points out two places in RFC4252 and RFC4253 which subtly change 
> meaning, and now encode a signature algorithm name.
>
> Since I cannot submit it right now, I attach a copy of my current 
> local version.
I have objection to change meaning of public key algorithm identifier . 
It is well defined in chapter 6.6. "Public Key Algorithms" of RFC 4253.

I cannot understand the goal of such change ("*Signature Algorithm as 
Distinct Aspect of* Public Key *Algorithm*").
You define new "public key algorithm identifier" and signature 
identifier is same although it not necessary as is by default "Public 
key/certificate formats that do not explicitly specify a signature 
format identifier MUST use the public key/certificate format identifier 
as the signature identifier."

It seems to me you would like to swap(replace) "public key" with 
"signature" in all RFC documents with this document(draft).


Why to redefineconcept?
Is not more easy to define new public-key algorithms? Such definition 
does not require relation with server extension. If server extension is 
not accepted then "rsa-sha2" should be canceled (suspended).



[SNIP]

Regards,
Roumen Petrov


P.S. attachment "rsa-sha2-03_vs_04.html" is deference in html format 
between v3 and v4.





--------------------------------------------------------------------------------
_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

v2.23.0 | Report a Bug | By Email