- From: Serge Egelman <egelman@cs.cmu.edu>
- Date: Fri, 12 Oct 2007 12:18:19 -0400
- To: Ian Fette <ifette@google.com>
- CC: yngve@opera.com, Johnathan Nightingale <johnath@mozilla.com>, W3C WSC Public <public-wsc-wg@w3.org>
I think you need to ask yourself these questions: Do you believe that current SSL warning messages in this example (domain mismatch) are effective? Of the number of sites that yield warnings for this (where the certificate was granted for the domain, but the subdomain doesn't match), how many are malicious? How many times is it benign when this warning appears? If you agree there's a problem with users ignoring the messages, changing the look of the messages isn't going to solve the problem. You can create new messages, but if they appear in situations where the user knows there is little or no risk, the user becomes habituated. Then, all such messages will be ignored in the future, regardless of the real risk. Thus, we might have expended time/energy/resources creating new warnings, but they're just as useless as the ones they replaced. serge Ian Fette wrote: > Yngve's point is much more what I was worried about. Without getting > into architecture of any particular companies, it's entirely possible > that a company could use a set of servers in the front to handle and > load-balance all their traffic. These front-end servers have no idea* > which domain and/or subdomain is being requested, only that they need to > do a handshake, and then do some work with backend servers to make magic > happen. So they do a handshake, and life is good. > > *Not absolutely true. A company can set up its properties to resolve to > different IPs, and then use the IP address to determine which cert, if > any, to present. > > My point however is that you (the browser) are extending trust where I > (the webmaster) did not intend trust to be extended, and you are doing > so without any basis in PKI spec. Now I as a webmaster have to go out of > my way to make sure that I'm not extending trust under this new model, > which may be more difficult than you think. > > You're essentially changing a default, which is always a dangerous thing > to do and is certainly going to bite someone. Previously, by default, > you extended trust only by specifically designating domains (and > sub-domains). Now, you're proposing extending trust by default - this > has a lot of implications, and while it might be reasonably simple on > the "one website one server" domain, it can get more complicated when > you start talking about complex architectures. > > On 10/12/07, *Yngve Nysaeter Pettersen* <yngve@opera.com > <mailto:yngve@opera.com>> wrote: > > > On Fri, 12 Oct 2007 16:25:58 +0200, Johnathan Nightingale > <johnath@mozilla.com <mailto:johnath@mozilla.com>> wrote: > > > Well hold up a second though. Correct me if I've got this wrong: > > > > - example.com <http://example.com> has a non-wildcard, DV cert. > > - example.com <http://example.com> gives out subdomains to > people it doesn't > > particularly trust with the " example.com <http://example.com>" > name, people who might not > > even be hosted on the same server. > > - example.com <http://example.com> wants to enable SSL > > > > So Ian's making the point that ifette.example.com > <http://ifette.example.com> shouldn't be > > allowed to use example.com <http://example.com>'s cert, and > therefore that user agents are > > right to warn in that case. > > > > But ifette.example.com <http://ifette.example.com> can't just > decide to start using that cert > > without the private key, right? If the cert is otherwise valid, and > > the mismatch is confined to a subdomain, to me the question still > > remains as to whether that's a sensible warning - if not in absolute > > PKI orthodoxy terms, then at least in terms of false-positive/false- > > negative rate. If ifette can, without authorization, complete a TLS > > handshake with example.com <http://example.com>'s cert, there are > bigger problems at play. > > What if a SSL frontend is used for the whole example.com > <http://example.com> domain, and which > is configured to forward data to the real ifette.example.com > <http://ifette.example.com> server over > another connection? > > > I will offer that the counter-case, where " example.com > <http://example.com>" is presenting > > a cert issued to "ifette.example.com <http://ifette.example.com>" > is much more worrisome, since > > it is absolutely the case that deception could occur there. That I > > can obtain a subdomain of googlepages, or dyndns.org > <http://dyndns.org>, or blogger.com <http://blogger.com> > > - and prove that to a CA, should not allow me to quietly masquerade > > as the top level site. > > > > I think Serge was talking about the first case though - top-level non- > > wildcard DV cert being applied to a specific subdomain. > > > > Cheers, > > > > Johnathan > > > > > > On 11-Oct-07, at 8:47 PM, Ian Fette wrote: > > > >> Has some level of control, yes. But that doesn't address the second > >> case, where ifette.googlepages.com > <http://ifette.googlepages.com> is a phishing site, and I don't > >> want Google's cert being used there... > >> > >> -Ian > >> > >> On 10/11/07, Serge Egelman < egelman@cs.cmu.edu > <mailto:egelman@cs.cmu.edu>> wrote: > >> That's not what I said. ianfette.googlepages.com > <http://ianfette.googlepages.com> is still under the > >> googlepages.com <http://googlepages.com> domain. The person who > controls the googlepages.com <http://googlepages.com> > >> domain still has control over the other subdomains. > >> > >> serge > >> > >> Ian Fette wrote: > >> > Not really... you have absolutely no way of knowing that > >> > ianfette.googlepages.com <http://ianfette.googlepages.com> > <http://ianfette.googlepages.com <http://ianfette.googlepages.com>> > is on the > >> > same server as googlepages.com <http://googlepages.com> < > http://googlepages.com>. Given our > >> > architecture, I have no idea. It's a server we own, but it's not > >> > necessarily one of the googlepages.com <http://googlepages.com> > < http://googlepages.com> > >> servers. > >> > > >> > Also though, let's say that you have a phishing site at > >> > https://ifette.googlepages.com - I don't really know that I want > >> a lock > >> > being displayed there, or whatever security indicators we > >> display, based > >> > on Google's certificate. Right now most free web hosts aren't > giving > >> > users SSL (that I know of), and this would be an easy way for an > >> > attacker to get free SSL with a pretty good cert. Not really > >> ideal, and > >> > could even make us more of a target. Who knows, rampant > >> speculation past > >> > this point... > >> > > >> > -Ian > >> > > >> > On 10/11/07, *Serge Egelman* < egelman@cs.cmu.edu > <mailto:egelman@cs.cmu.edu> > >> > <mailto:egelman@cs.cmu.edu <mailto:egelman@cs.cmu.edu>>> wrote: > >> > > >> > ...and in that case it's still accurate. > >> > > >> > serge > >> > > >> > Ian Fette wrote: > >> > > Well, it's still an attestation to some level. It's not an > >> attestation > >> > > that you're talking with Google, but it is an attestation > >> that you're > >> > > talking with google.com <http://google.com> > <http://google.com> <http:// > >> google.com <http://google.com>>. > >> > But beyond that I have no > >> > > good answer. > >> > > > >> > > On 10/11/07, *Serge Egelman* < egelman@cs.cmu.edu > <mailto:egelman@cs.cmu.edu> > >> > <mailto:egelman@cs.cmu.edu <mailto:egelman@cs.cmu.edu> > > >> > > <mailto:egelman@cs.cmu.edu <mailto:egelman@cs.cmu.edu> > <mailto: egelman@cs.cmu.edu <mailto:egelman@cs.cmu.edu>>>> > >> wrote: > >> > > > >> > > Point taken. > >> > > > >> > > But what about certificates that are not > >> attestations? E.g., > >> > anything > >> > > non-EV? > >> > > > >> > > serge > >> > > > >> > > Ian Fette wrote: > >> > > > The need to warn comes in around something like > >> > googlepages.com <http://googlepages.com> > <http://googlepages.com > > >> > > < http://googlepages.com> > >> > > > <http://googlepages.com>. Right now, the management > >> is all under > >> > > > pages.google.com <http://pages.google.com> > <http://pages.google.com> > >> > < http://pages.google.com> < > >> > > http://pages.google.com> and we use a SSL cert for > >> > > > google.com <http://google.com> <http://google.com> > < http://google.com> > >> > <http://google.com> for login etc. > >> > > But it is conceivable that > >> > > > at some point we might actually want to SSL enable > >> > > > https://www.googlepages.com > <https://www.googlepages.com> for login, or who knows > >> what. > >> > (This is > >> > > wild > >> > > > speculation, I don't work on the project, this is > >> just an > >> > example). So > >> > > > we would then need a cert for googlepages.com > <http://googlepages.com> > >> > <http://googlepages.com <http://googlepages.com>> > >> > > < http://googlepages.com> <http://googlepages.com > >> > < http://googlepages.com>>. > >> > > > But user content is located at > username.googlepages.com <http://username.googlepages.com> > >> > < http://username.googlepages.com> > >> > > < http://username.googlepages.com > > >> > > > < http://username.googlepages.com>, and we really > >> don't want to > >> > > attest to > >> > > > anything about the identity of whatever is found at > >> those > >> > > locations. So > >> > > > when you try to load https://ifette.googlepages.com > >> under this > >> > > scenario > >> > > > (where googlepages.com <http://googlepages.com> > <http://googlepages.com> > >> > < http://googlepages.com> < > >> > > http://googlepages.com> is actually ssl enabled > >> > > > and serving up something), you had better get a > warning. > >> > > > > >> > > > Subdomains are not *always* controlled (or rather, > >> authored > >> > / attested > >> > > > to) by the owner of the higher-level domain, and it's > >> not > >> > always a > >> > > safe > >> > > > assumption to make. You can make arguments about www > >> being a > >> > special > >> > > > case, but beyond that... > >> > > > > >> > > > -Ian > >> > > > > >> > > > On 10/11/07, *Serge Egelman* < egelman@cs.cmu.edu > <mailto:egelman@cs.cmu.edu> > >> > <mailto:egelman@cs.cmu.edu <mailto:egelman@cs.cmu.edu>> > >> > > <mailto: egelman@cs.cmu.edu > <mailto:egelman@cs.cmu.edu> <mailto: egelman@cs.cmu.edu > <mailto:egelman@cs.cmu.edu>>> > >> > > > <mailto:egelman@cs.cmu.edu > <mailto:egelman@cs.cmu.edu> <mailto: egelman@cs.cmu.edu > <mailto:egelman@cs.cmu.edu>> > >> > <mailto: egelman@cs.cmu.edu <mailto:egelman@cs.cmu.edu> > <mailto:egelman@cs.cmu.edu <mailto:egelman@cs.cmu.edu>>>>> > >> wrote: > >> > > > > >> > > > This is an error I'm trying to do some research > >> on, maybe > >> > > someone can > >> > > > shed some light on it. There are thousands of > >> legitimate > >> > > sites that > >> > > > have this problem, either because they don't use an > >> > alt-name, > >> > > or the > >> > > > certificate is being used on some other > subdomain of > >> > their domain. > >> > > > > >> > > > In the case where one certificate is being used > >> by another > >> > > host within > >> > > > the domain that it was legitimately issued for, > >> I'm not > >> > > entirely sure > >> > > > what the threat model is. Sure, this is a great > >> way for CAs > >> > > to make > >> > > > money (by either making a site buy a new > >> certificate for > >> > every > >> > > host or > >> > > > making them buy a wildcard cert), but beyond this, > >> > what's the need > >> > > > to warn? > >> > > > > >> > > > Yes, the DNS can be hacked to add in a new > >> hostname, but at > >> > > that point > >> > > > there are bigger problems. > >> > > > > >> > > > serge > >> > > > > >> > > > Ian Fette wrote: > >> > > > > bankofamerica.com <http://bankofamerica.com> > <http://bankofamerica.com> > >> > < http://bankofamerica.com> > >> > > < http://bankofamerica.com> < > >> > > > http://bankofamerica.com > <http://bankofamerica.com>> does not use an alt-name. > >> > > > > What's the point? (And for those of us who aren't > >> > using IE7, I'm > >> > > > > assuming you just get a common name mismatch > >> error, or > >> > > what?) if eBay > >> > > > > uses it, then I think you need to be worried > about > >> > breaking it. > >> > > > > > >> > > > > On 10/11/07, *Close, Tyler J.* > <tyler.close@hp.com <mailto:tyler.close@hp.com> > >> > <mailto: tyler.close@hp.com <mailto:tyler.close@hp.com>> > >> > > <mailto:tyler.close@hp.com > <mailto:tyler.close@hp.com> <mailto:tyler.close@hp.com > <mailto:tyler.close@hp.com>>> > >> > > > <mailto: tyler.close@hp.com > <mailto:tyler.close@hp.com> > >> <mailto:tyler.close@hp.com <mailto:tyler.close@hp.com>> > >> > <mailto:tyler.close@hp.com <mailto:tyler.close@hp.com> > <mailto: tyler.close@hp.com <mailto:tyler.close@hp.com>>>> > >> > > > > <mailto: tyler.close@hp.com > <mailto:tyler.close@hp.com> > >> > <mailto: tyler.close@hp.com <mailto:tyler.close@hp.com>> > <mailto:tyler.close@hp.com <mailto:tyler.close@hp.com> > >> > <mailto:tyler.close@hp.com <mailto:tyler.close@hp.com> >> > >> > > <mailto: tyler.close@hp.com > <mailto:tyler.close@hp.com> <mailto:tyler.close@hp.com > <mailto:tyler.close@hp.com>> > >> > <mailto: tyler.close@hp.com <mailto:tyler.close@hp.com> > <mailto: tyler.close@hp.com <mailto:tyler.close@hp.com>>>>>> > >> wrote: > >> > > > > > >> > > > > Perhaps there's some way to finesse this > >> part of the > >> > > algorithm by > >> > > > > reference to RFC 2818. I'll work on it. > >> > > > > > >> > > > > Many sites don't seem to be using this cert > >> > feature. For > >> > > a fun > >> > > > > example, visit the following URL using IE7. > >> > > > > > >> > > > > https://bankofamerica.com/ > >> > > > > > >> > > > > --Tyler > >> > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > ---------------------------------------------------------------------- > >> -- > >> > > > > >> > > > > *From:* Ian Fette > >> [mailto:ifette@google.com <mailto:ifette@google.com> > >> > <mailto:ifette@google.com <mailto:ifette@google.com>> > >> > > <mailto: ifette@google.com <mailto:ifette@google.com> > <mailto:ifette@google.com <mailto:ifette@google.com>>> > >> > > > <mailto:ifette@google.com > <mailto:ifette@google.com> <mailto: ifette@google.com > <mailto:ifette@google.com>> > >> > <mailto:ifette@google.com <mailto:ifette@google.com> > <mailto:ifette@google.com <mailto:ifette@google.com> >>> > >> > > > > <mailto: ifette@google.com > <mailto:ifette@google.com> > >> > <mailto:ifette@google.com <mailto:ifette@google.com>> > <mailto: ifette@google.com <mailto:ifette@google.com> > >> > <mailto:ifette@google.com <mailto:ifette@google.com>>> > >> > > <mailto: ifette@google.com <mailto:ifette@google.com> > <mailto: ifette@google.com <mailto:ifette@google.com>> > >> > <mailto:ifette@google.com <mailto:ifette@google.com> > <mailto:ifette@google.com <mailto:ifette@google.com>>>>>] > >> > > > > *Sent:* Thursday, October 11, 2007 > >> 12:48 PM > >> > > > > *To:* Close, Tyler J. > >> > > > > *Cc:* public-wsc-wg@w3.org > <mailto:public-wsc-wg@w3.org> > >> > <mailto: public-wsc-wg@w3.org <mailto:public-wsc-wg@w3.org>> > >> > > <mailto:public-wsc-wg@w3.org > <mailto:public-wsc-wg@w3.org> <mailto:public-wsc- <mailto:public-wsc-> > >> wg@w3.org <mailto:wg@w3.org>>> > >> > <mailto: public-wsc-wg@w3.org <mailto:public-wsc-wg@w3.org> > <mailto:public-wsc-wg@w3.org <mailto:public-wsc-wg@w3.org>> > >> > > <mailto:public-wsc-wg@w3.org > <mailto:public-wsc-wg@w3.org> <mailto:public-wsc- <mailto:public-wsc-> > >> wg@w3.org <mailto:wg@w3.org> >>> > >> > > > <mailto:public-wsc-wg@w3.org > <mailto:public-wsc-wg@w3.org> > >> > <mailto: public-wsc-wg@w3.org <mailto:public-wsc-wg@w3.org> > > <mailto: public-wsc-wg@w3.org <mailto:public-wsc-wg@w3.org> > >> > <mailto:public-wsc-wg@w3.org <mailto:public-wsc-wg@w3.org>>> > >> > > <mailto: public-wsc-wg@w3.org > <mailto:public-wsc-wg@w3.org> <mailto:public-wsc- <mailto:public-wsc-> > >> wg@w3.org <mailto:wg@w3.org>> > >> > <mailto: public-wsc-wg@w3.org <mailto:public-wsc-wg@w3.org> > <mailto:public-wsc-wg@w3.org <mailto:public-wsc-wg@w3.org>>>>> > >> > > > > *Subject:* Re: clarifications needed re > >> safe form > >> > > editor cert > >> > > > > matching algorithm > >> > > > > > >> > > > > It is in huge use. For example. if you > >> go to > >> > > > > https://signin.ebay.com and look at the > >> cert - > >> > the CN is > >> > > > > signin.ebay.com > <http://signin.ebay.com> < http:// > >> signin.ebay.com <http://signin.ebay.com>> < > >> > http://signin.ebay.com> < > >> > > http://signin.ebay.com> > >> > > > < http://signin.ebay.com <http:// > >> signin.ebay.com <http://signin.ebay.com>>> but > >> > the certificate > >> > > > > subject alt name lists: > >> > > > > > >> > > > > Not Critical > >> > > > > DNS Name: signin.cafr.ebay.ca > <http://signin.cafr.ebay.ca> > >> > < http://signin.cafr.ebay.ca> > >> > > <http://signin.cafr.ebay.ca> > <http://signin.cafr.ebay.ca > > >> > > > < http://signin.cafr.ebay.ca> > >> > > > > DNS Name: signin.ebay.ca > <http://signin.ebay.ca> > >> > <http://signin.ebay.ca> <http://signin.ebay.ca> > >> > > < http://signin.ebay.ca > > >> > > > < http://signin.ebay.ca> > >> > > > > DNS Name: signin.ebay.com.au > <http://signin.ebay.com.au> > >> > < http://signin.ebay.com.au> > >> > > <http://signin.ebay.com.au> < http://signin.ebay.com.au > > >> > > > < http://signin.ebay.com.au <http:// > >> signin.ebay.com.au <http://signin.ebay.com.au>> > >> > < http://signin.ebay.com.au>> > >> > > > > DNS Name: signin.ebay.com.cn > <http://signin.ebay.com.cn> > >> > <http://signin.ebay.com.cn > > >> > > < http://signin.ebay.com.cn> < http://signin.ebay.com.cn> > >> > > > < http://signin.ebay.com.cn> > >> > > > > DNS Name: signin.express.ebay.com > <http://signin.express.ebay.com> > >> > <http://signin.express.ebay.com > > >> > > < http://signin.express.ebay.com> > >> > > > < http://signin.express.ebay.com > > >> > < http://signin.express.ebay.com> > >> > > > > DNS Name: signin.half.ebay.com > <http://signin.half.ebay.com> > >> > < http://signin.half.ebay.com> > >> > > <http://signin.half.ebay.com> > >> > > > < http://signin.half.ebay.com> < http:// > >> signin.half.ebay.com <http://signin.half.ebay.com>> > >> > > > > DNS Name: > signin.liveauctions.ebay.com <http://signin.liveauctions.ebay.com> > >> > <http://signin.liveauctions.ebay.com> > >> > > < http://signin.liveauctions.ebay.com > > >> > > > <http://signin.liveauctions.ebay.com> > >> > > > > < http://signin.liveauctions.ebay.com > >> > > > <http://signin.liveauctions.ebay.com>> > >> > > > > DNS Name: signin.shopping.ebay.com > <http://signin.shopping.ebay.com> > >> > <http://signin.shopping.ebay.com > <http://signin.shopping.ebay.com>> > >> > > < http://signin.shopping.ebay.com> > >> > > > <http://signin.shopping.ebay.com > <http://signin.shopping.ebay.com> > >> > <http://signin.shopping.ebay.com >> > >> > > <http://signin.shopping.ebay.com > <http://signin.shopping.ebay.com>> > >> > > > > DNS Name: signin.tw.ebay.com > <http://signin.tw.ebay.com> > >> > <http://signin.tw.ebay.com> > >> > > < http://signin.tw.ebay.com> < http://signin.tw.ebay.com> > >> > > > < http://signin.tw.ebay.com <http:// > >> signin.tw.ebay.com <http://signin.tw.ebay.com>>> > >> > > > > DNS Name: signin.ebay.com > <http://signin.ebay.com> > >> > <http://signin.ebay.com> <http://signin.ebay.com> > >> > > < http://signin.ebay.com> > >> > > > <http://signin.ebay.com <http://signin.ebay.com > > >> > > < http://signin.ebay.com>> > >> > > > > > >> > > > > and if you go to > https://signin.ebay.de <https://signin.ebay.de> > >> you again > >> > > get a cert > >> > > > > with CN= signin.ebay.com > <http://signin.ebay.com> > >> > < http://signin.ebay.com> <http://signin.ebay.com> > >> > > <http://signin.ebay.com> < > >> > > > http://signin.ebay.com> but alt names of: > >> > > > > Not Critical > >> > > > > DNS Name: signin.befr.ebay.be > <http://signin.befr.ebay.be> > >> > <http://signin.befr.ebay.be> > >> > > <http://signin.befr.ebay.be > < > http://signin.befr.ebay.be> > >> > > > < http://signin.befr.ebay.be <http:// > >> signin.befr.ebay.be <http://signin.befr.ebay.be>>> > >> > > > > DNS Name: signin.benl.ebay.be > <http://signin.benl.ebay.be> > >> > <http://signin.benl.ebay.be <http://signin.benl.ebay.be>> > >> > > < http://signin.benl.ebay.be> > <http://signin.benl.ebay.be> > >> > > > < http://signin.benl.ebay.be <http:// > >> signin.benl.ebay.be <http://signin.benl.ebay.be>>> > >> > > > > DNS Name: signin.ebay.at > <http://signin.ebay.at> > >> > < http://signin.ebay.at> <http://signin.ebay.at> > >> > > < http://signin.ebay.at <http://signin.ebay.at >> > >> > > > <http://signin.ebay.at <http://signin.ebay.at>> > >> > > > > DNS Name: signin.ebay.be > <http://signin.ebay.be> > >> > < http://signin.ebay.be> < http://signin.ebay.be> > >> > > <http://signin.ebay.be> > >> > > > < http://signin.ebay.be <http://signin.ebay.be> > > >> > > > > DNS Name: signin.ebay.co.uk > <http://signin.ebay.co.uk> > >> > < http://signin.ebay.co.uk> > >> > > <http://signin.ebay.co.uk> <http://signin.ebay.co.uk> > >> > > > < http://signin.ebay.co.uk> > >> > > > > DNS Name: signin.ebay.de > <http://signin.ebay.de> > >> > <http://signin.ebay.de <http://signin.ebay.de> > > <http://signin.ebay.de > > >> > > <http://signin.ebay.de> > >> > > > < http://signin.ebay.de> > >> > > > > DNS Name: signin.ebay.es > <http://signin.ebay.es> > >> > <http://signin.ebay.es <http://signin.ebay.es>> < > http://signin.ebay.es> > >> > > <http://signin.ebay.es> > >> > > > < http://signin.ebay.es < http://signin.ebay.es>> > >> > > > > DNS Name: signin.ebay.fr > <http://signin.ebay.fr> > >> > < http://signin.ebay.fr> < http://signin.ebay.fr> > >> > > <http://signin.ebay.fr < http://signin.ebay.fr>> > >> > > > < http://signin.ebay.fr> > >> > > > > DNS Name: signin.ebay.ie > <http://signin.ebay.ie> > >> > <http://signin.ebay.ie> < http://signin.ebay.ie> > >> > > < http://signin.ebay.ie> < > >> > > > http://signin.ebay.ie> > >> > > > > DNS Name: signin.ebay.nl > <http://signin.ebay.nl> > >> > <http://signin.ebay.nl> <http://signin.ebay.nl> > >> > > < http://signin.ebay.nl> > >> > > > < http://signin.ebay.nl> > >> > > > > DNS Name: signin.express.ebay.co.uk > <http://signin.express.ebay.co.uk> > >> > <http://signin.express.ebay.co.uk> > >> > > < http://signin.express.ebay.co.uk > >> > <http://signin.express.ebay.co.uk>> > >> > > > < http://signin.express.ebay.co.uk > > >> > > > > <http://signin.express.ebay.co.uk > >> > < http://signin.express.ebay.co.uk > > >> > > <http://signin.express.ebay.co.uk>> > >> > > > > DNS Name: signin.ebay.com > <http://signin.ebay.com> > >> > <http://signin.ebay.com> < http://signin.ebay.com> > >> > > < http://signin.ebay.com > < > >> > > > http://signin.ebay.com < http://signin.ebay.com > <http://signin.ebay.com>>> > >> > > > > > >> > > > > > >> > > > > So yeah, it's important. > >> > > > > On 10/11/07, *Close, Tyler J.* < > >> > tyler.close@hp.com <mailto:tyler.close@hp.com> > <mailto:tyler.close@hp.com <mailto:tyler.close@hp.com>> > >> > > <mailto: tyler.close@hp.com > <mailto:tyler.close@hp.com> <mailto:tyler.close@hp.com > <mailto:tyler.close@hp.com> >> > >> > > > <mailto: tyler.close@hp.com > <mailto:tyler.close@hp.com> > >> <mailto: tyler.close@hp.com <mailto:tyler.close@hp.com>> > >> > <mailto: tyler.close@hp.com <mailto:tyler.close@hp.com> > <mailto:tyler.close@hp.com <mailto:tyler.close@hp.com> >>> > >> > > > > <mailto: tyler.close@hp.com > <mailto:tyler.close@hp.com> > >> > <mailto:tyler.close@hp.com <mailto:tyler.close@hp.com>> > >> > > <mailto:tyler.close@hp.com > <mailto:tyler.close@hp.com> <mailto: tyler.close@hp.com > <mailto:tyler.close@hp.com>>> > >> > <mailto: tyler.close@hp.com <mailto:tyler.close@hp.com> > <mailto:tyler.close@hp.com <mailto:tyler.close@hp.com>> > >> > > <mailto: tyler.close@hp.com <mailto:tyler.close@hp.com> > >> <mailto:tyler.close@hp.com <mailto:tyler.close@hp.com>>>>>> > >> > > > wrote: > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > Thomas Roessler wrote: > >> > > > > > going through the matching > >> algorithm while > >> > > folding > >> > > > it in... > >> > > > > > > >> > > > > > - The current language confuses > >> > attributes and > >> > > > fields. I > >> > > > > suspect > >> > > > > > that you mean the various > >> attributes > >> > of the > >> > > Subject > >> > > > > certificate > >> > > > > > field. Please confirm. > >> > > > > > >> > > > > The CN, O, L, ST and C values I > >> refer to > >> > are the > >> > > ones > >> > > > in the set > >> > > > > referred to by the Subject field in > >> the > >> > end entity > >> > > > > certificate. Not sure > >> > > > > how to be any more specific about > >> this in > >> > PKIXese. > >> > > > > > >> > > > > > - I notice that you have some > >> rules that > >> > concern > >> > > > matching > >> > > > > the CN > >> > > > > > attribute, but none concerning > >> > > > subjectAltName. I'm happy to > >> > > > > > simply track this point as an > >> issue. > >> > > > > > >> > > > > Could you point me to a document > >> covering the > >> > > semantics of > >> > > > > subjectAltName? Is it in use in X. > >> 509 certs on > >> > > the Web? > >> > > > > > >> > > > > > Also, I'll open an issue to track > >> the "PKI > >> > > orthodoxy" > >> > > > > remarks that > >> > > > > > Hal had made at the face-to-face, > >> and will > >> > > link to that > >> > > > > issue from > >> > > > > > the draft. > >> > > > > > >> > > > > Thanks, > >> > > > > --Tyler > >> > > > > > >> > > > > > >> > > > > > >> > > > > >> > > > -- > >> > > > /* > >> > > > Serge Egelman > >> > > > > >> > > > PhD Candidate > >> > > > Vice President for External Affairs, Graduate > >> Student > >> > Assembly > >> > > > Carnegie Mellon University > >> > > > > >> > > > Legislative Concerns Chair > >> > > > National Association of Graduate-Professional > >> Students > >> > > > */ > >> > > > > >> > > > > >> > > > >> > > -- > >> > > /* > >> > > Serge Egelman > >> > > > >> > > PhD Candidate > >> > > Vice President for External Affairs, Graduate Student > >> Assembly > >> > > Carnegie Mellon University > >> > > > >> > > Legislative Concerns Chair > >> > > National Association of Graduate-Professional Students > >> > > */ > >> > > > >> > > > >> > > >> > -- > >> > /* > >> > Serge Egelman > >> > > >> > PhD Candidate > >> > Vice President for External Affairs, Graduate Student Assembly > >> > Carnegie Mellon University > >> > > >> > Legislative Concerns Chair > >> > National Association of Graduate-Professional Students > >> > */ > >> > > >> > > >> > >> -- > >> /* > >> Serge Egelman > >> > >> PhD Candidate > >> Vice President for External Affairs, Graduate Student Assembly > >> Carnegie Mellon University > >> > >> Legislative Concerns Chair > >> National Association of Graduate-Professional Students > >> */ > >> > > > > --- > > Johnathan Nightingale > > Human Shield > > johnath@mozilla.com <mailto:johnath@mozilla.com> > > > > > > > > > > -- > Sincerely, > Yngve N. Pettersen > ******************************************************************** > Senior Developer Email: > yngve@opera.com <mailto:yngve@opera.com> > Opera Software ASA http://www.opera.com/ > Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 > ******************************************************************** > > -- /* Serge Egelman PhD Candidate Vice President for External Affairs, Graduate Student Assembly Carnegie Mellon University Legislative Concerns Chair National Association of Graduate-Professional Students */
Received on Friday, 12 October 2007 16:19:35 UTC