On Monday 06 October 2008 08:53:01 Rob Stradling wrote: <snip> > IINM, FF3 by default has the "When an OCSP connection fails, treat the > certificate as invalid" tickbox set to *disabled*, meaning that most users > won't see browser warnings. Therefore, IMHO, if Microsec don't think it's a > problem, then it's not a problem.
Then, on Monday 06 October 2008 11:01:19 Nelson B Bolyard wrote: <snip> > Some of us hope someday soon to treat certs for which we receive > invalid OCSP responses (as opposed to NO OCSP responses) as revoked. > If we have admitted CAs that are known to produce certs that will not > work in that case, I think that becomes a strong disincentive to ever > institute that stronger interpretation of invalid responses. :( In that case Nelson, I withdraw my "...if Microsec don't think it's a problem, then it's not a problem" statement. > 2. Incentives to be accurate - > > They have different financial liability limits for each class of cert > that they issue, and according to comment 10 in that bug, for one of their > classes (class2 non-qualified certificates), that limit is ZERO. > > For their qualified certs, they include an extension that reports the > limit of their liability, as an integer number of Hungarian Forints (HUF). > (Tell me, do you know how much money 100K HUF is? Does is surprise you > to learn that 1 HUF is about half a penny? 100K HUF is ~500 USD.) > Browsers do not show this information to users. Hungarian representatives > have requested that Mozilla browsers should do so. See bug 277797. > Even if browsers did show this information, users are not likely to know > the value of the monetary units of various European nations. > > They do not claim to include this information in non-qualified certs. > Apparently the absence of an explicit liability limit should be understood > to mean no liability. > > Any cert for which the issuer has no liability is a cert for which the > issuer has no incentive to be accurate. If a CA has no liability for > doing so, what stops it for issuing lots of certs for paypal.com? > I would advise Mozilla against trusting certs from a CA that disclaims > liability for the information in any of its cert classes. > > 3. Inclusion of unrecognized critical certificate extensions > > When bug 277797 was filed, it was claimed that Hungarian law required > Hungarian CAs to include in their qualified certificates a certain > extension, marked critical, that is relatively unknown. This meant that > those certificates were rejected by Mozilla software, because Mozilla > software complies with the IETF RFC that requires relying party software > to reject certs with critical extensions that it does not completely > understand and honor. > > IMO, Mozilla definitely should not add a root CA cert for a CA whose > certs will be rejected for that reason. > > Hungary has legislated much of this. Perhaps their legislators thought > they could pressure the browsers and other software for relying parties > into displaying this liability limit information. > > In summary, although they may be able to claim that they are in conformance > with Hungarian law, given these other issues, I'm not convinced this is > really a service of value to typical Mozilla product users. That's my > opinion. > _______________________________________________ > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto -- Rob Stradling Senior Research & Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
