Re: [Curdle] Confirming a change to draft-ietf-curdle-rsa-sha2-12

[denis bider <[e-mail]>]

Mark:

> If the octet string S begins with the most significant bit set,
> is it a MUST or a SHOULD or a MAY to prepend a zero octet
> so that the number is not considered to be negative?

In historic and current practice, for "ssh-rsa", as per RFC 4253, the
signature encoding is specified as follows:


      string    "ssh-rsa"
      string    rsa_signature_blob

   The value for 'rsa_signature_blob' is encoded as a string containing
   s (which is an integer, without lengths or padding, unsigned, and in
   network byte order).



In my opinion, this is underspecified, and has led to discrepancies in
actual implementations.

The treatment of leading zeros is not clarified here. This RFC could have
specified to encode S, i.e. a concrete, well-specified RSA signature
encoding described in RFC 8017. Perhaps it meant to specify S but someone
went with "s" instead. We can't tell at this point.

"s" is the abstract equivalent to "S", i.e. it's the RSA signature with no
specified encoding. So the encoding is defined entirely in the above
language, and we know the following:

- It is an integer encoded as a string.
- It's not encoded as a mpint.
- No lengths or padding.
*- Unsigned, therefore no zero prefix if high bit is on.* (I believe this
answers the above question.)
- Network byte order.

This is ALMOST identical to "S". Except it does not clearly specify what to
do if the signature has a naturally occurring leading 0 which occurs in
1/256 of all signatures.

Therefore, implementations diverge in whether the leading 0 is sent or not.
Some implementations send it. Some do not.


My intent with "rsa-sha2-256" and "rsa-sha2-512" is not to change how the
rsa_signature_blob is encoded, it's to document it better.

I don't think it's realistic to change it. The new public key algorithms
are already implemented and widely deployed, and the practical
implementations already diverge in the choice they make about the leading
0, in the same way as "ssh-rsa" implementations diverged.

The fact that implementations diverge on this detail is not a big deal, but
there's good reason to document it. Otherwise people are prone to implement
and release software that's going to fail to validate 1/256 of signatures
sent by other SSH implementations.


> mpint     rsa_signature_blob

No no no no no no no! Wrong! Error! Please do not even mention this. :)

I marked it in red to emphasize that this is very wrong.

This is already implemented. It's already deployed. It's too late to
change. It's clear this is not an mpint, and has never been in "ssh-rsa"
either. Changing this to "mpint" now would completely divorce the spec from
actual implementations.

My intent with this late improvement to the text is to clarify actual
practice for the benefit of future implementations. Changing existing
implementations is a no-go.



On Sun, Mar 11, 2018 at 7:56 PM, Mark D. Baushke <[e-mail]> wrote:

> Salz, Rich <[e-mail]> writes:
>
> > Eric rightly pounts out that this is a tech change made during the
> > final stage of RFC editing and that it should be confirmed by the WG.
> > It's about MAY accepting fewer leading zero's.
> >
> > Does anyone object?
> >
> >     > > The value for 'rsa_signature_blob' is encoded as a string that
> >     > > contains an octet string S (which is the output of
> RSASSA-PKCS1-v1_5)
> >     > > and that has the same length (in octets) as the RSA modulus.
> When S
> >     > > contains leading zeros, there exist signers that will send a
> shorter
> >     > > encoding of S that omits them.  A verifier MAY accept shorter
> >     > > encodings of S with one or more leading zeros omitted.
>
> Question:
>
> If the octet string S begins with the most significant bit set, is it a
> MUST or a SHOULD or a MAY to prepend a zero octet so that the number is
> not considered to be negative?
>
> Consideration:
>
> RFC 8017 section 4.1 specifies x as a nonnegative integer to be
> converted to an Octet String primitive. It is not clear if the octet
> string S is to always be considered unsigned or not.
>
> RFC4251 provides that an mpint is a multiple precision integer in two's
> complement format, stored as a string, 8 bits per byte, MSB first.
> Negative numbers have the value 1 as the most significant bit of the
> first byte of the data partition. If the most significant bit would be
> set for a positive number, the number MUST be preceded by a zero byte
> [RFC4251, sectio 5, page 8.]. RFC4251 provides that a 'string'
>
> If draft-ietf-curdle-rsa-sha2-12 would like to see the
> rsa_signature_blob be treated as an mpint with a leading zero-byte for
> strings that otherwise would look negative, why not just change the type
> in section 3 to read:
>
> The resulting signature is encoded as follows:
>
>     string    "rsa-sha2-256" / "rsa-sha2-512"
>     mpint      rsa_signature_blob
>
>   The value for 'rsa_signature_blob' is encoded as a string containing
>   S   - an octet string which is the output of RSASSA-PKCS1-v1_5, of
>   length equal to the length in octets of the RSA modulus. As with any
>   mpint, there may be a leading zero octet to ensure that S is considered
>   a nonnegative number.
>
> If I have misunderstood the rationale for the change, please let me
> know.
>
>         Thank you,
>         -- Mark
>
> _______________________________________________
> Curdle mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/curdle
>