Comments (7)
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.
Related Issues (20)
- Addresss Directorate Reviews HOT 2
- Address Paul's AD review HOT 1
- Considerations about other CertificateTypes?
- Will the next version of draft define how to store delegated credential as file? HOT 1
- A propose of signature context string HOT 5
- Should sever abort connection when server dc SignatureScheme mismatch SignatureSchemeList in client dc extension? HOT 1
- [WGLC] Private vs secret key HOT 1
- [WGLC] Clarify compromise text HOT 1
- [WGLC] Clarify extension vs EKU usage HOT 1
- [WGLC] Address client clock skew HOT 1
- [WGLC] Note problems with DCs having lifetimes matching issuing certificates HOT 4
- [WGLC] Nits HOT 1
- There is something wrong with the formatting of the numbered list in Section 4.1.3.
- Address WGLC #2 comments HOT 1
- mglt: Refactor s1
- mglt: more text for downgrade
- mglt: additional text about different sigs for server cert and DC
- mglt: s7.6 mentions TLS1.2?
- Add DTLS
- Expiry behavior ambiguity HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
š Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ššš
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ā¤ļø Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tls-subcerts.