Or is it that redacted certs simply won’t be CT compliant and that there’s no need to look for redaction specifically?
-
Show this thread
-
Replying to @ivanristic
More than that - Redaction is active misissuance, and will be treated like any other active and knowing BR violation. They won’t be accepted by clients, BUT ALSO the CA has now misissued
1 reply 0 retweets 2 likes -
Replying to @sleevi_
Thanks for the clarification. Let me rephrase the question: is there any code in Chrome that rejects redacted certificates specifically (in absence of any other problems)?
2 replies 0 retweets 1 like -
Replying to @ivanristic @sleevi_
There is no redaction in CT. Symantec just made stuff up by mis-issuing a pre-cert for ?.example.com and embedding its SCT in a cert for http://sub.example.com . That doesn't work, just as an SCT for http://yahoo.com obviously doesn't work for http://google.com .
1 reply 0 retweets 3 likes -
And yet here’s one redacted precertificate in a CT log :) https://crt.sh/?q=997aeb30aeb419a0892de5b6831de56291ca110411bf13fd3dae713a2b54e78c …
2 replies 0 retweets 2 likes -
Replying to @ivanristic @__agwa
... I’m not sure what you’re highlighting? That’s entirely consistent with what we said. It was a misissued certificate.
2 replies 0 retweets 1 like -
I was replying to
@__agwa saying that there is no redaction in CT. There is, it’s just that there shouldn’t be.2 replies 0 retweets 1 like -
Replying to @ivanristic @sleevi_
But there isn't. There is no published spec that says how that pre-certificate for ?.badssl.com could match a final certificate for anything other than ?.badssl.com.
1 reply 0 retweets 1 like -
Well, in my experience with PKI, it’s not a requirement for something to be specified to work in practice. And the opposite happens to, specified things often don’t work.
1 reply 1 retweet 1 like -
Replying to @ivanristic @sleevi_
TLS clients need explicit support for redaction because of how SCT signatures work. Without explicit support, the SCT will have an invalid signature. No different than if you tried to use a http://yahoo.com SCT with a http://google.com cert.
2 replies 0 retweets 2 likes
Kind of like how clients need explicit support for wildcard identifiers. If a client doesn't know about wildcards, a cert for *.example.com isn't going to work except for literally *.example.com.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.