Subject: Re: [Curdle] Opsdir last call review of draft-ietf-curdle-ssh-ed25519-ed448-07

From: Daniel Migault <[email-masked]>
Date: Wed, 5 Jun 2019 09:53:00 -0400

Dear co-authors of curdle-ssh-ed25519-ed448,

Could we update the document and address the concern from Sheng ?

Yours,
Daniel

On Thu, Jan 3, 2019 at 11:23 AM Daniel Migault <[email-masked]>
wrote:

> Hi Sheng,
>
> Thanks for the comment. It should be easily addressed in the next version.
>
> Yours,
> Daniel
>
> -----Original Message-----
> From: Sheng Jiang <[email-masked]>
> Sent: Thursday, January 03, 2019 8:59 AM
> To: Daniel Migault <[email-masked]>; Tim Hollebeek <
> [email-masked]>; [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: Opsdir last call review of
> draft-ietf-curdle-ssh-ed25519-ed448-07
>
> Hi, Daniel,
>
> The suggestion from Tim is a good improvement. However, it would be even
> better for a "standard track" document, if it gave a little bit more
> detailed guidance "where" and "how" a SSH implement should quota the key
> format that defined in this document.
>
> Regards,
>
> Sheng
>
> -----Original Message-----
> From: Daniel Migault [mailto:[email-masked]]
> Sent: Thursday, January 3, 2019 2:57 AM
> To: Tim Hollebeek <[email-masked]>; Sheng Jiang <
> [email-masked]>; [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: Opsdir last call review of
> draft-ietf-curdle-ssh-ed25519-ed448-07
>
> Thanks for the suggestion Tim. That works for me.
> Yours,
> Daniel
>
> -----Original Message-----
> From: Tim Hollebeek <[email-masked]>
> Sent: Wednesday, January 02, 2019 1:12 PM
> To: Daniel Migault <[email-masked]>; Sheng Jiang <
> [email-masked]>; [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: Opsdir last call review of
> draft-ietf-curdle-ssh-ed25519-ed448-07
>
> Why not just reference RFC 2119 and say "Standard implementations of SSH
> SHOULD implement these signature algorithms." ?
>
> -Tim
>
> > -----Original Message-----
> > From: Curdle <[email-masked]> On Behalf Of Daniel Migault
> > Sent: Wednesday, January 2, 2019 10:43 AM
> > To: Sheng Jiang <[email-masked]>; [email-masked]
> > Cc: [email-masked]; [email-masked];
> > [email-masked]
> > Subject: Re: [Curdle] Opsdir last call review of
> draft-ietf-curdle-ssh-ed25519-
> > ed448-07
> >
> > Hi Sheng,
> >
> > Thanks for the comment and the suggestion. I agree that it may sound
> > strange to have a standard Track category without any reference to
> > RFC2119. In addition, while the document provides IANA registry
> > updates, the IANA registration does not require a Standard Track. So
> > *technically*
> the
> > informational category could be fine.
> >
> > The motivation for a Standard Track document was to have these
> > algorithms as part of the SSH protocol. In other words, we expect that
> > SSH will come with these algorithms in the future. For that reason we
> > requested the
> status
> > to be "Standard Track" to remain coherent with RFC425{1-4}.
> >
> > (RFC4250 and) RFC4253 provided the initial values for the Public Key
> registry.
> > While the protocol comes with some registry values, my understanding
> > is that updating the registry by adding a new value is not considered
> > as an update the RFC. For that reason we did not provide RFC4253 or
> > RFC4250 in the update status. While the update does not concern the
> > RFC, it affects
> the
> > protocol and should - in my opinion be associated to the same status
> > as
> the
> > protocol.
> >
> > As a side note, all RFCs that have updated the Public Key Algorithm
> > Names are Standard Track documents. On the other hand, they seem to
> > reference and use the RFC2119 terms.
> >
> > I believe that the Standard Track category is the most appropriated,
> > however, I am happy to be wrong and have misunderstood something. Feel
> > free to let me know your opinion on the category, as well as if there
> > are
> any
> > clarification we should add in the text. I suggest that we add a
> > sentence around the lines:
> > """ These signature algorithms are expected to be integrated into the
> > standard implementations of SSH. """
> >
> > Any feed back is welcome!
> >
> > Yours,
> > Daniel
> > -----Original Message-----
> > From: Sheng Jiang <[email-masked]>
> > Sent: Wednesday, January 02, 2019 5:02 AM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked];
> > [email-masked]
> > Subject: Opsdir last call review of
> > draft-ietf-curdle-ssh-ed25519-ed448-07
> >
> > Reviewer: Sheng Jiang
> > Review result: Has Issues
> >
> > Reviewer: Sheng Jiang
> > Review result: Has Issues
> >
> > Hi, OPS-DIR, Authors,
> >
> > I have reviewed this document as part of the Operational directorate's
> > ongoing effort to review all IETF documents being processed by the IESG.
> > These comments were written with the intent of improving the
> > operational aspects of the IETF drafts. Comments that are not
> > addressed in last call
> may
> > be included in AD reviews during the IESG review. Document editors and
> > WG chairs should treat these comments just like any other last call
> comments.
> >
> > This standard track document describes the use of the Ed25519 and
> > Ed448 digital signature algorithm in the Secure Shell (SSH) protocol.
> > This
> document
> > is one of the shortest documents I have ever seen. It is clear and
> > well written.
> > However, I have a fundamental issue regarding to its Intended status
> > "Standards Track", describe below. Therefore, it has issues for
> publication
> > although I think it is easy to fixed - changing the Intended status.
> >
> > Major issue: this document has Intended status for Standards Track.
> > However, neither this document fails to quota RFC 2119 or has any
> > normative words.
> > Consistently, I don't think the description in this document has any
> > mandatory requirements for any implementations of protocols. Actually,
> > the most important quota of this document, RFC8032, is Informational,
> > which is a Downref in this document. Therefore, I think it is more
> > proper this document intends for Informational status.
> >
> > Minor issue: no.
> >
> > Regards,
> >
> > Sheng
> >
> >
> > _______________________________________________
> > Curdle mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/curdle
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>

---

From: Dave Cridland <[email-masked]>
Date: Wed, 5 Jun 2019 16:10:05 +0100

On Wed, 2 Jan 2019 at 10:01, Sheng Jiang <[email-masked]> wrote:

> However,
> neither this document fails to quota RFC 2119 or has any normative words.
>

On this, there is no necessity that Standards Track documents use RFC 2119.
Other Standards Track documents do not, for example RFC 4469.

Equally, statements which do not use RFC 2119 Magic Words are not
automatically informative, but might nevertheless be normative statements
which mandate particular behaviour in an implementation.

I am nervous about the suggestion in your email that this document does not
have any "normative words", therefore, since I cannot imagine how that
might be the case.

This is not to say that we should not use RFC 2119, of course - indeed, we
must use RFC 2119 Magic Words whenever something may be unclear. But it
should remain an optional part of our process, rather than required.

Dave.

---

From: Loganaden Velvindron <[email-masked]>
Date: Thu, 6 Jun 2019 10:13:28 +0400

I believe that this change already took place in rev08. What more do we
need to add ?

https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-curdle-ssh-ed25519-ed448-08.txt

On Wed, Jun 5, 2019 at 5:53 PM Daniel Migault <[email-masked]>
wrote:

> On Thu, Jan 3, 2019 at 11:23 AM Daniel Migault <
> [email-masked]> wrote:
>
>> Hi Sheng,
>>

---

From: Daniel Migault <[email-masked]>
Date: Thu, 6 Jun 2019 10:59:52 -0400

This is correct, I was looking at the wrong version 07. I believe this
issue is now closed.
Yours,
Daniel