Re: [cryptography] Request - PKI/CA History Lesson
the only logical way to protect against man in the middle attacks would be perspectives (is that project abandoned?) or some sort of distributed certificate cache checking. because that's the only use of certificates right? to protect against man in the middle? On Mon, Apr 28, 2014 at 6:25 PM, Jason Iannone jason.iann...@gmail.comwrote: If browsers are defeating the purpose of the chain of trust, by forcing trust in this example, why design them to freak out when a site self signs? On Apr 28, 2014 6:32 PM, Jeffrey Walton noloa...@gmail.com wrote: On Mon, Apr 28, 2014 at 8:20 PM, Ryan Carboni rya...@gmail.com wrote: One can always start with the difficult first step of uninstalling certificate authorities you do not trust. Opera will autorepair damage to the certificate repository, a missing Certificate Authority is considered damage. Opera ships with a list of frequently used certificates, and if any of these are missing they will be added the next time the repository is read from disk. Other certificates will be added from the online repository as needed. - http://my.opera.com/community/forums/topic.dml?id=1580452 Its not just Opera. Others are using similar innovative methods to reduce the support load and costs. Jeff On Mon, Apr 28, 2014 at 4:42 PM, ianG i...@iang.org wrote: On 29/04/2014 00:12 am, Ryan Carboni wrote: trust is outsourced all the time in the non-cryptographic world trust is built up all the time, risks are taken all the time, choice is taken all the time. unless you do not have a bank account That's not outsourced, that's direct, person to bank, the person has a choice, chooses to place her trust in that bank. Also, it is limited to defined things that are required, can't be done by the person, and bolstered by real backing such as FIDC. When you suggest it's probably best we trust authorities that is CA-playbook crapola meaning you must trust the authorities that have been picked for you. The vector has been reversed, people are told what has to happen, so there is no trust. Trust derives from choice. Where is the choice? On Mon, Apr 28, 2014 at 3:00 PM, James A. Donald jam...@echeque.com mailto:jam...@echeque.com wrote: On 2014-04-29 05:58, Ryan Carboni wrote: We happen to live on a planet where most users are ordinary users. given the extent of phishing, it's probably best we outsource trust to centralized authorities. Although it should be easier establishing your own certificate authority. Cannot outsource trust Ann usually knows more about Bob than a distant authority does. A certificate authority does not certify that Bob is trustworthy, but that his name is Bob. In practice, however we find that diverse entities have very similar names, and a single entity may have many names. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 28/04/2014 23:00, James A. Donald wrote: Cannot outsource trust Ann usually knows more about Bob than a distant authority does. A certificate authority does not certify that Bob is trustworthy, but that his name is Bob. In practice, they are certifying they sold a certificate to someone that had Bob on it. Even for EV certificates, that isn't hard to do, even if you are actually Kevin. On 29/04/2014 02:25, Jason Iannone wrote: If browsers are defeating the purpose of the chain of trust, by forcing trust in this example, why design them to freak out when a site self signs? Mostly the value of the delusion in getting people to do things they wouldn't do on an insecure site. Getting a CA cert is more about the feelgood factor of they have a verified cert, so I can trust them than anything they can really assert given the body of evidence pointing to the real case of they have a verified cert, so clearly had a CC on hand with enough credit to buy a cert. This CC may even have been theirs - however, provided the vast majority of people believe it to be true, it is nearly as good as *being* true for commercial entities (and of course for the CAs) Most users wouldn't know what to do to verify a thumbprint, even if it were printed on the back of their debit card, but would just click OK regardless. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 29/04/2014 07:41 am, Ryan Carboni wrote: the only logical way to protect against man in the middle attacks would be perspectives (is that project abandoned?) or some sort of distributed certificate cache checking. because that's the only use of certificates right? Well. Certificates define their MITM as being the sort they can protect against, sure. to protect against man in the middle? Certs don't defend against *the MITM*, they only defend against _their MITM_. Subtle different, the MITM known as phishing is more or less unprotected. What to make of this? Security economics: there is zero point in investing anything in a form of MITM that is known to be so rare as statistically unmeasurable, even in unprotected environments, when there is another form of MITM that has clocked up billions in measurable losses. But jobs depend on that not being true, so it isn't. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 2014-04-28, at 5:00 PM, James A. Donald jam...@echeque.com wrote: Cannot outsource trust Ann usually knows more about Bob than a distant authority does. So should Ann verify the fingerprints of Amazon, and Paypal herself? How do you see that working assuming that Ann is an “ordinary user”? This is exactly the kind of thing I was complaining about in my earlier comment. There are burdens that we cannot push onto the user. People do trust their browsers and OSes to maintain a list of trustworthy CAs. Sure, we might have the occasional case where some people manually remove or add a CA. But for the most part, we’ve outsourced trust to the browser vendors, how have outsourced trust to various CAs, etc. I am not saying that the system isn’t fraught with series problems. I’m saying that at least it tries to work for ordinary users. A certificate authority does not certify that Bob is trustworthy, but that his name is Bob. Yes, of course. Back in the before time (1990s), I had feared that this was going to be a big problem. That people would take the take “trust the authenticity” of a message to be “trust the veracity” of the message. But as it turns out, we haven’t seen a substantially higher proportion of fraud of this nature than in meatspace. I think it is because reputations are now so fragile. Cheers, -j ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
Hi Jeffrey, On 29/04/2014 17:14 pm, Jeffrey Goldberg wrote: On 2014-04-28, at 5:00 PM, James A. Donald jam...@echeque.com wrote: Cannot outsource trust Ann usually knows more about Bob than a distant authority does. So should Ann verify the fingerprints of Amazon, and Paypal herself? How do you see that working assuming that Ann is an “ordinary user”? First, do a proper security analysis; don't accept some marketing dross from the sellers of stuff. If you look at the history of web commerce, there is nothing there that supports the notion that the in-protocol MITM is a risk to be mitigated. Even if you look at close analogues, the support is not there. And, if you look at the rest of the equation -- humans, banks, stores, remember them? -- you find they don't care either. That's because they're all ready for chargebacks, and always have been so Alice has no problem, ever. She does not *ever* need to worry about fingerprints. Then, what are they worried about? Mass raids of databases, that's what. By far the #1. The next issue, way behind, is phishing, the other MITM. (Which again they do little about.) It turns out -- and early simple analysis suggested -- that an in-protocol MITM is the worst possible attack, it's daft to an extraordinary level, and only security experts ever worry about it. Conclusion? Strawman. A real security analysis reveals all this. Question then, is where did the notion that you HAVE to defend yourself form the evil in-protocol MITM? Why are we all terrified? This is exactly the kind of thing I was complaining about in my earlier comment. There are burdens that we cannot push onto the user. People do trust their browsers and OSes to maintain a list of trustworthy CAs. No they don't. Again, you are taking the words from the sold-model. People don't have a clue what a trustworthy CA is, in general. That's because the same model hid it, and is still hiding it. Have a look at amazon today -- look Ma, no CA. In sight. The day the CA is in sight, the users might care. Until then they don't know so they cannot possibly trust. (c.f., the *real meaning of trust* being a human decision to take a risk on available information.) Sure, we might have the occasional case where some people manually remove or add a CA. But for the most part, we’ve outsourced trust to the browser vendors, how have outsourced trust to various CAs, etc. We the users have done nothing of the kind. Browsers have done what they've done, and you could claim that the browsers trust the CAs. Maybe. More so these days coz they actually do something about it, in CABForum, less so before then, before Mozo policy. I am not saying that the system isn’t fraught with series problems. I’m saying that at least it tries to work for ordinary users. Well. It tries to not interfere with ordinary users. In terms of working, one would need to establish the tangible benefit... A certificate authority does not certify that Bob is trustworthy, but that his name is Bob. Yes, of course. Back in the before time (1990s), I had feared that this was going to be a big problem. That people would take the take “trust the authenticity” of a message to be “trust the veracity” of the message. But as it turns out, we haven’t seen a substantially higher proportion of fraud of this nature than in meatspace. I think it is because reputations are now so fragile. That last comment. Yes, either the system worked, or the system never worked, and wasn't needed. http://financialcryptography.com/mt/archives/001255.html Show which? The more things you do to it, and discover that nothing changes, is evidence to the latter. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
the only logical way to protect against man in the middle attacks would be perspectives (is that project abandoned?) or some sort of distributed certificate cache checking plug It would be blockchain-based solution like DNSChain: https://github.com/okTurtles/dnschain (Which is very much not abandoned.) /plug to protect against man in the middle? Certs don't defend against *the MITM*, they only defend against _their MITM_. Subtle different, the MITM known as phishing is more or less unprotected. I don't know what you mean by their MITM. Certs don't protect against MITM. Certs encourage Big-Brother MITM because they are intertwined with X.509 PKI: http://blog.okturtles.com/2014/02/introducing-the-dotdns-metatld/ - Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. signature.asc Description: Message signed with OpenPGP using GPGMail ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
Hi Jason, It's quite the coincidence that I saw this email of yours a few days ago when I was wondering the same thing. I've read through many of the replies to this thread but haven't been able to answer a related question that I have. I'm looking for a date that I could point to and call the birth of modern HTTPS/PKI. There is the Loren M Kohnfelder thesis from May of 1978, but that's not quite it because it wasn't actually available to anyone at the time. Perhaps an event along the lines of first modern HTTPS implementation in a public web browser was released, or something like that. Any leads? Maybe something from Netscape's history? Thanks, Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Apr 16, 2014, at 10:30 AM, Jason Iannone jason.iann...@gmail.com wrote: The more I read, the more bewildered I am by the state of the PKI. The trust model's unwieldy system[1] of protocols, dependencies, and outright assumptions begs to be exploited. Add to that the browser behavior for a self-signed certificate (RED ALERT! THE SKY IS FALLING!) compared to a trusted site and we're in bizarro world. I'd rather we close the gap and appreciate a secure transaction with an unauthenticated party than proclaim all is lost when a self-signed key is presented. I see no reason to trust VeriSign or Comodo any more than Reddit. Assuming trust in a top heavy system of Certificate Authorities, Subordinate Certificate Authorities[2], Registration Authorities, and Validation Authorities[3] in a post bulk data collection partnership world is a non-starter. The keys are compromised. With that, I ask for a history lesson to more fully understand the PKI's genesis and how we got here. Maybe a tottering complex recursive heirarchical system of trust is a really great idea and I just need to be led to the light. [1]http://csrc.nist.gov/publications/nistpubs/800-15/SP800-15.PDF, http://csrc.nist.gov/publications/nistpubs/800-32/sp800-32.pdf [2]https://www.eff.org/files/DefconSSLiverse.pdf, https://www.eff.org/files/ccc2010.pdf [3]http://en.wikipedia.org/wiki/Public-key_infrastructure ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography signature.asc Description: Message signed with OpenPGP using GPGMail ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 29 April 2014 07:41, Ryan Carboni rya...@gmail.com wrote: the only logical way to protect against man in the middle attacks would be perspectives (is that project abandoned?) or some sort of distributed certificate cache checking. Or Certificate Transparency. :-) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 29/04/2014 19:02 pm, Greg wrote: I'm looking for a date that I could point to and call the birth of modern HTTPS/PKI. There is the Loren M Kohnfelder thesis from May of 1978, but that's not quite it because it wasn't actually available to anyone at the time. Perhaps an event along the lines of first modern HTTPS implementation in a public web browser was released, or something like that. Any leads? Maybe something from Netscape's history? Yes, 1994, when Netscape invented SSL v1. Which had no MITM support, which was then considered to be a life and death issue by RSADSI ... which just happened to have invested big in a think called x.509. And the rest is history. Some commentary here, which is opinion not evidence. http://financialcryptography.com/mt/archives/000609.html iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
Or Certificate Transparency. :-) Sorry Ben, But your Certificate Transparency is not a solution. It's an invitation to more trouble: - Your currently published RFC doesn't actually fix the MITM problem, it merely gives the illusion of a fix. It doesn't actually prevent governments from issuing fake certificates and MITMing connections, and your attempt to address this problem is a mere TBD. - Your RFC is an obvious attempt to preserve today's pay-for-protection system. It's clear from the RFC that Google is actually trying to lead the internet down a dangerous path where people *must* pay for security by not supporting self-signed certificates. I look forward to writing a more detailed post on it. Cheers, Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Apr 29, 2014, at 1:11 PM, Ben Laurie b...@links.org wrote: On 29 April 2014 07:41, Ryan Carboni rya...@gmail.com wrote: the only logical way to protect against man in the middle attacks would be perspectives (is that project abandoned?) or some sort of distributed certificate cache checking. Or Certificate Transparency. :-) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography signature.asc Description: Message signed with OpenPGP using GPGMail ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
- Your RFC is an obvious attempt to preserve today's pay-for-protection system. It's clear from the RFC that Google is actually trying to lead the internet down a dangerous path where people *must* pay for security by not supporting self-signed certificates. Erm, sorry, that should read: where people *must* pay for insecurity, as it's, well, not actually secure. -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Apr 29, 2014, at 1:22 PM, Greg g...@kinostudios.com wrote: Or Certificate Transparency. :-) Sorry Ben, But your Certificate Transparency is not a solution. It's an invitation to more trouble: - Your currently published RFC doesn't actually fix the MITM problem, it merely gives the illusion of a fix. It doesn't actually prevent governments from issuing fake certificates and MITMing connections, and your attempt to address this problem is a mere TBD. - Your RFC is an obvious attempt to preserve today's pay-for-protection system. It's clear from the RFC that Google is actually trying to lead the internet down a dangerous path where people *must* pay for security by not supporting self-signed certificates. I look forward to writing a more detailed post on it. Cheers, Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. signature.asc Description: Message signed with OpenPGP using GPGMail ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 2014-04-29 18:18, ianG wrote: On 29/04/2014 19:02 pm, Greg wrote: I'm looking for a date that I could point to and call the birth of modern HTTPS/PKI. There is the Loren M Kohnfelder thesis from May of 1978, but that's not quite it because it wasn't actually available to anyone at the time. Perhaps an event along the lines of first modern HTTPS implementation in a public web browser was released, or something like that. Any leads? Maybe something from Netscape's history? Yes, 1994, when Netscape invented SSL v1. Which had no MITM support, which was then considered to be a life and death issue by RSADSI ... which just happened to have invested big in a think called x.509. And the rest is history. Some commentary here, which is opinion not evidence. http://financialcryptography.com/mt/archives/000609.html I guess the historic gap between Loren Kohnfelder thesis and Netscape SSL development has to be filled with due consideration of the OSI development, and notably the Network Layer Security Protocol (NLSP). Prior to the domination of IP protocols, the information highway was expected to be secured with the NLSP over an X.25 backbone. The payment industry was investing in SET (Secure Electronic Transactions), and the Netscape SSL was first perceived as a childish attempt for a quick and (very) dirty short term solution. Even then, in my understanding, there would still be a gap between Loren thesis and the NLSP development. I have some clues that the Digital Equipment DecNET protocols would fill this gap. Don't look at Microsoft. By 1995, their only IT security commitment seemed to be for a facsimile security protocol (even devoid of public key crypto). (This should have been a prior art against Data Treasury cheque imaging patent battle, but that's another lllooonng story.) In retrospect, the ASN.1 based X.509 security certificate has been salvaged from the OSI effort thanks to Verisign dedication to license their patents for some IETF protocols on easy terms. Lotus Notes security is special because it evolved from an RSA technology license acquired prior to RSADSI, and they use certificates without the ASN.1/X.509 paradigms. Regards, - Thierry Moreau ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
I suspect our current X.509 PKI was invented at Xerox … likely PARC. The first X.509 draft was a Xerox contribution in about 1984. I have it somewhere in my garage… Paul On Apr 29, 2014, at 1:45 PM, Greg g...@kinostudios.com wrote: On Apr 29, 2014, at 1:18 PM, ianG i...@iang.org wrote: Yes, 1994, when Netscape invented SSL v1. Which had no MITM support, which was then considered to be a life and death issue by RSADSI ... which just happened to have invested big in a think called x.509. And the rest is history. Some commentary here, which is opinion not evidence. http://financialcryptography.com/mt/archives/000609.html Fascinating. I especially liked the timelines there, thanks for the link! I'm now slowly coming to the conclusion that my search for a specific birthdate of modern PKI might be in vain. The way I phrased it in an email to Peter was: Do you happen to know of the date of the following event: when did the first publicly available web browser successfully connect over HTTPS to the a publicly available HTTPS website, and have the website's certificate validated by a CA in the same manner as it is done today? ..if that's not available, then simply the date of the release of the first implementation of HTTPS? There's also this little timeline graphic from the link: gp8.png Then there's the wiki: https://en.wikipedia.org/wiki/Transport_Layer_Security#History_and_development Which says: The SSL protocol was originally developed by Netscape.[10] Version 1.0 was never publicly released; version 2.0 was released in February 1995 but contained a number of security flaws which ultimately led to the design of SSL version 3.0.[11] SSL version 3.0, released in 1996, was a complete redesign of the protocol produced by Paul Kocher working with Netscape engineers Phil Karlton and Alan Freier. Newer versions of SSL/TLS are based on SSL 3.0. The 1996 draft of SSL 3.0 was published by IETF as a historical document in RFC 6101. And there's the x509 wiki: https://en.wikipedia.org/wiki/X.509#Public-Key_Infrastructure_.28X.509.29_Working_Group The The Public-Key Infrastructure (X.509) working group (PKIX) was a working group of the Internet Engineering Task Force dedicated to creating RFCs and other standard documentation on issues related to public key infrastructure based on X.509 certificates. PKIX was established in Autumn 1995 in conjunction with the National Institute of Standards and Technology.[17] So... it sounds like Netscape either had a publicly available implementation of modern PKI before, or at about the same time as the standards were being published. In that case, while there doesn't appear to be a precise date, the birth year at least seems to be 1995. This monstrosity was born sometime late 1995. Is that about right? Or would I be mistaken to call that the birth year? Thanks much for the history lesson and fascinating references! - Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
Hi Ian, I will just respond to one of the many excellent points you’ve made. On 2014-04-29, at 12:12 PM, ianG i...@iang.org wrote: On 29/04/2014 17:14 pm, Jeffrey Goldberg wrote: People do trust their browsers and OSes to maintain a list of trustworthy CAs. No they don't. Again, you are taking the words from the sold-model. I will explain my words below. People don't have a clue what a trustworthy CA is, in general. I emphatically agree with you. I hadn’t meant to imply otherwise. I have been using “trust” in a sort of behavioral way. For the sake of the next few sentences, I’m going to introduce some terrible terminology. “b-trust” is my “behavioral trust” which will defined in terms of “c-trust” (“cognitive”). So let’s say that A c-trusts B wrt to X when A is confident that B will act in way X. (Cut me some slack on “act”). A “b-trusts” B wrt to X when she behaves as if she c-trusts B wrt to X. So when I say that users trust their browsers to maintain a list of trustworthy CAs, I am speaking of “b-trust”. They may have no conscious idea or understanding what they are actually trusting or why it is (or isn’t) worthy of their trust. But they *behave* this way. A vampire bat may b-trust that its rook mates will give it a warm meal if necessary. Life is filled with such trust relations even where there is no c-trust. (c.f., the *real meaning of trust* being a human decision to take a risk on available information.) Which is what I am talking about. And I’m talking about it because it is what matters for human behavior. And I want a system that works for humans. I see that you’ve written on financial cryptography. Well think about conventional currency works. For all its problems currency works, and it is a system that requires “trust”. But only a negligible fraction of the people who successfully use the system do so through c-trust. It may well be that all of the problems with TLS are because the system is trying to work for agents who don’t understand how the system works. But, as I said at the beginning, that is the world we are living in. Cheers, -j ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On Apr 29, 2014, at 12:28 PM, Thierry Moreau thierry.mor...@connotech.com wrote: On 2014-04-29 18:18, ianG wrote: On 29/04/2014 19:02 pm, Greg wrote: I'm looking for a date that I could point to and call the birth of modern HTTPS/PKI. There is the Loren M Kohnfelder thesis from May of 1978, but that's not quite it because it wasn't actually available to anyone at the time. Perhaps an event along the lines of first modern HTTPS implementation in a public web browser was released, or something like that. Any leads? Maybe something from Netscape's history? Yes, 1994, when Netscape invented SSL v1. Which had no MITM support, which was then considered to be a life and death issue by RSADSI ... which just happened to have invested big in a think called x.509. And the rest is history. Some commentary here, which is opinion not evidence. http://financialcryptography.com/mt/archives/000609.html I guess the historic gap between Loren Kohnfelder thesis and Netscape SSL development has to be filled with due consideration of the OSI development, and notably the Network Layer Security Protocol (NLSP). Prior to the domination of IP protocols, the information highway was expected to be secured with the NLSP over an X.25 backbone. No. NLSP had two modes, connection-less and connection oriented. I was one of the authors … The connection oriented never went very far. NLSP was essentially the SP3 protocol developed as a research effort with NSA funding for a complete suite of protocols using public key based authentication in the Secure Data Network System (SDNS) project. it was the late 80’s and at the time NSA encouraged open publication of the work. NIST published the effort as the “SDN” series (e.g. SDN.301 for layer 3 security). The same work went into ISO (as NLSP) and the IETF. The SP3 and KMP were starting points of the IPsec work. In hind sight, the KMP specification is much better than what we ended up with IKE. However, some good improvements were added in the process. It’s interesting that I can not find any of the NIST published SDN specification on the NIST site :-( More digging required. The Message Security Protocol (MSP) work was also a SDNS effort for secure email. When taken public this morphed into our current Internet email security. Paul The payment industry was investing in SET (Secure Electronic Transactions), and the Netscape SSL was first perceived as a childish attempt for a quick and (very) dirty short term solution. Even then, in my understanding, there would still be a gap between Loren thesis and the NLSP development. I have some clues that the Digital Equipment DecNET protocols would fill this gap. Don't look at Microsoft. By 1995, their only IT security commitment seemed to be for a facsimile security protocol (even devoid of public key crypto). (This should have been a prior art against Data Treasury cheque imaging patent battle, but that's another lllooonng story.) In retrospect, the ASN.1 based X.509 security certificate has been salvaged from the OSI effort thanks to Verisign dedication to license their patents for some IETF protocols on easy terms. Lotus Notes security is special because it evolved from an RSA technology license acquired prior to RSADSI, and they use certificates without the ASN.1/X.509 paradigms. Regards, - Thierry Moreau ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
Message du 29/04/14 20:11 De : Ben Laurie On 29 April 2014 07:41, Ryan Carboni wrote: the only logical way to protect against man in the middle attacks would be perspectives (is that project abandoned?) or some sort of distributed certificate cache checking. Or Certificate Transparency. :-) And how is that supposed to work? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On Tue, Apr 29, 2014 at 7:10 PM, tpb-cry...@laposte.net wrote: Or Certificate Transparency. :-) And how is that supposed to work? Here, let me help you out: http://lmgtfy.com/?q=certificate+transparencyl=1 -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
