Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [TLS] Re: TLS 1.2 draft
Date: Wed, 7 Mar 2007 16:22:58 +0200
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F2403DB5D7A@esebe105.NOE.Nokia.com>
In-Reply-To: <45ED8D09.2060600@redhat.com>
Thread-Topic: [TLS] Re: TLS 1.2 draft
Thread-Index: AcdgBvEq28nc0BLpQoGonDwmRMsCkgAue3Gg
References: <20070305054158.3A09C1CC24@delta.rtfm.com><87zm6qydae.fsf@latte.josefsson.org>
 <45ED8D09.2060600@redhat.com>
From: <Pasi.Eronen@nokia.com>
To: <wtchang@redhat.com>, <tls@ietf.org>
Cc: 
Precedence: list
Errors-To: tls-bounces@lists.ietf.org

Wan-Teh Chang wrote:

> I was surprised to learn about this change when I read your message.
> So I did some research.  Here is what I found.
>=20
> Appendix H of RFC 3447 explains the change to recommend omitting
> the parameters for the SHA-x hash algorithms defined by NIST:
>=20
>     The following corrections were made in converting the PKCS #1 v2.1
>     document to this RFC:
>=20
>     *  The requirement that the parameters in an AlgorithmIdentifier
>        value for id-sha1, id-sha256, id-sha384, and id-sha512 be
>        NULL was changed to a recommendation that the parameters be
>        omitted (while still allowing the parameters to be
>        NULL). This is to align with the definitions originally
>        promulgated by NIST. Implementations MUST accept
>        AlgorithmIdentifier values both without parameters and with
>        NULL parameters.
>=20
>     [...]
>=20
>     These corrections will be reflected in future editions of PKCS #1
>     v2.1.
>=20
> This change has been made to PKCS #1 v2.1 in the errata.
> (ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1errata.txt)

No, this is not exactly what pkcs-1v2-1errata.txt says; there
is additional text in the errata:

  Exception: When formatting the DigestInfoValue in EMSA-PKCS1-V1.5=20
  (see 9.2), the parameters field associated with id-sha1, id-sha256,=20
  id-sha384 and id-sha512 SHALL have a value of type NULL. This is to=20
  maintain compatibility with existing implementations and with the=20
  numeric information values already published for EMSA-PKCS1-V1.5=20
  which are also reflected in IEEE 1363a-2004[27].

In other words: AlgorithmIdentifier is used in several different
places, and the text "MUST accept both, SHOULD omit" applies to=20
all of those *except* one place (EMSA-PKCS1-V1.5). But that place
happens to be the one we care about for TLS 1.2 (ServerKeyExchange
and CertificateVerify messages)!

I think we should follow pkcs-1v2-1errata.txt and IEEE 1363a-2004
(which both agree) here, unless there are compelling arguments
against it...

Best regards,
Pasi

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls