Loose binding of indicated signature scheme to handshake signature scheme about tls-subcerts HOT 7 CLOSED

A algorithm identifier can correspond to multiple schemes, for example pss and pkcs.

I think you are concerned if a pkcs signature is interpreted as a pss signature. We include the signature scheme into the signed data for DCs, however we talked to karthik and folks and it seemed like a x-signature attack was unlikely. In the presence of such an attack I’m not sure binding it would protect it in any case depending on the attack, because the binding only has any guarantees anything if the signature validation logic can only be validated in 1 way. If there are multiple validations possible, all bets are off

from tls-subcerts.

... because the binding only has any guarantees anything if the signature validation logic can only be validated in 1 way.

Could you explain this a bit more?

In any case, I agree that a practical attack is unlikely. But let me ask you this: What's the argument for having SubjectPublicKeyInfo at all? Why not just have the public key, and add the handshake signature scheme identifier to the delegation signature? Then the DC would only have the information that's necessary for its use in TLS. To me it seems worthwhile to do away with this dependency on X.509.

I guess it's useful if you want to parse the DC before you know the signature scheme. Even if we leave the SubjectPublicKeyInfo as is, my hunch is that adding the signature scheme to the scope of the delegation signature is still a good idea, because it provides a definitive binding to the validation code path on the client side. (That is, the message being verified only matches the message that was signed if the client has taken the correct code path.) At least, this seems better from a provable security point of view.

from tls-subcerts.

The argument for SubjectPublicKeyInfo was that it's what is normally used in other purposes like certificate pinning and is very easy to extract using existing APIs. It could be possible to remove the dependency on X.509, however the draft currently already has other strong dependencies on X.509 including mandating the presence of an extension for DCs.

We do add the signature scheme to dcs in the signature, checkout
https://tools.ietf.org/html/draft-ietf-tls-subcerts-00#section-4

   6.  Big endian serialized 2 byte SignatureScheme scheme.

Is this what you mean or something more?

By my point of validation logic here's my argument, and it's sad I can't use any latex here:

A signature scheme is 2 functions:

Sign(k, m) -> s
Verify(k, m, s) -> true / false

If there exists another function
Verify2(k, m, s) -> true
when
Verify(k, m, s) - > false

where I trick you into running Verify2 vs Verify, augmenting m = (m || Verify) might have some significance to the protocol security, or might not. It really depends on the characteristics of Verify and Verify2.

In any case we do embed the signature scheme into the message.

from tls-subcerts.

It could be possible to remove the dependency on X.509, however the draft currently already has other strong dependencies on X.509 including mandating the presence of an extension for DCs.

Good point. Works for me.

Is this what you mean or something more?

The SignatureScheme scheme refers to the algorithm used to produce the signature, i.e., the scheme is the algorithm of the delegation certificate. What I would like to see is a binding to the algorithm of the credential itself, i.e., the value that the server will send in the signature_algorithms extension.

from tls-subcerts.

I tend to agree with @cjpatton on this issue for two reasons:

• AlgorithmIdentifier is a less specific binding than SignatureScheme
• Yes, there are X.509 dependencies in the draft, but they are in the certificate chain, which is often offloaded to a pkix library. Removing AlgorithmIdentifier from DC parsing makes it simpler.

from tls-subcerts.

After chatting with @grittygrease offline, I agree with @cjpatton as well. We should add the SignatureScheme to the binding

from tls-subcerts.

i think this is good to close out

from tls-subcerts.