Re: [TLS] Updated TLS 1.2 I-D

"Anyang Ren" <anyang.ren@gmail.com> writes:

> On 6/25/06, Eric Rescorla <ekr@networkresonance.com> wrote:
>> I've submitted an update TLS 1.2 I-D an in the meantime
>> you can find it at:
>>
>> http://scm.sipfoundry.org/rep/ietf-drafts/ekr/tls/tls.txt
>
> In Section 1.1 Differences from TLS 1.1, you have:
>
>      - Replacement of MD5/SHA-1 combination in the PRF
>
>      - Replacement of MD5/SHA-1 combination in the digitally-signed
>      element.
>
> Are you going to replace the MD5/SHA-1 combination in the
> verify_data field of the Finished message?

It's already done. The PRF is used to create the verify_data.

> The "Hash" algorithm used in RSA signatures is the same hash
> algorithm used in the signature of the certificate.  Although this
> is a simple way to choose the "Hash" algorithm, the chosen hash
> algorithm really reflects the capability of the CA that issued the
> certificate as opposed to the capability of the certificate's subject
> (the server or the client). For example, the CA may sign a server
> certificate that contains an RSA public key using DSA, and "Hash"
> would be SHA-1 because the signature of the certificate is a DSA
> signature.

Yes. This is a hueristic, but it's the one we have. Since it seems
like a generally safe assumption that you can verify your own
cert, I don't think there's a problem here.

> The DSS signatures are hardcoded to use SHA-1. Are you planning
> to support extensions of DSA for the SHA-2 algorithms (as in Draft
> FIPS 186-3)?

Yes.

> Any interest in adding SHA-384 to the enumerated HashType defined
> in 7.4.1.4.7? The current definition of HashType seems to imply that
> CAs don't plan to sign certificates with SHA-384 in the signatures.

I don't personally hear much interest in that. How do other
WG members feel?

-Ekr

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls