> enforcing the default. The default being:
> - Hash algorithm the same as specified in Signature Algorithm
> - MGF1 hash is the same as above
> - Salt length same as digest length above
No problem with that being recommendation, but I've seen people claiming
that
some applications don't follow that salt length requirement, so I'd say it
would cause unnecessary problems if it was set too strict
I’m sure some apps follow, and some don’t. I’m simply saying that it makes
sense for TLS to pick a sensible default (like the above) and stick with it.
Other apps may do what they think is best.
As for above, in view of the following discussion I think it would be better to
replace “Signature Algorithm” above with
“subjectPublicKeyInfo.algorithm.parameters.hashAlgorithm”.
I still think that only the necessary minimum of parameters should be passed
explicitly.
I'm talking about subjectPublicKeyInfo field, *not* about
signatureAlgorithm
field from RFC 3280
OK, point taken. Thanks for clarifying.
and there are clients that advertise only a subset of hashes:
https://www.ssllabs.com/ssltest/viewClient.html?
name=Safari&version=6&platform=iOS%206.0.1&key=33
Seriously? iOS 6? Why not iOS 5 or 4? I think I still have an iOS 5 device
somewhere. ;-)
> The cryptographic module would perform RSA-PSS *signature* with whatever
> hashes it can. It won’t bother with *validation*, so this module’s
> limitations shouldn’t matter.
but it can't perform that signature using hash
*that the client didn't advertise*
You’re probably right. But for my benefit, could you please outline the
scenario how this would/could be used? To make sure I completely understand the
use case?
Now, because the subjectPublicKeyInfo is chosen by the person generating
the
key (user) and signatureAlgorithm is chosen by the CA, and it is quite
common
already that e.g. a P-384 CA signs with SHA384 a P-256 intermediate CA that
then signs EE with a SHA-256. I really don't think that *all* hashes should
be
the same.
OK, you convinced me here. I missed that. :-(
> Oh no – I’m eccentric but not quite insane yet. ;-)
well, we do work on ASN.1 stuff... ;)
And I start developing liking of ASN.1. Does it mean it’s time to get my head
examined? ;-)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
