AD review of draft-moonesamy-sshfp-ed25519-01

[Stephen Farrell <stephen.farrell%cs.tcd.ie@localhost>]

Hi SM, all,

I've agreed to AD sponsor this and so have done my AD review
and have one question before I start IETF LC. Apologies if
this was answered before;-)

I'm still concerned if the format of the thing that is
hashed is only defined in the SSH code. Is that the case?

If so, what happens when someone else implements and does
it differently and/or when we do have an ED25519 public
key format in an RFC that's not the same as in the current
code? Do we need another code point then?

I'd be just fine if you wanted to add the public key
format being used by SSH here and we add a new codepoint
later if one is needed because we standardise a different
format. Or, I'd be fine if you want to add a reference
to some other specification (not necessarily an RFC) or
even to a draft (though not sure there's a stable one
there today).

I note that RFC6594 contains examples of public key values
that are hashed as well and this does not.

I don't believe there's a shortage of codepoints here
so adding another later isn't a problem from that POV
but not sure what the implementers would want to do.

But this question will be asked so I'd like to know the
answer regardless of whether or not that means changes
to this draft.

The rest are nits that can be fixed now or later, but good
to get done before IESG eval.

1) ID nits has two things:

1.1)
  == Unused Reference: 'RFC6594' is defined on line 109, but no explicit
     reference was found in the

That's just in the acks, so I'm fine with it. But you could add
a ref.

1.2)
  == Unused Reference: 'FIPS180-4' is defined on line 113, but no
     explicit reference was found in the text

What's up there? How can a normative ref not be referred to?

2) The Reference for ed25519 isn't great. Isn't there anything better
than that web site to add as well? (Keep the URL though.)

Thanks,
S.