Dear co-authors of curdle-ssh-ed25519-ed448,
Could we update the document and address the concern from Sheng ?
Yours,
Daniel
Daniel
On Thu, Jan 3, 2019 at 11:23 AM Daniel Migault <daniel.migault@xxxxxxxxxxxx> wrote:
Hi Sheng,
Thanks for the comment. It should be easily addressed in the next version.
Yours,
Daniel
-----Original Message-----
From: Sheng Jiang <jiangsheng@xxxxxxxxxx>
Sent: Thursday, January 03, 2019 8:59 AM
To: Daniel Migault <daniel.migault@xxxxxxxxxxxx>; Tim Hollebeek <tim.hollebeek@xxxxxxxxxxxx>; ops-dir@xxxxxxxx
Cc: draft-ietf-curdle-ssh-ed25519-ed448.all@xxxxxxxx; curdle@xxxxxxxx; ietf@xxxxxxxx
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:daniel.migault@xxxxxxxxxxxx]
Sent: Thursday, January 3, 2019 2:57 AM
To: Tim Hollebeek <tim.hollebeek@xxxxxxxxxxxx>; Sheng Jiang <jiangsheng@xxxxxxxxxx>; ops-dir@xxxxxxxx
Cc: draft-ietf-curdle-ssh-ed25519-ed448.all@xxxxxxxx; curdle@xxxxxxxx; ietf@xxxxxxxx
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 <tim.hollebeek@xxxxxxxxxxxx>
Sent: Wednesday, January 02, 2019 1:12 PM
To: Daniel Migault <daniel.migault@xxxxxxxxxxxx>; Sheng Jiang <jiangsheng@xxxxxxxxxx>; ops-dir@xxxxxxxx
Cc: draft-ietf-curdle-ssh-ed25519-ed448.all@xxxxxxxx; curdle@xxxxxxxx; ietf@xxxxxxxx
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 <curdle-bounces@xxxxxxxx> On Behalf Of Daniel Migault
> Sent: Wednesday, January 2, 2019 10:43 AM
> To: Sheng Jiang <jiangsheng@xxxxxxxxxx>; ops-dir@xxxxxxxx
> Cc: draft-ietf-curdle-ssh-ed25519-ed448.all@xxxxxxxx; curdle@xxxxxxxx;
> ietf@xxxxxxxx
> 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 <jiangsheng@xxxxxxxxxx>
> Sent: Wednesday, January 02, 2019 5:02 AM
> To: ops-dir@xxxxxxxxx
> Cc: draft-ietf-curdle-ssh-ed25519-ed448.all@xxxxxxxx; curdle@xxxxxxxx;
> ietf@xxxxxxxx
> 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
> Curdle@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/curdle
_______________________________________________
Curdle mailing list
Curdle@xxxxxxxx
https://www.ietf.org/mailman/listinfo/curdle
