I personally would not accept source code as the sole specification. IETF
tradition has always been providing both the "verbal" description in English
(or as close to it as practical) *plus* a reference implementation, preferably
more than one.
Mere existence of an implementation has never been an excuse to weasel out of
actually documenting the protocol.
My $0.02.
Quoting "Joseph Salowey (jsalowey)" <jsalowey@xxxxxxxxx>:
On May 30, 2014, at 4:43 AM, S Moonesamy <sm+ietf@xxxxxxxxxxxx> wrote:
Hi Joe,
Thanks for the review. I'll comment below.
At 21:35 26-05-2014, Joseph Salowey (jsalowey) wrote:
This document defines an SSHFP DNS record for ED25519 signature
algorithm. The document is ready with issues:
1) This document describes how to store the fingerprint of a
public key that can be used with the ed25519 signature algorithm.
I do not see any reference as to how to use the ed25519 signature
algorithm in SSH. Perhaps I am missing a reference somewhere, but
it really seems that the use of the signature algorithm in SSH
should be defined somewhere, preferably in an IETF document. I so
not see the point of publishing the SSHFP record document without
some reference as to how it will be used.
OpenSSH used the following reference to implement the ed25519
signature algorithm:
Bernstein, D. J., Lange T., Schwabe P., Yang B-Y., High-
Speed High-Security Signatures, Journal of Cryptographic
Engineering, Vol. 2, September 26, 2011
TeraTerm also implemented that (
http://sourceforge.jp/ticket/browse.php?group_id=1412&tid=33263 ).
In my opinion that passes the "running code" test. I'll highlight
that the intended status of the document is Informational. The
reason was to have documentation about the code point assignment and
to determine IETF Consensus for the assignment. The point in
publishing the document is to fulfill RFC 4255 requirements.
[Joe] Running code is certainly good, but I don't think the ed25519
paper by itself provides enough information to create an
interoperable implementation. Without this information I'm not sure
its possible to implement the draft. For example, as you mention
below the format for the key is undocumented is it well enough
understood what the format of the data to be hashed in the
fingerprint is from the draft and its references? It seems the only
documentation of the protocol is in the source code. I'm not sure if
there is a precedent for referencing a source code, but if it is
source controlled perhaps it is acceptable.
2) The examples in RFC 6594 include the OpenSSH formatted key that
is decoded and hashed to obtain the resulting fingerprint. It
would be better if the draft followed this aspect of 6594 and
included the key used to generate the fingerprint.
Stephen Farrell raised that question during the AD Review (the
message was on the ietf-ssh@xxxxxxxxxx mailing list). I mentioned
that the public key fingerprint used for ED25519 in the SSHFP
Resource Record relies on an undocumented OpenSSH public key format
and I did not follow the examples in RFC 6594 because of that.
Regards,
S. Moonesamy
_______________________________________________
secdir mailing list
secdir@xxxxxxxx
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview