Using the CA model you should [trust the signature]. If the signature was created before the revocation (proven by a timestamp), then you could accept it. If there's no timestamp, then you shouldn't, but the decision is really up to you.
<veering even further off-topic>
i thought one of the main uses of key revocation is to announce a key compromise.
If the CA's private key was compromised, then what's to stop the attacker from forging signatures with timestamps prior to the revocation date? Is there some ultra-reliable third-party time-granting scheme? Does a parent CA (presumably with a non-compromised key) need to sign off on the cert as well to validate the timestamp? If that were the case, why bother with the intermediate CA at all? And what if there are no parent CAs (such as when the root CA is the one doing the signing in the first place)?
It seems like the same flaw as in the WoT model to me, but i'm probably missing something.
It suffers from one serious drawback though: it has no revocation information. If your key pair is stolen, you are pretty much doomed. There is no infomation on whether your key is still yours, and if not, from what point of time?
You can generate revocation certificates in the web-of-trust model just like you can with X.509, can't you? There's still the issue of how you expect to distribute the revocation cert should you need to, but those can be distributed through any channel (even non-secure ones) since they should be effectively un-forgeable. Is there something more to a CRL that i'm missing?
As far as figuring out whether a signature is valid given a known-revoked cert, the web of trust does require that signatures be timestamped. But a malicious agent with a copy of a compromised key and root privileges somewhere (to reset the clock) could create bogus signatures with bogus timestamps that would look valid.
Doesn't X.509 have the same flaw? It seems that you shouldn't trust any signatures from a given key (no matter what the signature timestamp) if the key is known to have been revoked, under any PKI trust model.
Average end users don't care about HOW things are done, they just want a reliable infrastructure. Th problem is that there's no such thing if you don't care about the details...
i see what you're saying, and it makes sense. It's currently too difficult (and not granular enough) to indicate your levels of trust in a given certificate authority. Mozilla (for example) will allow you to modify your list of root certificate authorities yourself through the "Privacy and Security|Certificates" pane of the Preferences dialog. But you can only add or remove CAs wholesale (indicating "trust to identify websites"), you can't score their trustworthiness.
To make any such scoring scheme work, you'd need some good way of calculating the "accumulated validity" of a visited site's identity, based on the trustworthiness scores of the signing CAs. And you'd need a good way to report that back to the user.
GPG's implementation of the web of trust is slightly more granular than Mozilla's (but not much!). For each key, you can indicate a level of trust in that user's ability to do adequate identity validation: none, marginal, or full. (you can also choose "unknown").
A key's stated identity is only considered fully valid if enough other keys have signed it (by default, "enough" is defined as 1 fully trusted key or 3 marginally trusted keys); But GPG only counts keys that are within 5 hops from the user (this parameter is also tunable to suit your paranoia). So this is a method of scoring "accumulated validity", since it can also report "marginal validity" (e.g. if only 2 marginally trusted keys have signed it).
So, a system like you describe exists! it's not as fine-grained as you proposed, but it's more fine-grained than the existing X.509 implementations in popular web browsers.
About your last point: why is the "one step removed from the CA" useful when the declared root CAs aren't necessarily trustworthy themselves? It's only a useful metric if you are sure that you really do trust the CAs, which i think most people only do implictly.
And many big sites aren't even "one step removed from the CA". Using mozilla's default CAs, https://www.microsoft.com/ is 3 steps removed (OK, that might be a bad example). But browsers make it fairly inconvenient to see how many levels of signing authority are used, and i've never seen anyone inspect the length of the cert chain before deciding a site was secure.
What you're describing begins to approximate the Web of Trust. But why approximate and not go all the way?
Why should each CA have the same trustworthiness value to every user? Joe could think that Verisign was the best thing since sliced bread, while Maria might want to give them a low score, and instead might want to trust CAcert.org more highly.
Furthermore, why relegate trust just to official "Certificate Authorities"? If i know that my brother will do a good job verifying identities of organizations that he deals with, why can't i choose to trust him for these tasks as well?
Once you start to distribute the responsibility for certification, you are building a web of trust, in which each entity can both certify and be certified, and the middlemen/brokers/leeches we use today as CAs would be forced to actually do identity validation or become irrelevant and useless.
Of course, this all depends on every user knowing what it means to "trust a certificate authority"...
And it depends on web site admins not just wanting the "least hassle" when it comes to getting their SSL identities signed.
An SSL certificate is just a (hopefully long) bit-string formatted in a certain way. I don't see how the fact that anyone can generate a long bit string to a well-known format contributes to the insecurity of SSL.
If a protocol can be weakened by someone generating a long bit-string, then that protocol isn't worth much in the first place.
Public knowledge of SSL (incarnated in the openSSL source) is not the problem. Rather, the problem is twofold:
Uncomprehending users
End users don't understand PKI, for the most part. They don't understand the implications and assumptions which underly the system. By default, the X.509 architecture means that they end up implicitly trusting the root Certificate Authorities installed by their browser provider (which means they are implicitly trusting their browser provider and we know who that usually is...)
Untrustworthy Hierarchy in X.509
The hierarchical nature of SSL's PKI means that even for those people who understand how it works, they are still strongly compelled to trust some large CAs. Sadly, many of the large CAs have abandoned their ideal role of actually establishing and verifying identity. They seem to now see themselves as yet another middleman who deserves a cut of any transaction without providing a service.
How many times have you seen a CA whose policy for establishing identity amounts to "Please send us a fax on company letterhead" ? Who can't send a fax on "company letterhead" these days?
I would be willing to pay a good CA for actual verification, even as a client, if i could be sure that they were actually verifying the folks they issued certificates to. But it would need to be big enough to be able to certify a large number of sites to be worthwhile...
The non-hierarchical nature of the web of trust model of PKI is so much better than X.509, so it would fix the untrustworthy hierarchy issue above. But, even more than X.509, it expects all the end users to understand the basic ideas of PKI, not just "look for the little lock and click those dialogs as soon as they come up". sigh...
Orange County election officials have traced the problem to poll workers who were responsible for giving each voter a four-digit code to enter into the voting machines.
Does this mean that, as long as a voter knows the code for some other district, sie could vote on that district's ballot without actually residing in the district?
This seems like a flaw in the technology itself. The old way, you'd have to assert your name and address to a human poll worker, who then gave you the specific ballot.
The method described in the article is equivalent to the poll worker giving you a stack of ballots, one for each district, and just accepting whichever one you decide to give back to hir.
Slashdot Mirror
you are looking for debian's fai package, the Fully Automated Installer.
i thought one of the main uses of key revocation is to announce a key compromise.
If the CA's private key was compromised, then what's to stop the attacker from forging signatures with timestamps prior to the revocation date? Is there some ultra-reliable third-party time-granting scheme? Does a parent CA (presumably with a non-compromised key) need to sign off on the cert as well to validate the timestamp? If that were the case, why bother with the intermediate CA at all? And what if there are no parent CAs (such as when the root CA is the one doing the signing in the first place)?
It seems like the same flaw as in the WoT model to me, but i'm probably missing something.
As far as figuring out whether a signature is valid given a known-revoked cert, the web of trust does require that signatures be timestamped. But a malicious agent with a copy of a compromised key and root privileges somewhere (to reset the clock) could create bogus signatures with bogus timestamps that would look valid.
Doesn't X.509 have the same flaw? It seems that you shouldn't trust any signatures from a given key (no matter what the signature timestamp) if the key is known to have been revoked, under any PKI trust model.
All too true, sadly.To make any such scoring scheme work, you'd need some good way of calculating the "accumulated validity" of a visited site's identity, based on the trustworthiness scores of the signing CAs. And you'd need a good way to report that back to the user.
GPG's implementation of the web of trust is slightly more granular than Mozilla's (but not much!). For each key, you can indicate a level of trust in that user's ability to do adequate identity validation: none, marginal, or full. (you can also choose "unknown").
A key's stated identity is only considered fully valid if enough other keys have signed it (by default, "enough" is defined as 1 fully trusted key or 3 marginally trusted keys); But GPG only counts keys that are within 5 hops from the user (this parameter is also tunable to suit your paranoia). So this is a method of scoring "accumulated validity", since it can also report "marginal validity" (e.g. if only 2 marginally trusted keys have signed it).
So, a system like you describe exists! it's not as fine-grained as you proposed, but it's more fine-grained than the existing X.509 implementations in popular web browsers.
About your last point: why is the "one step removed from the CA" useful when the declared root CAs aren't necessarily trustworthy themselves? It's only a useful metric if you are sure that you really do trust the CAs, which i think most people only do implictly.
And many big sites aren't even "one step removed from the CA". Using mozilla's default CAs, https://www.microsoft.com/ is 3 steps removed (OK, that might be a bad example). But browsers make it fairly inconvenient to see how many levels of signing authority are used, and i've never seen anyone inspect the length of the cert chain before deciding a site was secure.
Why should each CA have the same trustworthiness value to every user? Joe could think that Verisign was the best thing since sliced bread, while Maria might want to give them a low score, and instead might want to trust CAcert.org more highly.
Furthermore, why relegate trust just to official "Certificate Authorities"? If i know that my brother will do a good job verifying identities of organizations that he deals with, why can't i choose to trust him for these tasks as well?
Once you start to distribute the responsibility for certification, you are building a web of trust, in which each entity can both certify and be certified, and the middlemen/brokers/leeches we use today as CAs would be forced to actually do identity validation or become irrelevant and useless.
Of course, this all depends on every user knowing what it means to "trust a certificate authority"...
And it depends on web site admins not just wanting the "least hassle" when it comes to getting their SSL identities signed.
If a protocol can be weakened by someone generating a long bit-string, then that protocol isn't worth much in the first place.
Public knowledge of SSL (incarnated in the openSSL source) is not the problem. Rather, the problem is twofold:
Uncomprehending users End users don't understand PKI, for the most part. They don't understand the implications and assumptions which underly the system. By default, the X.509 architecture means that they end up implicitly trusting the root Certificate Authorities installed by their browser provider (which means they are implicitly trusting their browser provider and we know who that usually is...) Untrustworthy Hierarchy in X.509 The hierarchical nature of SSL's PKI means that even for those people who understand how it works, they are still strongly compelled to trust some large CAs. Sadly, many of the large CAs have abandoned their ideal role of actually establishing and verifying identity. They seem to now see themselves as yet another middleman who deserves a cut of any transaction without providing a service. How many times have you seen a CA whose policy for establishing identity amounts to "Please send us a fax on company letterhead" ? Who can't send a fax on "company letterhead" these days?I would be willing to pay a good CA for actual verification, even as a client, if i could be sure that they were actually verifying the folks they issued certificates to. But it would need to be big enough to be able to certify a large number of sites to be worthwhile...
The non-hierarchical nature of the web of trust model of PKI is so much better than X.509, so it would fix the untrustworthy hierarchy issue above. But, even more than X.509, it expects all the end users to understand the basic ideas of PKI, not just "look for the little lock and click those dialogs as soon as they come up". sigh...
This seems like a flaw in the technology itself. The old way, you'd have to assert your name and address to a human poll worker, who then gave you the specific ballot.
The method described in the article is equivalent to the poll worker giving you a stack of ballots, one for each district, and just accepting whichever one you decide to give back to hir.