Re: draft-harris-ssh-rsa-kex-01.txt

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

>> Now, RFC3447 *does* specify that conversion.  But the encoding of
>> this data blob as a string is deceptively close to the encoding of
>> the big number as an mpint (the major difference is exactly how and
>> when leading zero bits are included).  I'd like to see this
>> similarly explicitly acknowledged and clarified.

> Why is it encoded as a string in the first place when the value is
> quite clearly an integer?

I don't know, of course, since I didn't design it - but I suspect it
was done in order to directly use the existing RSAES-OAEP mode from
RFC3447 (or perhaps I should be saying PKCS #1, but 3447 is the
reference I used), as the existing definition is octet-string ->
octet-string encryption.

> For the equivalent DH keyex, the corresponding quantities e and f are
> encoded as mpints and not strings.  Making a subtle change to the
> encoding for this alternative keyex method seems to be asking for
> implementor confusion.

Yes.  But I can understand a desire to use an existing spec directly,
rather than making slight changes to it.  Encoding that as an mpint
instead of a string would require draft-harris-ssh-rsa-kex to go under
the hood of RFC3447 (or else specify converting it back from an octet
string to a big number, which is almost uglier).  If you have existing
RSAES-OAEP library code, you can use it directly with the current spec.

That's why I suggested emphasizing that it's a string rather than an
mpint, as opposed to suggesting switching from opaque-blob-as-string to
big-number-as-mpint.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B