- From: Yngve N. Pettersen (Developer Opera Software ASA) <yngve@opera.com>
- Date: Mon, 21 May 2007 22:04:10 +0200
- To: "Mary Ellen Zurko" <Mary_Ellen_Zurko@notesdev.ibm.com>
- Cc: public-wsc-wg@w3.org
On Mon, 21 May 2007 21:54:53 +0200, Mary Ellen Zurko <Mary_Ellen_Zurko@notesdev.ibm.com> wrote: > Very interesting. So in the sense that the DN specifies a single entity, > it is "signed by the self", but it is not "self signed" in the sense that > it's signed with the same key that's associated with the cert's public > key. Is that right? Yes. That is exactly what is going on. > public-wsc-wg-request@w3.org wrote on 05/03/2007 09:55:11 AM: > >> >> Hello Stephen, >> >> >> Ordinary selfsigned certificates is not a problem, those will be > forwarded >> to the user as an unknown CA dialog, as you observed. >> >> What we have in this case is that somebody creates a selfsigned root >> certificate with the name X, including the server's name. So far, so > good, >> it can even be used on the server. >> >> Then they issue a server certificate from that root, but uses the same >> name X as subject, issued from X, but without the Authority Key >> Identifier, (AKID, which would have solved the problem). >> >> Then we have a certificate that looks like a selfsigned certificate, but > >> isn't. Trying to verify the server certificate's signature with the > public >> key in the server certificate will fail. >> >> There are certainly people that think we are overly strict (and are > quite >> vocal about it), but I am not sure it is possible to separate out this >> particular class of certificate and still fail on a faked or manipulated > >> certificate. >> >> What it comes down to is which problems do the client block (and refuse > to >> load), which do they accept silently, and which do they ask the user >> about? For this particular problem (signature verification failure) I am > >> not sure it is possible to separate the first and third type. >> >> On Thu, 03 May 2007 14:18:29 +0200, Stephen Farrell >> <stephen.farrell@cs.tcd.ie> wrote: >> >> > >> > >> > IMO you're being overly strict there, but I can understand >> > why. I'm interested if you think that this is different from >> > a site that just uses a self-signed cert - do you & if so, >> > why? >> > >> > Opera 9.10 (installed here) does offer me the choice to go >> > ahead for my web server [1], which does have an entirely >> > good bogus self-signed cert. Would that fail with your >> > version? >> > >> > If so, then I definitely think you need a way to allow >> > users to get to such informally setup web servers. I >> > would however not have a problem if the question to the >> > user was turned around - instead of "do you want to >> > trust this cert" it could be "do you want to access this >> > site" - the former one could have other consequences if >> > the private key is also elsewhere. >> > >> > Stephen. >> > >> > [1] https://down.dsg.cs.tcd.ie/ >> > >> > Yngve Nysaeter Pettersen wrote: >> >> Hello all, >> >> I am not quite sure if this fits into the anti-pattern discussion > but >> >> it may be relevant. >> >> I occasionally have to deal with a particular type of homemade >> >> certificates. >> >> The certificate chain contain at least two certificates, but two of >> >> them (A and B) have the same Distinguished Name (X) as Issuer and >> >> Subject, but have different public keys (K_A and K_B), and one of > them >> >> was used to sign the other (that is, Cert_A have Subject X and Issuer > >> >> X, Key K_A, and is signed by K_B from Cert_B, Cert_B have Subject X > and >> >> key K_B, Cert B is usually selfsigned, but might be part of a longer >> >> chain). There is no Authority Key Identifier extension. >> >> That means that as far as the certificate validation (in Opera, at >> >> least) is concerned the lowermost certificate (Cert_A) is selfsigned, > >> >> but the signature does not verify. >> >> Opera treats this certificate as a signature verification failure > and >> >> issues a fatal TLS error (code 42, "Bad certificate") and refuses to >> >> access the site, but other clients treat this is as an Unknown CA and > >> >> asks the user. >> >> One live example (currently) is <URL: https://proj.koios.de/ > >> >> Any opinions on this particular scenario, and how it should be > handled? >> >> On Tue, 24 Apr 2007 00:41:17 +0200, >> >> <michael.mccormick@wellsfargo.com> wrote: >> >> >> >>> It appears ACTION-182 stems from my Lightning Discussion on 4 April >> >>> about the cryptic IE6 browser errors that I received when I >> >>> encountered a self-signed SSL certificate at the www.x9.org web > site. >> >>> According to my notes, as well as the official meeting notes from >> >>> Thomas, we had a lively discussion about the security anti patterns >> >>> implied by such browser error messages. In particular I captured > the >> >>> following possible anti patterns in my notes: >> >>> >> >>> 1. Use of technical jargon containing terms with which the average >> >>> layperson is not familiar. >> >>> 2. Providing a web site's URL as the only contact info for it. >> >>> (creates "catch-22" dilemma for user) >> >>> 3. Actions suggested can't really be carried out. >> >>> 4. Consequences or risks of user actions not explained. >> >>> These are the [anti-]recommendations I propose we adopt. > Anticipating >> >>> comment, I haven't yet updated the wiki. Cheers Mike >> >> >> >> >> >> -- >> Sincerely, >> Yngve N. Pettersen >> >> ******************************************************************** >> Senior Developer Email: yngve@opera.com >> Opera Software ASA http://www.opera.com/ >> Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 >> ******************************************************************** >> > -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ********************************************************************
Received on Monday, 21 May 2007 20:04:56 UTC