Dealing with third-party subordinates of T-Systems and others
Frank Hecker
evaluation process for T-Systems. If you recall, that request (bug
378882) got bogged down in a discussion of how to deal with situations
where the root CA doesn't actually issue end entity certificates and the
root CA's CPS doesn't address issuance of EE certs, but instead all the
EE certs are issued by third-party subordinates.
Kathleen thinks, and I agree, that the best way to approach this both
with T-Systems and with other CAs in general is to ask the CA to update
the CP/CPS for the root to include language addressing the following:
* Clear requirements for subordinate CAs for how information in
end-entity certs is to be verified, such that section 7 of the Mozilla
CA policy (http://www.mozilla.org/projects/security/certs/policy/) is
satisfied.
* Requirements for subordinate CAs in regards to whether or not
subordinate CAs are constrained to issue certificates only within
certain domains, and whether or not subordinate CAs can create their
own subordinates.
* Audit requirements for subordinate CAs with regard to the frequency of
audits and who can/should perform them, as per sections 8, 9, and 10 of
the Mozilla CA policy.
Our goal here is to avoid having to evaluate lots and lots of
subordinate CAs, and instead have the roots take care of their own
subordinates and ensure they're compliant to policy.
Does this sound reasonable? If so we'll proceed as noted above.
Frank
P.S. One thing I asked for before at some point, and I'll re-ask now, is
a clear brief technical description on how root CAs would constrain
subordinates to issue EE certs only within certain domains, and also
prevent them from creating their own subordinates. I'd like to add this to
https://wiki.mozilla.org/CA:Recommendations_for_Roots
to provide some technical background for anyone interested.
--
Frank Hecker
hec...@mozillafoundation.org
Justin Dolske
> Kathleen Wilson and I have been discussing how to re-start the
> evaluation process for T-Systems. If you recall, that request (bug
> 378882) got bogged down in a discussion of how to deal with situations
> where the root CA doesn't actually issue end entity certificates and the
> root CA's CPS doesn't address issuance of EE certs, but instead all the
> EE certs are issued by third-party subordinates.
Out of curiousity... How many (if any) such CAs are currently included
in NSS? It seems a little scary to be providing a way for these 3rd
party CAs to become operational in Mozilla products without going
through the Mozilla approval process. It seems like a different degree
or trust.
Justin
Eddy Nigg
>
> Kathleen thinks, and I agree, that the best way to approach this both
> with T-Systems and with other CAs in general is to ask the CA to update
> the CP/CPS for the root to include language addressing the following:
>
> * Clear requirements for subordinate CAs for how information in
> end-entity certs is to be verified, such that section 7 of the Mozilla
> CA policy (http://www.mozilla.org/projects/security/certs/policy/) is
> satisfied.
>
> * Requirements for subordinate CAs in regards to whether or not
> subordinate CAs are constrained to issue certificates only within
> certain domains, and whether or not subordinate CAs can create their
> own subordinates.
>
> * Audit requirements for subordinate CAs with regard to the frequency of
> audits and who can/should perform them, as per sections 8, 9, and 10 of
> the Mozilla CA policy.
It is basically a question of how those are audited. I'd suppose that a
physical walk-through and evidence gathering at the premises of the
sub-ordinate CAs must have taken place during auditing - and if needed
shall be confirmed explicitly as such upon request by Mozilla by the
auditor. This information isn't usually included in typical audit
statements and we might need to ask for such a confirmation. It doesn't
apply in case the sub-ordinate or cross-signed CA certificate is
operated from within the root CA infrastructure and was audited as part
of that PKI.
The principal guiding us should be the audit requirements mentioned
above and there shall be no CA included which hasn't undergone such an
audit, being it as part of a root or in its own rights. A root shall not
be included in case sub-ordinate CAs exist which haven't seen the face
of an auditor at least once (not speaking about yearly re-auditing yet).
Out of fairness, Mozilla requires a WebTurst or equivalent audit
performed by CAs, which shouldn't be circumvented by cross-signing or
sub-signing of CA certificates.
>
> Our goal here is to avoid having to evaluate lots and lots of
> subordinate CAs, and instead have the roots take care of their own
> subordinates and ensure they're compliant to policy.
>
Since the Mozilla CA policy clearly calls for auditing of the CA, I
think that Mozilla will have to share the burden in cases the CAs in
question haven't been part of such an audit and would like to apply in
their own right. Not sure how many there will be, but in such a case
it's simply a matter of implementing the policy.
> P.S. One thing I asked for before at some point, and I'll re-ask now, is
> a clear brief technical description on how root CAs would constrain
> subordinates to issue EE certs only within certain domains, and also
> prevent them from creating their own subordinates. I'd like to add this to
>
> https://wiki.mozilla.org/CA:Recommendations_for_Roots
>
> to provide some technical background for anyone interested.
>
I think path length should be 0 for such CAs. It's a requirement for the
issuing CA certificate of EV certificates and makes sense also here.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org
Frank Hecker
> Out of curiousity... How many (if any) such CAs are currently included
> in NSS?
It's not clear, since we've never gone back and looked at all the legacy
CAs. There are certainly a number of root CAs that authorize third
parties to run subordinate CAs and issue end entity certificates. This
is fairly common with large companies -- they get a subordinate CA cert
issued by a root, and then run their own CAs internally.
> It seems a little scary to be providing a way for these 3rd
> party CAs to become operational in Mozilla products without going
> through the Mozilla approval process. It seems like a different degree
> or trust.
I don't think the practice of having third party subordinates is in and
itself a problem. It's just that the root CA needs to have some sort of
control over the subordinates (e.g., through appropriate legal
agreements), and some way of ensuring (e.g., through audits) that the
subordinates operate in accordance with the controls.
Remember that a lot of CAs working with enterprises outsource the
Registration Authority function to those enterprises. In other words,
the enterprise is ultimately responsible for doing verification of
subscribers (e.g. when issuing certificates to employees and corporate
web sites), even when the CA itself is issuing the certificate. Going
from outsourced RAs to third-party subordinates adds some additional
risk, but it's not a qualitatively different situation as I see it.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Eddy Nigg
> Out of curiousity... How many (if any) such CAs are currently included
> in NSS? It seems a little scary to be providing a way for these 3rd
> party CAs to become operational in Mozilla products without going
> through the Mozilla approval process. It seems like a different degree
> or trust.
>
To all of my knowledge there are some, mostly some legacy roots or roots
which have been admitted before the formal policy was established. I
expect that once the backlog of CA inclusions has been cleared some
effort can be invested to research this and other aspects of such CAs.
At least I'd propose that if needed hereby...
However since Spring 2007 no such CAs were knowingly admitted anymore.
Eddy Nigg
> Remember that a lot of CAs working with enterprises outsource the
> Registration Authority function to those enterprises. In other words,
> the enterprise is ultimately responsible for doing verification of
> subscribers (e.g. when issuing certificates to employees and corporate
> web sites), even when the CA itself is issuing the certificate. Going
> from outsourced RAs to third-party subordinates adds some additional
> risk, but it's not a qualitatively different situation as I see it.
You are right and you've touched a sensitive issue here! It's certainly
something we might want to look at some stage.
But due to the fact that the issuing CA has been audited, this includes
how the CA governs and controls the RAs, but also the environmental,
logical and physical aspects of the infrastructure - including access
regulations and a lot more...I think there is still a difference between
relying on verifications done by an RA and having a complete CA at a
different location run by a different entity.
Frank Hecker
> The principal guiding us should be the audit requirements mentioned
> above and there shall be no CA included which hasn't undergone such an
> audit, being it as part of a root or in its own rights. A root shall not
> be included in case sub-ordinate CAs exist which haven't seen the face
> of an auditor at least once (not speaking about yearly re-auditing yet).
This issue is going to come up with WISeKey (scheduled for public
comment next week), but I may as well speak of it in general terms right
now.
It is not clear to me that it's realistic for us to require actual
audits for each and every third-party subordinate CA. Even beyond the
WISeKey model (the "CA in a box" appliance device), I suspect that a
number of other CAs serving the enterprise market have enough
subordinates that it would be unrealistic to require actual audits of
all subordinates in these cases as well. (Which is not to say that
there's no auditing at all -- for example, the (root) CA could have some
sort of random or spot auditing scheme.)
> Since the Mozilla CA policy clearly calls for auditing of the CA, I
> think that Mozilla will have to share the burden in cases the CAs in
> question haven't been part of such an audit and would like to apply in
> their own right. Not sure how many there will be, but in such a case
> it's simply a matter of implementing the policy.
Well, it does matter how difficult it is to implement a policy, and I
think we have to exercise some judgment here. At one end of the spectrum
we have situations where we have a small number of subordinate CAs, each
of which issues lots and lots of certificates. T-Systems is apparently
like this, as are KISA and perhaps others. Here I think it is realistic
for us to take a closer look at the subordinates.
In other cases, like the "enterprise CA" case mentioned above, there are
lots of subordinates, and each subordinate issues relatively few
certificates. Here I think it is unrealistic to look at each and every
CA; it's quite possible we won't even know the actual names of each and
every CA. In these case I think we will instead have to look at the
overall manner in which the (root) CA oversees and controls the
subordinates.
To echo what I wrote earlier, it's analogous to the case of CAs that
out-source the RA function to others, especially in the enterprise
environment. I doubt that, e.g., a WebTrust audit entails auditing each
and every organization participating in RA activities; I presume what is
done is instead to look at the overall controls in place for such
arrangements.
> I think path length should be 0 for such CAs. It's a requirement for the
> issuing CA certificate of EV certificates and makes sense also here.
Thanks. If you have time please feel free to edit the wiki page and add
a note on this near the bottom (where subordinate are discussed).
Eddy Nigg
>
I turned your reply somewhat upside-down, because I want to comment
first in general terms...
>
> Well, it does matter how difficult it is to implement a policy, and I
> think we have to exercise some judgment here. At one end of the spectrum
> we have situations where we have a small number of subordinate CAs, each
> of which issues lots and lots of certificates. T-Systems is apparently
> like this, as are KISA and perhaps others. Here I think it is realistic
> for us to take a closer look at the subordinates.
>
I agree that we need to think about it and provide clear guidance about
what is acceptable one what not! Lets go...
The physical evidence gathering at the CA is a *substantial* part of an
audit, it's one of the cornerstones of auditing. Without it, auditing
would be very difficult and mostly meaningless. The physical
walk-through and on-spot evidence gathering is a a *substantial* effort
in relation of time and money to the CA. It's also the basis which
allows Mozilla to trust those audits and have some confidence about the
CA, being it the controls in place and general functioning.
Now, you are suggesting that we can rely on meaningless contractual
requirements set up by the CA with no guaranties whatsoever that the
external entities which aren't even part of the same company and don't
share the physical infrastructure, have really done so.
How does an auditor confirm requirements set up by the CA without
actually visiting those intermediate CAs? Either the auditor gathers
evidence about the controls in place which govern those CAs; in which
case the auditor has no problem confirming them. Otherwise the auditor
hasn't done so, can't confirm conformance of the controls set up by the
CA. It's a chicken and egg problem, either the CA has sufficient
controls in place and set up requirements which resemble those of the
root - in which case the auditor must confirm them, or the CA doesn't
have those controls in place and the auditor has nothing to confirm
either. In either case the result is the same - the sub-ordinate CAs
were part of the audit or not, the auditor can confirm it or not.
>
> To echo what I wrote earlier, it's analogous to the case of CAs that
> out-source the RA function to others, especially in the enterprise
> environment. I doubt that, e.g., a WebTrust audit entails auditing each
> and every organization participating in RA activities; I presume what is
> done is instead to look at the overall controls in place for such
> arrangements.
Yes, but the RA doesn't control the CA infrastructure nor does the RA
actually issue the certificates. Neither has the RA the power to move,
remove, modify anything about the CA - it validates the subjects
according to some criteria and the CA is obligated to assert control and
assure the quality of the RA by various means. This is NOT the same as a
sub-CA or cross-signed CA. See "Business Continuity Management" and
"Physical and Environmental Security"...
Hey! An RA can make a mistake here and there (the most), the RA can't
take the whole CA infrastructure down or compromise the CA keys. This is
a substantial difference!
> It is not clear to me that it's realistic for us to require actual
> audits for each and every third-party subordinate CA.
No? But it's a requirement of (root) CAs, how can it be NOT a
requirement of any participating CA? Mozilla defines the rules - that's
the most realistic it can get. If the audit requirement can be
circumvented by simply getting into a contractual agreement with another
CA, than I request to skip the audit requirement altogether, why bother?
(This should serve as an example, I don't really mean it)
> Even beyond the
> WISeKey model (the "CA in a box" appliance device), I suspect that a
> number of other CAs serving the enterprise market have enough
> subordinates that it would be unrealistic to require actual audits of
> all subordinates in these cases as well.
Who said that everything which was done to date was correct and useful
(to the relying parties)? Just because it exists it doesn't mean it's
the right thing to do really. "CA-in-a-box" is a risk Mozilla shouldn't
accept without some guaranties (which auditing provides). Lets suppose
CAs stop verifying domain control of server certificates because some
hardware vendors decided that the enterprise market needs it, will you
also call it unrealistic to make it a requirement? Most likely not!
Your effort to admit more CAs shouldn't come on the expense of basic
requirements; and those are confirmed by an audit. No audit, no
confirmation, no confidence and a higher risk.
> (Which is not to say that
> there's no auditing at all -- for example, the (root) CA could have some
> sort of random or spot auditing scheme.)
>
You know what's that worth...are you promoting CAs to be auditors now?
Having the cats take care of the milk...
Random checking goes as far as it's convenient. There is no problem
performing such a check around the next corner, but going all the way to
the Falkland Islands is neither convenient nor financially attractive,
hence it will not happen either. It's simply useless, besides that I
question the effectiveness of such a check performed by the CA itself.
Would you be willing to loose a good paying customer because of some
"minor deficiencies"?
Eddy Nigg
> On 10/03/2008 04:29 AM, Frank Hecker:
>> WISeKey model (the "CA in a box" appliance device), I suspect that a
>> number of other CAs serving the enterprise market have enough
>> subordinates that it would be unrealistic to require actual audits of
>> all subordinates in these cases as well.
>
> Who said that everything which was done to date was correct and useful
> (to the relying parties)? Just because it exists it doesn't mean it's
> the right thing to do really. "CA-in-a-box" is a risk Mozilla shouldn't
> accept without some guaranties (which auditing provides). Lets suppose
> CAs stop verifying domain control of server certificates because some
> hardware vendors decided that the enterprise market needs it, will you
> also call it unrealistic to make it a requirement? Most likely not!
>
Here I wanted to add something...it's not that we should prevent
intermediate third-party CAs or cross-signing, but we need to apply the
same requirements on all CAs. Now, the requirements are defined in the
Mozilla CA policy which calls for auditing. Not by mistake, because this
gives Mozilla some confidence about the CA it - and with it just a few
million users - are going to trust the work done by the CA. By removing
this requirement explicitly by not applying the same requirements to all
CAs, there is no use maintaining it.
Iang
being the devil's advocate here, personal opinions if any...
Eddy Nigg wrote:
> On 10/03/2008 04:29 AM, Frank Hecker:
>> Well, it does matter how difficult it is to implement a policy, and I
>> think we have to exercise some judgment here. At one end of the spectrum
>> we have situations where we have a small number of subordinate CAs, each
>> of which issues lots and lots of certificates. T-Systems is apparently
>> like this, as are KISA and perhaps others. Here I think it is realistic
>> for us to take a closer look at the subordinates.
>>
>
> I agree that we need to think about it and provide clear guidance about
> what is acceptable one what not! Lets go...
>
> The physical evidence gathering at the CA is a *substantial* part of an
> audit, it's one of the cornerstones of auditing. Without it, auditing
> would be very difficult and mostly meaningless. The physical
> walk-through and on-spot evidence gathering is a a *substantial* effort
> in relation of time and money to the CA. It's also the basis which
> allows Mozilla to trust those audits and have some confidence about the
> CA, being it the controls in place and general functioning.
I am not entirely convinced that it is as easy as that. The
audit is a far more nuanced thing than "auditor checks, it's
ok." If you think that, then, I've got a subprime to sell you.
> Now, you are suggesting that we can rely on meaningless contractual
> requirements set up by the CA with no guaranties whatsoever that the
> external entities which aren't even part of the same company and don't
> share the physical infrastructure, have really done so.
Actually, this is one of the weaknesses of the entire cycle.
Currently, the contractual relationships between any of
the parties in the cycle are weak. This weakness then flows
through to other areas, and inspires worried people to ask
for more and more checks ... which is fruitless because the
checks that are in place are not anchored to a general need
and/or any contractual backing.
In general, I'd agree that even more weak contractual links
will not help; we should sort out the ones we already have
before expanding or adding to them.
> How does an auditor confirm requirements set up by the CA without
> actually visiting those intermediate CAs? Either the auditor gathers
> evidence about the controls in place which govern those CAs; in which
> case the auditor has no problem confirming them. Otherwise the auditor
> hasn't done so, can't confirm conformance of the controls set up by the
> CA. It's a chicken and egg problem, either the CA has sufficient
> controls in place and set up requirements which resemble those of the
> root - in which case the auditor must confirm them, or the CA doesn't
> have those controls in place and the auditor has nothing to confirm
> either. In either case the result is the same - the sub-ordinate CAs
> were part of the audit or not, the auditor can confirm it or not.
This seems a little black and white. Auditors do not check
everything, and indeed they do not necessarily check that a
particular thing is good. What they more do is check that
reasonable checks are in place; this might be checking of
the checking of the checks, rather than checking the
physical evidence.
Which is to say, an auditor can check an internal auditing
department. And lean on that. Or can choose to audit by
self. Or some other thing. The important thing would be
that the method take is clear and obvious to all.
>> To echo what I wrote earlier, it's analogous to the case of CAs that
>> out-source the RA function to others, especially in the enterprise
>> environment. I doubt that, e.g., a WebTrust audit entails auditing each
>> and every organization participating in RA activities; I presume what is
>> done is instead to look at the overall controls in place for such
>> arrangements.
>
> Yes, but the RA doesn't control the CA infrastructure nor does the RA
> actually issue the certificates. Neither has the RA the power to move,
> remove, modify anything about the CA - it validates the subjects
> according to some criteria and the CA is obligated to assert control and
> assure the quality of the RA by various means. This is NOT the same as a
> sub-CA or cross-signed CA. See "Business Continuity Management" and
> "Physical and Environmental Security"...
>
> Hey! An RA can make a mistake here and there (the most), the RA can't
> take the whole CA infrastructure down or compromise the CA keys. This is
> a substantial difference!
Well, what's your most likely attack? A rogue RA works for
a phishing enterprise, delivers a 1000 dodgy certs on
demand, and faces 1000 revocations and loss of privileges?
Versus, a rogue sub-CA which does the same, and gets the
same treatment?
Yes, there is a technical and infrastructure difference, but
how much does this matter, in a material sense, to a real
attack, to a real user? Maybe the attacker is just at a
different point in the food chain?
>> It is not clear to me that it's realistic for us to require actual
>> audits for each and every third-party subordinate CA.
>
> ...If the audit requirement can be
> circumvented by simply getting into a contractual agreement with another
> CA, than I request to skip the audit requirement altogether, why bother?
> (This should serve as an example, I don't really mean it)
:) Certainly if Mozilla succeeds in creating a good
framework that covers this situation, there will be an
incentive for CAs to band together and vote on one victim to
go through the pain once, for all. I'm not sure that is a
bad thing, that's just an economic argument, so far.
As to whether the audit is needed ... well, there are *many*
issues with the overall process. Here's one: what does it
offer to the users? How much safer to people feel because
there are lots of extra audit processes these days?
http://www.sslshopper.com/article-phishing-with-ev-ssl-certificates.html
>> Even beyond the
>> WISeKey model (the "CA in a box" appliance device), I suspect that a
>> number of other CAs serving the enterprise market have enough
>> subordinates that it would be unrealistic to require actual audits of
>> all subordinates in these cases as well.
>
> Who said that everything which was done to date was correct and useful
> (to the relying parties)?
Ahhh, relying parties, who are they, he asks innocently :)
> Just because it exists it doesn't mean it's
> the right thing to do really. "CA-in-a-box" is a risk Mozilla shouldn't
> accept without some guaranties (which auditing provides). Lets suppose
> CAs stop verifying domain control of server certificates because some
> hardware vendors decided that the enterprise market needs it, will you
> also call it unrealistic to make it a requirement? Most likely not!
The current *implication* I would draw is that anything that
is expressed in the policy applies to all sub CAs. So that
particular question is covered.
We would have more of a question about something in a CPS of
the primary CA, that was reversed in a sub-CA.
> Your effort to admit more CAs shouldn't come on the expense of basic
> requirements; and those are confirmed by an audit. No audit, no
> confirmation, no confidence and a higher risk.
There are ways of extending that basic requirement down the
line to the other subCAs. Also, it's a good chance to show
that the basic requirements make sense; if we can't figure
out a comfortable way to deal with this, we may have to ask
higher level questions.
>> (Which is not to say that
>> there's no auditing at all -- for example, the (root) CA could have some
>> sort of random or spot auditing scheme.)
>>
>
> You know what's that worth...are you promoting CAs to be auditors now?
> Having the cats take care of the milk...
Yes, that's one direction. Internal audit. Another
development (which I have frequently commented on without
any particular favour :) ) is that Mozilla itself is
auditing the audits. E.g., what's this 40 week backlog, if
not that process of auditing the audits. So we end up with:
super-audit -> audit -> sub-audit
Is that a problem?
Another direction is more auditing done by the users; those
who benefit. The public comment period is a first step in
that direction.
> Random checking goes as far as it's convenient. There is no problem
> performing such a check around the next corner, but going all the way to
> the Falkland Islands is neither convenient nor financially attractive,
> hence it will not happen either. It's simply useless, besides that I
> question the effectiveness of such a check performed by the CA itself.
Have you read the auditor's opinion? It generally starts
with something like "*management* has put in place
procedures and policies..." If you don't trust the checks
performed by the CA, then you're sunk, because the auditor
should check the system of checks, not do the checking by self.
> Would you be willing to loose a good paying customer because of some
> "minor deficiencies"?
These are all standard issues; but they are issues for
everyone in the food chain. Would an auditor be willing to
lose a good paying customer because of some "minor
deficiencies" ? Does an auditor check every RA operation,
physically? Does an auditor verify the creation of
certificates?
I think Frank's direction bears thinking about, not knocking
on the head just because it clashes with some old ideas.
iang
Paul Hoffman
>Here I wanted to add something...it's not that we should prevent
>intermediate third-party CAs or cross-signing, but we need to apply the
>same requirements on all CAs.
But we don't. All the legacy CAs have different requirements put on them. To me, this is a much bigger issue than the sub-CAs being discussed on this thread, and should be dealt with first.
Eddy Nigg
Well, that's somewhat lame...I can't influence the bigger issues which
certainly also should be tackled, and I'm all with you. However the
issue above is up for discussion now and here is where we can make a
difference now.
Eddy Nigg
>
> I am not entirely convinced that it is as easy as that. The audit is a
> far more nuanced thing than "auditor checks, it's ok." If you think
> that, then, I've got a subprime to sell you.
>
The WebTrust audit is pretty clear in this respect, not sure what you
mean really...
>
> In general, I'd agree that even more weak contractual links will not
> help; we should sort out the ones we already have before expanding or
> adding to them.
>
See my reply to Paul Hoffman.
>
> This seems a little black and white. Auditors do not check everything,
> and indeed they do not necessarily check that a particular thing is
> good. What they more do is check that reasonable checks are in place;
> this might be checking of the checking of the checks, rather than
> checking the physical evidence.
>
And how exactly do intent to check the checks that are in place without
gathering evidence about the effectiveness of those?
> Which is to say, an auditor can check an internal auditing department.
> And lean on that. Or can choose to audit by self. Or some other thing.
> The important thing would be that the method take is clear and obvious
> to all.
>
Self-auditing is part of the EV requirements for example, still a
third-party audit is done every year. It's best practice and part of the
controls a CA implements on its own operations. Auditing of the
sub/cross signed CA by the root is certainly part of the parent CA
obligations during day-to-day operation, it still would circumvent
Mozilla's requirement for auditing if the auditor doesn't confirm the
sub-ordinate CAs.
IMO the controls which we need to be in place in order to be comparable
to a third-party audit would have to be really, really convincing!
Basically the CP/CPS would call for auditing those by the third-party
auditor...
>
> Yes, there is a technical and infrastructure difference, but how much
> does this matter, in a material sense, to a real attack, to a real user?
> Maybe the attacker is just at a different point in the food chain?
>
It's called CA business continuity management amongst others. There is a
substantial difference between a failure of an RA and a CA.
>
> As to whether the audit is needed ... well, there are *many* issues with
> the overall process. Here's one: what does it offer to the users? How
> much safer to people feel because there are lots of extra audit
> processes these days?
>
I have no intention starting a discussion about the value of audits in
general. The rest implies the former.
> http://www.sslshopper.com/article-phishing-with-ev-ssl-certificates.html
>
That's out of the scope of what we are doing here.
>
> Ahhh, relying parties, who are they, he asks innocently :)
>
If you'd follow my postings for a while you'd here this very frequently
from me.... :-)
>
> The current *implication* I would draw is that anything that is
> expressed in the policy applies to all sub CAs. So that particular
> question is covered.
>
This assumption is incorrect - in practice and in policies.
But how do you confirm a particular infrastructure without auditing?
Assumptions? Because it's in the CPS? Else?
> We would have more of a question about something in a CPS of the primary
> CA, that was reversed in a sub-CA.
>
The issue is about auditing - we know what's in the CPS...
>
> Yes, that's one direction. Internal audit. Another development (which I
> have frequently commented on without any particular favour :) ) is that
> Mozilla itself is auditing the audits. E.g., what's this 40 week
> backlog, if not that process of auditing the audits.
Which shows to me that you've never participated in a real audit...
>
> Have you read the auditor's opinion? It generally starts with something
> like "*management* has put in place procedures and policies..." If you
> don't trust the checks performed by the CA, then you're sunk, because
> the auditor should check the system of checks, not do the checking by self.
>
Same as above...
> These are all standard issues; but they are issues for everyone in the
> food chain. Would an auditor be willing to lose a good paying customer
> because of some "minor deficiencies" ?
No, but the auditor will help correct those (and request some more
payment perhaps ;-) )
> Does an auditor check every RA
> operation, physically?
No, and he doesn't have to, it's an RA, a function performed many times
by CAs directly. The RA doesn't control the CA keys, issuance process
and procedures...basically the RA doesn't control anything really...the
RA performs part of the process.
> Does an auditor verify the creation of certificates?
Certainly.
Eddy Nigg
>
> subordinate CAs, and instead have the roots take care of their own
> subordinates and ensure they're compliant to policy.
>
I'd like to pick this discussion up once again and evaluate what the
goals of Mozilla and the Mozilla CA policy really are. Certainly the
above is not the defined goal, but rather provide some reasonable
assurance about the CAs included in NSS and Mozilla products and allow
users to rely on
- domain name control validation for web sites
- email control validation for email
- identity or organization validation for code signing
- in case of EV, compliance to the EV guidelines
- sound physical and logical security, controls, business continuity and
other aspects as they are covered by the acceptable audit criterion
Should any of the goals above not be that of Mozilla and its policy
please speak up...
> * Clear requirements for subordinate CAs for how information in
> end-entity certs is to be verified, such that section 7 of the Mozilla
> CA policy (http://www.mozilla.org/projects/security/certs/policy/) is
> satisfied.
I think this is implied by the policy itself, there is no need to add
additional requirements.
>
> * Requirements for subordinate CAs in regards to whether or not
> subordinate CAs are constrained to issue certificates only within
> certain domains, and whether or not subordinate CAs can create their
> own subordinates.
I think this is implied by the above as well...
>
> * Audit requirements for subordinate CAs with regard to the frequency of
> audits and who can/should perform them, as per sections 8, 9, and 10 of
> the Mozilla CA policy.
I really don't understand what's the fuss about having ANY CA to perform
an audit or having been part of an audit (in case of wider PKI and
signing scheme). With "CA" I mean including any entity which is physical
and/or logical independent.
Or is NSS just a football club or barbecue party..."bring as many
friends with you, everybody is welcome"?! Or is NSS a Web-of-Trust
scheme where members validate other members, aka PGP? Or shouldn't have
any to-be-admitted CA undergone some vetting for their business practices?
To make it clear about what we are talking....
- A CA should write and define a CA policy and publish a practice
statement which is in conformance with the Mozilla CA Policy (see above).
- A CA should implement its policy and engage with an acceptable
auditor, perform the audit and have its business practices confirmed.
That's about all what the Mozilla CA Policy calls for...
In case of T-Systems and other CAs issuing sub-ordinate CA certificates
to third party organizations, those infrastructures should be either
part during the audit of the parent CA or the CA performs an audit
itself. I really don't understand what the problem is to have the audit
INCLUDE all CAs under its root - including the CAs which are located and
operated elsewhere...or should I rather say, SPECIALLY when they are
located and operated elsewhere they MUST be explicitly audited and
confirmed?! (What's the difference anyway between the a root and
sub-ordinate certificate in regards to security, controls and business
practices)
Well, if a CA can't provide that, I don't want to have to rely on them!
Because it means that CAs will be included indirectly without ever
having undergone an audit - never seen a third party auditor at their
infrastructure and have their processes and controls reviewed. Auditing
is a good thing generally, it reveals shortcomings and other
deficiencies sometimes which allows the CA to improve their
infrastructure, additionally it confirms the CAs practices.
The fact that there are now some 40-50 CAs waiting for inclusion has
nothing to do with the defined goals. Or perhaps quite the opposite! Not
every CA knocking at Mozilla's doors must be included just because they
asked for it. They need to prove that they comply to the policy and this
can only be done by providing a CP/CPCS and auditing. Otherwise we
should clearly define the goals differently and rewrite the Mozilla CA
Policy.
Ian G
> On 10/02/2008 10:23 PM, Frank Hecker:
> >
> > Our goal here is to avoid having to evaluate lots and lots of
> > subordinate CAs, and instead have the roots take care of their own
> > subordinates and ensure they're compliant to policy.
> >
>
> I'd like to pick this discussion up once again and evaluate what the
> goals of Mozilla
The goals of Mozo are written somewhere else, and they only speak
softly to the issue of security from memory. I think it is worth
revisiting them, perhaps someone has them to hand?
> and the Mozilla CA policy really are.
I would interpolate the policy goals from the following snippets:
"based on the benefits and risks of such inclusion
to typical users of those product"
"would cause undue risks to users' security"
"might cause technical problems with the operation
of our software"
"provide some service relevant to typical users of
our software products;"
These speak to higher level goals. IMO, the rest of the policy
speaks to the tools that are chosen to assist in meeting those or
other goals. e.g., audit, criteria, DER,...
> Certainly the
> above is not the defined goal,
If anything, Frank seems to be implying a goal of "reasonable
efficiency" but that seems to not need to be stated. If anything,
he's talking about the efficiency of the tools that meet the higher
level goals (whatever they are), not the higher level goals.
> but rather provide some reasonable
> assurance about the CAs included in NSS and Mozilla products and allow
> users to rely on
The second part:
"allow users to rely on"
I'd flag as wrong. If there was a goal to allow users to rely on
CAs, certificates, etc, then there would be a requirement to tie in
the reliance of the Mozilla end-user, and the relying party of the
CA, as described in the CPSs and as promoted by the PKI literature
as a key person who has to read the key document and enter into this
game called reliance.
I'd suggest that Mozilla end-users, for the most part, in general,
are not relying parties. They may not rely on the certs, or they
are likely in for a surprise if they ever want to turn a failure
into a recovery.
They might *use* the certificates, and then go on to rely in other
ways. And, they may go to the CA's website and find out what it
takes to become relying parties ... But these are different things.
Then, the first part:
"reasonable assurance"
If you are defining it as the below, then that makes sense.
> - domain name control validation for web sites
> - email control validation for email
> - identity or organization validation for code signing
> - in case of EV, compliance to the EV guidelines
> - sound physical and logical security, controls, business continuity and
> other aspects as they are covered by the acceptable audit criterion
However I would also raise a caution here: current Mozilla policy
is separated into EV and non-EV. I don't think this is written down
anywhere. Either way, the strength of the difference is such that I
do not believe it that the word "reasonable" applies any more.
E.g., if EV was "reasonable" then the DV/AV, etc should be turned
off as being "not reasonable". If the latter was "reasonable" then
we don't need EV. QED.
Which is to say, perhaps a different wording. Perhaps more like:
"provide a level of assurance that is appropriate
to the user's needs, and is matched by the
software's security and UI."
(Or somesuch, just brainstorming here.) Now, we would need to match
that to the (implied) policy goals above (assuming they are still good):
"provide a level of assurance that brings benefits
to the end-user's use of the product, without unduly
impacting:
* the risks and liabilities of the user,
* the compatibility and operation of the software,
* the risks, liabilities and obligations of other
parties (including CAs, Mozilla and developers)"
OK, I added the last one for free.
> Should any of the goals above not be that of Mozilla and its policy
> please speak up...
iang
Eddy Nigg
>
> The goals of Mozo are written somewhere else, and they only speak
> softly to the issue of security from memory
I obviously meant the goals of the Mozilla CA Policy and NSS, which
isn't used only by Mozilla (Firefox) but lots of different software. NSS
is a cryptography library.
> I'd flag as wrong. If there was a goal to allow users to rely on
> CAs, certificates, etc, then there would be a requirement to tie in
> the reliance of the Mozilla end-user, and the relying party of the
> CA, as described in the CPSs and as promoted by the PKI literature
> as a key person who has to read the key document and enter into this
> game called reliance.
>
> I'd suggest that Mozilla end-users, for the most part, in general,
> are not relying parties. They may not rely on the certs, or they
> are likely in for a surprise if they ever want to turn a failure
> into a recovery.
>
> They might *use* the certificates, and then go on to rely in other
> ways. And, they may go to the CA's website and find out what it
> takes to become relying parties ... But these are different things.
>
I don't know in what business you are in, but in my industry digital
certificates are issued to subscriber so they can provide them to third
parties for them to rely on the certification, e.g. the third party
relies on the certificate issued to the subscriber.
Mozilla itself is a relying party and also makes sure on behalf of its
users that CAs included with the software adhere to certain criterion.
Those are defined in the Mozilla CA policy. Users certainly don't have
to visit the CA websites in order to know that the CA adheres to the set
requirements of the Mozilla CA Policy (at least). That's the whole point
of shipping a set of CA certificates with the library.
In order to understand CP/CPS of CAs a certain level of understanding
about the subject is required, something which Mozilla does on the
behalf of the user. Most users would fail with such an attempt.
Maybe at Cacert one should find out at their web site about what it
takes to become a relying party and perhaps one should better use other
ways for reliance... ;-)
...but for most Relying Party Obligations I've seen the software takes
care of it (e.g. revocation status checking, matching domain/email,
validity of the certificate, etc.)
>
> However I would also raise a caution here: current Mozilla policy
> is separated into EV and non-EV. I don't think this is written down
> anywhere. Either way, the strength of the difference is such that I
> do not believe it that the word "reasonable" applies any more.
>
Mainly EV provides a defined standard which applies to all CAs issuing
under the EV guidelines; for CAs included in NSS it's the Mozilla CA
policy (it might be more than that, but not less). Both are reasonable
to the extend of what each provides.
(Not that I believe that there could have been other ways achieving that
and better, but that's another story)
> E.g., if EV was "reasonable" then the DV/AV, etc should be turned
> off as being "not reasonable". If the latter was "reasonable" then
> we don't need EV. QED.
DV doesn't claim to provide EV - but not everybody needs EV either, DV
many times is sufficient. It's not either EV or DV, but it depends.
Incidentally there are other shades as well, such as object code
requiring IV/OV and it has been suggested that wild card certificates
should be IV/OV too. There might be others...
>
> "provide a *reasonable* level of assurance that is appropriate
> to the user's needs, and is matched by the
> software's security and UI."
>
I think I could sign on this one. The devil is in the details and the
definition of the above...
Ian G
> On 10/09/2008 05:33 PM, Ian G:
>> The goals of Mozo are written somewhere else, and they only speak
>> softly to the issue of security from memory
>
> I obviously meant the goals of the Mozilla CA Policy and NSS, which
> isn't used only by Mozilla (Firefox) but lots of different software. NSS
> is a cryptography library.
Sure, just that said goals had better tie up to the general goals of
Mozo as a mothership project, otherwise we have a question mark.
But I'm sure they do, it was the same people involved, IIRC. Small
point.
>> I'd flag as wrong. If there was a goal to allow users to rely on
>> CAs, certificates, etc, then there would be a requirement to tie in
>> the reliance of the Mozilla end-user, and the relying party of the
>> CA, as described in the CPSs and as promoted by the PKI literature
>> as a key person who has to read the key document and enter into this
>> game called reliance.
>>
>> I'd suggest that Mozilla end-users, for the most part, in general,
>> are not relying parties. They may not rely on the certs, or they
>> are likely in for a surprise if they ever want to turn a failure
>> into a recovery.
>>
>> They might *use* the certificates, and then go on to rely in other
>> ways. And, they may go to the CA's website and find out what it
>> takes to become relying parties ... But these are different things.
>>
>
> I don't know in what business you are in,
Weeeelllll.... whatever it is, you'd like it; read on.
> but in my industry digital
> certificates are issued to subscriber so they can provide them to third
> parties for them to rely on the certification, e.g. the third party
> relies on the certificate issued to the subscriber.
OK, as it's your industry, so we can happily refer to Verisign's
Relying Party Agreement:
YOU MUST READ THIS RELYING PARTY AGREEMENT ("AGREEMENT") BEFORE
VALIDATING A VERISIGN CERTIFICATE , USING VERISIGN'S ONLINE
CERTIFICATE STATUS PROTOCOL ("OCSP") SERVICES, ACCESSING OR USING A
VERISIGN OR VERISIGN AFFILIATE DATABASE OF CERTIFICATE REVOCATIONS
OR RELYING ON ANY VERISIGN CERTIFICATE-RELATED INFORMATION
(COLLECTIVELY, "VERISIGN INFORMATION”).
*IF YOU DO NOT AGREE TO THE TERMS OF THIS AGREEMENT*,
*DO NOT SUBMIT A QUERY AND DO NOT DOWNLOAD, ACCESS*,
*OR RELY ON ANY VERISIGN INFORMATION*.
IN CONSIDERATION OF YOUR AGREEMENT TO THESE TERMS, YOU ARE ENTITLED
TO USE VERISIGN INFORMATION AS SET FORTH HEREIN.
https://www.verisign.com/repository/rpa.html
Now, curiously, unless we agree to that text, we can't even rely on
that agreement, let along certs, due to its broad commentary, my
emphasis above. That even applies now that the RPA is delivered
under a pretty green cert ;)
So I would suggest -- please by all means possible correct me if
there is another interpretation -- that when a subscriber provides a
Verisign certificate, the user or third party or whoever's pushing
Firefox's buttons today
MUST NOT RELY,
until they have secured permission. Rather explicitly, with a big
solid caps-heavy legal++ scary^2 document, it seems.
And, who does that? Does my interpretation stand [1] ?
Reliance, no. Use, sure.
> Mozilla itself is a relying party
If that was true, there would likely be an agreement between Mozilla
and Verisign (following the above RPA tradition) explicitly giving
Mozilla permission to RELY.
I'm not Mozilla, so I guess we have to ask: Frank, is there any
such agreement that explicitly gives Mozilla permission to RELY?
I don't think there is an agreement, and I think the reason is
historical, not nefarious, these things just weren't thought about
way back when, and it is an acknowledged fact that there hasn't been
so much (if any) review of grandfathered CAs.
If so, here we are at a very important decision point:
Does Mozilla want to be a relying party?
Does it want to impose this on Verisign? Eddy, I guess you are
happy to take on that (having expressed those opinions) .. but what
about the others?
This is rather important because there is an opportunity here for
Mozilla to stamp down a new arrangement. It will improve matters
for users because it will clarify and simply things for them. This
will focus attention on what really matters, security for the users.
It will also help matters for CAs!
> and also makes sure on behalf of its
> users that CAs included with the software adhere to certain criterion.
No argument there.
> Those are defined in the Mozilla CA policy. Users certainly don't have
> to visit the CA websites in order to know that the CA adheres to the set
> requirements of the Mozilla CA Policy (at least).
At least, yes. Right. But they do not have permission to rely.
Not from Mozilla, not from the market-leading CAs. Mozilla itself
has recently gone through an interesting exercise over here:
http://lockshot.wordpress.com/2008/09/17/licensing-proposal-notice-page-screen-shot/
Have a look at those screen shots; looks a lot like "you may USE
but you may not RELY!" to me. (That is my assumption; the authors
were probably not directly thinking about certs. Either way, it's
the only guide I know of, because the policy doesn't address this
question.)
> That's the whole point
> of shipping a set of CA certificates with the library.
Well, that needs revising then. However, I believe it can be done
for the benefit of all (and I really do mean all), so I personally
am not worried about this.
> In order to understand CP/CPS of CAs a certain level of understanding
> about the subject is required, something which Mozilla does on the
> behalf of the user. Most users would fail with such an attempt.
OK. This may or may not be what people think. It's not what the
agreements say. The RPA does not say
"YOU MAY RELY IF YOU FAIL TO UNDERSTAND THIS AGREEMENT......"
so the above statement is maybe an explanation, but it does not
imply anything, and it does not re-interpret the agreements.
> Maybe at Cacert one should find out at their web site about what it
> takes to become a relying party and perhaps one should better use other
> ways for reliance... ;-)
Well, yes! They did that. That's why they discovered the industry
situation above. They constructed an arrangement that works for
them, helps users, and doesn't disadvantage others.
> ...but for most Relying Party Obligations I've seen the software takes
> care of it (e.g. revocation status checking, matching domain/email,
> validity of the certificate, etc.)
Um. Except, the agreements rule over such things, and they say
nothing of the sort, like "we'll take care of it in software..."
OK, I'm not enough of an expert in agency / principle legal theory
to fully understand what the above "take care of it" approach does
when contrasted with the real agreements in place. But there are
clear difficulties there, so I'd suggest that one also goes on the
"revise" list, too.
[snip]
>> "provide a *reasonable* level of assurance that is appropriate
>> to the user's needs, and is matched by the
>> software's security and UI."
>>
>
> I think I could sign on this one. The devil is in the details and the
> definition of the above...
OK, that's something!
iang
[1] Sanity check:
Thawte:
http://www.thawte.com/guides/pdf/cpsrelyingparty.pdf
GetTrust has similar.
Comodo hints that the agreement exists....
OK, we should check EV to see what it says.
Any more for this party?
Eddy Nigg
>
> Weeeelllll.... whatever it is, you'd like it; read on.
>
Actually I did :-)
>
> IN CONSIDERATION OF YOUR AGREEMENT TO THESE TERMS, YOU ARE ENTITLED
> TO USE VERISIGN INFORMATION AS SET FORTH HEREIN.
>
> https://www.verisign.com/repository/rpa.html
>
> Now, curiously, unless we agree to that text, we can't even rely on
> that agreement, let along certs, due to its broad commentary, my
> emphasis above. That even applies now that the RPA is delivered
> under a pretty green cert ;)
It's certainly an "interesting" approach Verisign took here...I think
Rick Andrews happens to be on this list or somebody else from Verisign
can comment on it.
However for what it's worth, the agreement itself is more or less what
I'd expect (rpa.html). The RP obligations are reasonable:
As a Relying Party, you are obligated to ensure the reasonableness of
your reliance on any VeriSign Information by: (i) assessing whether the
use of a Certificate for any given purpose is appropriate under the
circumstances; (ii) utilizing the appropriate software and/or hardware
to perform digital signature verification or other cryptographic
operations you wish to perform, as a condition of relying on a
Certificate in connection with each such operation; and (iii) checking
the status of a Certificate you wish to rely on, as well as the validity
of all the Certificates in its chain.
In the end of the day all the legalities are only necessary in case
something goes really wrong, in which case an RP might or might not be
tied to this agreement (it still has to stand up in court first). Also
Verisign makes explicit reference to their liability (limitations) which
sounds to me reasonable too. (I'm not here to defend Verisign, but I'm
commenting on it nevertheless)
>
> I'm not Mozilla, so I guess we have to ask: Frank, is there any
> such agreement that explicitly gives Mozilla permission to RELY?
>
I think this should be granted. It's a good point, but certainly also a
solvable one.
> I don't think there is an agreement, and I think the reason is
> historical, not nefarious, these things just weren't thought about
> way back when, and it is an acknowledged fact that there hasn't been
> so much (if any) review of grandfathered CAs.
>
Yes, even though Verisign went through the same procedures as every
other CA with their last request for upgrading to EV.
> Does it want to impose this on Verisign? Eddy, I guess you are
> happy to take on that (having expressed those opinions) .. but what
> about the others?
Lets hear about those...
> (That is my assumption; the authors
> were probably not directly thinking about certs. Either way, it's
> the only guide I know of, because the policy doesn't address this
> question.)
>
Another good point to pick up...
> OK, I'm not enough of an expert in agency / principle legal theory
> to fully understand what the above "take care of it" approach does
> when contrasted with the real agreements in place.
Technically NSS (in Firefox) does perform the RP obligations of the
Verisign RP agreement. The legal requirements bound to their agreement
(which doesn't have to stand up in court, but isn't hard to prove either
when using Firefox) might need some review.
> OK, we should check EV to see what it says.
>
There are no RP agreements but limited liability per RP.
Ian G
> On 10/10/2008 01:48 AM, Ian G:
>
>> TO USE VERISIGN INFORMATION AS SET FORTH HEREIN.
>>
>> https://www.verisign.com/repository/rpa.html
>>
>> Now, curiously, unless we agree to that text, we can't even rely on
>> that agreement, let along certs, due to its broad commentary, my
>> emphasis above. That even applies now that the RPA is delivered
>> under a pretty green cert ;)
>
> It's certainly an "interesting" approach Verisign took here...I think
> Rick Andrews happens to be on this list or somebody else from Verisign
> can comment on it.
>
> However for what it's worth, the agreement itself is more or less what
> I'd expect (rpa.html). The RP obligations are reasonable:
>
> As a Relying Party, you are obligated to ensure the reasonableness of
> your reliance on any VeriSign Information by: (i) assessing whether the
> use of a Certificate for any given purpose is appropriate under the
> circumstances; (ii) utilizing the appropriate software and/or hardware
> to perform digital signature verification or other cryptographic
> operations you wish to perform, as a condition of relying on a
> Certificate in connection with each such operation; and (iii) checking
> the status of a Certificate you wish to rely on, as well as the validity
> of all the Certificates in its chain.
>
> In the end of the day all the legalities are only necessary in case
> something goes really wrong,
Right, there are two ways of looking at software, like certs or any
other. What does it help to make go right, and what happens when it
goes wrong?
We need to consider both cases; the former view is that the
software should make more things go more right, the latter view is
that it should present some form of fair & efficient resolution.
If we ignore either side, we will end up unbalanced, and we fall over.
> in which case an RP might or might not be
> tied to this agreement (it still has to stand up in court first).
Well, it's worth walking through the possibilities, just to see this.
First, for the last decade++ it has stood up because it has kept
them out of court (any cases yet?).
Next. If the RP was not tied to this agreement, what else is there?
The agreement is very clear; you have to agree to it, or *you've
got nothing*. No agreement, no rights. And, especially NO
RELIANCE. Nothing, except perhaps some vague theory that CAs are
good for you, which is nothing.
Finally, if it ever did get to court, I don't see any good reasons
why it would not stand up? There are some "IANAL" thoughts below
[1], but the long and the short of it is that there is no reasonable
case for hoping it will be struck down at your 11th hour.
Sure, anything's possible. Meanwhile, it is best to assume the
(highly) probable case: the RPA is a solid and likely expression of
the situation.
> Also
> Verisign makes explicit reference to their liability (limitations) which
> sounds to me reasonable too. (I'm not here to defend Verisign, but I'm
> commenting on it nevertheless)
Yes, István already described how setting any number other than ZERO
creates a huge problem for the CA.
Basically, all CAs are encouraged to set their liability limits to
the general user to ZERO, and I don't know of any CA that doesn't.
I also can't see how in general it can be anything else.
So why not recognise it? Make it policy, let's move on.
(OK, things may look a little different with EV, but EV does not
control liability, only sets a minimum limit on disclaimers of a
liability value. Lawyers will know these are two different things.....)
>> I'm not Mozilla, so I guess we have to ask: Frank, is there any
>> such agreement that explicitly gives Mozilla permission to RELY?
>>
>
> I think this should be granted. It's a good point, but certainly also a
> solvable one.
>
>> I don't think there is an agreement, and I think the reason is
>> historical, not nefarious, these things just weren't thought about
>> way back when, and it is an acknowledged fact that there hasn't been
>> so much (if any) review of grandfathered CAs.
>>
>
> Yes, even though Verisign went through the same procedures as every
> other CA with their last request for upgrading to EV.
Something like that. There is no "agreement for CAs" posted
anywhere on the site.
( I should clarify things here: there is certainly an agreement
between each CA and Mozilla. It's however not a written agreement
with only one form, rather it is a compilation including:
* the policy,
* and in the case of EV, the Guidelines are incorporated,
* audit criteria,
* any side agreements or historical understandings,
* the filed documents under the ascension process,
* etc.
Either way, none of those suggest any permission to RELY, that I've
ever seen or heard of. )
>> Does it want to impose this on Verisign? Eddy, I guess you are
>> happy to take on that (having expressed those opinions) .. but what
>> about the others?
>
> Lets hear about those...
>
>> (That is my assumption; the authors
>> were probably not directly thinking about certs. Either way, it's
>> the only guide I know of, because the policy doesn't address this
>> question.)
>>
>
> Another good point to pick up...
>
>> OK, I'm not enough of an expert in agency / principle legal theory
>> to fully understand what the above "take care of it" approach does
>> when contrasted with the real agreements in place.
>
> Technically NSS (in Firefox) does perform the RP obligations of the
> Verisign RP agreement. The legal requirements bound to their agreement
> (which doesn't have to stand up in court, but isn't hard to prove either
> when using Firefox) might need some review.
Hmmm...
So, you are saying that Mozilla, by way of its software agent
("Firefox" and/or "NSS") are standing in for some of the risks,
liabilities, obligations expressed in the CA's RPA ?
I guess Verisign agrees, as per (ii), (iii) above in the Verisign
RPA above.
(I agree. The user certainly isn't doing it, and that is more or
less a policy decision by the browser.)
So, what happens in any real case? If grandma stands up and says "I
don't know how, but I was robbed!"
And the CA stands up and says "Your Honour, our RPA is very clear on
this point, and besides, we do not know this woman."
I guess we would need a software expert witness to outline the part
that is played by the browser in verifying and presenting the cert?
Then, the judge could muse on who is responsible.
>> OK, we should check EV to see what it says.
>>
>
> There are no RP agreements but limited liability per RP.
Right, EV sets a minimum liability limit of $2000 (from memory).
However, the essential incentives described above still exist, EV
does nothing to change the economics.
We then need to ask: is there a separate RPA? are there other
tools that effectively reduce liability? Are there tools that
seriously manage a liability of non-zero?
iang
[1] IANAL thoughts on whether a well-written RPA might be knocked down:
A judge might knock the RPA down on the basis that there is a better
agreement, but I don't know what that would be -- certainly the
mozilla agreements and policies, EV, PKI docs and so forth don't
present a better case as to what happens "when something goes
wrong." As we've not come across a better document, it is fairly
safe to assume that the user has not either.
( If we were instead talking about just the CPS, then we could make
a case (and some have) that such a document is not fit; I have not
looked at the one in question, this is a general remark. )
It might be knocked down under consumer protection clauses, but this
is a bit tricky because the user is not a consumer. That is, the
user didn't buy anything, only the subscriber did.
It might be knocked down because it is deceptive, or contradicted by
other claims. Now, in the past, there were many CAs who claimed
things on their websites, like "you can trust our certs" or "our
certs secure you". This is bad, but I think most CAs have stopped
doing that so blatantly. E.g., today, there is a claim that says
"When consumers trust you, trust Verisign!" But that is a message
to the subscriber, *not* to the user nor to any RP.
There is not a lot of applicable law, because most of the CA laws
exclude coverage one way or another. I guess it might be different
in those places where the CA registered as regulated under the state
(Utah?) but they are not so common. Under the European directive,
there might be more law, but it is strongly oriented towards
qualified certificates, and that's a corner case. The advanced
signatures sometimes come in for some protection; but not enough to
be consistent.
There is the "duty of care" theory but I don't see this can apply,
because "what is care" isn't expressed carefully enough, the CA's
position is very carefully expressed, they have a very small part of
the action, there are too many parties, and it has never been tested.
Then, there is the possibility of various class-action style
lawsuits based on actual losses such as phishing. The problem with
this is (and here is not the place to go into it, but others have
heard it before) is that the CA's job is more or less done when the
subscriber is shown not to have phished.
A short answer that is often presented is that they spent a huge
amount of money on legal fees to make this stand up, and it has
stood the test of time. It seems that other CAs have also followed
suit, so maybe the real arguments have been replayed over time, more
money has been spent, and the same results reached.
Well, enough of amateur lawyering.
Eddy Nigg
> Finally, if it ever did get to court, I don't see any good reasons
> why it would not stand up?
Well, I prefer to refrain from commenting on this, but the fact that I
mentioned it could give you some hint ;-)
> ( I should clarify things here: there is certainly an agreement
> between each CA and Mozilla. It's however not a written agreement
> with only one form, rather it is a compilation including:
>
> * the policy,
> * and in the case of EV, the Guidelines are incorporated,
> * audit criteria,
> * any side agreements or historical understandings,
> * the filed documents under the ascension process,
> * etc.
Actually the request made by the CA to have their root included
is/should/might be interpreted as a waiver for any special requirements,
agreements, conditions except if specifically conditioned in the bug.
The inclusion request is obviously an implicit agreement. I suggested in
the past to have CAs
- make a request also in writing
- provide audit statements, root certificates and other documents in
hard copy
- sign a standard agreement with Mozilla
This is the common approach with all major browsers besides Mozilla.
> So, you are saying that Mozilla, by way of its software agent
> ("Firefox" and/or "NSS") are standing in for some of the risks,
> liabilities, obligations expressed in the CA's RPA ?
No, but a user can easily prove that by using the browser he adheres to
the RP obligations (except if he overrides the browser configuration -
adds an exception)
> So, what happens in any real case? If grandma stands up and says "I
> don't know how, but I was robbed!"
That's not a case for the CA. Grandma has to sue the party which robbed
her. Provided that there was no flaw in the certification, the CA is
clean and not party of such circumstances.
> A judge might knock the RPA down on the basis that there is a better
> agreement, but I don't know what that would be
No, that's not the case, but I'm not really inclined to give ideas here...
> This is bad, but I think most CAs have stopped
> doing that so blatantly.
Really? I haven't seen that....
Ian G
> On 10/10/2008 01:45 PM, Ian G:
>> Finally, if it ever did get to court, I don't see any good reasons
>> why it would not stand up?
>
>
> Well, I prefer to refrain from commenting on this, but the fact that I
> mentioned it could give you some hint ;-)
Sounds a bit like the RIM/Blackberry case, "right" and "might" and
"justice" was on their side, all the way up to a $600m settlement :)
I don't think anyone wins by relying on hints and hopes. In a
business setting, it would be gambling at best to rely on the basis
that an agreement "might" be struck down if it ever needed to be
tested.... We need certainty.
One good way to achieve certainty is for Mozilla to require the
documents to be declared in the process. This is already explicit
in that the CPS must be provided, and is implicit for other key
documents. We might just want to recognise that the RPA or similar
forms a very important part of that which we call the overall "CPS
package".
Once so declared, it is agreed that this is "the agreement". That
reduces uncertainty, because the CA, Mozo, and the reviewing
community agree that it was the document; this only leaves the poor
end user with the possibility of saying otherwise.
Does that make sense?
>> ( I should clarify things here: there is certainly an agreement
>> between each CA and Mozilla. It's however not a written agreement
>> with only one form, rather it is a compilation including:
>>
>> * the policy,
>> * and in the case of EV, the Guidelines are incorporated,
>> * audit criteria,
>> * any side agreements or historical understandings,
>> * the filed documents under the ascension process,
>> * etc.
>
> Actually the request made by the CA to have their root included
> is/should/might be interpreted as a waiver for any special requirements,
> agreements, conditions except if specifically conditioned in the bug.
??? That I don't follow. How can a request for adding a root be
interpreted as a waiver? Special requirements?
My basic default expectation is that, if there are any waivers, they
would have to be specified in the bug request. They would have to
be clear to the community.
The community might not agree to them, but at a minimum, we should
know, right? Point 2 of the policy says that.
Otherwise we would see all sorts of issues arising. The notion of
there being unknown waivers and exceptions would rip the guts out of
any public faith in the process, I would think?
But I admit to not understanding, can you rephrase?
> The inclusion request is obviously an implicit agreement. I suggested in
> the past to have CAs
>
> - make a request also in writing
They do make a request in writing; it is the bug filing.
> - provide audit statements, root certificates and other documents in
> hard copy
+ I saw Gerv mention that the CAs have to provide a digital copy
from the auditor's website or email address. That's IMO good enough.
+ Root certificates are provided, otherwise it wouldn't work :)
+ Hard copy is not necessary; what is sufficient is clearly
designated digital copies. If this is an issue, ask the CA to amend
their bug to add the hash of each digital copy uploaded or mailed.
This doesn't need to be in the policy, it can be working practice,
and the Mozo people can do it as well.
> - sign a standard agreement with Mozilla
This then is a good point. There is (AFAIK, me not being Mozo) any
real *single* agreement in a document form.
Should there be?
Yes: it would allow mozo to protect themselves and their users.
it would allow mozo to establish some baseline things (e.g.,
Nelson's comments a few weeks ago about one standard for all CAs).
It would allow one law (choice & forum).
It would allow some standard no-no clauses.
It would simplify the complications of deciding what was in the
agreement and what was just "wiki chatter".
It would allow Mozo to push some CAs to tighten up their game.
No: it would cramp the style -- slow down the development of
things, as a single document has a lifetime of 2-8 years.
It would subject us to a long argument as to what it should be.
It would shift the power around a bit (EV v. Mozo v. big CAs).
It would offend the techies. It would empower the lawyers.
It isn't Mozo's policy nor style to slam an EULA on everything.
Each CA is so different, it should have a different agreement.
The browser is the proxy (relying? using?) party for the user and it
is up to the CA to lay this down to user and browser alike.
(yes, big long open question. luckily nobody is paying me to answer
it today!)
> This is the common approach with all major browsers besides Mozilla.
(Might be true, not sure how relevant it is. Copying others isn't
always the smart thing to do.)
>> So, you are saying that Mozilla, by way of its software agent
>> ("Firefox" and/or "NSS") are standing in for some of the risks,
>> liabilities, obligations expressed in the CA's RPA ?
>
> No, but a user can easily prove that by using the browser he adheres to
> the RP obligations (except if he overrides the browser configuration -
> adds an exception)
This is the same thing, just the other side of the coin. Who then
provided this software? Who then sets up this "adherence to RP
obligations" ? Who understands them, who wrote the code to do that?
>> So, what happens in any real case? If grandma stands up and says "I
>> don't know how, but I was robbed!"
>
> That's not a case for the CA. Grandma has to sue the party which robbed
> her. Provided that there was no flaw in the certification, the CA is
> clean and not party of such circumstances.
OK. Two things:
We agree that there is no special duty of care for certificates (as
opposed to a general duty). That's an important point, because it
might be that the only way to establish standing for a user in any
cert dispute is through some special, cert-related duty of care.
Secondly, a "flaw in certificates" ... is a pretty small attack
surface. If we are entirely agreed on that, this simplifies a whole
lot of stuff.
For example, the old hope of secure browsing is that these things
will authenticate a site to a user. Or, as some adverts have it
(below) the certs will apparently say that the site is secure.
That's a big difference from "no flaws in certificates".
It would be nice to agree which it was. Then, we could simply
allocate the liabilities left & right of that statement, and
everyone would be a lot better off.
>> A judge might knock the RPA down on the basis that there is a better
>> agreement, but I don't know what that would be
>
> No, that's not the case, but I'm not really inclined to give ideas here...
Sure. We all have our interests and hopes. But, let's look at it
this way.
It really doesn't help anyone in this forum to protect or downgrade
or mystify things... because these uncertainties rattle through time
until they become failures.
So, assuming that it is not outside ones interest to make things
more certain, what ways can we come up with to clearly make the
agreements of all CAs more certain?
If not in the judge's eyes, but at least in terms of our agreement
that "this is the document", or as the legal folks say, "the answer
is between these four corners of this page."
>> This is bad, but I think most CAs have stopped
>> doing that so blatantly.
>
> Really? I haven't seen that....
I live in hope, but hopes get dashed more frequently than I dare
admit...
https://financialcryptography.com/mt/archives/001050.html
iang
Eddy Nigg
> One good way to achieve certainty is for Mozilla to require the
> documents to be declared in the process.
That might be a good idea...actually that's what I assume when a CA
makes a request for inclusion (but on the other hand, no CA has yet
confirmed or signed an agreement in this respect with Mozilla).
> This is already explicit
> in that the CPS must be provided, and is implicit for other key
> documents.
...not sure which other key documents you refer to...there is no such
requirement per se.
> Once so declared, it is agreed that this is "the agreement". That
> reduces uncertainty, because the CA, Mozo, and the reviewing
> community agree that it was the document
>
> Does that make sense?
I think it does.
>> Actually the request made by the CA to have their root included
>> is/should/might be interpreted as a waiver for any special requirements,
>> agreements, conditions except if specifically conditioned in the bug.
>
>
> ??? That I don't follow. How can a request for adding a root be
> interpreted as a waiver? Special requirements?
By requesting to have the CA root included and by the nature of Mozilla
being a relying party (yes, yes, it is..) it can be assumed that because
no special requirements were tied to that request (like, please also
confirm our XYZ agreements and conditions) Mozilla is not bound not
bound to any agreement set up before, during or after the inclusion.
I expect that the RP obligations in the CP/CPS are the binding
requirements, but not any other additional agreements - since none have
been forwarded during the request. But the legal department of MoFo can
answer these questions better.
>
> My basic default expectation is that, if there are any waivers, they
> would have to be specified in the bug request. They would have to
> be clear to the community.
I think it's the other way around. With making a request for including a
root, any additional agreements, conditions etc. not brought forward
during the document gathering period or upon initial request for
inclusion are void (and the request itself represents a waiver of any
special agreements, conditions or requirements).
> The community might not agree to them, but at a minimum, we should
> know, right? Point 2 of the policy says that.
Obviously any agreement, condition or requirement tied to including a CA
root must be disclosed during request. Otherwise they are not binding
for Mozilla.
>
> They do make a request in writing; it is the bug filing.
>
Nonono...it's still harder to prove than with hard copies. A CA can
claim that the request or anything else within the bug (like comments)
were modified, tainted etc. Bugzilla is under the control of Mozilla and
hence its use in court is questionable to some extend.
>
> + I saw Gerv mention that the CAs have to provide a digital copy
> from the auditor's website or email address. That's IMO good enough.
And you believe that our NSS/CA Policy team archived CP/CPSs and audit
statements upon approval? And you believe that they remain there forever
at the auditors web site? And you believe CP/CPS don't change (or can be
modified, including removal)?
> This doesn't need to be in the policy, it can be working practice,
> and the Mozo people can do it as well.
Sending the root printed in paper would be just an added benefit...if we
are already mailing hard-copies...
>
> Yes: it would allow mozo to protect themselves and their users.
> it would allow mozo to establish some baseline things (e.g.,
> Nelson's comments a few weeks ago about one standard for all CAs).
> It would allow one law (choice & forum).
> It would allow some standard no-no clauses.
> It would simplify the complications of deciding what was in the
> agreement and what was just "wiki chatter".
> It would allow Mozo to push some CAs to tighten up their game.
>
> No: it would cramp the style -- slow down the development of
> things, as a single document has a lifetime of 2-8 years.
> It would subject us to a long argument as to what it should be.
> It would shift the power around a bit (EV v. Mozo v. big CAs).
> It would offend the techies. It would empower the lawyers.
> It isn't Mozo's policy nor style to slam an EULA on everything.
> Each CA is so different, it should have a different agreement.
> The browser is the proxy (relying? using?) party for the user and it
> is up to the CA to lay this down to user and browser alike.
I can't befriend myself with the contra arguments...none are really
valid...CA is not that much about technology, style and a lot about
legalities if we are at it...
>
> (Might be true, not sure how relevant it is. Copying others isn't
> always the smart thing to do.)
>
However the "others" aren't always idiots either...it's good to learn
about what others do and come to a decision if it's also good for you.
> We agree that there is no special duty of care for certificates (as
> opposed to a general duty). That's an important point, because it
> might be that the only way to establish standing for a user in any
> cert dispute is through some special, cert-related duty of care.
Except if the CA says otherwise - something which is obviously disclosed
in the CP/CPS (and reviewed by Mozilla). For example this forum and the
comments period are excellent tools to report on them if they exist.
>
> Secondly, a "flaw in certificates" ... is a pretty small attack
> surface.
But an important one. This is what CAs are here for. But what CAs have
to do in order to remain flawless is beyond this exchange of thoughts here.
> It would be nice to agree which it was. Then, we could simply
> allocate the liabilities left & right of that statement, and
> everyone would be a lot better off.
>
That's over-simplified perhaps...liabilities is really only part of the
story, isn't it!?
> It really doesn't help anyone in this forum to protect or downgrade
> or mystify things... because these uncertainties rattle through time
> until they become failures.
You are talking about one specific agreement set up by one specific CA.
> If not in the judge's eyes, but at least in terms of our agreement
> that "this is the document", or as the legal folks say, "the answer
> is between these four corners of this page."
>
The four corners are in the Mozilla CA Policy. It clearly says what CAs
must do and can't do (in order to be shipped with the software).
Frank Hecker
don't have time to respond to every message, unfortunately.]
Ian G wrote:
> If that was true, there would likely be an agreement between Mozilla
> and Verisign (following the above RPA tradition) explicitly giving
> Mozilla permission to RELY.
>
> I'm not Mozilla, so I guess we have to ask: Frank, is there any
> such agreement that explicitly gives Mozilla permission to RELY?
We (Mozilla Foundation) do not sign explicit agreements with CAs
regarding inclusion of root certificates, and never have to my
knowledge. Whether our dealings with CAs result in an implicit
contract/agreement is a question that (as a non-lawyer) I'm not prepared
to express an opinion on.
Whether it's a good idea to have such agreements in future is an open
question, and I don't have any useful thoughts on it right now. However
I will say that in terms of our ongoing relationship with our users, at
least for Firefox, the relevant legal framework will be that outlined by
Harvey Anderson (general counsel for the Mozilla Corporation) in his
series of blog posts at <http://lockshot.wordpress.com/>. Any explicit
agreements with CAs would have to be consistent with that framework.
Frank Hecker
> The goals of Mozo are written somewhere else, and they only speak
> softly to the issue of security from memory. I think it is worth
> revisiting them, perhaps someone has them to hand?
Are you referring to the high-level goals of the Mozilla Foundation (not
necessarily security-related)? The goals at the highest level are
expressed traditionally by the mission statement "promote choice and
innovation on the Internet". More recently we have the Mozilla Manifesto
as an expanded statement of principles and goals:
http://www.mozilla.org/about/manifesto
Note that the Manifesto does address security-related concerns in a
couple of places, most notably principles 4 and 8.
Going down a level, to my knowledge we (still) don't have a single
authoritative document that addresses the topic of overall security
goals for Firefox or other Mozilla products. However Johnathan
Nightingale has blogged a lot on this topic, and I suspect one could put
together such a document based on what Johnathan and others have written.
Turning to the question of CAs specifically, the most complete (and
unofficial) take on the question is probably my CA certificate
"meta-policy" document:
http://hecker.org/mozilla/ca-certificate-metapolicy
(Though note that I haven't read it in detail for quite a while, and
it's possible that my thinking may have changed in at least one or two
areas.)
> I would interpolate the policy goals from the following snippets:
>
> "based on the benefits and risks of such inclusion
> to typical users of those product"
>
> "would cause undue risks to users' security"
>
> "might cause technical problems with the operation
> of our software"
>
> "provide some service relevant to typical users of
> our software products;"
>
> These speak to higher level goals.
That language in the policy was probably my adaption of points 5 and 6
in the CA certificate metapolicy. My main thinking at the time revolved
around the idea of treating PKI and inclusion of CA certs in the context
of overall product security, with trade-offs made as appropriate to
balance risks and benefits to typical users.
If I were to rewrite the metapolicy today, I'd probably explore two
additional points:
* treating the EV case differently than the non-EV case
* not having a "one size fits all" policy for CAs, but looking at CAs in
context, at least to some extent
(To expand on the latter point, what I mean by "in context" includes
things like whether the CA is government-operated vs. private sector,
which geographic and vertical markets it serves, what its market share
is, etc.)
> If anything, Frank seems to be implying a goal of "reasonable
> efficiency" but that seems to not need to be stated. If anything,
> he's talking about the efficiency of the tools that meet the higher
> level goals (whatever they are), not the higher level goals.
I'm not sure what you mean by "reasonable efficiency" in this context.
Ian G
> [I'm trying to catch up on these threads, my apologies for the delay. I
> don't have time to respond to every message, unfortunately.]
(I understand, I also feel the pressure.)
> Ian G wrote:
>> If that was true, there would likely be an agreement between Mozilla
>> and Verisign (following the above RPA tradition) explicitly giving
>> Mozilla permission to RELY.
>>
>> I'm not Mozilla, so I guess we have to ask: Frank, is there any
>> such agreement that explicitly gives Mozilla permission to RELY?
>
> We (Mozilla Foundation) do not sign explicit agreements with CAs
> regarding inclusion of root certificates, and never have to my
> knowledge. Whether our dealings with CAs result in an implicit
> contract/agreement is a question that (as a non-lawyer) I'm not prepared
> to express an opinion on.
I've been thinking a lot about this, too, and have a lot to say, but
this is a technical forum, and legal agreements don't compile....
Is there a better place?
> Whether it's a good idea to have such agreements in future is an open
> question, and I don't have any useful thoughts on it right now. However
My thoughts, compressed: for the CAs, much work has been done in
the past on the legal framework. The upshot, the final result, of
that work is that the CA's liability to the end-user is zero.
Meanwhile, users continue to rely on stuff, do stupid things, and
the environment is getting worse. If they muck up and decide they
want remedy, then I would fear that the legal theory of "deepest
pockets" is applicable.
Mozo is stuck between those two forces. So, to cut a lot of
analysis short, the obvious course is to follow the "simple view"
and disclaim all liability to users on the basis of using certificates.
> I will say that in terms of our ongoing relationship with our users, at
> least for Firefox, the relevant legal framework will be that outlined by
> Harvey Anderson (general counsel for the Mozilla Corporation) in his
> series of blog posts at <http://lockshot.wordpress.com/>. Any explicit
> agreements with CAs would have to be consistent with that framework.
Yes, I've read the last few posts on that, I think my thoughts are
consistent, at least.
There is a lot more to say about this... is there a forum that is
better at this stuff than a technical forum? I posted a comment on
the last blog entry on this topic.
iang
Ian G
> Ian G wrote:
>> The goals of Mozo are written somewhere else, and they only speak
>> softly to the issue of security from memory. I think it is worth
>> revisiting them, perhaps someone has them to hand?
>
> Are you referring to the high-level goals of the Mozilla Foundation (not
> necessarily security-related)? The goals at the highest level are
> expressed traditionally by the mission statement "promote choice and
> innovation on the Internet". More recently we have the Mozilla Manifesto
> as an expanded statement of principles and goals:
>
> http://www.mozilla.org/about/manifesto
>
> Note that the Manifesto does address security-related concerns in a
> couple of places, most notably principles 4 and 8.
Yes, that's what I was thinking of (I think):
4. Individuals' security on the Internet is fundamental and cannot
be treated as optional.
8. Transparent community-based processes promote participation,
accountability, and trust.
> Going down a level, to my knowledge we (still) don't have a single
> authoritative document that addresses the topic of overall security
> goals for Firefox or other Mozilla products. However Johnathan
> Nightingale has blogged a lot on this topic, and I suspect one could put
> together such a document based on what Johnathan and others have written.
>
> Turning to the question of CAs specifically, the most complete (and
> unofficial) take on the question is probably my CA certificate
> "meta-policy" document:
>
> http://hecker.org/mozilla/ca-certificate-metapolicy
>
> (Though note that I haven't read it in detail for quite a while, and
> it's possible that my thinking may have changed in at least one or two
> areas.)
Hmm, worth a read, yes.
>> I would interpolate the policy goals from the following snippets:
>>
>> "based on the benefits and risks of such inclusion
>> to typical users of those product"
>>
>> "would cause undue risks to users' security"
>>
>> "might cause technical problems with the operation
>> of our software"
>>
>> "provide some service relevant to typical users of
>> our software products;"
>>
>> These speak to higher level goals.
>
> That language in the policy was probably my adaption of points 5 and 6
> in the CA certificate metapolicy. My main thinking at the time revolved
> around the idea of treating PKI and inclusion of CA certs in the context
> of overall product security, with trade-offs made as appropriate to
> balance risks and benefits to typical users.
I don't find fault in it today.
> If I were to rewrite the metapolicy today, I'd probably explore two
> additional points:
>
> * treating the EV case differently than the non-EV case
> * not having a "one size fits all" policy for CAs, but looking at CAs in
> context, at least to some extent
>
> (To expand on the latter point, what I mean by "in context" includes
> things like whether the CA is government-operated vs. private sector,
> which geographic and vertical markets it serves, what its market share
> is, etc.)
Yes, I agree with those two, together :)
Meta-Pt 7 agrees, 8 counters.
>> If anything, Frank seems to be implying a goal of "reasonable
>> efficiency" but that seems to not need to be stated. If anything,
>> he's talking about the efficiency of the tools that meet the higher
>> level goals (whatever they are), not the higher level goals.
>
> I'm not sure what you mean by "reasonable efficiency" in this context.
Took a bit of untangling to work it out myself. The context is the
suggestion:
> Our goal here is to avoid having to evaluate lots and lots of
> subordinate CAs, and instead have the roots take care of their
> own subordinates and ensure they're compliant to policy.
Eddy may have made a claim that this didn't match the goals of
Mozilla, to which I responded that an implied goal here is one of
being more productive, and that is not normally stated in a missions
discussion.
Having seen the schedule for CAs, I think we can all appreciate that
the workload is too high.
Getting the CAs to control their sub-CAs will be a big load off of
Mozilla's team, and, assuming it works, increases the number of CAs
available and therefore the number of certificates. So, in the end,
assuming quality is maintained somehow, the project of "roots look
after sub-CAs" meets Mozilla's security leanings, if only by simple
productivity improvements.
Or something?
iang
Frank Hecker
> I'd like to pick this discussion up once again and evaluate what the
> goals of Mozilla and the Mozilla CA policy really are. Certainly the
> above is not the defined goal, but rather provide some reasonable
> assurance about the CAs included in NSS and Mozilla products and allow
> users to rely on
>
> - domain name control validation for web sites
> - email control validation for email
> - identity or organization validation for code signing
> - in case of EV, compliance to the EV guidelines
> - sound physical and logical security, controls, business continuity and
> other aspects as they are covered by the acceptable audit criterion
Unlike Ian, I'm not going to try to parse what "rely on" means. Leaving
that issue aside, I think the above is a reasonable summary of what the
Mozilla CA policy says. However as Ian notes, the above are not really
goals or ends in themselves, they're means to an end, namely to minimize
security risks to typical Mozilla users, trading off risks vs. benefits
in an approach consistent with that taken with other security-relevant
parts of the product.
So making trade-offs of various kinds is an inherent part of the CA
evaluation process. (For example, I think the security risks associated
with a non-EV CA are less than with an EV CA. Note that I don't mean
that non-EV certs are more "secure", I mean that as more and more major
ecommerce sites move to EV certificates any problems with CAs issuing
non-EV certs will be less likely to affect typical users.)
Eddy Nigg
> Eddy Nigg wrote:
>> I'd like to pick this discussion up once again and evaluate what the
>> goals of Mozilla and the Mozilla CA policy really are. Certainly the
>> above is not the defined goal, but rather provide some reasonable
>> assurance about the CAs included in NSS and Mozilla products and allow
>> users to rely on
>>
>> - domain name control validation for web sites
>> - email control validation for email
>> - identity or organization validation for code signing
>> - in case of EV, compliance to the EV guidelines
>> - sound physical and logical security, controls, business continuity
>> and other aspects as they are covered by the acceptable audit criterion
>
> Unlike Ian, I'm not going to try to parse what "rely on" means. Leaving
> that issue aside, I think the above is a reasonable summary of what the
> Mozilla CA policy says. However as Ian notes, the above are not really
> goals or ends in themselves, they're means to an end, namely to minimize
> security risks to typical Mozilla users, trading off risks vs. benefits
> in an approach consistent with that taken with other security-relevant
> parts of the product.
>
Of course! But lets see this in the right context of CAs, their current
requirements and obligations. We should also find the right context in
relation to the investments made in cryptographic libraries, most
notably NSS itself.
It can't be (IMO) that there are huge requirements placed on CAs -
including auditing - and at the same minute dismissed through some
questionable practices (like "we'll audit other CAs" or "we'll set up
CA's on the Falklands through remote"). IMO it's a security risk if the
physical and logical controls of a CA are not audited, confirmed and
attested by a third party auditor - the very same it is for any root CA.
That's why Mozilla decided that this is one of the requirements in order
to mitigate and minimize the risk for typical users.
It seems to me that this was the right approach as MITM attacks are
effectively prevented and encryption (and identification) to a high
degree guarantied. The recent example showed clearly that no CA issued
certificates were involved (and the failure was that of the user - with
some help from the UI). But overall, it seems to be working.
Basically what I'm asking for is, to apply the same requirements equally
upon all CAs, being it root or otherwise. It doesn't mean that Mozilla
has to review and approve each intermediate CA (so it can do that under
certain circumstances and is even required to do so as the Austrian
example has shown - even though they are subordinate only to some
extend), instead the applying party shall provide attestation confirming
those.
Having said that, I suggest that we start to process the requests for
inclusion in a more efficient way and stick to the schedules we've
defined. Kathleen does an excellent job and I really believe that we own
better performance to the CAs which applied. Kathleen is also filtering
and detecting many occurrences of problematic practices or
incompleteness in the requests, those which might be picked on in the
public discussion. This pre-filtering and pre-evaluation is an important
part of the process and will help to process those requests more
efficiently.
IMO a CA should not come up for discussion if clear deficiencies are
detected or the request most likely will receive some objections. This
includes the latest CA which had the OCSP problem (which was detected,
but nevertheless advanced to the public discussion) and this should have
been cleared upfront.
In this respect I suggest to review the upcoming CAs for public
discussion and process those with the most likely least problems first.
Schedule CAs, which might be problematic, which might be incomplete or
which most likely will fall into a grey area, back - in favor of those
which are clearly conforming to the Mozilla CA policy (and don't have
problematic practices).