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

denis bider <> Mon, 12 March 2018 02:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB1A9126CBF for <>; Sun, 11 Mar 2018 19:21:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2S_AZy2mAL36 for <>; Sun, 11 Mar 2018 19:21:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DBABF12008A for <>; Sun, 11 Mar 2018 19:21:37 -0700 (PDT)
Received: by with SMTP id y137so9864369qka.4 for <>; Sun, 11 Mar 2018 19:21:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M5V58aKsft+UkIirOIbIQFIpW9h36uVSIYAVRpcGRuE=; b=pWQ1GRVwg+AsTTkVhODSlK6x/7jSH9AZ5TstMgsxi5C9Pi2X9xw36Ybxml3xgvY1c8 Za/roj7gTyKJ16qf9qwVJLMgLwDnw+kBRPKqNj4wUQmCsNRtLvDjOKkkYNErlAy5ltht wNaaa/QIWdqnuL2UFNmkjhVwsmOgPUZuXLyy2z4Z6T+YARdrYFfbTkpchI2ik3LOqVJE uh2kQ6pg9hzijM4stJ3Tl3M0LocahXIDoGlSS8rQyMmHJgcoHUESMNhb+kTzOn3/Q8uo GDH3w38+wdt8l0kSOuu7nBU5mVHbjNk5iitO1B56ctISUT0ewAULDBBCIzEr7rXsLSjY 1TQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M5V58aKsft+UkIirOIbIQFIpW9h36uVSIYAVRpcGRuE=; b=e0k/kjlUVp1wYytXs8IBjja6PCT45oO6FRnUwLt4p6CQ+jF+TZbLhd9LYM0bP25dvO VTXxPZCCkQToOZaVhIfL645UHJ0o4ktarIL0Wq8Ar7RKEcBYx2SbQzE5kR41MdoOfJrA Ye68IN6ue+MXMNumyRjGl0WuQVmvEQpEeblwwB6cboo4I1CX3kYx5sTqMUv1Qn1/wxHa thcEuyi9PlbVphHGhhtMNoQfh/BlMpmoIVO6dcwczKC44e8TaeQd/E0i7kVmQZpujNeQ kpv/pIL1Yy04PqyaQKDLgEh+mta1BJS1wg/Ttx9IprrL4K7O9Xby88COveieu1wOJn1p 9fyA==
X-Gm-Message-State: AElRT7HWJXeNorPMRTMekykx+O7E+LQ4S8sZEGi7iuWZRb1nKPOa1zpU vsWxF+NvJ2PaLacbOa+/sbviO+4pS8mGlcz+N/E=
X-Google-Smtp-Source: AG47ELuY4LLoc2687G+kbsOZLE6ZKagbjYCHTRZJRK/AjBfPBkxKO5qyvTW1W6lW4hox19zb6UbtONK/iUCBSpOWQxs=
X-Received: by with SMTP id c203mr9562415qkb.351.1520821296842; Sun, 11 Mar 2018 19:21:36 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 11 Mar 2018 19:21:36 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: denis bider <>
Date: Sun, 11 Mar 2018 21:21:36 -0500
Message-ID: <>
To: "Mark D. Baushke" <>
Cc: "Salz, Rich" <>, "" <>
Content-Type: multipart/alternative; boundary="001a114a9bb22a4d1605672dcd97"
Archived-At: <>
Subject: Re: [Curdle] Confirming a change to draft-ietf-curdle-rsa-sha2-12
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "List for discussion of potential new security area wg." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Mar 2018 02:21:41 -0000


> 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 <> wrote:

> Salz, Rich <> 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