Re: A crazy thought?
re: http://www.garlic.com/~lynn/aadsm27.htm#22 A crazy thought? for some other topic drift regarding certification authorities ... having been certification authorities for digital certificates targeted at the (electronic but) offline market ... they encountered a number of issues in the mid-90s as the world was transitioning to ubiquitous online operation ... the digital certificates were somewhat targeted for relying parties ... dealing with total strangers (that they had no prior information about) and had no timely mechanisms for directly contacting any authorities for references regarding the stranger. so one of the issues for x.509 identity certificates ... small x-over from this other thread http://www.garlic.com/~lynn/aadsm27.htm#25 Why self describing data formats was to try and move out of the no-value market into the identity market ... aka ... as world transitioned to ubiquitous online operation ... the remaining offline was no-value situations where the relying-party couldn't justify the cost of maintaining information about the parties that they dealt with (aka something analogous to browser cookies) and/or couldn't justify the cost of directly contacting responsible agencies for information about the parties they were deailing with. now in this recent thread ... somewhat about some internet historical evolution http://www.garlic.com/~lynn/2007l.html#67 nouns and adjectives http://www.garlic.com/~lynn/2007l.html#68 nouns and adjectives http://www.garlic.com/~lynn/2007l.html#69 nouns and adjectives http://www.garlic.com/~lynn/2007l.html#70 nouns and adjectives the last posts drifts into the subject of some of the recent churn around identity activities ... also lengthy post on the subject here: http://www.garlic.com/~lynn/aadsm27.htm#23 Identity resurges as a debate topic the certification authorities were somewhat looking at increasing the value of x.509 identity digital certificates (since there wasn't a lot of future selling into the no-value market segment) by starting to grossly overload the digital certificates with enormous amounts of personal information. now typically identity has been a authentication characteristic ... adding potentially enormous amounts of personal information could be considered attempting to move into the authorization area ... where a relying-party might be able to make a authorization, approval, and/or permission decision purely based on the additional personal information in the digital certificate. what was seen by the mid-90s was that many of the institutions were starting to realize that x.509 identity digital certificates, grossly overloaded with personal information represented significant privacy and liability issues. what you saw then was a retrenchment to purely authentication, relying-party-only digital certificate http://www.garlic.com/~lynn/subpubkey.html#rpo with the digital certificate containing little more than a record locator (where all the necessary information was actually kept, even real-time, and aggregated information ... which is difficult to achieve in a stale, static digital certificate paradigm) and a public key ... note, however, we could trivially show that in such situations the stale, static digital certificate was redundant and superfluous ... aka just add the public key to the entity's record ... which already had all the personal, private and other information necessary for authorization. in the payments market segment ... this is somewhat separate from the fact that the appended stale, static, redundant, and superfluous digital certificates were causing a factor of 100 times payload and processing bloat http://www.garlic.com/~lynn/subpubkey.html#bloat one of the other problems faced by certification authorities attempting to move identity digital certificates into the authorization market segment was what (with loads of personal information), if any, liability were certification authorities going to accept with regard to authorization problems encountered by the relying-parties (depending on the digital certificate personal information in their decision making process). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A crazy thought?
Ian G wrote: What you are suggesting is called Web of Trust (WoT). That's what the PGP world does, more or less, and I gather that the SPKI concept includes it, too. However, x.509 does not support it. There is no easy way to add multiple signatures to an x.509 certificate without running into support problems (that is, of course you can hack it in, but browsers won't understand it, and developers won't support you). re: http://www.garlic.com/~lynn/aadsm27.htm#22 A crazy thought? http://www.garlic.com/~lynn/aadsm27.htm#26 A crazy thought? http://www.garlic.com/~lynn/aadsm27.htm#27 A crazy thought? actually ... at a very fundamental level both PKI and PGP have nearly identical business and implementation processes ... the difference is somewhat that the PKI operations tend to try and make out that their structure is more formal ... and therefor should be more trusted. Both implementations require that the relying-parties have some sort of local trusted public key repository ... initially populated with some out-of-bad process. In the SSL PKI scenario ... there tends to be a trusted public key repository built into each browser distributed ... initially loaded with possibly 40-50 public keys that you are told that you can trust. In the web of trust scenario ... there tend to be some set of public keys that are also trusted and have also been acquired in some out-of-band process. In both scenarios ... the relying-party is expected to trust new public keys that carry digital signatures ... where these digital signatures can be verified with public keys from their local repository of (already) trusted public keys (public keys that have typically been distributed/initialized by some out-of-band process) It isn't so much that the fundamental processes are different ... it is more about how tightly controlled and cast in concrete the surrounding pieces happen to be (aka formalized and not easily changed/adapted). For totally other drift ... one of the places we came up with requirement for multiple digital signatures was in the process for x9.59 financial infrastructure for payment transactions ... i.e. in the mid-90s, the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments http://www.garlic.com/~lynn/x959.html#x959 x9.59 actually doesn't specify the details of digital signature process ... but defines the fields necessary for a payment transactions which require authentication and integrity protection on end-to-end basis. one of the scenarios is the authentication of the account holder with digital signature (which also provides payment transaction integrity). one of the trust issues was that their could be various kinds of exploits at the originating environment (where the account holder's digital signature and the transaction was otherwise valid). to increase the trust (as indication of possible countermeasures against these additional exploits/vulnerabilities) allowed for the originating environment to also digitally sign the transaction (as a flavor of device authentication, possibly a point-of-sale terminal or other kind of device that was used to originate the transaction). the FSTC electronic check work also allowed for multiple digital signatures ... representing the equivalent of requiring multiple co-signers on business checks ... i.e. business checks that allow for single signer if the amount is below some limit ... but requires additional co-signers for larger amounts. note that both in the FSTC electronic check and the X9.59 financial standard scenario, there was some assumption that the basic transaction went via normal existing electronic payment networks ... with appended digital signature(s) ... where the transaction might actually only be encoded during just the digital signature generation and digital signature verification processes. recent posts in the encoding thread: http://www.garlic.com/~lynn/aadsm27.htm#24 Why self describing data formats: http://www.garlic.com/~lynn/aadsm27.htm#25 Why self describing data formats: also any additional appending of traditional digital certificates to such operations could represent a factor of 100 times payload and processing bloat. http://www.garlic.com/~lynn/subpubkey.html#bloat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A crazy thought?
Allen wrote: Hi Gang, In a class I was in today a statement was made that there is no way that anyone could present someone else's digital signature as their own because no one has has their private key to sign it with. This was in the context of a CA certificate which had it inside. I tried to suggest that there might be scenarios that could accomplish this but was told impossible. Not being totally clear on all the methods that bind the digital signature to an identity I let it be; however, the impossible mantra got me to thinking about it and wondering what vectors might make this possible. Awareness of the failure models of various PKI solutions is an important part of using and designing uses for them. There are many, many failure models for the current x509/Certification Authority model used by ssl. (everyone already familiar with the failure modes should probably hit next message now, unless they want to double check I am not giving out bad advice; this email is going to get rather long :) Consider the following steps. I will predefine three actors here - [SITE] which for email is the *recipient*, for web traffic is the server owner. [USER] which is the mail sender and/or site user - originator of protected data. [CA] which is the certificate authority 1. [CA] generates and stores securely a private key This is a once-in-a-decade event, but even so, there are failure modes. One possible mode is to use political pressure (or just bad coding) to force one of the two primes used in RSA to be either fixed or from a very small subset of possible primes (aka canned primes). As you can imagine, finding the private key becomes near trivial if you know one of the two primes in advance... We can move onto the security of the key later. 2. [CA] generates and stores a public certificate using the private key This at least is without any real issues (except security of the private key of course). In practice, this would be the same operation as (1) but need not be. 3. [CA] transmits the public key verifiably to the end recipients This is actually more complex than it sounds - I would guess 99% of the keys everyone has on their machine (if not 100%) were supplied to them with the browser, or in the case of IE, preinstalled on the machine. The vast majority of users have no idea how to even display those keys, never mind check them. To verify, ask yourself this question. For each web browser or email package installed to your machine, a) Where are root keys stored? b) How do I view them? c) Where is the public key or hash I should check? d) where do I obtain a known-good copy of that so I can verify it? The answers to some of those might surprise you (for instance, IE stores its root certs unprotected in the registry, and your AD administrator can override them at will; IE keys are used by almost everything supplied by microsoft, including execution digital signatures and email - Outlook or OE). All are trivially over-ridable by an attacker with write access to your machine. 4. [SITE] Generates and stores securely a private key Pretty much the same provisos apply here as did for the CA. Do you know and can you trust your key generation software? IIS for instance relies on a tool supplied my microsoft for the purpose; Apache usually suggests OpenSSL, email clients usually use their associated web browser for an interactive generation of both key and CSR while connected to the CA's website. However as another exercise - for each, where (and how) is the private key stored and protected? 5. [SITE] Generates and forwards to the CA a certificate signing request (CSR) Modulo the usual private key concerns, this is usually trouble-free (and again, is usually a combined step with key generation) 6. [CA] Receives and (for a payment) signs the CSR with its private key. This is where things get interesting. The certificate generated at this stage may or may not use exact copies of the data in the CSR; It may or may not be signed directly by the CA master key (for many CA's, their master key is kept offline in a bank vault and used to sign an intermediate key which is used for actual CSRs. In fact, it may sign *multiple* intermediate keys, for a number of good reasons (which we won't go into at this stage) but which also introduce another possible attack vector for a TLA with the power to force a CA of his choice (or someone with access to a private key there) to do selected tasks. Several potential attacks require that this transmission to the CA be intercepted and fulfilled by someone other than the CA themselves. Conventional wisdom says that there is little or no risk caused by site certificate substitution, and to a great extent this is correct - other than the possible forcing of the symmetric encryption method to one breakable by the TLA, there is little or no benefit to such a substitution. 7.
Re: A crazy thought?
Allen wrote: Hi Gang, In a class I was in today a statement was made that there is no way that anyone could present someone else's digital signature as their own because no one has has their private key to sign it with. This was in the context of a CA certificate which had it inside. I tried to suggest that there might be scenarios that could accomplish this but was told impossible. Not being totally clear on all the methods that bind the digital signature to an identity I let it be; however, the impossible mantra got me to thinking about it and wondering what vectors might make this possible. CAs are certification authorities ... they certify some information they have checked and issue digital certificates that represent that checking ... somewhat analogous to physical licenses, credentials, certificates. most certification authorities aren't the authoritative agency for the information that they certify ... for the most part they are simply certifying that they have checked the information with whatever authoritative agency is responsible for that information. in that sense they are somewhat like notary ... i.e. if somebody has done some identity theft and managed to obtain a valid driver's license ... the notary isn't held responsible ... they just notarize that they checked a valid drivers license. this is somewhat the catch-22 scenario in recent posts for ssl domain name certification authorities http://www.garlic.com/~lynn/subpubkey.html#catch22 where they are in something of a situation because big part of the original justification for ssl domain name certificates involved integrity issues with the domain name infrastructure ... however, the domain name infrastructure is also the authoritative agency for domain name owner information, which the ssl domain name certification authority is dependent on as part of the integrity for certifying ssl domain name information. Fixing integrity issues in the domain name infrastructure ... improves the probability that correct ssl domain name certification is being performed ... but fixing integrity issues in the domain name infrastructure can also drastically reduce justification for having ssl domain name certificates. recent posts http://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored http://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored http://www.garlic.com/~lynn/aadsm27.htm#16 dnssec? http://www.garlic.com/~lynn/aadsm27.htm#17 dnssec? http://www.garlic.com/~lynn/aadsm27.htm#19 307 digit number factored http://www.garlic.com/~lynn/aadsm27.htm#20 307 digit number factored http://www.garlic.com/~lynn/aadsm27.htm#21 307 digit number factored in some cases, there is the possibility that the excessive attention to the details of the cryptographic operations is pure obfuscation that the rest of the end-to-end business processes may purely be built on a house of cards. for additional drift, some recent posts in related thread on digital certificates in another fora (including some possible infrastructure vulnerabilities and systemic risks) http://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007i.html#28 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007i.html#48 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007i.html#51 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007k.html#79 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007l.html#0 Re: John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007l.html#2 Re: John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007l.html#6 Re: John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007l.html#9 Re: John W. Backus, 82, Fortran developer, dies - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A crazy thought?
At 06:28 AM 5/27/2007, Allen wrote: Validating a digital signature requires getting the public key from some source, like a CA, or a publicly accessible database and decrypting the signature to validate that the private key associated with the public key created the digital signature, or open message. Which lead me to the thought of trust in the repository for the public key. Here in the USA, there is a long history of behind the scenes cooperation by various large companies with the forces of the law, like the wiretap in the ATT wire room, etc. What is to prevent this from happening at a CA and it not being known for a lengthy period of time? Jurors have been suborned for political reasons, why not CAs? Would you, could you trust a CA based in a country with a low ethics standard or a low regard for human rights? Which lead me to the thought that if it is possible, what could be done to reduce the risk of it happening? This (if I'm understanding you correctly) is exactly the thing that the web of trust [1] is intended to address. One issue with the web of trust is how to bootstrap it. My understanding is that in the case of PGP, this was handled by Zimmermann publishing his public key in the (dead-trees) version of his book. Udhay [1] http://en.wikipedia.org/wiki/Web_of_trust -- ((Udhay Shankar N)) ((udhay @ pobox.com)) ((www.digeratus.com)) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A crazy thought?
Allen wrote: Which lead me to the thought that if it is possible, what could be done to reduce the risk of it happening? It occurred to me that perhaps some variation of separation of duties like two CAs located in different political environments might be used to accomplish this by having each cross-signing the certificate so that the compromise of one CA would trigger an invalid certificate. This might work if the compromise of the CA happened *after* the original certificate was issued, but what if the compromise was long standing? Is there any way to accomplish this? What you are suggesting is called Web of Trust (WoT). That's what the PGP world does, more or less, and I gather that the SPKI concept includes it, too. However, x.509 does not support it. There is no easy way to add multiple signatures to an x.509 certificate without running into support problems (that is, of course you can hack it in, but browsers won't understand it, and developers won't support you). (Anecdote 1: I pushed all of the Ricardo financial transaction stuff over to x.509 for a time in 1998, but when I discovered the lack of multiple sigs, and a few other things, I was forced to go back to PGP. Unfortunately, finance is fundamentally web of trust, and hierarchical PKI concepts such as coded into x.509, etc, will not work in that environment.) (Anecdote 2: over at CAcert they attempt to graft a web of trust on to the PKI, and they sort of succeed. But the result is not truly WoT, it is a hybrid, in that there is still only one sig on the cert, and we are back to the scenario that you suggest. Disclosure: I have something to do with CAcert...) So as a practical matter, that which is known as x.509 PKI cannot do this. For this reason, some critics have relabeled the CAs as Centralised Vulnerability Parties (CVPs) instead of the more familiar Trusted Third Parties (TTPs). As a side note, outside the cryptography layer, there are legal, contractual, customary defences against the attacks that you outline. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A crazy thought?
Allen, I am not sure what you are trying to achieve. The CA never has your private key. They are just signing a X.509 certificate that holds your public key. This way they are vouching that that you own the public. Even if you subpoena a CA they won't be able to decrypt any information encrypted with your public key. So having a separation-of-duty is not providing any additional security. Can you please elaborate on you are trying to achieve? Thanks saqib http://www.full-disk-encryption.net On 5/26/07, Allen [EMAIL PROTECTED] wrote: Hi Gang, In a class I was in today a statement was made that there is no way that anyone could present someone else's digital signature as their own because no one has has their private key to sign it with. This was in the context of a CA certificate which had it inside. I tried to suggest that there might be scenarios that could accomplish this but was told impossible. Not being totally clear on all the methods that bind the digital signature to an identity I let it be; however, the impossible mantra got me to thinking about it and wondering what vectors might make this possible. Validating a digital signature requires getting the public key from some source, like a CA, or a publicly accessible database and decrypting the signature to validate that the private key associated with the public key created the digital signature, or open message. Which lead me to the thought of trust in the repository for the public key. Here in the USA, there is a long history of behind the scenes cooperation by various large companies with the forces of the law, like the wiretap in the ATT wire room, etc. What is to prevent this from happening at a CA and it not being known for a lengthy period of time? Jurors have been suborned for political reasons, why not CAs? Would you, could you trust a CA based in a country with a low ethics standard or a low regard for human rights? Which lead me to the thought that if it is possible, what could be done to reduce the risk of it happening? It occurred to me that perhaps some variation of separation of duties like two CAs located in different political environments might be used to accomplish this by having each cross-signing the certificate so that the compromise of one CA would trigger an invalid certificate. This might work if the compromise of the CA happened *after* the original certificate was issued, but what if the compromise was long standing? Is there any way to accomplish this? Thoughts? Best to all, Allen - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Saqib Ali, CISSP, ISSAP http://www.full-disk-encryption.net - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A crazy thought?
Two birds with one shot. :) Ali, Saqib wrote: I am not sure what you are trying to achieve. The CA never has your private key. They are just signing a X.509 certificate that holds your public key. This way they are vouching that that you own the public. Even if you subpoena a CA they won't be able to decrypt any information encrypted with your public key. So having a separation-of-duty is not providing any additional security. Can you please elaborate on you are trying to achieve? I never said that the CA had your private key, only that they could validate an open message came from whomever held the private key associated with a given public key. I like going back to historical instances to illustrate issues because people can read about them from second sources and perhaps get clues about the issue they might not of otherwise. In this case I'll refer to a commonly acknowledged observation that the biggest financial backer of the Communist Party, USA, in the 1950s was the FBI. Another instance of a similar sort is that in many cases during the anti-Vietnam war years, the people advocating violent actions turned out to be paid agents of the FBI and other government agencies. And a third scenario to consider is the capture of German spies by the British and them using them to send both bogus and real intelligence back to their masters. PKI and other similar structures are an attempt to maintain confidentiality between two parties that are not present in the same room while at the same time assure each other that they are indeed talking to who they think they are. In the case of the FBI agents they were not talking to whom they though they were. With the German spies, they were, but the spies had been suborned with threats of the noose if they did not comply. Same problem, two different expressions. How do you trust who you are talking to is the person they represent themselves as? It is almost a side issue whether anyone else is privy to the contents of the conversation, important to prevent misuse and fraud by others, but not central to the first point: Identification. In a private e-mail a suggestion was made that it might be possible for a CA to issue a second certificate alleging it to be yours but in fact it belonged to someone else. In this case which is the real you as represented by the conflicting certificates? Then Ian G wrote: [snip] As a side note, outside the cryptography layer, there are legal, contractual, customary defences against the attacks that you outline. Ah, yes, the rule of law. Well, I think we've seen enough with the Real Innocence Project validating that people are put to death with customary legal processes and that Guantanamo Bay exists to say that if the law is your only protection you need help in a big way if someone gets a burr up their butt about you. My goal in this discussion examine how we can keep the underlying issues clear and utilize tools, like cryptography, to assist us in achieving well founded trust relationships. Best, Allen - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: A crazy thought?
On Sat 5/26/2007 at 8:59 PM Allen [EMAIL PROTECTED] wrote: Validating a digital signature requires getting the public key from some source, like a CA, or a publicly accessible database and decrypting the signature to validate that the private key associated with the public key created the digital signature, or open message. No. Usually the signer's certificate is included with the message so you don't go anywhere to get Alice's certificate, but you verify it against a trusted root. Which lead me to the thought of trust in the repository for the public key. Here in the USA, there is a long history of behind the scenes cooperation by various large companies with the forces of the law, like the wiretap in the ATT wire room, etc. From my perspective, the primary attack vector here is the Trusted Root CA list. If you can get the recipient to accept a new root, the forgery is pretty simple. If the end-user fails to validate the Trusted Root CA list and examine the certificate signature chain, then any trusted root CA could issue a cert with any Subject making any claim. And yes, being in the security business, I do check the certificate chain for my bank's on-line service before logging on. (I've also complained to them when they re-used a certificate from one host for another.) What is to prevent this from happening at a CA and it not being known for a lengthy period of time? Jurors have been suborned for political reasons, why not CAs? Would you, could you trust a CA based in a country with a low ethics standard or a low regard for human rights? To some extent, CA's are all about policy. What steps were required to obtain a certificate? These vary from I had control of an e-mail account at the time of certificate issuance. to I've had my lawyer present a notarized copy of my letters of incorporation and 2 years of public financial statements. To me it's simple: Don't trust the root CA if you don't trust them to enforce their policies. Verisign has built a small business on this premise. -Piers - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A crazy thought?
On Sat, 26 May 2007, Allen wrote: Validating a digital signature requires getting the public key from some source, like a CA, or a publicly accessible database and decrypting the signature to validate that the private key associated with the public key created the digital signature, or open message. Yep. Which lead me to the thought of trust in the repository for the public key. Here in the USA, there is a long history of behind the scenes cooperation by various large companies with the forces of the law, like the wiretap in the ATT wire room, etc. What is to prevent this from happening at a CA and it not being known for a lengthy period of time? Jurors have been suborned for political reasons, why not CAs? Would you, could you trust a CA based in a country with a low ethics standard or a low regard for human rights? The CA certifies that X is your public key. It doesn't know what your private key is. If the CA starts handing out false public keys - which is the worst that it could do, right? - it will find itself instantly distrusted. Everybody in the world will be able to see that the CA used its private key to sign a false statement. The offended party need only put the false declaration up on the Web. -- Jim Dixon [EMAIL PROTECTED] cellphone 415 / 570 3608 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A crazy thought?
Jim Dixon wrote: [snip] The CA certifies that X is your public key. ^ Who is you? That is the real question. To leave CAs out for the moment, imagine J. Doe and J. Doe, two different people, each put a public key on a server and you get a message created with a private key. You get the public key and validate it comes from one of the two J. Does. The question is who is the real J. Doe? Is one real and the other a repudiated key? Is one real and the other is trying to steal the identity of the other? Or is it simply that there are, indeed, two people with the same name? Adding a CA merely adds one layer of obfuscation and opportunity for false certification. If the CA starts handing out false public keys - which is the worst that it could do, right? - it will find itself instantly distrusted. Everybody in the world will be able to see that the CA used its private key to sign a false statement. Will they? What evidence do you have that proves the certificate is bogus? Say that the person who is having his identity stolen for whatever purpose discovers that there is a second certificate with his name on it but a different public key, what can he do, yell loudly, No, I'm the real me! How do we know that it isn't someone who is trying to muddy the waters and that the certificate holder is the real person? The offended party need only put the false declaration up on the Web. How many The Boy Who Cried Wolf cases would have to happen before we wouldn't trust *any* public key to represent who we think it does? How will dissident groups keep from getting compromised when fighting oppression? Best, Allen - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
A crazy thought?
Hi Gang, In a class I was in today a statement was made that there is no way that anyone could present someone else's digital signature as their own because no one has has their private key to sign it with. This was in the context of a CA certificate which had it inside. I tried to suggest that there might be scenarios that could accomplish this but was told impossible. Not being totally clear on all the methods that bind the digital signature to an identity I let it be; however, the impossible mantra got me to thinking about it and wondering what vectors might make this possible. Validating a digital signature requires getting the public key from some source, like a CA, or a publicly accessible database and decrypting the signature to validate that the private key associated with the public key created the digital signature, or open message. Which lead me to the thought of trust in the repository for the public key. Here in the USA, there is a long history of behind the scenes cooperation by various large companies with the forces of the law, like the wiretap in the ATT wire room, etc. What is to prevent this from happening at a CA and it not being known for a lengthy period of time? Jurors have been suborned for political reasons, why not CAs? Would you, could you trust a CA based in a country with a low ethics standard or a low regard for human rights? Which lead me to the thought that if it is possible, what could be done to reduce the risk of it happening? It occurred to me that perhaps some variation of separation of duties like two CAs located in different political environments might be used to accomplish this by having each cross-signing the certificate so that the compromise of one CA would trigger an invalid certificate. This might work if the compromise of the CA happened *after* the original certificate was issued, but what if the compromise was long standing? Is there any way to accomplish this? Thoughts? Best to all, Allen - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
