Microtec CA inclusion request

23 views
Skip to first unread message

Frank Hecker

unread,
Oct 2, 2008, 5:43:02 PM10/2/08
to
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.

https://bugzilla.mozilla.org/show_bug.cgi?id=370505

There's a summary of the information also available at

http://www.mozilla.org/projects/security/certs/pending/#Microsec

Some points worth mentioning about this request:

* This CA is based in Hungary. Though it provides a lot of information
in English (including a helpful CA hierarchy diagram) unfortunately all
of its CPS documents are currently available in Hungarian only. Microsec
has provided translations of the relevant sections in the bug comments,
as well as other background information. I've asked Andr�s T�m�r [1] of
the Hungarian localization team to double-check the translations; for
now I'm assuming the translations are accurate absent any information to
the contrary.

* Though a commercial CA, Microsec is audited by an agency of the
Hungarian government. (This appears to be a fairly common practice in
Europe, especially for CAs issuing so-called "qualified" certificates,
as Microsec does.) The audit is against ETSI TS 101 456 and 102 042 and
is annual. Kathleen has verified the relevant information with a
government representative.

* Microsec has a separate root used for OCSP, and apparently does not
offer OCSP as a general public service; please see the comments in the
bug. I'd like those of you who are OCSP experts to look at this issue
and tell us if you see any potential problems there.

This first public comment period will be for one week, and then I'll
make a preliminary determination regarding this request.

Frank

[1] Fun fact: Within Hungary names are normally given in "Eastern order"
(i.e., like China or Japan) with surname first. In this case I've
transposed to Western order (I think).

--
Frank Hecker
hec...@mozillafoundation.org

Frank Hecker

unread,
Oct 2, 2008, 5:44:45 PM10/2/08
to
Frank Hecker wrote:
> 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

D'oh! It's "Microsec", *not* "Microtec". I got it right everywhere
except for the subject line and the first sentence. Sigh...

Frank


--
Frank Hecker
hec...@mozillafoundation.org

Eddy Nigg

unread,
Oct 4, 2008, 7:54:10 AM10/4/08
to
On 10/03/2008 12:43 AM, Frank Hecker:

> * This CA is based in Hungary. Though it provides a lot of information
> in English (including a helpful CA hierarchy diagram) unfortunately all
> of its CPS documents are currently available in Hungarian only.

Frank, I think we should buy some tool that helps us with translating
such stuff. Apparently Google doesn't support Hungarian -> English yet,
but I searched and found some useful tools on the net which can do that.
Please get something that can translate the CP/CPS and publish it
somewhere so we can read about it.

Additionally I went to http://srv.e-szigno.hu/ and after accepting the
security exception when browsing to
https://srv.e-szigno.hu:4444/cgi-bin/editugyvedcsv.cgi I received first
received ssl_error_handshake_failure_alert. I realized that I have to
add their CA root, so I did that, but then I got
sec_error_ocsp_malformed_request. The default settings of FF3 is to use
OCSP and as you mentioned, this isn't going to work (as you mentioned
already).

Can you have a look into both issues above? I really would like to read
the CP/CPS and a translation tool for a few bucks would help...


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org

Rob Stradling

unread,
Oct 6, 2008, 3:53:01 AM10/6/08
to dev-tec...@lists.mozilla.org
On Thursday 02 October 2008 22:43:02 Frank Hecker wrote:
<snip>

> * Microsec has a separate root used for OCSP, and apparently does not
> offer OCSP as a general public service; please see the comments in the
> bug. I'd like those of you who are OCSP experts to look at this issue
> and tell us if you see any potential problems there.

Comment #3 in that bug indicates that they're not expecting Mozilla to
support "OCSP under a separate root".

When Microsec be include their OCSP Responder URL in an end-entity
certificates that they issue, FF3 will by default attempt to check the
certificate's status via OCSP. This OCSP check will of course fail, because:
i) the OCSP signer certificate does not chain up to a trusted Root, and...
ii) RFC2560 section 4.2.2.2 (and therefore FF3, I presume) insists that "a
certificate's issuer MUST either sign the OCSP responses itself or it MUST
explicitly designate this authority to another entity", and this condition is
not met.

On Saturday 04 October 2008 12:54:10 Eddy Nigg wrote:
> The default settings of FF3 is to use OCSP and as you mentioned, this isn't
> going to work (as you mentioned already).

Yes and no. 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.
(The other effect of a failed OCSP lookup in FF3 is that an EV cert will lose
its EV status, but I don't believe that Microsec are an EV certificate issuer
at present).

On a related note...
It might interest you to know that the Microsoft CryptoAPI does support "OCSP
under a separate root" in Windows XP and Vista. I recently asked our contact
at Microsoft to explain to me why this RFC2560-non-compliant feature exists.
He said:
"The feature to allow OCSP responses to be signed by a certificate under a
different root was added for customers with branch networks that cannot
connect to the CA's revocation repository, either because the customer do not
want to allow those machines to connect to the Internet directly, the
connection has limited bandwidth, or the branch network is physically
disconnected for extended periods (such as those on a ship)."

> This first public comment period will be for one week, and then I'll
> make a preliminary determination regarding this request.
>
> Frank
>
> [1] Fun fact: Within Hungary names are normally given in "Eastern order"
> (i.e., like China or Japan) with surname first. In this case I've
> transposed to Western order (I think).

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

Nelson B Bolyard

unread,
Oct 6, 2008, 6:01:19 AM10/6/08
to mozilla's crypto code discussion list
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.

Rob Stradling

unread,
Oct 6, 2008, 6:53:53 AM10/6/08
to dev-tec...@lists.mozilla.org
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.

> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto

Ian G

unread,
Oct 6, 2008, 9:03:48 AM10/6/08
to mozilla's crypto code discussion list
Nelson B Bolyard wrote:
> Frank Hecker wrote, On 2008-10-02 14:43:
>> In accordance with the schedule at
>>
>> https://wiki.mozilla.org/CA:Schedule


Hi Nelson, Hi Frank,

Having read the EU directive at length, here are some perspectives.
I have not looked at the CA's request in question.

(I think I agree with the logic expressed on OCSP, but not really my
cup of tea.)


> 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.)


Yup, this is a known criticism of the EU's concept. It should
disappear somewhat when/if Hungary adopts the euro.

(Yes, this doesn't solve the real problem of how much a Euro is
worth, but it can be ignored for now, as there are more important
things to worry about. If you are fussed at it, ask them whether
they can just change over to including a Euro number.)


> Browsers do not show this information to users. Hungarian representatives
> have requested that Mozilla browsers should do so. See bug 277797.


This is the bigger issue, yes. Browsers should show more
information, as otherwise, the certificate must logically be
considered to be valueless (see below). In which case, what is the
point?

The really big question is "what should be shown?"

Europe, for its part, has said it should be the monetary limit on
liabilities. I also think that is a bad idea [1] ... but for now,
this is what Europe has said, for qualified certs.


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


Correct. This should be the standard default of all
certificate-based presentation. If there is nothing presented to
the user, then there are only two possible interpretations available
for the user: that of unlimited liability, and that of zero liability.

All numbers inbetween require to be explained. As they are not
presented to the user, nor covered anywhere else in an
easy-to-understand fashion [2], and as nobody offers unlimited
liability, the only logical conclusion is zero liability.

If anyone is telling the users anything else, then they had better
be prepared to back up that claim in court [3] !


> Any cert for which the issuer has no liability is a cert for which the
> issuer has no incentive to be accurate.


That's overly broad. Firstly, there are other checks & balances:
reputation, audit, mozo-post-audit, sales, the monitoring of people
found on this group, laws, regs and customs in the countries, all
these things provide incentives.

Secondly, the claim of "no liability" is made to the wider public,
generally. The admissions of liability to other "insiders" like
subscribers or under other laws has the effect of providing an
incentive to accuracy that is enjoyed by everyone. That is, it is
not possible to have a cert that is "accurate to paying subscribers
but inaccurate to others...."

(Think of it like SB1386, the california breach notification law
that only applies in California. When push came to shove, in
_Choicepoint_, it magically also applied to all the other states ....)

Thirdly, they don't have a choice. If they didn't generally
disclaim liability, they would be in trouble, one way or another.

Fourthly, the issue of CAs' liability under any form has not to my
knowledge ever been tested in court. This means that we cannot
assert anything with confidence about the positive value of a
liability claim (which in effect means the likely value is zero).


> If a CA has no liability for
> doing so, what stops it for issuing lots of certs for paypal.com?


As above!


> I would advise Mozilla against trusting certs from a CA that disclaims
> liability for the information in any of its cert classes.


My reading of the CA industry is that CAs routinely limit the
_effective liability_ to zero [4]. This is done by a series of
legal tricks, all of which work together to reduce any stated
liability down to an effective number of zero [5].

Although we may find this uncomfortable, I would suggest that zero
liability is the default. The starting position, the reality.

The question is then, not whether this is bad and should not be
accepted, but whether the CA then goes on to offer something of
general use to the browser users. (This is explicit in the mozo
policy, for this very reason.)

Indeed, I would go so far as to suggest that Mozilla should consider
as a criteria that every CA has a limitation of liability to all
Mozilla users (e.g., the general public). And that the number
should be strongly recommended by Mozilla to be zero, or there is a
serious audit requirement to show how this number can be met. To
not set general liability to zero begs the question of just how we
differentiate this amount from fantasy, and as it is a legally
significant claim, and one that is intended to be believed by
Mozilla users, it should be seriously checked.

And, I would suggest that Mozilla do the same, by limiting its own
liability to zero (and, it appears, thankfully, that Mozilla is
doing exactly that in the new terms & conditions for Firefox).


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


This is the EU directive, which is implemented in law in most
states. Consider a directive to be similar level to federal US law.
The difference is that in Europe, first the "federal body" writes
the directive (as a committee of states' representatives), then the
states write the compatible law, following the directive.

So, from the EU directive (at least one old copy):

==================
5. Member States shall ensure that notwithstanding paragraph 1, a
certification service provider may, *in the qualified certificate*,
limit the value of transactions for which the certificate is valid.
The certification service provider shall not be held liable for
damages in excess of that value limit.
==================

(my emphasis) Now, bearing in mind that the whole digital signing
thing in Europe is *complex*, we can suggest that *if* an issuer
wishes to put in a monetary limit of liability, it *must* put that
limit in the certificate. If it does not, then likely it has
unlimited liability (within other restrictions), because it is
explicitly offered the option to disclaim in the law.

Now, no issuer nor business in its right mind accepts unlimited
liability [6]. So some number must be put in. So, I for one would
concur with their claim that they must put that number in by law.

This raises several conundrums:

1. for users, they will inspect the cert (to the extent that they
can) and will see either nothing or a number. This might be a good
number (they can sue) or it might be a suspect number (other legal
tools reduce the effective liability to zero). That will not be
showable in the cert, IMO, so it raises the issue of how we show
whether the number is effective or not.

2. if the users don't see the number, and the number is strong in
law (as it most surely is because of the directive) then they are
not being given the information they need to understand the cert,
and are thus having their rights interfered by. It would be an
extraordinary step for software to hide the number by policy ... as
opposed to technical difficulties.

3. for CAs, there should be a convention on where to put this
number. Which field in x.509? E.g., you could just simply knock up
a certificatePolicies variant that stated the number, with an OID,
mark it critical (?) unless the Europeans have already figured it out.

4. For software developers, as the number has legal significance,
there should be a convention as to how to show this value. It
should be shown when available, and easily so. I would suggest this
puts it in the "first click" display. Which means, adding that
field to the current O/CN/OU set, and show it in Tbird if it is present.

5. There then needs to be an agreement of what number should be
proposed to the user in the absence of a proper cert claim.
Obviously, I'm proposing that should be zero, but let's hear what
others think as a number.


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

I would suggest that we think in terms of the EU directive, not
Hungary. The requirements for qualified certs covers some 30 or so
countries in Europe. Although we may not like it [1], the law has
been passed in most countries in Europe, and qualified certificates
are pushed by a few governments [7] to the extent that various
ordinary documents *must* be signed by qualified certificates, or
you lose your money [8].

So, think about Europe, not Hungary. Do you want the software to be
accepted in Europe? Are Europeans of typical value to Mozilla?
Bearing in mind that (by law/directive) any European can be a
relying party to a qualified certificate!

An analogue is to also think in terms of security profiles. EV is a
security profile for mostly North American websites. Then, we can
think of the EU directive and the "qualified certificates" as a
profile for mostly European communications / p2b and b2b business.

(Also bear in mind that qualified certs are intended to be client
signing certs, so this is more an issue for Thunderbird than
Firefox. This may significantly help the implementation and legal
questions.)


iang

[1] Don't get me started on what is disastrous about the EU directive ;)

[2] Yes, I exclude the CPS from "easy to understand." Consider a
judge who thinks in terms of consumer rights, and strikes down a
contract that deliberately seeks to obfuscate what is going on.

[3] Has Mozilla's general counsel been asked for an opinion on this?

[4] I use the term _effective liability_ as like the term _expected
liability_ from the financial world, as distinct from the monetary
number posted as a headline somewhere. That is, after calculating
the probabilities and the reduction effects of various tools, one
can arrive at an estimate of how much real liability will come from
business. The general strategy of the CA is to set the expected
liability to zero, for various good business reasons.

[5] There are a few motives for this. One can be found in some
simple mathematics: Calculate the amount of phishing losses, and
imagine a class action suit in California court that declared that
the failure of the site authentication was to be pinned on the CA,
pro rata with the number of clients. It's a big number. So the
only sensible thing from the maths pov is to disclaim liability to
the general public to the extent possible.

[6] These days! In the good old days, reliable banking was built on
the concept of unlimited liability, and it showed the best and most
stable banking. Only these days with the apparent musical chairs
system of liabilities is banking a suspect concept.

[7] Not all; some countries disagree with the concept, but some
significant countries push it enough to make it serious.

[8] Germany and other countries intend that VAT declarations
(similar to US sales tax) have to be signed by qualified certs, or
you will lose your VAT value. It's a ticking timebomb, it's the
nuclear option.

István Zsolt BERTA

unread,
Oct 6, 2008, 9:54:45 AM10/6/08
to
Dear All,

Let me reflect to some of the above points.

First of all, our public website is www.e-szigno.hu.
The webpage at https://srv.e-szigno.hu:4444/cgi-bin/editugyvedcsv.cgi
is a restricted page, it requires a client-side SSL certificate (with
certain values in the subject DN), so you should not be able to access
it.

I do not know of any (useful) tool capable of translating from
Hungarian to English. Please let me know if you find one.

OCSP:
-----
According to section 2 of RFC 2560, there are three ways to operate an
OCSP responder:
"
All definitive response messages SHALL be digitally signed. The key
used to sign the response MUST belong to one of the following:

-- the CA who issued the certificate in question
-- a Trusted Responder whose public key is trusted by the requester
-- a CA Designated Responder (Authorized Responder) who holds a
specially marked certificate issued directly by the CA,
indicating
that the responder may issue OCSP responses for that CA
"

Later, in section 4.2.2.2 Authorized Responders, RFC 2560 gives more
requirements on using the third option, CA designated or authorized
responders. We do not use this third option.

We support the second option (Trusted Responder), where the requester
explicitly trusts the OCSP responder. (In our case the link of trust
is established by our CPS stating the the separate root can be trusted
for signing relevant OCSP responses.) I do not know of any statement
in RFC 2560 that requires the responder to be under the same root.

Based on the above, we consider our solution RFC 2560 conformant.

(We know of other similar solutions, e.g. openvalidation.org works
exactly this way.)

We had good reasons to choose this solution. According to Hungarian
regulations, a qualified CA is allowed to use its private key for the
following two purposes only:
* signing qualified end-user certificates and
* signing CRLs.
As neither 'signing OCSP responses', nor 'singing OCSP responder
certificates' is listed here, we were not allowed to support options 1
and 3 marked in RFC 2560, so only option 2 remained.

Our OCSP is used by our own customers for creating so-called 'archive
signatures' e.g. according to ETSI TS 101 903. (An archive signature
is timestamped and the necessary revocation information is also
attached to the signature. Certain signature policies require that the
revocation information needs to be issued _after_ the time of signing,
i.e. the point of time marked in the timestamp on the signature.)

We understand that our OCSP is not useful for the general public, so
we did not wish to include our OCSP root (and support for our OCSP) in
Mozilla.

If you consider that the OCSP URL in the AIA field poses a problem, we
can modify the profile of the SSL server certifictes so the AIA field
will not be included.


Unrecognized extensions:
------------------------
Our regulations require us to comply with European ETSI
specifications. Qualified certificates are one of the key concepts of
European PKI regulations and ETSI TS 101 862 defines the QCStatement
extension for marking a certificate to be qualified. According to ETSI
TS 101 862 this extension is mandatory.

This is not a Microsec-specific problem, it affects most of the other
European CAs who issue qualified certificates.

The QCStatement extension is *NOT* critical in our certificates.

Webserver and code signing certificates are generally non-qualified,
so they are not affected by this issue.


Liability:
----------
In our qualified certificates, the liability limit is included in the
certificate. The minimum value is ~5400 USD, the maximum value is ~1
million USD.

> They do not claim to include this information in non-qualified certs.

Our law does not allow us to do so.
We can include it in our CPS only.

> Apparently the absence of an explicit liability limit should be understood
> to mean no liability.

In our country this is exactly vice versa. If you do not state any
limit, your liability is unlimited. (This is a general and not a CA-
specific rule.)

In fact, the liability is unlimited anyway as you can limit it per
relying party only. If you limit your liability at $1, you may still
need to pay $1million for one million relying parties.

In case of class 3 non-qualified certificates this limit is ~$500.

> 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?

In fact, we agree that a CA should be responsible for certificates it
issues. Still, due to various reasons (mostly because other CAs limit
their liability to zero too), we need to offer class2 certificates
with zero liability too. Fortunately, we issue very few of these.

However, we refuse to issue webserver and code signing certificates as
class2, and we require them to be at least class3 (where the CP is
based on NCP or NCP+ and thus a face-to-face registration is used)
where our liability is non-zero.


> [1] Fun fact: Within Hungary names are normally given in "Eastern order"
> (i.e., like China or Japan) with surname first. In this case I've
> transposed to Western order (I think).

Sometimes we transpose our names ourselves, so that Western people can
figure out which one our first name is. Sometimes we meet people who
know that Hungarian names are written "the opposite" way, so they do
the transposition again.
Conclusion: in case of Hungarians you never know which the first name
and which the surname is. :)


Bye,

István

(this is my first name)

Eddy Nigg

unread,
Oct 6, 2008, 12:37:12 PM10/6/08
to
On 10/06/2008 03:54 PM, István Zsolt BERTA:

> We support the second option (Trusted Responder), where the requester
> explicitly trusts the OCSP responder. (In our case the link of trust
> is established by our CPS stating the the separate root can be trusted
> for signing relevant OCSP responses.) I do not know of any statement
> in RFC 2560 that requires the responder to be under the same root.
>
> Based on the above, we consider our solution RFC 2560 conformant.
>
> (We know of other similar solutions, e.g. openvalidation.org works
> exactly this way.)

openvalidation.org is to all of my knowledge kind of a proxy responder
which provides OCSP service for many different CAs (and acts like a
proxy). If I'd set the settings of Firefox to only trust your responder
it would maybe validate the certificates issued by your CA, but fail all
other CA issued certificates.

A trusted responder is to all of my knowledge not meant to be used by
CAs directly except in case of internal, corporate-wide CAs and OCSP
service. Or in the case of a proxy responder as mentioned above.

The correct way doing this for public CAs is via the AIA extensions IMO.
In your case it would invalid either your own or those of other CAs
issued certificates.

>
> We had good reasons to choose this solution. According to Hungarian
> regulations, a qualified CA is allowed to use its private key for the
> following two purposes only:
> * signing qualified end-user certificates and
> * signing CRLs.
> As neither 'signing OCSP responses', nor 'singing OCSP responder
> certificates' is listed here, we were not allowed to support options 1
> and 3 marked in RFC 2560, so only option 2 remained.

You are not allowed to issue intermediate CA certificates then? Are you
issuing directly from the CA root?

> Webserver and code signing certificates are generally non-qualified

What are the checks performed on code-signing certificates?

Eddy Nigg

unread,
Oct 6, 2008, 12:40:33 PM10/6/08
to

Nelson B Bolyard

unread,
Oct 6, 2008, 2:00:06 PM10/6/08
to mozilla's crypto code discussion list
István Zsolt BERTA wrote, On 2008-10-06 06:54:

> OCSP:
> -----
> According to section 2 of RFC 2560, there are three ways to operate an
> OCSP responder:
> "
> All definitive response messages SHALL be digitally signed. The key
> used to sign the response MUST belong to one of the following:
>
> -- the CA who issued the certificate in question
> -- a Trusted Responder whose public key is trusted by the requester
> -- a CA Designated Responder (Authorized Responder) who holds a
> specially marked certificate issued directly by the CA, indicating
> that the responder may issue OCSP responses for that CA
> "

> We support the second option (Trusted Responder), where the requester


> explicitly trusts the OCSP responder. (In our case the link of trust
> is established by our CPS stating the the separate root can be trusted
> for signing relevant OCSP responses.) I do not know of any statement
> in RFC 2560 that requires the responder to be under the same root.

A trusted responder is a responder CHOSEN BY THE RELYING PARTY. The model
is that the user chooses a single OCSP responder to which all of his OCSP
requests will be sent. Those OCSP requests may include information about
the OCSP URI that was present in the certificate under test, so that the
trusted responder may contact the issuer's responder for more information,
but the final response received by the requester MUST be signed by the
relying party's trusted responder.

This model is used in some corporations where the trusted responder sits on
a gateway/firewall system where it can be accessed by the users behind the
firewall, and will have access to the issuers' OCSP responders on the
internet. One reason to do this is to provide caching of OCSP responses.

Mozilla products have the configuration option (a preference) by which the
user can choose a single OCSP responder to which ALL of that user's OCSP
requests will be sent. There is no particular relationship required
between that responder and any issuer. The user must have a certificate
for that responder and must select it as being THE SOLE cert that the
client will trust for those OCSP responses.

> Based on the above, we consider our solution RFC 2560 conformant.

Now, if your OCSP responder is able to act as such a universal trusted
OCSP responder, and its cert is available for your customers to download
and trust for OCSP responses, then I would agree that *that responder*
could be said to be RFC conformant.

But if all your certs give AIA extensions that point to that responder,
so that all relying party software for users who have not chosen to trust
that responder as their delegated responder will still try to access that
responder, then that's a problem, because those other users will get a
response that they will be unable to prove comes from the issuer of the cert
under test.

I would not recommend that all Mozilla users should use a Hungarian
responder as their delegated OCSP responder. It may be fine for
Hungarian users (and any others who wish) to do so, but if only the users
who choose to do so (and to pay for the privilege) will have OCSP service
for the Hungarian certs, then I think the roots of the issuers of those
certs should only be trusted by the users who choose to do so. In other
words, the same users who choose to configure their browsers to trust a
Hungarian OCSP responder as their delegated OCSP responder could (and
should, IMO) also install and trust the associated root CA cert for the
certs that will cite that responder for OCSP requests.

> (We know of other similar solutions, e.g. openvalidation.org works
> exactly this way.)

Users choose to trust that organization's responder as their universal
delegated responder, IINM, irrespective of the OCSP URI in the cert
under test.

> We had good reasons to choose this solution. According to Hungarian
> regulations, a qualified CA is allowed to use its private key for the
> following two purposes only:
> * signing qualified end-user certificates and
> * signing CRLs.
> As neither 'signing OCSP responses', nor 'singing OCSP responder
> certificates' is listed here, we were not allowed to support options 1
> and 3 marked in RFC 2560, so only option 2 remained.

According to Indiana legislation, at one time, the value of pi was 3.2. :)
My point is that it is unfortunate if Hungarian law/regulation prohibits
Hungarian CAs from using OCSP in a way that is useful for the general
populace of the Internet, but the rest of the internet is not likely to
change its software to accommodate those unfortunate regulations.

> Our OCSP is used by our own customers for creating so-called 'archive
> signatures' e.g. according to ETSI TS 101 903. (An archive signature
> is timestamped and the necessary revocation information is also
> attached to the signature. Certain signature policies require that the
> revocation information needs to be issued _after_ the time of signing,
> i.e. the point of time marked in the timestamp on the signature.)

Well, of course, ALL revocation information is issued AFTER the time of
signing of the cert. No CA issues already-revoked certs.

> We understand that our OCSP is not useful for the general public, so
> we did not wish to include our OCSP root (and support for our OCSP) in
> Mozilla.

The question is: are the certs that rely on that responder useful to
the general public without it?

> If you consider that the OCSP URL in the AIA field poses a problem, we
> can modify the profile of the SSL server certifictes so the AIA field
> will not be included.

I opine that Mozilla should require that. Specifically that mozilla should
require that any OCSP URI in a server cert MUST work for Mozilla users
everywhere.


> Unrecognized extensions:
> ------------------------

> The QCStatement extension is *NOT* critical in our certificates.

> Webserver and code signing certificates are generally non-qualified,
> so they are not affected by this issue.

In bug 277797, a representative of a Hungarian CA claims that their
SSL server certs ARE qualified certs. If that is still true
(and it may not be, since that bug is a couple years old), then it
cannot be said that web server certs are generally non-qualified.

Ian G

unread,
Oct 6, 2008, 2:47:27 PM10/6/08
to mozilla's crypto code discussion list
Nelson B Bolyard wrote:
> István Zsolt BERTA wrote, On 2008-10-06 06:54:

>> We had good reasons to choose this solution. According to Hungarian
>> regulations, a qualified CA is allowed to use its private key for the
>> following two purposes only:
>> * signing qualified end-user certificates and
>> * signing CRLs.
>> As neither 'signing OCSP responses', nor 'singing OCSP responder
>> certificates' is listed here, we were not allowed to support options 1
>> and 3 marked in RFC 2560, so only option 2 remained.
>

> According to Indiana legislation, at one time, the value of pi was 3.2. :)
> My point is that it is unfortunate if Hungarian law/regulation prohibits
> Hungarian CAs from using OCSP in a way that is useful for the general
> populace of the Internet, but the rest of the internet is not likely to
> change its software to accommodate those unfortunate regulations.


Istvan, would it be possible to take the position that "signing
CRLs" is equivalent to signing OCSP responses or OCSP certificates?

They are both for the same end-result, getting the CR(L) to the
user. If the implementation details differ slightly, the
legislation is not likely to stand in the way. I imagine that if
you wanted, Mozo would provide documentation that could back up the
position.


>> Unrecognized extensions:
>> ------------------------


>
>> The QCStatement extension is *NOT* critical in our certificates.
>
>> Webserver and code signing certificates are generally non-qualified,
>> so they are not affected by this issue.
>

> In bug 277797, a representative of a Hungarian CA claims that their
> SSL server certs ARE qualified certs. If that is still true
> (and it may not be, since that bug is a couple years old), then it
> cannot be said that web server certs are generally non-qualified.


Yes, true. As I understand it, it was the intention of the
directive that only human persons be the holders of qualified
certificates. However when the CAs, industry and govt. departments
started working with them, they discovered problems with this
limitation. Different countries approached the problems in
different ways. In some countries, I gather, qualified certs can be
issued outside the strict intent of the directive.

However, it may still be reasonable for Mozilla to implement a
client-cert-only profile for EV.

iang

Frank Hecker

unread,
Oct 6, 2008, 5:30:10 PM10/6/08
to
Eddy Nigg wrote:
> On 10/03/2008 12:43 AM, Frank Hecker:
>> * This CA is based in Hungary. Though it provides a lot of information
>> in English (including a helpful CA hierarchy diagram) unfortunately all
>> of its CPS documents are currently available in Hungarian only.
>
> Frank, I think we should buy some tool that helps us with translating
> such stuff. Apparently Google doesn't support Hungarian -> English yet,
> but I searched and found some useful tools on the net which can do that.
> Please get something that can translate the CP/CPS and publish it
> somewhere so we can read about it.

We can consider this in the longer term. In the short term Kálmán
Kéménczy of the Mozilla localization team for Hungary has confirmed the
accuracy of the translations in the Microsoft bug, and is willing to
check further translations as needed.

Frank

P.S. I was out of the office all day, which is why I haven't been
participating in the discussion. I'll read all the comments in this
thread tonight and comment tomorrow.

Eddy Nigg

unread,
Oct 6, 2008, 6:26:18 PM10/6/08
to
On 10/06/2008 11:30 PM, Frank Hecker:

>
> We can consider this in the longer term. In the short term Kálmán
> Kéménczy of the Mozilla localization team for Hungary has confirmed the
> accuracy of the translations in the Microsoft bug, and is willing to
> check further translations as needed.
>

Frank, I've found some tools online for approximately US$ 50 - 100. If
Mozilla can't afford it, I'm willing to contribute it. I found that
Babylon is offering now Hungarian - English for free:
http://www.babylon.com/definition/Hungary/English

Perhaps somebody with a Windows Box can translate all documents from
http://www.mozilla.org/projects/security/certs/pending/#Microsec please?

I don't know how you read the documents, but I can't pinpoint to
something specific without getting an overview and I guess Kalman can't
do all of it...I'm not quite sure what the "Microsoft Bug" is, but
considering the comments this request already drew, I want to get a
better understanding about the operations of Microsec before commenting
on it.

Kyle Hamilton

unread,
Oct 6, 2008, 6:47:34 PM10/6/08
to mozilla's crypto code discussion list
I'll assume he meant Microsec instead of Microsoft, and work from
there. (bug 370505)

-Kyle H

Jean-Marc Desperrier

unread,
Oct 7, 2008, 8:10:02 AM10/7/08
to
István Zsolt BERTA wrote:
> [...]

> We had good reasons to choose this solution. According to Hungarian
> regulations, a qualified CA is allowed to use its private key for the
> following two purposes only:
> * signing qualified end-user certificates and
> * signing CRLs.
> As neither 'signing OCSP responses', nor 'singing OCSP responder
> certificates' is listed here, we were not allowed to support options 1
> and 3 marked in RFC 2560, so only option 2 remained.

How does the Hungarian regulation define the CA ?

In X509, a CA is defined by it's Distinguished Name, so can have several
certificates with several private key.

So according to X509, your CA can have both :
- a qualified certificate and associated private key that can only sign
end-user certificates and CRLs.
- another non-qualified certificate that signs OCSP response

If your OCSP Responder cert has the same DN as your CA cert and is also
signed by your Root CA, it should be recognized another cert issued for
the same CA and trusted according to option 1 of RFC2560.

Unfortunatly, I never had the opportunity to check how this specific
case is handled by NSS :-)

István Zsolt BERTA

unread,
Oct 7, 2008, 10:07:42 AM10/7/08
to
As I see we all agree on the fact that a 'trusted responder' can exist
according to RFC 2560, and it is possible that an OCSP responder
certificate is under a separate root. (There are various scenarios for
providing OCSP service, it can be provided by a CA directly or by
proxy responders, etc. but RFC 2560 does not deal with such issue.)

Thus, I refuse any statement that would claim that our solution is not
RFC 2560 conformant.


However, I accept that this way it could be very hard for an
application to automatically verify that a certain responder can be
trusted for answering OCSP requests for a certain certificate.
Moreover, our OCSP is currently not open for the general public, so
our OCSP service is not useful for Mozilla users.
We knew this from the very beginning, this is why we did not even ask
for the inclusion of our OCSP root in Mozilla.


> The question is: are the certs that rely on that responder useful to
> the general public without it?

Yes, this is the real question.

We say that yes, they are useful, as they can be verified using CRLs.

As I read above, it currently does not pose a problem that there is an
OCSP URL in the AIA field of the certificate. If you think that this
shall become problematic in the future, we can modify the profile of
webserver certificates and remove the OCSP URL (as long as the OCSP is
not useful for the general public).


> > We had good reasons to choose this solution. According to Hungarian
> > regulations, a qualified CA is allowed to use its private key for the
> > following two purposes only:

> You are not allowed to issue intermediate CA certificates then? Are you


> issuing directly from the CA root?

The CA key used for signing qualified certificates can be used for
signing qualified end-user certificates and CRLs. This also means that
we cannot issue intermediate CA certificates with that particular key
and we cannot issue non-qualified certificates either.

We have a root, which does not issue end-user certificates, but issues
CA certificates for our own CAs only. These 'productive' CAs can issue
either qualified or non-qualified certificates only.
This solution was accepted by our authorities.

In case of 'productive' CAs issuing qualified certificates the
'trusted responder' remained the only option.

> What are the checks performed on code-signing certificates?

1. We verify the existence of the company which requests the code-
signing certificate using an online connection to the Hungarian
registry of businesses.
2. We verify the existence of the documents (driving license, ID card
or passport) of the person who requests the code-signing certificate
on behalf of that particular company. We perform this verification
using an online connection to the Office of the Central Office for
Administrative and Electronic Public Services.
http://www.nyilvantarto.hu/kekkh/kozos/index.php?k=nyitolap_en&b=bal_eng
3. Using a face-to-face registration (as the CP is NCP-based) we
verify the identity of the person who requested the certificate on
behalf of that company. This person has to meet our registration
officer and has to present the document (driving license, ID card or
passport) that was verified in step 2.
4. We verify that this person has the authority to sign on behalf of
the company. We generally request a notarial deed (issued by a public
notary) as a proof.


> > attached to the signature. Certain signature policies require that the
> > revocation information needs to be issued _after_ the time of signing,
> > i.e. the point of time marked in the timestamp on the signature.)

> Well, of course, ALL revocation information is issued AFTER the time of


> signing of the cert. No CA issues already-revoked certs.

No, I meant: revocation information issued after the creation of an
_electronic_signature_.
I was referring to a concept known as 'grace period'. This means for
example that if a signature had been created on Wednesday, it should
not be accepted based on a CRL issued on Monday (because the
certificate of the signatory could have been revoked on Tuesday). This
a European concept that appears e.g. in CEN Workshop Agreement CWA
14171, Section 5.3.
ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/eSign/cwa14171-00-2004-May.pdf
This concept is specific to electronic signatures, and cannot be
applied for e.g. webserver certificates. This concept is also the
subject of many debates.


> In bug 277797, a representative of a Hungarian CA claims that their
> SSL server certs ARE qualified certs. If that is still true
> (and it may not be, since that bug is a couple years old), then it
> cannot be said that web server certs are generally non-qualified.

The EU Directive is about electronic signatures only (and e.g. not
about SSL), so the word 'qualified' can be used in the context of
electronic signatures only.

According to ETSI TS 102 280, Section 5.4.3, only the DigitalSignature
and NonRepudiation key usage bits may appear in certificates used for
signing. This means, a qualified certificate - a certificate used for
signing - cannot be used for SSL.

This EU requirement appears in Hungarian legislation too: according to
13. § (4) of the Hungarian act on electronic signatures, a private key
used for creating electronic signatures must not be used for any other
purpose (e.g. decryption, SSL authentication, etc).

This means, a webserver certificate cannot be qualified in Hungary.

I used the word 'generally', because other EU member states may
implement both the Directive and ETSI specifications differently. Some
countries are more, some countries are less strict on this issue.
Regulations also change in time. At the time when bug 277797 was
submitted, key usage bits in certificates was not a central issue for
our authority. A National Communications Authority statement in this
field has been published in late 2005, after bug 277797 was submitted
only.


> Yes, true. As I understand it, it was the intention of the
> directive that only human persons be the holders of qualified
> certificates. However when the CAs, industry and govt. departments
> started working with them, they discovered problems with this
> limitation. Different countries approached the problems in
> different ways. In some countries, I gather, qualified certs can be
> issued outside the strict intent of the directive.

Yes, different countries apply such concepts differently.

According to the Directive, qualified signatures are equivalent with
handwritten ones, so only natural persons were meant to have qualified
certificates. However, in certain countries, electronic invoices have
to be signed with qualified certificates. This led to the situation
where - in some countries - automated mechanisms also create qualified
signatures.
This is very far away from the original goal.

> Istvan, would it be possible to take the position that "signing
> CRLs" is equivalent to signing OCSP responses or OCSP certificates?

Personally, I agree with you.

This requirement in our regulations is the result of a (bad)
translation from CWA 14167-01. When we started our services, we were
not in the position to question such requirements and argue using
common sense.
Meanwhile, the situation has changed, new regulations appeared, and
relevant statements in ETSI TS 101 456, Section 7.2.5 (Certification
authority key usage) have been updated, clarified. Today, we might be
in a better position.

We shall try to take it into account when we modify our CA hierarchy
next time.


> How does the Hungarian regulation define the CA ?

Generally, it defines a CA as an organization.

This particular requirement is not about the organization, it is about
a private key - it is stated explicitly.

> Unfortunatly, I never had the opportunity to check how this specific
> case is handled by NSS :-)

I like the idea, but even if NSS handles this correclty, other
applications may fail to do so.

Anders Rundgren

unread,
Oct 7, 2008, 10:40:47 AM10/7/08
to mozilla's crypto code discussion list, istvan...@microsec.hu
>According to the Directive, qualified signatures are equivalent with
>handwritten ones, so only natural persons were meant to have qualified
>certificates. However, in certain countries, electronic invoices have
>to be signed with qualified certificates. This led to the situation
>where - in some countries - automated mechanisms also create qualified
>signatures.

I think this requires a slightly different explanation. In Germany clueless
government institutions buy signature devices capable of housing dozens
of smart cards in order to with a single manual operation ("handwritten")
be able to sign multiple invoices in one step using qualified signatures.

In Scandinavia and Estonia somewhat less clueless government institutions
have raised specific PKIs that issue "organization certificates" that are
similar to EV certs (strict issuance policies), but certify an organization
using a VAT, DnB or similar org-id rather than a domain name. These
certificates (well the private key if we should be nitpicking..) are
automatically signing outgoing messages indicating that they have passed
whatever is needed for messages to be "authorized" for external
consumption. These certificates are not called or issued as qualified
certificates. Employee signatures essentially never leave the homebase.

>This is very far away from the original goal.

Which is not that surprising since authenticity in the real world is
much more important than being able to get money from a CA due to
a screw-up. The original EU signature idea that you would be able to do
business with anybody because they have a QC, isn't for real because
a QC doesn't say if you are a credible person and a CA has no ability
bringing bad guys to a court either. In addition, identity schemes tend
to be pretty local (my Social Security Number has little value outside
of Sweden).

If e-mail security had started at that level (domain) instead of S/MIME,
the Internet had been a much better place!

Anders

Eddy Nigg

unread,
Oct 7, 2008, 12:56:16 PM10/7/08
to
On 10/07/2008 04:07 PM, István Zsolt BERTA:

> As I read above, it currently does not pose a problem that there is an
> OCSP URL in the AIA field of the certificate. If you think that this
> shall become problematic in the future, we can modify the profile of
> webserver certificates and remove the OCSP URL (as long as the OCSP is
> not useful for the general public).

Yes, I think this is what should be done. OCSP responders are not a
requirement currently (so I think it's highly suggested), but using the
AIA extension makes the certificates unusable for any relying party
which treats OCSP failures as an error.

>
>>> We had good reasons to choose this solution. According to Hungarian
>>> regulations, a qualified CA is allowed to use its private key for the
>>> following two purposes only:
>
>> You are not allowed to issue intermediate CA certificates then? Are you
>> issuing directly from the CA root?
>
> The CA key used for signing qualified certificates can be used for
> signing qualified end-user certificates and CRLs. This also means that
> we cannot issue intermediate CA certificates with that particular key
> and we cannot issue non-qualified certificates either.

Well, I don't get it. Your diagram at
http://srv.e-szigno.hu/menu/index.php?lap=english_ca_hierarchy shows
clearly that you are issuing intermediate CA certificates from the root,
but in the previous comment you claimed that the CA is only allowed to use
* signing qualified end-user certificates and
* signing CRLs.
Does this apply to the intermediate CA certificates but not the CA root?


>
> We have a root, which does not issue end-user certificates, but issues
> CA certificates for our own CAs only.

Which root is that? I understand there is only one root up for inclusion...

>
>> What are the checks performed on code-signing certificates?
>
> 1. We verify the existence of the company which requests the code-
> signing certificate using an online connection to the Hungarian
> registry of businesses.
> 2. We verify the existence of the documents (driving license, ID card
> or passport) of the person who requests the code-signing certificate
> on behalf of that particular company. We perform this verification
> using an online connection to the Office of the Central Office for
> Administrative and Electronic Public Services.
> http://www.nyilvantarto.hu/kekkh/kozos/index.php?k=nyitolap_en&b=bal_eng
> 3. Using a face-to-face registration (as the CP is NCP-based) we
> verify the identity of the person who requested the certificate on
> behalf of that company. This person has to meet our registration
> officer and has to present the document (driving license, ID card or
> passport) that was verified in step 2.
> 4. We verify that this person has the authority to sign on behalf of
> the company. We generally request a notarial deed (issued by a public
> notary) as a proof.
>

Thanks for that! I still would like to read your CP/CPS in English (even
if only machine translated). Is it somehow possible to facilitate that?

István Zsolt BERTA

unread,
Oct 8, 2008, 11:07:09 AM10/8/08
to
> Well, I don't get it. Your diagram at
> http://srv.e-szigno.hu/menu/index.php?lap=english_ca_hierarchy shows
> clearly that you are issuing intermediate CA certificates from the root,
> but in the previous comment you claimed that the CA is only allowed to use
> * signing qualified end-user certificates and
> * signing CRLs.
> Does this apply to the intermediate CA certificates but not the CA root?

It applies to the private key used for signing qualified certificates
(end-entity certificates issued to natural persons) only, so it does
not apply to roots that sign CA certificates.


> > We have a root, which does not issue end-user certificates, but issues
> > CA certificates for our own CAs only.

> Which root is that? I understand there is only one root up for inclusion...

We requested the inclusion of one root, 'Microsec e-Szigno Root CA'
only.
(The root 'e-Szigno OCSP CA' is our OCSP root. The root 'Közigazgatási
Gyökér Hitelesítés Szolgáltató' is a Hungarian governmental root
operated by the Hungarian government that cross-certififes certain
commercial CAs (like Microsec), it does not belong to us. The gray
ones below are our test roots for testing purposes, they do not belong
to our official system.)

> Thanks for that! I still would like to read your CP/CPS in English (even
> if only machine translated). Is it somehow possible to facilitate that?

We would like to avoid having to translate these documents if
possible, as our CPS is over 100 pages long.
I doubt that any Hungarian to English machine translation could
provide a quality good enough (that allows you to figure out that the
original document was in fact a CP/CPS of a CA). If you have trouble
feeding the PDF into a machine translator, I can provide our documents
in some other format: in TXT or in RTF, etc.

Regards,

István

Eddy Nigg

unread,
Oct 8, 2008, 11:54:39 AM10/8/08
to
On 10/08/2008 05:07 PM, István Zsolt BERTA:

>> Thanks for that! I still would like to read your CP/CPS in English (even
>> if only machine translated). Is it somehow possible to facilitate that?
>
> We would like to avoid having to translate these documents if
> possible, as our CPS is over 100 pages long.

In understand that and didn't requested a complete translation.

> I doubt that any Hungarian to English machine translation could
> provide a quality good enough (that allows you to figure out that the
> original document was in fact a CP/CPS of a CA). If you have trouble
> feeding the PDF into a machine translator, I can provide our documents
> in some other format: in TXT or in RTF, etc.
>

A plain text version would be extremely helpful. Concerning machine
translation, I think I'll be alright ;-)

Kyle Hamilton

unread,
Oct 8, 2008, 4:45:58 PM10/8/08
to mozilla's crypto code discussion list
On Wed, Oct 8, 2008 at 8:07 AM, István Zsolt BERTA
<istvan...@microsec.hu> wrote:
>> Well, I don't get it. Your diagram at
>> http://srv.e-szigno.hu/menu/index.php?lap=english_ca_hierarchy shows
>> clearly that you are issuing intermediate CA certificates from the root,
>> but in the previous comment you claimed that the CA is only allowed to use
>> * signing qualified end-user certificates and
>> * signing CRLs.
>> Does this apply to the intermediate CA certificates but not the CA root?
>
> It applies to the private key used for signing qualified certificates
> (end-entity certificates issued to natural persons) only, so it does
> not apply to roots that sign CA certificates.

Okay, I'm a bit confused. The Root CA itself does not sign qualified
certificates, but it authenticates the private key used to sign
qualified certificates?

>> > We have a root, which does not issue end-user certificates, but issues
>> > CA certificates for our own CAs only.
>
>> Which root is that? I understand there is only one root up for inclusion...
>
> We requested the inclusion of one root, 'Microsec e-Szigno Root CA'
> only.
> (The root 'e-Szigno OCSP CA' is our OCSP root. The root 'Közigazgatási
> Gyökér Hitelesítés Szolgáltató' is a Hungarian governmental root
> operated by the Hungarian government that cross-certififes certain
> commercial CAs (like Microsec), it does not belong to us. The gray
> ones below are our test roots for testing purposes, they do not belong
> to our official system.)

The 'Microsec e-Szigno Root CA' is a different CA name than 'e-Szigno
OCSP CA', and thus the OCSP CA does not match the X.509 or OCSP
requirements to be able to sign OCSP responses for 'Microsec e-Szigno
Root CA'.

-Kyle H

István Zsolt BERTA

unread,
Oct 9, 2008, 12:16:13 PM10/9/08
to
> A plain text version would be extremely helpful. Concerning machine
> translation, I think I'll be alright ;-)

I have attached a plain text version to Bug 370505, it is available
here:
https://bugzilla.mozilla.org/attachment.cgi?id=342436
I still don't think a machine translation will be of any help.

> Okay, I'm a bit confused. The Root CA itself does not sign qualified
> certificates, but it authenticates the private key used to sign
> qualified certificates?

Yes. In our system, qualified certificates are signed by intermediate
CAs only.
'Qualified' does not necessarily mean that its more secure, it means
that more regulations apply, and a qualified signature (based on a
qualified certificate and created using a secure signature creation
device) can be considered equivalent with a handwritten one according
to the EU Directive. A non-qualified signature created in a secure
environment can sometimes be considered more secure than a qualified
one.
Many regulations apply to the CA used for signing qualified
certificates, but a lot less regulations apply to the root who signs
the certificate for the key that is used for signing qualified
certificates. I agree that this is not necessarily logical.

István

Eddy Nigg

unread,
Oct 11, 2008, 7:50:52 AM10/11/08
to
On 10/03/2008 12:43 AM, Frank Hecker:
>
> 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.
>

Besides the issue with the OCSP responder and their including of the
OCSP URI in the AIA extension with EE certificates, I have not found any
issues with this request. My recommendation for Microsec is to refrain
from including the OCSP service URI if and until they can provide an
OCSP responder which is usable with Firefox and other browsers (when
relying on AIA extension).

I must note that a I couldn't read the CP/CSP of Microsec and my
information is based solemnly on the bug entries and comments from
István, even though István posted a text version of one of their CP/CPS
at the bug. I believe that Mozilla should have the basic tools to
perform at least machine translations of such documents in case no
English version exists. It's important for me to inspect the CP/CPS and
browse through the documents provided by the CA.

Nelson B Bolyard

unread,
Oct 11, 2008, 4:58:53 PM10/11/08
to mozilla's crypto code discussion list
István Zsolt BERTA wrote, On 2008-10-07 07:07:
> As I see we all agree on the fact that a 'trusted responder' can exist
> according to RFC 2560, and it is possible that an OCSP responder
> certificate is under a separate root. (There are various scenarios for
> providing OCSP service, it can be provided by a CA directly or by
> proxy responders, etc. but RFC 2560 does not deal with such issue.)
>
> Thus, I refuse any statement that would claim that our solution is not
> RFC 2560 conformant.

It is conformant IF and only IF the user (not the CA) chooses to trust
that responder. If the CERTIFICATE issued by the issuer says to go to
that responder for OCSP, but the responder's cert is not either
a) the the issuer's cert, or
b) a cert issued by the same issuer as the cert under test,
then it is not conformant. The RFC is very clear about that.

Kyle Hamilton

unread,
Oct 11, 2008, 6:48:17 PM10/11/08
to mozilla's crypto code discussion list
I vote no on this proposal due to OCSP interoperability issues.

-Kyle H

On Sat, Oct 11, 2008 at 1:58 PM, Nelson B Bolyard <nel...@bolyard.me> wrote:
> István Zsolt BERTA wrote, On 2008-10-07 07:07:

>> As I see we all agree on the fact that a 'trusted responder' can exist
>> according to RFC 2560, and it is possible that an OCSP responder
>> certificate is under a separate root. (There are various scenarios for
>> providing OCSP service, it can be provided by a CA directly or by
>> proxy responders, etc. but RFC 2560 does not deal with such issue.)
>>
>> Thus, I refuse any statement that would claim that our solution is not
>> RFC 2560 conformant.
>

> It is conformant IF and only IF the user (not the CA) chooses to trust
> that responder. If the CERTIFICATE issued by the issuer says to go to
> that responder for OCSP, but the responder's cert is not either
> a) the the issuer's cert, or
> b) a cert issued by the same issuer as the cert under test,
> then it is not conformant. The RFC is very clear about that.

István Zsolt BERTA

unread,
Oct 12, 2008, 10:24:34 AM10/12/08
to
> It is conformant IF and only IF the user (not the CA) chooses to trust
> that responder. If the CERTIFICATE issued by the issuer says to go to
> that responder for OCSP, but the responder's cert is not either
> a) the the issuer's cert, or
> b) a cert issued by the same issuer as the cert under test,
> then it is not conformant. The RFC is very clear about that.

I still disagree. RFC 2560 does allow the responder to be under a
separate root as a 'trusted responder'. Naturally, no responder is
trusted by everyone, there are users who accept a certain responder
and
there are users who do not accept it. I don't think that a responder
is
not conformant according to RFC 2560 just because there are users who
do
not trust it.

> My recommendation for Microsec is to refrain
> from including the OCSP service URI if and until they can provide an
> OCSP responder which is usable with Firefox and other browsers (when
> relying on AIA extension).

I agree, our responder is not useful for most Mozilla users.

We shall remove the OCSP URL from the AIA field for webserver
certificates.

> I vote no on this proposal due to OCSP interoperability issues.

I think the removal of the OCSP URL should eliminate this problem.

Regards,

István

Eddy Nigg

unread,
Oct 12, 2008, 11:20:32 AM10/12/08
to
István Zsolt BERTA:

>> It is conformant IF and only IF the user (not the CA) chooses to trust
>> that responder. If the CERTIFICATE issued by the issuer says to go to
>> that responder for OCSP, but the responder's cert is not either
>> a) the the issuer's cert, or
>> b) a cert issued by the same issuer as the cert under test,
>> then it is not conformant. The RFC is very clear about that.
>
> I still disagree. RFC 2560 does allow the responder to be under a
> separate root as a 'trusted responder'. Naturally, no responder is
> trusted by everyone, there are users who accept a certain responder
> and
> there are users who do not accept it. I don't think that a responder
> is
> not conformant according to RFC 2560 just because there are users who
> do
> not trust it.

I think the point Nelson was making that if the certificate issued to
the users includes an OCSP URI it's not conforming to the RFC.

> We shall remove the OCSP URL from the AIA field for webserver
> certificates.

Yes

>
>> I vote no on this proposal due to OCSP interoperability issues.
>
> I think the removal of the OCSP URL should eliminate this problem.
>

Except if Nelson thinks otherwise, removing the AIA OCSP service URI
solves this issue. More specific the Mozilla CA Policy calls for:

cRLDistributionPoints or OCSP authorityInfoAccess extensions for which
no operational CRL or OCSP service exists.

Therefor the OCSP reference MUST NOT appear in the EE certificates of
Microsec. I suggest to follow up on this to confirm compliance.

Eddy Nigg

unread,
Oct 12, 2008, 11:40:11 AM10/12/08
to
Eddy Nigg:

>
> Except if Nelson thinks otherwise, removing the AIA OCSP service URI
> solves this issue. More specific the Mozilla CA Policy calls for:
>
> cRLDistributionPoints or OCSP authorityInfoAccess extensions for which
> no operational CRL or OCSP service exists.
>
> Therefor the OCSP reference MUST NOT appear in the EE certificates of
> Microsec. I suggest to follow up on this to confirm compliance.
>

I think we have a problem here! I wanted to make sure that the CA root
and intermediate CA certificates don't include OCSP AIA extensions and I
noticed the following when importing and examining the CA root...

- The CA root includes the OCSP service URI in the AIA extension:
OCSP: URI: https://rca.e-szigno.hu/ocsp
- Upon going to https://srv.e-szigno.hu/ I received an
sec_error_unknown_issuer error. Apparently the certificate isn't
installed correctly and doesn't present the certificate chain.

The later is just an annoyance which can be easily fixed, however the
OCSP URI in the CA root IS a problem. Additionally the intermediate CA
certificate might also feature the AIA extension (which I couldn't test).

As mentioned earlier, the Mozilla CA Policy states:

...might cause technical problems with the operation of our software,
for example, with CAs that issue certificates that have...

...cRLDistributionPoints or OCSP authorityInfoAccess extensions for

which no operational CRL or OCSP service exists.

Micorsec doesn't provide an operational OCSP responder when used in
conjunction with AIA service URI. Over to Frank.

Eddy Nigg

unread,
Oct 12, 2008, 12:18:52 PM10/12/08
to
Eddy Nigg:

>
> I think we have a problem here! I wanted to make sure that the CA root
> and intermediate CA certificates don't include OCSP AIA extensions and I
> noticed the following when importing and examining the CA root...
>
> - The CA root includes the OCSP service URI in the AIA extension:
> OCSP: URI: https://rca.e-szigno.hu/ocsp
> - Upon going to https://srv.e-szigno.hu/ I received an
> sec_error_unknown_issuer error. Apparently the certificate isn't
> installed correctly and doesn't present the certificate chain.
>
> The later is just an annoyance which can be easily fixed, however the
> OCSP URI in the CA root IS a problem. Additionally the intermediate CA
> certificate might also feature the AIA extension (which I couldn't test).
>
> As mentioned earlier, the Mozilla CA Policy states:
>
> ...might cause technical problems with the operation of our software,
> for example, with CAs that issue certificates that have...
>
> ...cRLDistributionPoints or OCSP authorityInfoAccess extensions for
> which no operational CRL or OCSP service exists.
>
> Micorsec doesn't provide an operational OCSP responder when used in
> conjunction with AIA service URI. Over to Frank.
>

More followup's on this issue...I found a correctly installed
certificate at https://rca.e-szigno.hu/ and I could examine also the
intermediate CA certificate which also features the OCSP AIA extension.
This means that all certificates from the root up to the EE certificate
include the AIA extension OCSP URI.

Additionally the OCSP URI is a HTTPS URL which makes it even more
unusable. How can the OCSP responder be accessed by HTTPS if it can't
confirm the validity of the connection to the responder itself? IMO this
is never going to work. OCSP responses are signed and SHOULD NOT be
served over a secure connection. The only workaround would be to have
the OCSP HTTPS connection signed by a certificate issued by a different CA.

Rob Stradling

unread,
Oct 13, 2008, 2:01:35 AM10/13/08
to mozilla's crypto code discussion list
"the OCSP URI in the CA root IS a problem"

Nelson, does NSS ever attempt to check the revocation status of a built-in
Root Certificate if that Root Certificate contains CRLDP(s) and/or OCSP
URI(s) ?

--

István Zsolt BERTA

unread,
Oct 13, 2008, 10:36:02 AM10/13/08
to
> I think we have a problem here! I wanted to make sure that the CA root
> and intermediate CA certificates don't include OCSP AIA extensions and I
> noticed the following when importing and examining the CA root...

In fact, our intermediate CA certificates also included an OCSP AIA
extension.

As we promised, we have updated the profile of our webserver
certificates, so now we do not include an OCSP URL in the AIA field.
We have also updated our CA certificate we use for issuing webserver
certificates, so now it does not include an OCSP URL either.

See https://www.e-szigno.hu as an example.
(Now this server also presents the certificate chain.)


> - The CA root includes the OCSP service URI in the AIA extension:

We accept that it is awkward that our root certificate includes the
OCSP AIA extension, it was a bad idea for us to include it.
Unfortunately our root certificate is not something we can change on
the short run.

We don't quite understand why anyone would check the revocation status
of a trust anchor via CRL or OCSP.

Regards,

István

Nelson B Bolyard

unread,
Oct 13, 2008, 1:12:30 PM10/13/08
to mozilla's crypto code discussion list
Rob Stradling wrote, On 2008-10-12 23:01:

> Nelson, does NSS ever attempt to check the revocation status of a built-in
> Root Certificate if that Root Certificate contains CRLDP(s) and/or OCSP
> URI(s) ?

Good question. The answer is somewhat complex. :-/

As you may know, NSS has two separate bodies of code for building
certification paths and validating them. Firefox uses both implementations
at different times.

The old one checks OCSP only for EE certs, and does CRL checks for any
certs issued by any CA for which it has a CRL, but does not automatically
fetch CRLs. So the answer to your question for the old implementation is: no.

The new one is capable of checking OCSP and CRLs at every level, and
eventually will have the ability to fetch CRLs when a CDP extension is
found in a cert. With the new implementation, all this checking is under
the application's control, so that application can choose to do revocation
checking on CAs, or not, and can choose to do OCSP, or CRLs, or both, or
none. I would expect that when the application has told it to use both
revocation protocols on all certs (including CA certs) the code would
check revocation information for any cert that was both (a) not trusted,
and (b) not self-issued. So I would expect that it would not check the
revocation status of any root CA cert, whether built in or not.
But I am not sure what it does. I will attempt to investigate that.

Eddy Nigg

unread,
Oct 13, 2008, 3:27:24 PM10/13/08
to
Rob Stradling:

> "the OCSP URI in the CA root IS a problem"
>
> Nelson, does NSS ever attempt to check the revocation status of a built-in
> Root Certificate if that Root Certificate contains CRLDP(s) and/or OCSP
> URI(s) ?
>

Adding to Nelson's comment....CRL is checked at any level if provided
(requires manually providing the CRLDP). EV requires CRL and/or OCSP
checking at the intermediate CA level, hence I expect it to check those
at least. With the root there is always the egg-and-chicken game as you
most likely know...

Rob Stradling

unread,
Oct 14, 2008, 1:32:30 AM10/14/08
to mozilla's crypto code discussion list
On Monday 13 October 2008 15:36:02 István Zsolt BERTA wrote:
<snip>

> > - The CA root includes the OCSP service URI in the AIA extension:
>
> We accept that it is awkward that our root certificate includes the
> OCSP AIA extension, it was a bad idea for us to include it.
> Unfortunately our root certificate is not something we can change on
> the short run.

István,

Just a thought...
If Nelson's investigation does find that the OCSP AIA extension in your Root
Certificate is a problem for NSS, is there really anything to stop you from
issuing a new Root Certificate? This new Root Certificate could be identical
to your current Root Certificate except for i) different serial number, and
ii) OCSP AIA removed.
As the old and new Root Certificates would have the same Subject Name and Key,
they would effectively be interchangeable.

> We don't quite understand why anyone would check the revocation status
> of a trust anchor via CRL or OCSP.
>
> Regards,
>
> István

> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto

--

István Zsolt BERTA

unread,
Oct 15, 2008, 10:14:10 AM10/15/08
to
> Just a thought...
> If Nelson's investigation does find that the OCSP AIA extension in your Root
> Certificate is a problem for NSS, is there really anything to stop you from
> issuing a new Root Certificate? This new Root Certificate could be identical
> to your current Root Certificate except for i) different serial number, and
> ii) OCSP AIA removed.
> As the old and new Root Certificates would have the same Subject Name and Key,
> they would effectively be interchangeable.

Theoretically, we could issue such a certificate, but we would like to
avoid this if possible.
Our current root certificate is already used in many systems and many
applications, and it also appears in a vast number of timestamped
signatures (of ETSI TS 101 903 format). I am afraid, we would not be
able to forget about our current root certificate completely, but we
would need to use the two roots in parallel. As many of these systems
or applications are not under our control, the two roots could lead to
problems we cannot foresee.


I have also reread relevant sections from RFC 5280 and X.509, and I
have not found any requirement for checking the revocation status for
trust anchors. I found that a trust anchor is an input to the path
validation algorithm, and - even if it is presented as a self-signed
certificates - it is not included as a part of the certification path.
The path validation algorithm checks the revocation status of members
of the certification path only.

However, I do accept that it is awkward to have an OCSP AIA extension
in a root certificate.

Regards,

István

Frank Hecker

unread,
Oct 17, 2008, 12:02:46 AM10/17/08
to
Frank Hecker wrote:
> 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.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=370505

First, my apologies for the delay in my responding to the public
comments. I've messed up the schedule I previously outlined; see below
for my proposal to revise the schedule and deal with the Microsec request.

I've read through all the public comments. Rather than try to respond to
each and every comment, I've written a brief summary of my
understanding of the various issues raised. Please feel free to correct
my understanding where appropriate.

* Translation of the Microsec CPSs. As I noted in my original message,
all of the Microsec CPS documents are available in Hungarian only. Our
policy does not mandate that CA documents be available in English, so I
don't see a justification for requiring that Microsec prepare official
English translations. Thus far we've relied on Microsec-provided
translations of key CPS sections; the Mozilla Hungarian localization
team (in the person of Kálmán Kéménczy) was kind enough to verify the
accuracy of the translations.

IMO Getting human-created English translations of all the CPSs is going
to be too difficult and time-consuming to be feasible, at least in the
near term. I've followed up on the tips provided by Eddy Nigg and
researched various options for machine translation of Hungarian. It
appears that the best online option is the Webforditas.hu site:

http://www.webforditas.hu/web-translator.php
http://www.webforditas.hu/translation.php

The company behind the site also sells a Windows-based translation
application (MorphLogic). I'm going to try and see if I can use either
the site or (more likely) the application to get rough translations of
relevant CPS sections, starting with the tables of contents.

* Liability associated with Microsec certificates. There were a number
of comments relating to the monetary liability associated with Microsec
certificates. The thread was interesting in relation to understanding
practices in Hungary and the EU, but I think that ultimately it is not
relevant to our consideration of this request. Our policy does not have
any requirements relating to monetary liability of CAs, and I am not
persuaded that disclaiming liability in certain contexts causes security
issues for typical Mozilla users. I'm therefore minded to ignore this
issue for purposes of evaluating this request.

* OCSP. My understanding is that the Microsec practice of having a
separate root for OCSP is very problematic, particularly given the
inclusion of AIA extensions with OCSP URLs in end entity certificates.
As I understand it, Microsec is removing AIA extensions with OCSP URLs
from end entity certificates and from intermediate CA certificates, and
this should address this problem going forward. However there still
appears to be an open question as to whether having an AIA extension
with OCSP URL in the Microsec root certificate will cause a problem with
NSS. (Nelson wrote that he was going to investigate this, but I don't
recall seeing a followup to this.)

Based on the above, my inclination is to postpone consideration of this
request for at least two weeks. That will give me time to try to get
more of the Microsec CPS content translated, and also to get a final
answer on the question of root certificates with AIA extensions with
OCSP URLs. Once those two things get done I'll formally start a new
public comment period. (You can still comment in the meantime, of
course; I'm just setting a formal date for purposes of scheduling CA
requests.)

I've revised the CA schedule to reflect this delay:

https://wiki.mozilla.org/CA:Schedule

Nelson Bolyard

unread,
Oct 17, 2008, 1:11:37 AM10/17/08
to mozilla's crypto code discussion list
Frank Hecker wrote:

> * OCSP. My understanding is that the Microsec practice of having a
> separate root for OCSP is very problematic, particularly given the
> inclusion of AIA extensions with OCSP URLs in end entity certificates.
> As I understand it, Microsec is removing AIA extensions with OCSP URLs
> from end entity certificates and from intermediate CA certificates, and
> this should address this problem going forward.

... after some period of time has elapsed. Certainly the day after they
begin to issue certs without the OCSP URL in the AIA extension, 99+% of the
existing certs will still have those AIA extensions. Over time that number
should decline.

At what point does it become appropriate to consider the problem to have
abated enough to no longer be an issue? Is it when the number of remaining
outstanding valid certs that bear that AIA extension is 90%? 50%? 20%? 10%?
5%? 1%?

Do we know what the maximum validity period is in the cert they've issued?
That would give us a date after which we could be sure it's 0%.

> However there still appears to be an open question as to whether having an
> AIA extension with OCSP URL in the Microsec root certificate will cause a
> problem with NSS. (Nelson wrote that he was going to investigate this, but I
> don't recall seeing a followup to this.)

Sorry, I did get the answer but forgot to write it up. :-/
Although we haven't tested it with libPKIX, as far as I know, OCSP URLs
in root certs will not be a problem for NSS. NSS will never check a
self-issued cert for OCSP revocation.


Rob Stradling

unread,
Oct 17, 2008, 4:15:49 AM10/17/08
to mozilla's crypto code discussion list
On Wednesday 15 October 2008 15:14:10 István Zsolt BERTA wrote:
> > Just a thought...
> > If Nelson's investigation does find that the OCSP AIA extension in your
> > Root Certificate is a problem for NSS, is there really anything to stop
> > you from issuing a new Root Certificate? This new Root Certificate could
> > be identical to your current Root Certificate except for i) different
> > serial number, and ii) OCSP AIA removed.
> > As the old and new Root Certificates would have the same Subject Name and
> > Key, they would effectively be interchangeable.
>
> Theoretically, we could issue such a certificate, but we would like to
> avoid this if possible.
> Our current root certificate is already used in many systems and many
> applications, and it also appears in a vast number of timestamped
> signatures (of ETSI TS 101 903 format). I am afraid, we would not be
> able to forget about our current root certificate completely, but we
> would need to use the two roots in parallel. As many of these systems
> or applications are not under our control, the two roots could lead to
> problems we cannot foresee.

István,

I must confess that I'm not too familiar with the ETSI TS 101 903 timestamped
signature format. Do these signatures include a copy of your current root
certificate? If yes, then I agree that there might be "problems we cannot
foresee".

It might interest you to know that GlobalSign have recently "refreshed" their
Root Certificate in Mozilla NSS:
https://bugzilla.mozilla.org/show_bug.cgi?id=406794
Presumably GlobalSign don't foresee any problems with using "two roots in
parallel". But then, I guess GlobalSign may not be intending to support the
same range of systems and applications that Microsec support.

> I have also reread relevant sections from RFC 5280 and X.509, and I
> have not found any requirement for checking the revocation status for
> trust anchors. I found that a trust anchor is an input to the path
> validation algorithm, and - even if it is presented as a self-signed
> certificates - it is not included as a part of the certification path.
> The path validation algorithm checks the revocation status of members
> of the certification path only.
>
> However, I do accept that it is awkward to have an OCSP AIA extension
> in a root certificate.
>
> Regards,
>
> István

Ian G

unread,
Oct 17, 2008, 6:28:16 AM10/17/08
to mozilla's crypto code discussion list
Nelson Bolyard wrote:

> Frank Hecker wrote:
>> However there still appears to be an open question as to whether having an
>> AIA extension with OCSP URL in the Microsec root certificate will cause a
>> problem with NSS. (Nelson wrote that he was going to investigate this, but I
>> don't recall seeing a followup to this.)
>
> Sorry, I did get the answer but forgot to write it up. :-/
> Although we haven't tested it with libPKIX, as far as I know, OCSP URLs
> in root certs will not be a problem for NSS. NSS will never check a
> self-issued cert for OCSP revocation.


Ah, ok, excellent, that helps with the big question: Can we
conclude from this that roots cannot be revoked by means of the
OCSP/CRL channel?

(Therefore they can only really be replaced by an adjustment to the
root list?)

This notion of revoking the root has been floating around for some
time in various places, but never with the hard facts of whether it
is possible.

And -- broader question for the policy wonks as well as the coders
-- are we actually happy that this is a good thing: revocation of
roots is not a CRL/OCSP possibility? Should we write this up as a
policy statement somewhere? Or should we treat it as a bug to be
filed & fixed?

It would be nice to put a stake through the heart of this issue.

iang

Eddy Nigg

unread,
Oct 17, 2008, 7:03:38 AM10/17/08
to
Ian G:

>
> Ah, ok, excellent, that helps with the big question: Can we
> conclude from this that roots cannot be revoked by means of the
> OCSP/CRL channel?

No, because it depends on the application and library implementing it I
think. Apparently it's correct for NSS.

Now IMO as the root certificate signs itself, with the same authority it
should be able to revoke itself. This would result obviously in
repeating the process until the root is removed and not used anymore,
but it would mark the root and all certificates signed by it revoked.
That would be a benefit in case of a disaster (including key compromise
- specially for the ones issuing EE certs directly from the root). Just
my $0.02.

Frank Hecker

unread,
Oct 17, 2008, 9:32:10 AM10/17/08
to
Eddy Nigg wrote:
> Now IMO as the root certificate signs itself, with the same authority it
> should be able to revoke itself. This would result obviously in
> repeating the process until the root is removed and not used anymore,
> but it would mark the root and all certificates signed by it revoked.

I'm not sure what you mean by "repeating the process". How would such
revocation work in practice (assuming a PKI library that did CRL
checking for roots)? Would the root just sign a CRL with its own
certificate's serial number on it? Presumably at that point any
application retrieving such a CRL would note revocation of the root
certificate, and from that point forward would refuse to recognize as
valid any certificates chaining up to the root, any subsequent CRLs
signed by the root, and so on. Or am I missing something?

Frank Hecker

unread,
Oct 17, 2008, 9:57:17 AM10/17/08
to
Nelson Bolyard wrote:
> Frank Hecker wrote:
>> * OCSP. My understanding is that the Microsec practice of having a
>> separate root for OCSP is very problematic, particularly given the
>> inclusion of AIA extensions with OCSP URLs in end entity certificates.
>> As I understand it, Microsec is removing AIA extensions with OCSP URLs
>> from end entity certificates and from intermediate CA certificates, and
>> this should address this problem going forward.
>
> ... after some period of time has elapsed. Certainly the day after they
> begin to issue certs without the OCSP URL in the AIA extension, 99+% of the
> existing certs will still have those AIA extensions. Over time that number
> should decline.

Please refresh my memory here: As I understand it, the basic problem was
that if the Microsec root were included in Firefox (or other products)
and a user surfed to an SSL/TLS-enabled site with an end entity
certificate issued by Microsec (a cert with the AIA extension with the
OCSP URL), then this would cause an error in Firefox 3, because Firefox
3 does OCSP checking by default and it would get what it considered to
be a bad OCSP response. Do I have this right?

> At what point does it become appropriate to consider the problem to have
> abated enough to no longer be an issue? Is it when the number of remaining
> outstanding valid certs that bear that AIA extension is 90%? 50%? 20%? 10%?
> 5%? 1%?

I think it is in Microsec's interest to revoke and reissue certificates
for sites that encounter problems with Firefox. I would consider this
problem to be effectively addressed after Microsec actively begins an
initiative to work with its affected customers to get them new
certificates. At that point if customers do not update their sites IMO
it is their problem, not Microsec's or Mozilla's.

If approved, the Microsec root would not go into Firefox 3 until late
this year or early next year. So I think there is plenty of time for
Microsec to put together a suitable plan for how to ease the transition
for its customers and minimize any errors that might be experienced by
Firefox users.

> Although we haven't tested it with libPKIX, as far as I know, OCSP URLs
> in root certs will not be a problem for NSS. NSS will never check a
> self-issued cert for OCSP revocation.

Thanks for looking into this. My conclusion is therefore that there is
no need for Microsec to reissue its root certificate, at least as far as
Mozilla is concerned. However as Rob Stradling noted, I do suggest that
Microsec look at what GlobalSign did with its root refresh, in case
Microsec wants to do something similar in the future. (I should also
note that if Microsec's current root is approved for inclusion, I would
give expedited approval to any future refresh of the root, as long as
nothing had changed in terms of Microsec's operations and there were no
technical problems with the new root.)

One final question: Does anyone know what Thunderbird 3 will be doing in
terms of OCSP checks? Will this problem affect end entity certificates
issued by Microsec for S/MIME use?

Nelson B Bolyard

unread,
Oct 17, 2008, 12:47:45 PM10/17/08
to mozilla's crypto code discussion list
Frank Hecker wrote, On 2008-10-17 06:57:

> Please refresh my memory here: As I understand it, the basic problem was
> that if the Microsec root were included in Firefox (or other products)
> and a user surfed to an SSL/TLS-enabled site with an end entity
> certificate issued by Microsec (a cert with the AIA extension with the
> OCSP URL), then this would cause an error in Firefox 3, because Firefox
> 3 does OCSP checking by default and it would get what it considered to
> be a bad OCSP response. Do I have this right?

Yes. Bad response, ugly errors, no fun.

> One final question: Does anyone know what Thunderbird 3 will be doing in
> terms of OCSP checks? Will this problem affect end entity certificates
> issued by Microsec for S/MIME use?

I would expect it to be identical to FF3. They use the same PSM and NSS.

Frank Hecker

unread,
Oct 17, 2008, 1:20:04 PM10/17/08
to
Nelson B Bolyard wrote:
>> One final question: Does anyone know what Thunderbird 3 will be doing in
>> terms of OCSP checks? Will this problem affect end entity certificates
>> issued by Microsec for S/MIME use?
>
> I would expect it to be identical to FF3. They use the same PSM and NSS.

Thanks for the answer. Given the current schedule for Thunderbird 3 and
the low usage of signed/encrypted email, it's not as critical IMO to
address the situation with regard to Microsec certificates usable for
S/MIME. What I'd like to see from Microsec is a plan to first address
fixing certificates for SSL/TLS web sites (to prevent problems with
Firefox 3) and then to proceed to resolving any issues with certs usable
for S/MIME (to prevent problems with Thunderbird 3).

Eddy Nigg

unread,
Oct 17, 2008, 1:21:49 PM10/17/08
to
Frank Hecker:

>
> I'm not sure what you mean by "repeating the process". How would such
> revocation work in practice (assuming a PKI library that did CRL
> checking for roots)? Would the root just sign a CRL with its own
> certificate's serial number on it? Presumably at that point any
> application retrieving such a CRL would note revocation of the root
> certificate, and from that point forward would refuse to recognize as
> valid any certificates chaining up to the root, any subsequent CRLs
> signed by the root, and so on. Or am I missing something?
>

That's entirely and implementation issue and design approach. If we
assume that the root is built-in (and valid), every time a certificate
issued by this root (or sub roots) is encountered, it will read the CRL
and refuse to connect (or whatever). Depending on the CRL life time, I
expect the application to repeat the CRL checking over and over again
until the root is removed. But such an implementation may vary.

However I don't want to start an endless debate about the
egg-and-chicken problem here. The principal guiding my thought is, that
with the same authority the root was (self)signed, it should be possible
to mark the self-signed certificate invalid.

Nelson B Bolyard

unread,
Oct 17, 2008, 2:13:48 PM10/17/08
to mozilla's crypto code discussion list
Ian G wrote, On 2008-10-17 03:28:

> Nelson Bolyard wrote:
>> NSS will never check a self-issued cert for OCSP revocation.

To clarify, the PRESENT RELEASE of NSS will never check a self-issued
cert for OCSP revocation. Future releases may do different things.

> Ah, ok, excellent, that helps with the big question: Can we
> conclude from this that roots cannot be revoked by means of the
> OCSP/CRL channel?

In the present release, yes, we can conclude that.

> (Therefore they can only really be replaced by an adjustment to the
> root list?)

The user can always add/delete certs and/or set/unset trust on certs.

> This notion of revoking the root has been floating around for some
> time in various places, but never with the hard facts of whether it
> is possible.

It's possible, but we've chosen not to do it in NSS.

> And -- broader question for the policy wonks as well as the coders
> -- are we actually happy that this is a good thing: revocation of
> roots is not a CRL/OCSP possibility? Should we write this up as a
> policy statement somewhere? Or should we treat it as a bug to be
> filed & fixed?

A root that revokes itself invokes the liar's paradox.
NSS wishes to avoid the fate of the android Norman. :)

Rather than having roots be self-revoking, a somewhat better model is
to have a Uber-CA service that cross certifies other root CAs and
potentially revokes its own cross certifications. Some of the participants
in this list have previously advocated such a model. Maybe someone will
speak up.

> It would be nice to put a stake through the heart of this issue.

I won't bring it up again if you won't.

Ian G

unread,
Oct 17, 2008, 2:15:15 PM10/17/08
to mozilla's crypto code discussion list
Having read and mused on this "chicken and egg" problem, I see a
bunch of questions here. I doubt they will all be answered, but
food for thought:

1. If a root is compromised, how is it revoked and/or replaced?

2. If it is done by signing a revocation over self in CRL form, then:

a. Is NSS the authority on revocation, or is the application?

b. Once so revoked, are all following CRLs also "revoked"?

c. Or, are all certificates revoked?

d. Is a CA to escrow a pre-signed revocation, such as is suggested
in the PGP communities? Should this be stated, demanded, hidden,
ignored?

3. If not by self-signing, then:

a. Is removal from the root list a revocation? Semantically, is
that what removal means?

b. Is there a way in the root list (code) to signal that a root is
revoked (other than by a self-signed CRL of self)? E.g., by a flag
or something?

c. If not, how does the root list owner intend to "revoke" a root
when it goes rogue? For example, it is discovered that Acme CA Inc.
is now selling to scammers for bulk prices, or some other motive
where we can conveniently agree to employ the nuclear option.

d. Can Eddy send an unsigned email to Frank asking for revocation,
and explain how the entire hierarchy is toast because of some disaster?

e. Can anyone else? :)

4. It is also possible to ask these questions of subroots; e.g.,
do the CRLs of a revoked subroot now stop working, and/or, are all
certificates of that revoked subroot now "super-revoked" ?

5. At the higher or business or liability level, some observations:

a. CAs probably want some defined way to do root revocation.

b. Audit criteria and practices generally require some
consideration to be in place for disaster recovery, which would
suggest the CA to have in place a root compromise & replacement plan.

c. In serious, high availability or high value industries, there
would be fierce resistance to unanswered questions like this. No
single points of failure, etc.

d. Does Mozilla have an interest in stating some additional things
here, or is it content to leave it up to general business and/or
audit considerations?

6. A somewhat contrary position is that "the root should never be
compromised." Assuming that, one question with this position is
that it is the users and subscribers who lose, presumably, so it
seems troubling to set the user up that way.

iang

Paul Hoffman

unread,
Oct 17, 2008, 6:42:43 PM10/17/08
to mozilla's crypto code discussion list
At 11:13 AM -0700 10/17/08, Nelson B Bolyard wrote:
>A root that revokes itself invokes the liar's paradox.
>NSS wishes to avoid the fate of the android Norman. :)

Sorry, but that's a bit too glib. A "suicide note" is one valid method of trust anchor management. It does not invoke the liar's paradox if the semantics of the system accounts for it. PKIX doesn't have a standardized semantic for suicide notes, but a system such as NSS could create one. And, of course, such a semantic could be added to PKIX at any time, if the PKIX WG wanted to work on it.

>Rather than having roots be self-revoking, a somewhat better model is
>to have a Uber-CA service that cross certifies other root CAs and
>potentially revokes its own cross certifications. Some of the participants
>in this list have previously advocated such a model. Maybe someone will
>speak up.

I can speak up for it, but I am loathe to say it is "better" than suicide notes.

Having a trusted service that manages trust anchors for users can be very helpful. A trust anchor management protocol can also handle some of the problems that people have brought up on this list, such as wanting particular trust anchors to only cover constrained subsets of the naming tree. The downside is that few users know who they would trust to do this, and there has not been a good deployed model for making money running such a system other than in enterprises where the users have no choice. Thus, we muddle along with what we have today.

The advantage of suicide notes is that it can be completely clear what they mean. "If you see a message whose structure is A, signed by B, never use B in any position in any validation chain ever again." That's pretty darn simple. It is also much more limited than a full-blown trust anchor management system.

Eddy Nigg

unread,
Oct 17, 2008, 7:57:42 PM10/17/08
to
Ian G:

> b. Once so revoked, are all following CRLs also "revoked"?

The CRL would have to be valid until the expiration time of the root.

>
> c. Or, are all certificates revoked?

They are revoked due to the fact that the root is revoked....Revoking
recursive could also be an option.

> a. Is removal from the root list a revocation? Semantically, is
> that what removal means?

Yes, kind of. In the relation we are discussing it, it is. However roots
can be removed and not be revoked, the root being used elsewhere.
Removal doesn't imply automatically revocation, it can however.

>
> b. Is there a way in the root list (code) to signal that a root is
> revoked (other than by a self-signed CRL of self)? E.g., by a flag
> or something?

Not that I'm aware of.

>
> c. If not, how does the root list owner intend to "revoke" a root
> when it goes rogue? For example, it is discovered that Acme CA Inc.
> is now selling to scammers for bulk prices, or some other motive
> where we can conveniently agree to employ the nuclear option.

That's maybe a case for removal but not necessary a case for revocation.
It would be a one-sided action by the software vendor as opposed to an
action by the CA itself.

>
> d. Can Eddy send an unsigned email to Frank asking for revocation,
> and explain how the entire hierarchy is toast because of some disaster?

No, Eddy has other means to contact Frank and similar vendors.

>
> e. Can anyone else? :)

Asking yes. You can do that here.

>
> 4. It is also possible to ask these questions of subroots; e.g.,
> do the CRLs of a revoked subroot now stop working, and/or, are all
> certificates of that revoked subroot now "super-revoked" ?

Supposed CRLs would work with NSS like they do with MS software, all
certificates issued by that sub root would be invalid. For NSS this
would have to be a OCSP response.

>
> a. CAs probably want some defined way to do root revocation.
>
> b. Audit criteria and practices generally require some
> consideration to be in place for disaster recovery, which would
> suggest the CA to have in place a root compromise & replacement plan.

Indeed! CAs MUST have a disaster recovery plan. I also advocate for a
fair treatment of the CA by the software vendors like Mozilla in order
to give the CA a fair chance to recover from the disaster. This should
work as an incentive for CAs to really come forward in an efficient way
to prevent havoc (in case the issue wasn't highly published elsewhere).
The CA should be able - after discovering and correcting the error which
led to the compromise - to issue a new root and re-issue all
certificates and have the new root included in an efficient manner.
There shouldn't be too many strings attached - however a re-audit within
a reasonable time should be made mandatory (due to the lack of a yearly
audit requirement here).

> d. Does Mozilla have an interest in stating some additional things
> here, or is it content to leave it up to general business and/or
> audit considerations?

Beyond the above principal (if Mozilla decides to adopt it), the current
industry practice and audit requirements seem to me sufficient.


>
> 6. A somewhat contrary position is that "the root should never be
> compromised."

Yes :-)

But there are scenarios this could happen - even if technically it
wouldn't be possible to compromise the root.

Eddy Nigg

unread,
Oct 17, 2008, 8:11:39 PM10/17/08
to
Paul Hoffman:

> At 11:13 AM -0700 10
>
> I can speak up for it, but I am loathe to say it is "better" than suicide notes.

I like the phrase "suicide note"....that what it really is :-)

>
> Having a trusted service that manages trust anchors for users can be very helpful.

NSS itself is a trust anchor, the CA certificates are signed into
certdata.txt upon the request of Frank.

> The advantage of suicide notes is that it can be completely clear what they mean.

Indeed! Even though I believe that the big software vendors would act
relatively speedily upon such an event, a CRL issued by the CA is way
faster. It would also reach other and smaller applications and libraries
(vendors) which the CA most likely isn't able to reach in the same
manner as the four or five big browser vendors.

One of the problems we have with NSS is however that it doesn't care
much about CRL's. Albeit an entirely different issue, but I wonder what
that patent is, which is holding NSS back and I question the validity of
such a patent (of CRLDP). Did anybody ever try to challenge that patent?
How can embedding a URI into an X.509 extension be patented??

Frank Hecker

unread,
Oct 17, 2008, 10:27:56 PM10/17/08
to
Eddy Nigg wrote:
>> b. Is there a way in the root list (code) to signal that a root is
>> revoked (other than by a self-signed CRL of self)? E.g., by a flag
>> or something?
>
> Not that I'm aware of.

I don't know if this is what Ian was referring to, but in theory we can
leave the root certificate in NSS but set the "trust flags" off. This
would result in rejecting any use of a certificate whose cert chain
terminated in that root. Note that we've never actually done this for
any root.

Note also that (I think) in this case a user could manually set the
flags back to allow the root to be used again.

Eddy Nigg

unread,
Oct 17, 2008, 10:42:13 PM10/17/08
to
Frank Hecker:

> Eddy Nigg wrote:
>>> b. Is there a way in the root list (code) to signal that a root is
>>> revoked (other than by a self-signed CRL of self)? E.g., by a flag
>>> or something?
>>
>> Not that I'm aware of.
>
> I don't know if this is what Ian was referring to, but in theory we can
> leave the root certificate in NSS but set the "trust flags" off. This
> would result in rejecting any use of a certificate whose cert chain
> terminated in that root. Note that we've never actually done this for
> any root.

Oh right, I completly forgot about that. I think I was too concentrated
about what the CA can do instead reading the question correctly...Ian
indeed asked about NSS (he calls it root list :-) ).

>
> Note also that (I think) in this case a user could manually set the
> flags back to allow the root to be used again.
>

Which isn't such a good idea. I think the only flag which should be
allowed in such a case would be the email flag. But I remember from some
bug that removal of the CA root nevertheless allows to read previously
encrypted mail, provided the EE cert was marked accordingly.

Frank Hecker

unread,
Oct 17, 2008, 10:45:13 PM10/17/08