Microtec CA inclusion request
Frank Hecker
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
> 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
> * 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
<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
> 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
<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
> Frank Hecker wrote, On 2008-10-02 14:43:
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
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
> 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
possibilities:
http://www.google.com/search?q=translate+hungarian+english&sourceid=navclient-ff&ie=UTF-8&rlz=1B3GGGL_enIL280IL280&aq=t
Nelson B Bolyard
> 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
> 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
> 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
>
> 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
there. (bug 370505)
-Kyle H
Jean-Marc Desperrier
> [...]
> 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
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
>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
> 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
> 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
>> 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
<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
> 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
>
> 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
> 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
-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
> 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
>> 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
>
> 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
>
> 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
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
> 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
> 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
> "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
<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
> 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
> 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.
>
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
> * 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
> > 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
> 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.)
>
> 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
>
> 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
> 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
> 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
> 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
>> 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
>
> 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
> 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
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
>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
> 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
> At 11:13 AM -0700 10
>
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
>> 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
> 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
> Paul Hoffman:
<snip>
>> 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.
Yes, but as I understand it what is being discussed here is a more
elaborate scheme whereby, for example, we (Mozilla) might run an actual
CA just for the purpose of cross certifying the roots that we accept.
Like Nelson, I can't remember who exactly was advocating this and what
their arguments for this proposal were.
> 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??
The issue was with regard to the CRLDP patent held by Entrust (which
inherited it from Nortel). It's a long story, but basically due to some
good work by Entrust and Sun the patent is no longer an issue as far as
NSS is concerned, and the NSS team is free to implement CRLDP
functionality in a future NSS release. I'll let them speak to exactly
what their plans are.
Kyle Hamilton
binding of the information in the certificate from the public key
contained in the certificate.
The trust of the public key as a trust anchor is a separate concept
from the binding of the information in the certificate. Even if an RP
gets the trust anchor as part of a certificate, and decides to accept
the trust anchor as a result of the information bound in that
certificate, the trust anchor isn't removed.
This doesn't really seem to make much sense to me, and I'd like to see
the "reason" code be used for CA CRL inclusions. "Key compromise"
should be a notification that the trust anchor needs to be removed
from the store, but other codes exist that would allow for a follow-up
CA root certificate being issued with that key (changing the name of
it, for example), without that key being removed from the trust
anchors list. (all 'trusted entities' should be allowed to 'terminate
the trust' on their side, since if they can no longer guarantee what
they're trusted for they should at least be able to tell everyone that
they don't want to be trusted anymore.)
-Kyle H
Eddy Nigg
> Yes, but as I understand it what is being discussed here is a more
> elaborate scheme whereby, for example, we (Mozilla) might run an actual
> CA just for the purpose of cross certifying the roots that we accept.
> Like Nelson, I can't remember who exactly was advocating this and what
> their arguments for this proposal were.
>
IIRC it was Ben Buksch? Otherwise memory is failing me...it was proposed
almost two years ago during the EV discussion I think.
The idea was dismissed because of the burden and responsibility to run
such a CA, the counter argument was, that certdata.txt has about similar
requirements. The idea never got beyond that I think...
>
> The issue was with regard to the CRLDP patent held by Entrust (which
> inherited it from Nortel). It's a long story, but basically due to some
> good work by Entrust and Sun the patent is no longer an issue as far as
> NSS is concerned, and the NSS team is free to implement CRLDP
> functionality in a future NSS release. I'll let them speak to exactly
> what their plans are.
>
That sounds like some great news! I just recently happened to come
across a comment at Bugzilla (I think of Kathleen) where the patent
issue was mentioned once again...so libpkix will have it? Nelson?
--
Kaspar Brand
> Frank Hecker wrote, On 2008-10-17 06:57:
>
>> 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?
>
With the default settings in Firefox 3, it isn't that bad... remember
that it's the "graceful failure" mode which is selected by default:
> 1056 PRBool ocspRequired;
> 1057 pref->GetBoolPref("security.OCSP.require", &ocspRequired);
> 1058 if (ocspRequired) {
> 1059 CERT_SetOCSPFailureMode(ocspMode_FailureIsVerificationFailure);
> 1060 }
> 1061 else {
> 1062 CERT_SetOCSPFailureMode(ocspMode_FailureIsNotAVerificationFailure);
> 1063 }
> 1064 }
[http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/manager/ssl/src/nsNSSComponent.cpp&rev=1.167&mark=1056-1063#1056]
And in Firefox 2, OCSP is disabled by default anyway.
Frank Hecker wrote:
> 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)
After a closer look, I think that the "Microsec OCSP issue" isn't really
one, at least for the foreseeable future. Looking at the OCSP URIs in
the chain served by https://rca.e-szigno.hu e.g., we see this list:
Method: PKIX Online Certificate Status Protocol
Location:
URI: "https://srv.e-szigno.hu/ocsp"
Method: PKIX Online Certificate Status Protocol
Location:
URI: "https://arca.e-szigno.hu/aocsp"
Method: PKIX Online Certificate Status Protocol
Location:
URI: "https://rca.e-szigno.hu/ocsp"
I.e., unless bugs 205436 or 92923 are worked on soon, using https OCSP
URIs will quite effectively prevent Mozilla clients from connecting to
this responder :-) [1] István, maybe you can confirm that in all the
certs issued so far you've only used https OCSP URIs?
Kaspar
[1] for NSS, cf.
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/certhigh/ocsp.c&rev=1.55&mark=2741-2746#2741
Ian G
> 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.
That is partly what I was thinking. It seems preferably to retain
the root certificate, so as to preserve the information, and set
some flags on it, rather than just remove it totally.
(I think Paul reported a case where Microsoft just refills any
removed roots?).
Then, it would be nice to have some way to positively set a
revocation. Perhaps a new flag which is "revoked". An untrust
flag, perhaps.
> Note that we've never actually done this for
> any root.
That is indeed a whole separate other (important) question!
I'd point to Eddy's comment at this stage, and underline his
remarks. When a CA is in trouble, then we should try and help the
CA to work with the damage and limit it, not make it harder to deal
with. Making it harder is likely to lead to adverse decisions in
the event. Conceivably, if there are no options to deal with this,
it could go as badly as being ignored totally.
(From finance, there is a pathological case where as a company gets
nearer to bankruptcy, it is encouraged to make decisions that take
it closer and closer to bankruptcy ... the analogue here is that if
there are no "easy options" to do the right thing, then likely a
compromise will be buried rather than dealt with.)
For this motive, I would also wonder whether there is merit in a
"revoked-limited" possibility that just revokes the root, and
another "revoked-recursive" that also revokes all the issued certs.
That would give the CA more ability to survive a lesser compromise.
> Note also that (I think) in this case a user could manually set the
> flags back to allow the root to be used again.
And, the user might be entirely justified in turning them on! For
this reason, a positive flag would be preferable, so that we
eliminate any misunderstanding.
iang
Anders Rundgren
Anders
István Zsolt BERTA
> URIs will quite effectively prevent Mozilla clients from connecting to
> this responder :-) [1] István, maybe you can confirm that in all the
> certs issued so far you've only used https OCSP URIs?
Yes, they all contain https OCSP URLs.
> 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".
According to ETSI TS 101 903, they may include the root certificates,
it is optional.
In our case, they always include the root certificates. We would like
to avoid the problem of an application rejecting a signature simply
because the root certificate it contains is not among the root
certificates it trusts. Applications may handle this problem
differently, and it may be possible that an application rejects a
signature because of comparing the root certificates and not their DN-
s. Many applications are not under our control.
> 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.
Fortunately, we do not have many customers with SSL certificates.
(However, some certificates are at very prestigious places, like the
Hungarian governmental portal.) If our request is approved, we can
contact each of our clients and offer them replacement certificates.
I do not see any problem with this.
> 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).
In case of SSL certificates, we have removed the OCSP URL from the
certificates, this solves the problem on the short run.
On the long run, we plan to introduce an OCSP service that is usable
for the general public, i.e. that does not require authentication and
works using the 'authorized responder' concept. This week we had a
discussion with the National Communications Authority, we shall be
able to issue OCSP responder certificates with our CAs, even with CAs
that sign qualified certificates.
We plan to solve the problem with certificates used for S/MIME this
way.
However, this requires major modifications to our system, we shall be
able to perform this during the first half of the next year.
Nelson B Bolyard
> Nelson B Bolyard wrote:
>> Yes. Bad response, ugly errors, no fun.
>
> With the default settings in Firefox 3, it isn't that bad... remember
> that it's the "graceful failure" mode which is selected by default:
>
Don't forget the OCSP checks done in cert manager, and the effect of
failed OCSP checks on the behavior of cert manager.
Eddy Nigg
> On the long run, we plan to introduce an OCSP service that is usable
> for the general public, i.e. that does not require authentication and
> works using the 'authorized responder' concept. This week we had a
> discussion with the National Communications Authority, we shall be
> able to issue OCSP responder certificates with our CAs, even with CAs
> that sign qualified certificates.
István, I think this is really what you should do. I understand you are
on the best way to have this going!
Paul Hoffman
>Yes, but as I understand it what is being discussed here is a more elaborate scheme whereby, for example, we (Mozilla) might run an actual CA just for the purpose of cross certifying the roots that we accept. Like Nelson, I can't remember who exactly was advocating this and what their arguments for this proposal were.
It doesn't have to be a CA: it has to be a trusted service of some sort. For example, see the TAMP work currently being discussed in the PKIX WG.
Kaspar Brand
With Firefox 3, cert manager no longer validates certs (the "Purposes"
column was removed). In cert viewer, OCSP failures might indeed be an
issue, correct.
However, importing the "Microsec e-Szigno Root CA" from
http://srv.e-szigno.hu/menu/RootCA.crt, enabling trust for SSL and then
navigating to https://arca.e-szigno.hu works quite well with the default
validation settings in Firefox 3 - cert viewer will even say that the
cert has been verified for use as an "SSL Server Certificate".
Enabling "hard failure" mode for OCSP and then visiting
https://arca.e-szigno.hu/ is no fun, admittedly... but the error message
is somewhat misleading (SEC_ERROR_OCSP_MALFORMED_REQUEST, "The OCSP
server found the request to be corrupted or improperly formed", should
better be SEC_ERROR_CERT_BAD_ACCESS_LOCATION [1]).
Kaspar
Julien R Pierre - Sun Microsystems
Eddy Nigg wrote:
> 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.
If the root could "revoke itself", in the case of root cert key
compromise, ie. the root cert's private key becoming public, anybody
could then sign revocation information for that root CA - whether to
mark it revoked or unrevoked. The revocation therefore always has to
come from a higher level than the root cert iteslf.
There are several solutions in the case of NSS/PSM :
1) update the root cert module to one that no longer includes those root
certs
2) update the root cert module to one that includes those root certs,
but has them explicitly marked untrusted
3) without updating any software, marking the compromised root cert as
untrusted . This can be done manually in PSM .
Julien R Pierre - Sun Microsystems
Ian G wrote:
> 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?
Roots cannot be revoked by OCSP/CRL channels. You only need to read PKIX
standards (RFC3280 for one) to figure that out. Trust anchors are
outside the scope of these revocation protocols.
> (Therefore they can only really be replaced by an adjustment to the
> root list?)
Correct.
> 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?
You should take that up with the IETF if you want the CRL and OCSP
protocols changed to allow root revocation.
IMO, the more roots we have in NSS/PSM, the greater likelihood it is
that one of them will be compromised one day.
We should be prepared for the eventuality and we have several means of
dealing with that, which I just described in another post to Eddy.
Unfortunately there is no standards-compliant way of dealing with that
problem in general.
Julien R Pierre - Sun Microsystems
Eddy Nigg wrote:
> That's entirely and implementation issue and design approach.
No. It is also an issue of PKIX standards as well. CAs should not
implement revocation mechanisms that are not standard, and expect them
to be supported by general-purpose software like NSS/Mozilla.
Julien R Pierre - Sun Microsystems
Ian G wrote:
> 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?
By means of marking that cert as untrusted , or deleting that cert if
possible (which it's not in the case of the nssckbi root cert module).
> 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?
NSS is not an "authority" - it is a software library and merely
implements open standard PKIX protocols. It works with whatever standard
data you feed it.
Perhaps you are referring specifically to the root cert module component
of NSS, which is merely a bundled list of CA certs. It's possible to
write NSS applications and not use the root cert module. Many corporate
applications do so.
> b. Once so revoked, are all following CRLs also "revoked"?
Certificates get revoked. CRLs don't get revoked.
In general, revocation is for a given issuer and serial number.
> 3. If not by self-signing, then:
>
> a. Is removal from the root list a revocation? Semantically, is
> that what removal means?
Removal from the root list accomplishes a similar goal to revocation -
the cert is no longer present, and thus is no longer trusted.
Any cert that would be so removed would have a lesser status which is
untrusted by default, much the same as the CA you are using to sign your
messages.
Marking the CA cert as untrusted is another way to do the same thing.
> 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?
You can mark certs as untrusted in the root cert module. You can't mark
them as trusted.
The root cert module could be enhanced to also contain
standards-compliant CRLs, but no such CRL can be formed to revoke roots
because they have no issuer above them.
> 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.
Either by deleting the root CA from nssckbi, or marking it untrusted in
an update version, or updating the cert DB during upgrade to mark it
untrusted.
> 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? :)
I would hope so. And that would be treated as a security-sensitive bug.
> 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" ?
There is no need to reinvent any protocol. If a particular CA is no
longer trusted, then automatically none of the certs that chain back to
it are valid anymore. Same for CRLs.
> 5. At the higher or business or liability level, some observations:
>
> a. CAs probably want some defined way to do root revocation.
This problem appears to have been handled in a vendor-specific manner so
far.
Julien R Pierre - Sun Microsystems
Eddy Nigg wrote:
> 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.
Remember that CRLs don't expire. The application can consider them
either valid or invalid based on the certification path of the issuer of
the CRL.
Eddy Nigg
Yes correct! Perhaps I should have suggested, that it would be
interesting to have such an approach working in some form because the CA
could react the fastest for all applications which would implement that
approach. It could be a different key under the CA control or something
else as a first defense (but not on the application level like NSS).
My concern is, that reaching all applications, libraries and users which
don't upgrade/update regularly (if at all and very late) is very
difficult to accomplish. Instead, a revocation mechanism under the CAs
control (and perhaps out of reach, with special controls in place) would
be more efficient.
> If the root could "revoke itself", in the case of root cert key
> compromise, ie. the root cert's private key becoming public, anybody
> could then sign revocation information for that root CA - whether to
> mark it revoked or unrevoked.
Correct, however the CRLDP is included in the original certificate which
is embedded into the software. This information isn't going to change.
It would require at least a DNS compromise on the subject BEFORE the
root would be marked revoked. I guess there could be different
approaches for the application in having the root revoked at the first
possible opportunity.
In any case, the suggested best practice is to refrain from issuing
directly from the CA root and issue from intermediate CA certificates
instead. Everything remains under the CA control, including revocation.
Damage would be limited and controllable in such a case and that's
another reason why issuing directly from CA roots is under the
problematic practice charter:
https://wiki.mozilla.org/CA:Problematic_Practices#Issuing_end_entity_certificates_directly_from_roots
Eddy Nigg
Or until next update. It's still valid but not updated anymore.
Julien R Pierre - Sun Microsystems
Eddy Nigg wrote:
> Julien R Pierre - Sun Microsystems:
>> Eddy Nigg wrote:
>>> 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.
>>
>> Remember that CRLs don't expire. The application can consider them
>> either valid or invalid based on the certification path of the issuer
>> of the CRL.
>
> Or until next update. It's still valid but not updated anymore.
It still remains valid for the application to use an old CRL if it is
unable to obtain newer one, whatever the reason.
Eddy Nigg
>
> It still remains valid for the application to use an old CRL if it is
> unable to obtain newer one, whatever the reason.
I think that's what I said :-)
Ian G
this:
===============
https://wiki.mozilla.org/CA:Recommendations_for_Roots#SubRoots
Revocation of the Root [edit]
* For a root listed in Mozilla's root list, file a bug to
request the root be marked "untrusted". Once distributed, any certs
chained of the root will also be untrusted.
* This method may assist disaster recovery plans and audit
needs. There is currently no better method.
* There is no PKIX method for revoking a root, and CRL/OCSP only
revoke downwards. Root revocation is generally handled in a
vendor-specific way, CAs will need to contact other vendors
individually.
================
Revoke at will!
iang
Paul Hoffman
At 5:31 PM -0700 10/20/08, Julien R Pierre - Sun Microsystems wrote:
>If the root could "revoke itself", in the case of root cert key compromise, ie. the root cert's private key becoming public, anybody could then sign revocation information for that root CA - whether to mark it revoked or unrevoked. The revocation therefore always has to come from a higher level than the root cert iteslf.
This is not true at all. Only someone who knows the private key can sign the suicide note. Obviously, it is not in an attacker's best interest to sign it.
There is no "higher level" than a trust anchor. If you are using a trust anchor manager, they can pull a trust anchor out of your trust anchor pile, but that is quite different than revoking it.
At 5:34 PM -0700 10/20/08, Julien R Pierre - Sun Microsystems wrote:
>Roots cannot be revoked by OCSP/CRL channels. You only need to read PKIX standards (RFC3280 for one) to figure that out. Trust anchors are outside the scope of these revocation protocols.
Correct.
>You should take that up with the IETF if you want the CRL and OCSP protocols changed to allow root revocation.
Good lord, no. If you follow the IETF's PKIX WG, you will see that they take forever to finish something and it often comes out much worse than when it went in. Well, that was true in the past; now, most people are just burnt out and not saying anything.
If you want to to be able to "revoke" roots, please consider instead getting active in the current work on TAMP (trust anchor management protocol) being discussed in the PKIX WG. It's a large protocol, but that's because the initial work was done before coming to the IETF. The authors are genuinely interested in getting feedback on the proposal, and they are getting too little in the WG.
The main different between TAMP and revoking trust anchors is that TAMP is run by a trusted party who might or might not listen to a trust anchor owner who says "please revoke me". The advantage of TAMP is that trusted party might revoke *before* the trust anchor owner wants people to in an iffy situation.
I can certainly see Mozilla running TAMP instead of relying on the update process to add and remove trust anchors. Pulling in another thread from this list, TAMP allows the trusted party to put limitations on a trust anchor, such as "only good for signing keys with names in *.com" and so on; that information doesn't need to reside in the trust anchor itself.
My two cents....
--Paul Hoffman
Frank Hecker
> If you want to to be able to "revoke" roots, please consider instead
> getting active in the current work on TAMP (trust anchor management
> protocol) being discussed in the PKIX WG.
Thanks for the suggestion; I presume that
http://www.ietf.org/internet-drafts/draft-ietf-pkix-tamp-00.txt
is the main document of interest?
At first glance this looks interesting, though I haven't yet read it in
detail.
Kyle Hamilton
<julien.pie...@sun.com> wrote:
>
> If the root could "revoke itself", in the case of root cert key compromise,
> ie. the root cert's private key becoming public, anybody could then sign
> revocation information for that root CA - whether to mark it revoked or
> unrevoked. The revocation therefore always has to come from a higher level
> than the root cert iteslf.
I would think that it would be easier just to say that if a root is
EVER marked revoked, it should be automatically untrusted. (the
'suicide note' concept.)
(Perhaps I'm thinking of something far too much like PGP's capability
to revoke assurances on identities associated with a key, and the
ability of a key to sign a revocation certificate for itself that can
be propagated to the keyservers. I don't know if X.509 or the PKIX
has a means of creating a separate revocation certificate which can be
considered bound to the key the same way an identity can be bound.)
> There are several solutions in the case of NSS/PSM :
> 1) update the root cert module to one that no longer includes those root
> certs
> 2) update the root cert module to one that includes those root certs, but
> has them explicitly marked untrusted
> 3) without updating any software, marking the compromised root cert as
> untrusted . This can be done manually in PSM .
Another problem with X.509 is one that MS's "Friendly Certificate
Name" concept was supposed to handle... the CA is identified by the
CA's Subject Name, and authenticated with its public key. This means
that it's very difficult to change the Subject name to include
information like "compromised and untrusted as of [date]" so that
people don't blithely add trust flags that have been removed by people
who have more information.
-Kyle H
Paul Hoffman
>Paul Hoffman wrote:
>>If you want to to be able to "revoke" roots, please consider instead
>>getting active in the current work on TAMP (trust anchor management
>>protocol) being discussed in the PKIX WG.
>
>Thanks for the suggestion; I presume that
>
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-tamp-00.txt
>
>is the main document of interest?
Yep. A more time-invariant way to reach the draft is at:
http://tools.ietf.org/html/draft-ietf-pkix-tamp
There is also a requirements document that the protocol is supposed to match at:
http://tools.ietf.org/html/draft-ietf-pkix-ta-mgmt-reqs
>At first glance this looks interesting, though I haven't yet read it in detail.
The requirements document is much shorter and more digestable than the protocol itself.
Again, feel free to comment on either on the PKIX WG mailing list. There appears to be a lot of interest but few commenters.
Julien R Pierre - Sun Microsystems
Kyle Hamilton wrote:
> On Mon, Oct 20, 2008 at 5:31 PM, Julien R Pierre - Sun Microsystems
> <julien.pie...@sun.com> wrote:
>> If the root could "revoke itself", in the case of root cert key compromise,
>> ie. the root cert's private key becoming public, anybody could then sign
>> revocation information for that root CA - whether to mark it revoked or
>> unrevoked. The revocation therefore always has to come from a higher level
>> than the root cert iteslf.
>
> I would think that it would be easier just to say that if a root is
> EVER marked revoked, it should be automatically untrusted. (the
> 'suicide note' concept.)
There is no trace of "suicide note" in any PKIX standard.
NSS does not arbitrarily mark certificates as revoked. The database
trust flags include "trusted" and "untrusted" for specific purposes, but
not revoked.
NSS only declares a cert as revoked if it finds evidence of it during
the processing standards-compliant revocation methods such as OCSP and CRLs.
I don't think root-signed CRLs would be particularly adequate to
implement "suicide notes" because :
a) there is no "last CRL" . A newer one can always be issued
b) how can you trust the CA's key that signed the CRL if it's been
compromised ?
c) if the CA's key has been compromised, you would also have to deal
with the potential problem of "resurrection note" in a CRL, where a
serial number is removed from the CRL.
This is against PKIX standards except if the reason code was "on hold".
however, a client that would only obtain the "latest" CRL could be
unaware of the "previous" CRL containing a suicide note.
In cases where the root is revoked for reasons other than a root CA key
compromise, this method *could* work. But I still think marking the root
as not trusted is more desirable.
> (Perhaps I'm thinking of something far too much like PGP's capability
> to revoke assurances on identities associated with a key, and the
> ability of a key to sign a revocation certificate for itself that can
> be propagated to the keyservers. I don't know if X.509 or the PKIX
> has a means of creating a separate revocation certificate which can be
> considered bound to the key the same way an identity can be bound.)
PKIX has the concept of indirect CRLs. I'm not sure if that could be
used for this case. Indirect CRLs are not mandated to be supported by
PKIX implementations. The scheme does not seem particularly secure, and
right now we have chosen not to implement indirect CRLs (even for libpkix).
>> There are several solutions in the case of NSS/PSM :
>> 1) update the root cert module to one that no longer includes those root
>> certs
>> 2) update the root cert module to one that includes those root certs, but
>> has them explicitly marked untrusted
>> 3) without updating any software, marking the compromised root cert as
>> untrusted . This can be done manually in PSM .
>
> Another problem with X.509 is one that MS's "Friendly Certificate
> Name" concept was supposed to handle... the CA is identified by the
> CA's Subject Name, and authenticated with its public key. This means
> that it's very difficult to change the Subject name to include
> information like "compromised and untrusted as of [date]" so that
> people don't blithely add trust flags that have been removed by people
> who have more information.
Why would you want to include revocation information in the subject name
? By definition revocation is separate from the certificate.
Julien R Pierre - Sun Microsystems
Kyle Hamilton wrote:
> On Mon, Oct 20, 2008 at 5:31 PM, Julien R Pierre - Sun Microsystems
> <julien.pie...@sun.com> wrote:
>> If the root could "revoke itself", in the case of root cert key compromise,
>> ie. the root cert's private key becoming public, anybody could then sign
>> revocation information for that root CA - whether to mark it revoked or
>> unrevoked. The revocation therefore always has to come from a higher level
>> than the root cert iteslf.
>
> I would think that it would be easier just to say that if a root is
> EVER marked revoked, it should be automatically untrusted. (the
> 'suicide note' concept.)
There is no trace of "suicide note" in any PKIX standard.
NSS does not arbitrarily mark certificates as revoked. The database
trust flags include "trusted" and "untrusted" for specific purposes, but
not revoked.
NSS only declares a cert as revoked if it finds evidence of it during
the processing standards-compliant revocation methods such as OCSP and CRLs.
I don't think root-signed CRLs would be particularly adequate to
implement "suicide notes" because :
a) there is no "last CRL" . A newer one can always be issued
b) how can you trust the CA's key that signed the CRL if it's been
compromised ?
c) if the CA's key has been compromised, you would also have to deal
with the potential problem of "resurrection note" in a CRL, where a
serial number is removed from the CRL.
This is against PKIX standards except if the reason code was "on hold".
however, a client that would only obtain the "latest" CRL could be
unaware of the "previous" CRL containing a suicide note.
In cases where the root is revoked for reasons other than a root CA key
compromise, this method *could* work. But I still think marking the root
as not trusted is more desirable.
> (Perhaps I'm thinking of something far too much like PGP's capability
> to revoke assurances on identities associated with a key, and the
> ability of a key to sign a revocation certificate for itself that can
> be propagated to the keyservers. I don't know if X.509 or the PKIX
> has a means of creating a separate revocation certificate which can be
> considered bound to the key the same way an identity can be bound.)
PKIX has the concept of indirect CRLs. I'm not sure if that could be
used for this case. Indirect CRLs are not mandated to be supported by
PKIX implementations. The scheme does not seem particularly secure, and
right now we have chosen not to implement indirect CRLs (even for libpkix).
>> There are several solutions in the case of NSS/PSM :
>> 1) update the root cert module to one that no longer includes those root
>> certs
>> 2) update the root cert module to one that includes those root certs, but
>> has them explicitly marked untrusted
>> 3) without updating any software, marking the compromised root cert as
>> untrusted . This can be done manually in PSM .
>
> Another problem with X.509 is one that MS's "Friendly Certificate
> Name" concept was supposed to handle... the CA is identified by the
> CA's Subject Name, and authenticated with its public key. This means
> that it's very difficult to change the Subject name to include
> information like "compromised and untrusted as of [date]" so that
> people don't blithely add trust flags that have been removed by people
> who have more information.
Why would you want to include revocation information in the subject name
Julien R Pierre - Sun Microsystems
Paul Hoffman wrote:
> I disagree with Julien on two items in this thread.
>
> At 5:31 PM -0700 10/20/08, Julien R Pierre - Sun Microsystems wrote:
>> If the root could "revoke itself", in the case of root cert key compromise, ie. the root cert's private key becoming public, anybody could then sign revocation information for that root CA - whether to mark it revoked or unrevoked. The revocation therefore always has to come from a higher level than the root cert iteslf.
>
> This is not true at all. Only someone who knows the private key can sign the suicide note. Obviously, it is not in an attacker's best interest to sign it.
If the root CA private key has been compromised, potentially anybody
could sign "suicide notes", provided an actual format existed for them.
That's the definition of a private key compromise - the private key fell
into the wrong hands. For example, the private key might have been
extracted, or cracked and posted on a public website, in an extreme case.
If you use a format such as a CRL for the "suicide note", then you have
to potentially deal with other problems such as "resurrection notes".
This is a fairly theoritical discussion anyway since suicide notes don't
exist in PKIX.
>> You should take that up with the IETF if you want the CRL and OCSP protocols changed to allow root revocation.
>
> Good lord, no. If you follow the IETF's PKIX WG, you will see that they take forever to finish something and it often comes out much worse than when it went in. Well, that was true in the past; now, most people are just burnt out and not saying anything.
Myself included, I haven't been on the IETF list for a while. However,
this is really the process that we are stuck with. There is little point
in trying to come up with some generic root revocation scheme if you are
going to be the only one using it in the end. I don't really see how
that's better than a proprietary mechanism like the mozilla update process.
> If you want to to be able to "revoke" roots, please consider instead getting active in the current work on TAMP (trust anchor management protocol) being discussed in the PKIX WG. It's a large protocol, but that's because the initial work was done before coming to the IETF. The authors are genuinely interested in getting feedback on the proposal, and they are getting too little in the WG.
Thanks for the pointer. I will take a look.
Gervase Markham
> compromise, ie. the root cert's private key becoming public, anybody
> could then sign revocation information for that root CA - whether to
> mark it revoked or unrevoked.
Leaving aside the question of what the standards say for just a moment,
what's wrong with that in principle? If you know a private key has been
compromised, most of the time you still have the key - so why shouldn't
or couldn't it be used to sign its own suicide note?
Gerv
Paul Hoffman
Quite right. The flip side of this is that if *anyone* other than the person who generated the key pair has they public key, they *should* sign the suicide note and distribute it because if they have it, a bad actor could have it as well.
Julien R Pierre - Sun Microsystems
I don't think we can really leave the standards out of it. One of the
main problems is how a client is going to read the suicide note. Not
everybody is at the scene of the crime to read it.
Julien R Pierre - Sun Microsystems
Yes, they should ... But the big question is how do they actually do
that and get software to take notice of that suicide note ?
I don't think that can really be done without standards.
Updating software with a new root module is a lot simpler. Of course
that process has its own set of security issues as well.
Julien R Pierre - Sun Microsystems
Yes, they should ... But the big question is how do they actually do
Eddy Nigg
>
> Yes, they should ... But the big question is how do they actually do
> that and get software to take notice of that suicide note ?
> I don't think that can really be done without standards.
>
I think that's the key to solve the problem of this discussion. But due
to lacking standards, other solutions are looked at. I think this is
what happens here.
> Updating software with a new root module is a lot simpler. Of course
> that process has its own set of security issues as well.
>
Besides that, one of the problems is, how to reach each and every
software (including older or non-updated or smaller ones).
Eddy Nigg
>> Yes, they should ... But the big question is how do they actually do that and get software to take notice of that suicide note ?
>> I don't think that can really be done without standards.
>
>
+1
Julien R Pierre - Sun Microsystems
Paul Hoffman wrote:
>> Updating software with a new root module is a lot simpler. Of course that process has its own set of security issues as well.
>
> It also doesn't work for users who are using a different root module. "Barely traceable management action" != "open message protocol".
True. In that case the only solution is to mark the root as untrusted.
Also, note that if somebody modified the trust on a root cert previously
in any way, a copy of that cert and trust is made in the user's cert
database. The database trust always has priority over the root module's
trust. So, updating the root module alone for those users would not
suffice to disable the use of that root.
Resetting the trust for a root gone rogue could be accomplished in
update code programmatically, however.
Julien R Pierre - Sun Microsystems
Eddy Nigg wrote:
>> Updating software with a new root module is a lot simpler. Of course
>> that process has its own set of security issues as well.
>>
>
> Besides that, one of the problems is, how to reach each and every
> software (including older or non-updated or smaller ones).
I think generally, we don't try to solve security issues in older and no
longer supported software. A root compromise would fall under that category.
However, in this particular case, for all NSS-based software - a manual
solution exists for older applications : simply mark the root as untrusted.
Eddy Nigg
>
> However, in this particular case, for all NSS-based software - a manual
> solution exists for older applications : simply mark the root as untrusted.
If they happen to hear about it. Or if they happen to use an updated NSS
library. However reality shows that it takes quite some time until a new
version of NSS seeps to the application level, including with Mozilla's
own products (which would be by far the fastest). I'd expect that in an
emergency a new FF/TB/SM etc. version would be shipped, but for those
outside of Mozilla making use of NNS it might take month, even years.
I've mentioned initially at this thread, that revocation of CA roots has
its problems, but I haven't been able to define something better with
current tools. Apparently there is a shortcoming which needs to be
addressed at some point.
Ian G
> Paul Hoffman wrote:
>> At 4:39 PM +0100 10/22/08, Gervase Markham wrote:
>>> Julien R Pierre - Sun Microsystems wrote:
>>>> If the root could "revoke itself", in the case of root cert key
>>>> compromise, ie. the root cert's private key becoming public, anybody
>>>> could then sign revocation information for that root CA - whether to
>>>> mark it revoked or unrevoked.
>>> Leaving aside the question of what the standards say for just a moment,
>>> what's wrong with that in principle? If you know a private key has been
>>> compromised, most of the time you still have the key - so why shouldn't
>>> or couldn't it be used to sign its own suicide note?
>>
>> Quite right. The flip side of this is that if *anyone* other than the
>> person who generated the key pair has they public key, they *should*
>> sign the suicide note and distribute it because if they have it, a bad
>> actor could have it as well.
I think we all understand that the basic concept of a root-signed
self-revocation is workable, in principle, at the information level.
There may be substantial implementation questions...
> Yes, they should ... But the big question is how do they actually do
> that and get software to take notice of that suicide note ?
Is there any reason why the message cannot be delivered by the
current channels? CRL, OCSP? Leaving aside the standards question,
that is...
Is a self-reference in a CRL or OCSP:
defined? Banned? Undefined? Going to cause chaos?
(Where, Chaos is defined as making matters worse for the software
that otherwise has to deal with a rogue root out in the wild serving
up the devil's contract every 3rd packet to grandma...)
It would seem that, if the root list is delivered by party A, and
the software is written by party A, and the revocation is
distributed to software of party A, then it should all tie together.
(Yes there will be some issues with party B. Refer to definition of
chaos.)
> Updating software with a new root module is a lot simpler. Of course
> that process has its own set of security issues as well.
Hey, if it's good enough for Debian ... ;)
iang
Kyle Hamilton
>>> Quite right. The flip side of this is that if *anyone* other than the
>>> person who generated the key pair has they public key, they *should*
>>> sign the suicide note and distribute it because if they have it, a bad
>>> actor could have it as well.
>
>
> self-revocation is workable, in principle, at the information level.
>
> There may be substantial implementation questions...
There are those who don't think so, since the operations defined at
the Root level include "revoking certificates" as well as "derevoking
certificates", via CRL.
There is no such thing as a "suicide note" in X.509 or PKIX.
(I was actually just thinking of this when I was trying to get a root
-- not in my control -- to mark a couple of certificates as revoked
due to key compromise. If there were such a thing as a "suicide
note", I could mark my own certificate as revoked and then submit it
to the CA for additional processing [such as adding it to CRLs and
OCSP responses].)
>> Yes, they should ... But the big question is how do they actually do
>> that and get software to take notice of that suicide note ?
>
>
> Is there any reason why the message cannot be delivered by the
> current channels? CRL, OCSP? Leaving aside the standards question,
> that is...
CRLs are signed by the root itself. The CRL can be reissued by anyone
who has the key.
OCSP is usually handled by a delegated responder with its own identity
binding (and its own key). OCSP should be able to handle the case of
"the root is compromised" by responding to all certificates with
serial numbers in that root's space as being "invalid, key
compromise". However, this relies on the ability of the OCSP
responder to operate with a known-revoked certificate.
> Is a self-reference in a CRL or OCSP:
>
> defined? Banned? Undefined? Going to cause chaos?
Self-reference in CRL isn't a singular thing. Anyone with the root
key can reissue a CRL. GoodGuy issues one with the self-reference
saying "revoked, key compromised". BadGuy issues one with the
self-reference missing, since BadGuy wants people to still trust the
root. Thus, it's chaotic.
OCSP I've mentioned above.
> (Where, Chaos is defined as making matters worse for the software
> that otherwise has to deal with a rogue root out in the wild serving
> up the devil's contract every 3rd packet to grandma...)
>
> It would seem that, if the root list is delivered by party A, and
> the software is written by party A, and the revocation is
> distributed to software of party A, then it should all tie together.
>
> (Yes there will be some issues with party B. Refer to definition of
> chaos.)
I'd like to see Mozilla run its own CA and cross-certify its root
list. That way, Mozilla would be the "higher authority" and could
issue non-chaotic root revocations... by revoking the
cross-certifications.
-Kyle H
Ian G
> 2008/10/22 Ian G <ia...@iang.org>:
>>>> Quite right. The flip side of this is that if *anyone* other than the
>>>> person who generated the key pair has they public key, they *should*
>>>> sign the suicide note and distribute it because if they have it, a bad
>>>> actor could have it as well.
>>
>> self-revocation is workable, in principle, at the information level.
>>
>> There may be substantial implementation questions...
>
> There are those who don't think so,
At the level of information and in principle, and leaving standards
aside, I do not see any difficulties.
Then, drifting back from information principles to implementation
and standards issues, there will be substantial implementation
questions, such as the ones raised.
However, it is important to recognise that the difficulties are
found inside PKIX and x.509, not in the capabilities of computer
science, crypto or networks.
> since the operations defined at
> the Root level include "revoking certificates" as well as "derevoking
> certificates", via CRL.
So, a need to add a new operation, being "revoke self" for example.
> There is no such thing as a "suicide note" in X.509 or PKIX.
Adding one would be non-standard, yes.
> (I was actually just thinking of this when I was trying to get a root
> -- not in my control -- to mark a couple of certificates as revoked
> due to key compromise. If there were such a thing as a "suicide
> note", I could mark my own certificate as revoked and then submit it
> to the CA for additional processing [such as adding it to CRLs and
> OCSP responses].)
Indeed. But, that might be left for a later sanity check.
>>> Yes, they should ... But the big question is how do they actually do
>>> that and get software to take notice of that suicide note ?
>>
>> Is there any reason why the message cannot be delivered by the
>> current channels? CRL, OCSP? Leaving aside the standards question,
>> that is...
>
> CRLs are signed by the root itself. The CRL can be reissued by anyone
> who has the key.
The part means that the new CRL could de-include the root, thus
un-revoking it. So we would need:
* a root revocation is to be cached and not replaced.
Also, as CRLs should only be acquired from stated places that are
listed in the certificate, there shouldn't be a danger for existing
certs.
> OCSP is usually handled by a delegated responder with its own identity
> binding (and its own key). OCSP should be able to handle the case of
> "the root is compromised" by responding to all certificates with
> serial numbers in that root's space as being "invalid, key
> compromise". However, this relies on the ability of the OCSP
> responder to operate with a known-revoked certificate.
OK. It would seem to require two things:
* an extra flag that says "compromised because root compromised"
(I don't know whether OCSP has flags or not...)
* a semantic leap of "all certs except my own compromised"
(to join the other semantic leaps inherent in the root)
These three things don't sound so much, but I'd like to hear what
the coders say as to how worthwhile this is. It could just be more
trouble than it is worth?
>> Is a self-reference in a CRL or OCSP:
>>
>> defined? Banned? Undefined? Going to cause chaos?
>
> Self-reference in CRL isn't a singular thing. Anyone with the root
> key can reissue a CRL. GoodGuy issues one with the self-reference
> saying "revoked, key compromised". BadGuy issues one with the
> self-reference missing, since BadGuy wants people to still trust the
> root. Thus, it's chaotic.
I don't quite see that. CRLs and OCSP checks are acquired from
places listed inside the certs. So the bad guy would have to
compromise the delivery of certs as well as the root itself.
(If that happens, it might be fairer to say that the business is
taken over rather than the root compromised :)
Now, one can imagine weird cyclical loops, so it would make sense of
engineering to add "stickiness" to the CRL as suicide note.
This would probably indicate a special CRL that included only one
identified cert, the root, and became "sticky".
> OCSP I've mentioned above.
>
>> (Where, Chaos is defined as making matters worse for the software
>> that otherwise has to deal with a rogue root out in the wild serving
>> up the devil's contract every 3rd packet to grandma...)
>>
>> It would seem that, if the root list is delivered by party A, and
>> the software is written by party A, and the revocation is
>> distributed to software of party A, then it should all tie together.
>>
>> (Yes there will be some issues with party B. Refer to definition of
>> chaos.)
>
> I'd like to see Mozilla run its own CA and cross-certify its root
> list. That way, Mozilla would be the "higher authority" and could
> issue non-chaotic root revocations... by revoking the
> cross-certifications.
A possibility. Some thoughts:
How do we revoke Mozilla's root?
How does the CRL / OCSP get delivered / run? Are we now asking each
certificate check to also chain up and check two or more OCSPs?
Can we eliminate the whole CA notion by just using a single sig over
the list from a "root" ... and just deliver signed updates?
I suppose another thing that could be done is: Each CA can run its
own cross-CA. That is, each CA runs two roots. It then treats both
root as independent business units, to the extent that it desires.
Each may revoke the other. Each CA can then submit the two roots,
to Mozo's root list, and the software sorts out how the cross
linking goes.
Downside of this is complexity, and costs for the smaller players
(certain large players finding it trivial). Also are we back to
chaining the OCSP checking up another layer?
It's good to have this debate and thrash out some ideas. I would
like to conclude it one way or another; it would be nice to see
just how far and how reliable revocation is. There is another
niggling contradiction with revocation:
The less reliable it is, the less useful is reliance. If reliance
isn't useful, then the cert isn't valuable. So, for example, if we
can make CRLs/OCSP optional, that also means we can lower the cost
of practically everything.
OTOH, if we want to make it more reliable, such that it is plausible
to rely on it, then it needs to be online and real time. Hence
let's make OCSP obligatory.
But if that is the case, then you don't need the cert, just the key,
because you can get all the content info in the online revocation
checkup. So, if we implement OCSP fully, we are now ready to
re-engineer the system (because once all the clients are engineered
to deal with those flows, changing the messages is a snap).
So right now, it is Mozo's wish that certificates be reliable and
that revocation be strong and OCSP be online and solid.... However
there are limits to that, it may be that the last thing we want is
to make all the processes super-strong; and include things like
root revocation.
iang
PS: This is mirrored at the business level, but another day...
Julien R Pierre - Sun Microsystems
Ian G wrote:
> Is there any reason why the message cannot be delivered by the
> current channels? CRL, OCSP?
Yes, there is one : the fact that trust anchors are specifically
excluded from CRL and OCSP revocation checking in PKIX standards.
In other words, no PKIX-compliant software, including but not limited to
NSS, is ever going to try to look for CRLs or check OCSP revocation
status for a root.
Leaving aside the standards question,
> that is...
I don't think we can leave it out . That is the core issue.
> Is a self-reference in a CRL or OCSP:
>
> defined? Banned? Undefined? Going to cause chaos?
Undefined.
> (Where, Chaos is defined as making matters worse for the software
> that otherwise has to deal with a rogue root out in the wild serving
> up the devil's contract every 3rd packet to grandma...)
That would completely depend on how you are making that special CRL
available.
Most likely, NSS/PSM, would never even obtain it, so it would not do
anything at all.
> It would seem that, if the root list is delivered by party A, and
> the software is written by party A, and the revocation is
> distributed to software of party A, then it should all tie together.
And it could - party A can deliver a revised root list.
>> Updating software with a new root module is a lot simpler. Of course
>> that process has its own set of security issues as well.
>
>
> Hey, if it's good enough for Debian ... ;)
I don't have any what Debian does, but I would prefer we don't stray too
much off topic. We could talk about the Mozilla clients update process,
but that would deserve at least its own thread here. And I have no
involvement with it, nor much of the NSS team.
Julien R Pierre - Sun Microsystems
Kyle Hamilton wrote:
>> I think we all understand that the basic concept of a root-signed
>> self-revocation is workable, in principle, at the information level.
>>
>> There may be substantial implementation questions...
>
> There are those who don't think so, since the operations defined at
> the Root level include "revoking certificates" as well as "derevoking
> certificates", via CRL.
There is the matter of the "scope" of a CRL . You may want to read about
that. See section 5 of RFC3280 .
The CRL is always signed by a given CRL signer cert, which is outside of
the CRL scope.
> There is no such thing as a "suicide note" in X.509 or PKIX.
Indeed. And I'm not saying suicide notes are impractical - just that
they aren't defined by PKIX, and we probably would not want to implement
them as CRLs. At the very least they would not fit the existing
definitions for CRLs.
Julien R Pierre - Sun Microsystems
Ian G wrote:
> The part means that the new CRL could de-include the root, thus
> un-revoking it. So we would need:
>
> * a root revocation is to be cached and not replaced.
Which is something completely foreign to any PKIX standards today. There
is no persistence of any revocation information. Most software does not
even have it, certainly not for OCSP, and even CRLs are often fetched
into RAM only and then discarded when the software exits.
The PKIX standards explicitly require that current revocation always be
retrievable at any time for unexpired certificates. I think that's a
very reasonable requirement.
What about the case where somebody installs old software that contains a
revoked root ? How does he get the suicide note ?
If you are going to define suicide notes, you will have to ensure that
somebody is keeping track of all of them, and that software can get to
them again at any time.
> How do we revoke Mozilla's root?
By updating mozilla software :)
> How does the CRL / OCSP get delivered / run? Are we now asking each
> certificate check to also chain up and check two or more OCSPs?
>
> Can we eliminate the whole CA notion by just using a single sig over
> the list from a "root" ... and just deliver signed updates?
Have you read RFC3280 ?
> But if that is the case, then you don't need the cert, just the key,
> because you can get all the content info in the online revocation
> checkup.
Wrong. Multiple certs can use the same public key in X509, and
frequently do, especially in cases of cross-certification.
Thus you cannot retrieve everything else just from the key.
Also, even if it could be done, it would be much more of a strain on the
network to retrieve the whole cert content than just sending the serial
number and obtaining a status code + revocation reason as OCSP does.
Kyle Hamilton
...did the people who created PKIX just not realize that if a non-root
certificate needs the ability to be revoked, a root certificate would
also?
-Kyle H
> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
Julien R Pierre - Sun Microsystems
Eddy Nigg wrote:
> On 10/23/2008 12:34 AM, Julien R Pierre - Sun Microsystems:
>>
>> However, in this particular case, for all NSS-based software - a manual
>> solution exists for older applications : simply mark the root as
>> untrusted.
>
> If they happen to hear about it. Or if they happen to use an updated NSS
> library. However reality shows that it takes quite some time until a new
> version of NSS seeps to the application level, including with Mozilla's
> own products (which would be by far the fastest). I'd expect that in an
> emergency a new FF/TB/SM etc. version would be shipped, but for those
> outside of Mozilla making use of NNS it might take month, even years.
If a root ended up being compromised and we heard about it, I can assure
you that we would produce a new NSS release with an update root cert
module with all due haste - meaning probably within a couple of business
days.
The NSS team always maintains at least 2 versions - a "stable branch"
(currently 3.11.x) and current development version (currently the trunk,
which is 3.12.x)
FF/TB/SM are indeed often reluctant to take NSS updates when they
contain functionality updates, but I'm sure that for such a major
security problem they would pick up the update as soon as it's available.
Julien R Pierre - Sun Microsystems
Kyle Hamilton wrote:
> RFC3280 has been obsoleted by RFC5280.
True - sorry but I'm still working with the old RFC. NSS is not current
on the standards yet.
> Aside from that, though...
>
> ...did the people who created PKIX just not realize that if a non-root
> certificate needs the ability to be revoked, a root certificate would
> also?
Remember that PKIX standards are derived from X.509 which is not
Internet-specific. In other environments, there may be more secure,
offline methods for updating roots (eg. physical).
I think the distribution of trust anchors is something that nobody has
really tried to generalize, because I think once again everybody is free
to do it their own way. Some of those methods are secure, and others
less so.
In general though, I think it's very hard to make anything secure -
including your first Mozilla client download that contains your root,
let alone an update to it - if you don't trust at least a single entity.