Subject: RE: [TLS] Re: TLS 1.2 draft
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Wed, 7 Mar 2007 16:22:58 +0200
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.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.
> 
> Appendix H of RFC 3447 explains the change to recommend omitting
> the parameters for the SHA-x hash algorithms defined by NIST:
> 
>     The following corrections were made in converting the PKCS #1 v2.1
>     document to this RFC:
> 
>     *  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.
> 
>     [...]
> 
>     These corrections will be reflected in future editions of PKCS #1
>     v2.1.
> 
> 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 
  (see 9.2), the parameters field associated with id-sha1, id-sha256, 
  id-sha384 and id-sha512 SHALL have a value of type NULL. This is to 
  maintain compatibility with existing implementations and with the 
  numeric information values already published for EMSA-PKCS1-V1.5 
  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 
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls