Frank Hecker wrote, On 2008-10-02 14:43:
> In accordance with the schedule at
> 
>    https://wiki.mozilla.org/CA:Schedule
> 
> I am now opening the first public discussion period for a request from 
> Microtec Ltd to add the Microsec e-Szigno Root CA root certificate to 
> Mozilla. This is bug 370505, and Kathleen has produced an information 
> document attached to the bug.

Speaking only for myself ... several things about this application
bother me. At least one of them is not entirely clear.  The statements
below reflect my understanding after reading their statements in bug
370505, and also bug 277797.

1. OCSP issues -

a) Their OCSP service reportedly does not conform to the IETF RFCS.  The
OCSP responder certs are neither
  i) the CA cert of the issuer of the cert under test, nor
  ii) a cert issued by the issuer of the cert under test.
This means that any OCSP response obtained from their responder will
be deemed invalid, with an illegitimate signer.

b) They explain that OCSP service is an extra cost service for
relying parties.

I wonder: do all their certs have AIA extensions with OCSP URLs?
What sort of OCSP response do non-paying relying parties receive?

I won't go so far as to insist that CAs use OCSP, but I think it is very
reasonable to insist that CAs who issue certs with OCSP URLs in AIA
extensions MUST make those OCSP responses conform to the RFCs, and work
correctly for Mozilla users.

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.  :(

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

Reply via email to