WISeKey root inclusion request (re-start public discussion)
Frank Hecker
past few weeks. A combination of illness (both my own and family),
out-of-town trips, and other Mozilla Foundation business kept me from
having any significant time to devote to CA matters. I am working on
ways to ensure that I am not the bottleneck in this process in the long
term; in the short term I'm going to try to restart CA public
discussions on a regular schedule.
Per the CA schedule, the next CA on the list for public comment is
WISeKey, which has applied to add its (one) root CA certificate to the
Mozilla root store, as documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=371362
and in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#WISeKey
WISeKey has been through an initial comment period a while back, during
which we got nvolved in a lengthy discussion about WISeKey's Blackbox
product (a "CA in a box" product intended for enterprise deployment) and
whether and how auditing was done for WISeKey's subordinate CAs
associated with that product. WISeKey supplied more information about
their arrangements, which you can find in the bug.
We've had some lengthy discussions about the issue of auditing
subordinate CAs. I'm not going to rehash all those discussions, I'll
just summarize my current thinking:
First, the general issue of auditing subordinate CAs was something we
didn't think through much when we did our Mozilla CA policy: We were
thinking of a fairly simple model where a CA organization operated both
its root CA(s) and also any subordinate CAs under those roots, with a
CPS and associated audit that covered the both root and subordinates
all. In actual practice things are more complicated, and our policy
didn't really capture that complication.
My personal opinion is that it doesn't make sense to try to address this
complication by mandating traditional WebTrust-style audits of any and
all subordinates under a root. I think this approach is impractical, and
I don't think it's necessary. I'd rather look at the overall manner in
which CAs exercise controls over subordinates, legally, technically, and
otherwise, as well as the general nature of the subordinates and how
they function in practice. I think in some cases it might make sense to
require audits for all subordinates, and in some cases it might not.
For purposes of this particular evaluation, my goal is for us to gain a
shared understanding of what WISeKey actually does, including getting
answers to any remaining questions, and then I'll make a judgement call
as to whether what WISeKey is doing meets the general intent of our policy.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Ian G
> We've had some lengthy discussions about the issue of auditing
> subordinate CAs. I'm not going to rehash all those discussions, I'll
> just summarize my current thinking:
>
> First, the general issue of auditing subordinate CAs was something we
> didn't think through much when we did our Mozilla CA policy: We were
> thinking of a fairly simple model where a CA organization operated both
> its root CA(s) and also any subordinate CAs under those roots, with a
> CPS and associated audit that covered the both root and subordinates
> all. In actual practice things are more complicated, and our policy
> didn't really capture that complication.
Yes, I agree. IMHO, the policy has served remarkably well, and of
course issues will arise with more experience.
> My personal opinion is that it doesn't make sense to try to address this
> complication by mandating traditional WebTrust-style audits of any and
> all subordinates under a root. I think this approach is impractical, and
> I don't think it's necessary. I'd rather look at the overall manner in
> which CAs exercise controls over subordinates, legally, technically, and
> otherwise, as well as the general nature of the subordinates and how
> they function in practice. I think in some cases it might make sense to
> require audits for all subordinates, and in some cases it might not.
Some musing on this. I agree it is an issue that we should try and
clarify, if not nail down.
One way to short-circuit this is to simply state that the root CA is
responsible for any/all subroots. So this would imply that the root
CA's policies and audit drill down through the subroots, and they apply.
Then, it would be up to the root auditor to decide whether a subroot
needed a separate audit or not.
One problem with this is that it might also not be realistic. Consider
two CAs, one of which does "style A" and another does "style B". In the
doco and audit for the root CA, there will be a need somehow to capture
that distinction. The natural direction here will end up that the
root's policies will tend to say "see the subroot's policies for more
detail."
So Mozilla's review of this will be looking at a blank spot. E.g.,
future subroots. I see this contrast all frequently. We accept the
base situation, then the CA goes and issues another subroot. Suddenly a
whole new class of activity has occurred, and there is no check done on
this until the next audit, and none at all by Mozilla.
One way to deal with that is to add a criteria that says "audit should
list the allowed subroots" or somesuch. So new subroots would have to
wait until the next audit. But this might slow down the process, add
complication, push the audit into too much management, and be also
somewhat arbitrary; CAs can be inventive and find ways around it, and
audits might be sympathetic to these ideas. Mozilla only does one
review, so in time the topic will drift.
Either way we look at it, I feel that the more controls are put in
place, the more we end up putting in "paper fixes" and the more we
complicate things for a gain that we don't fully understand.
Alternatively, we just set the responsibility, and pass it to the root CA.
This does somewhat put the finger on the relationship between the CA and
Mozilla. Currently, this is an informal agreement based on the policy,
bug filing, and other communications. What might be better is a single
document (or mod to the policy) that specified what the complete
agreement was (listing the others). In this we could typically include
the disclaimers of liability, and how we would deal with the disputes,
e.g., over the activities of the CA's wilder subroots, and at an extreme
level, any root revocation at Mozilla's discretion.
iang
Eddy Nigg
> I agree it is an issue that we should try and
> clarify, if not nail down.
Sounds good!
>
> One way to short-circuit this is to simply state that the root CA is
> responsible for any/all subroots.
This is the situation we had until recently, with CAs under their own
control. Of course the CA is "responsible" for all its sub roots...
> So this would imply that the root CA's
> policies and audit drill down through the subroots, and they apply.
> Then, it would be up to the root auditor to decide whether a subroot
> needed a separate audit or not.
Except that some CA policies many times don't even cover the aspects of
the sub ordinate CAs. Such "root" CAs are simply audited as their CP/CPS
defines. An auditor is not required to audit something not claimed in
their policies. Auditors generally confirm the claims made in the
CP/CPS, not those that aren't made.
>
> One problem with this is that it might also not be realistic. Consider
> two CAs, one of which does "style A" and another does "style B". In the
> doco and audit for the root CA, there will be a need somehow to capture
> that distinction. The natural direction here will end up that the root's
> policies will tend to say "see the subroot's policies for more detail."
If that policy was part of the audit, that would already provide good
indications.
>
> So Mozilla's review of this will be looking at a blank spot. E.g.,
> future subroots. I see this contrast all frequently. We accept the base
> situation, then the CA goes and issues another subroot. Suddenly a whole
> new class of activity has occurred, and there is no check done on this
> until the next audit, and none at all by Mozilla.
Right. It was suggested to require a yearly audit or by other frequency.
> Either way we look at it, I feel that the more controls are put in
> place, the more we end up putting in "paper fixes" and the more we
> complicate things for a gain that we don't fully understand.
I don't perceive it as such at all. What do we not understand? There is
a very competent team at work (Kathleen, Gerv, Frank) and a few of us
here. I think the issues are fully understood.
>
> Alternatively, we just set the responsibility, and pass it to the root CA.
>
That's what we had previously. Some easy-to-find flaws already have been
detected (DigiNotar, Staat der Nederlanden). Those were just the ones we
came across by chance, I don't even want to know about everything we
don't know.
>In this we could typically include
> the disclaimers of liability, and how we would deal with the disputes,
> e.g., over the activities of the CA's wilder subroots, and at an extreme
> level, any root revocation at Mozilla's discretion.
>
One of the problems is of course that no follow ups exist currently as
you correctly stated above. So far nobody has ever dedicated time to
review CAs not up for inclusion.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org
Eddy Nigg
>...in the short term I'm going to try to restart CA public
> discussions on a regular schedule.
Nice to see you back here!
> First, the general issue of auditing subordinate CAs was something we
> didn't think through much when we did our Mozilla CA policy: We were
> thinking of a fairly simple model where a CA organization operated both
> its root CA(s) and also any subordinate CAs under those roots, with a
> CPS and associated audit that covered the both root and subordinates
> all. In actual practice things are more complicated, and our policy
> didn't really capture that complication.
I'm glad that this issue is recognized as such!
>
> My personal opinion is that it doesn't make sense to try to address this
> complication by mandating traditional WebTrust-style audits of any and
> all subordinates under a root. I think this approach is impractical, and
> I don't think it's necessary. I'd rather look at the overall manner in
> which CAs exercise controls over subordinates, legally, technically, and
> otherwise, as well as the general nature of the subordinates and how
> they function in practice.
Even though your statement would on general issues make sense, we must
also recognize that it would be very difficult to implement. First of
all it's a matter of policy and every time the policy didn't address a
specific issue in the past we were in a Grey area. The "problematic
practices" were implemented as a result of it.
I believe that the policy (and/or other relevant policy guiding
statements) should be clear in respect what Mozilla requires from the
CAs. This is important for planning and preparing for the CAs
themselves, it's important for us in order to make the right judgment. I
think that a case-by-case approach is at least unfair and hardly
sustainable in the long term. Incidentally those CAs which would be most
likely acceptable by the terms you outlined above, are usually the ones
which either audit their whole infrastructure or are not affected by the
problematic practices of sub-ordinate CAs in first place. But obviously
it's difficult to draw a clear line...
There are various risks Mozilla needs to be prepared to take in case no
clear policy is defined, mainly the inclusion-by-proxy of CAs (it rather
would not have included) and questionable practices of sub-ordinate CAs.
Additionally I believe that Mozilla shouldn't take the risk of including
CAs (sub-ordinate or not) *without* having their physical and logical
infrastructure confirmed and audited. Specially problematic are those
which are independent entities in relation to the root CA and operate
their own infrastructure (inclusion by proxy). It makes no sense
whatsoever to require auditing of a root, if the issuing CA isn't
audited at all. Recent examples have shown that it's no guaranty for
adherence to the Mozilla CA policy - despite the fact that the very same
(cross-signed or sub-ordinate) CAs were actually audited independently!!!
(I refrain from getting into the auditing aspects, but it makes a great
deal and difference for all parties involved. Otherwise Mozilla and the
other browsers wouldn't made it a requirement from the beginning.)
> I think in some cases it might make sense to
> require audits for all subordinates, and in some cases it might not.
Can you define those cases? What are the requirements and where doesn't
and where does it make sense? How to draw the line? You must be specific
in order for us to understand the differences!
> For purposes of this particular evaluation, my goal is for us to gain a
> shared understanding of what WISeKey actually does, including getting
> answers to any remaining questions, and then I'll make a judgement call
> as to whether what WISeKey is doing meets the general intent of our policy.
In this particular case I think that the practice in question doesn't
meet the requirements of the Mozilla CA policy. This includes in
particular section 6 and 7 of the Mozilla CA Policy.
>
> WISeKey has been through an initial comment period a while back, during
> which we got nvolved in a lengthy discussion about WISeKey's Blackbox
> product (a "CA in a box" product intended for enterprise deployment) and
> whether and how auditing was done for WISeKey's subordinate CAs
> associated with that product. WISeKey supplied more information about
> their arrangements, which you can find in the bug.
>
Frank, I greatly missed the thorough and systematic work of Kathleen in
this bug and it's a pity she didn't perform another round of
"information gathering" in case some new evidence was provided. Anyhow,
I couldn't find anything new in the bug since the last time. I'm not
sure what is supposed to have changed.
Since I can't find anything new, I assume that nothing has changed and
therefore the condition for inclusion didn't change at all. If we
consider that all recent inclusion requests were specifically tested for
such practices - most notably CAs like Comodo, but also T-Systems who's
inclusion has been delayed as a result of it - I can't see any
particular reason for making an exception here. Not only do their
products circumvent the audit requirement, they might be in direct
conflict with the basic requirements of the Mozilla CA policy such as
email and domain validation (IIRC - see comment 32 in bug 371362).
(Additionally, I couldn't confirm that this CA commands any significant
market share with the information at my disposal. I'm the opinion that
it would be a mistake to make an exception on the audit requirement for
sub-CAs, which in the future could serve as an argument in favor for
similar scenarios.
It was also pointed out at the bug that this CA is in MS software,
however I suspect their policies to be also in conflict of the MS root
program. Just some side-note...)
Eddy Nigg
>
> Frank, I greatly missed the thorough and systematic work of Kathleen in
> this bug and it's a pity she didn't perform another round of
> "information gathering" in case some new evidence was provided. Anyhow,
> I couldn't find anything new in the bug since the last time. I'm not
> sure what is supposed to have changed.
>
I forgot to mention, that in case inclusion is relevant we should gather
additional information about the auditor and independent confirmation of
the audit report.
Ian G
> I believe that the policy (and/or other relevant policy guiding
> statements) should be clear in respect what Mozilla requires from the
> CAs.
It's a nice ideal, but I wonder myself whether it can be achieved. This
is one of the reasons why we have ended up with the race-to-the-bottom
in secure browsing; necessitating (?) the EV thing, etc etc.
Here we are, 14 years after this started, and we still haven't got a
"clear and reasonable" regime. That should tell us something :)
Not that I disagree with your central point that it *should be* clear,
it is just that I wonder if it can be clear.
> This is important for planning and preparing for the CAs
> themselves, it's important for us in order to make the right judgment. I
> think that a case-by-case approach is at least unfair and hardly
> sustainable in the long term.
"Yep, exactly, but..."
>> I think in some cases it might make sense to
>> require audits for all subordinates, and in some cases it might not.
>
> Can you define those cases?
I think if the subroots were managed by the lead CA, and the CPS said
they were under the same set of policies, then there would be little
point in requiring separate audits.
If on the other hand they were managed by other organisations, and they
were not under some agreement, then there is an open-ended question, so
it might make sense to say (in a Mozo requirement) that uncontrolled
subroots are to be separately audited.
The problem then being that between those two points there is an awful
lot of space.
> What are the requirements and where doesn't
> and where does it make sense? How to draw the line? You must be specific
> in order for us to understand the differences!
Well, I suspect Mozo doesn't know. Demanding a solution isn't going to
result in a solution, but it might result in a line being drawn. Then,
in 2 years we'll be back here challenging that line, and grumbling about
how some smart CA crossed the line or bent it or broke it or made lotsa
dosh or something.
In such a circumstance, case-by-case makes sense. Mozo might benefit by
letting the market experiment. That old socialism stuff where we tell
everyone what they have to do is so out of style these days (although
you wouldn't know it if you looked at the finance markets ;) .
iang
Ian G
> On 11/15/2008 06:29 PM, Ian G:
>> I agree it is an issue that we should try and
>> clarify, if not nail down.
>
> Sounds good!
>
>>
>> One way to short-circuit this is to simply state that the root CA is
>> responsible for any/all subroots.
>
> This is the situation we had until recently, with CAs under their own
> control. Of course the CA is "responsible" for all its sub roots...
>
>> So this would imply that the root CA's
>> policies and audit drill down through the subroots, and they apply.
>> Then, it would be up to the root auditor to decide whether a subroot
>> needed a separate audit or not.
>
> Except that some CA policies many times don't even cover the aspects of
> the sub ordinate CAs. Such "root" CAs are simply audited as their CP/CPS
> defines. An auditor is not required to audit something not claimed in
> their policies. Auditors generally confirm the claims made in the
> CP/CPS, not those that aren't made.
So, in the above case, it seems that we have found a hole in the
criteria. We might just need then to add some comments about subroots
to the policy. Perhaps:
"The CPS is to identify the policy on subroots."
"The CPS is to state whether subroots are covered by the CA's policy or
by other policies or other regimes."
"Auditor is to opine on whether the subroots policy of the CA raises any
undue risks."
(just throwing stuff up on the whiteboard here...)
>> One problem with this is that it might also not be realistic. Consider
>> two CAs, one of which does "style A" and another does "style B". In the
>> doco and audit for the root CA, there will be a need somehow to capture
>> that distinction. The natural direction here will end up that the root's
>> policies will tend to say "see the subroot's policies for more detail."
>
> If that policy was part of the audit, that would already provide good
> indications.
Yes, sure, but the problem with this is that the CA's policy can say
this year "we don't do subroots" and next year it can say "we do
subroots under our own policies" and the year after "we do subroots if
they give us cash" ...
Meanwhile, every fresh audit can be led along with a slight change to
the previous. Frog boiling, it is called.
The Mozilla review can only catch the first one, and an acceptable part
of life is that there is an (albeit controlled) method of changing the
policies over time. The boiling frog is (a) going to bypass Mozo's
review and (b) make someone a lotta dosh.
I can see solutions to this, but they are not going to make people laugh
with joy ;) E.g., Mozo does its review every year...
>> So Mozilla's review of this will be looking at a blank spot. E.g.,
>> future subroots. I see this contrast all frequently. We accept the base
>> situation, then the CA goes and issues another subroot. Suddenly a whole
>> new class of activity has occurred, and there is no check done on this
>> until the next audit, and none at all by Mozilla.
>
> Right. It was suggested to require a yearly audit or by other frequency.
Yes, that is frequently suggested. I don't know why anyone believes it
will work. I can sort of understand that everyone feels that if we just
try harder and double the checks, it will be good, but surely we have
passed the age of innocence by now? Sarbanes-Oxley and all that. More
checking doesn't solve the issue, but it sure makes someone a lotta dosh.
>> Either way we look at it, I feel that the more controls are put in
>> place, the more we end up putting in "paper fixes" and the more we
>> complicate things for a gain that we don't fully understand.
>
> I don't perceive it as such at all. What do we not understand? There is
> a very competent team at work (Kathleen, Gerv, Frank) and a few of us
> here. I think the issues are fully understood.
Well, if you understand it, lay out your solution. Now compare the
solution to the solutions of every other CA. They will be different.
So, obviously there will be a choice to make ... and the very competent
team might conclude ... this is harder than we thought :)
E.g., WISeKey's solution will be "trust us, it's a grand product, and it
follows the rules you laid out."
>> Alternatively, we just set the responsibility, and pass it to the root
>> CA.
>>
>
> That's what we had previously. Some easy-to-find flaws already have been
> detected (DigiNotar, Staat der Nederlanden). Those were just the ones we
> came across by chance, I don't even want to know about everything we
> don't know.
Can you describe those flaws for me or us? Case studies are helpful.
>> In this we could typically include
>> the disclaimers of liability, and how we would deal with the disputes,
>> e.g., over the activities of the CA's wilder subroots, and at an extreme
>> level, any root revocation at Mozilla's discretion.
>>
>
> One of the problems is of course that no follow ups exist currently as
> you correctly stated above. So far nobody has ever dedicated time to
> review CAs not up for inclusion.
>
Right. This is a clear flaw. It's also likely a trap, as we can
probably imagine that at least one of those has moved over the last
decade (since original incorporation) to be outside the standards of
"today". I'm just speaking statistically here.
Which will bring up some fascinating choices. I wouldn't want to be
over-hasty in pushing a bureaucratic solution to that, and then
discovering that the result creates bad precedents and backfires on us.
iang
Frank Hecker
> IMHO, the policy has served remarkably well, and of
> course issues will arise with more experience.
I wouldn't go so far as to say "the policy has served remarkably well".
However I think it has served as a useful document in terms of providing
a context for our discussions, has helped in surfacing some
long-standing CA-related issues, and has I think shed more light on what
for many years was sort of a overlooked part of the overall Internet/web
infrastructure.
> One way to short-circuit this is to simply state that the root CA is
> responsible for any/all subroots. So this would imply that the root
> CA's policies and audit drill down through the subroots, and they apply.
> Then, it would be up to the root auditor to decide whether a subroot
> needed a separate audit or not.
I think this approach would be good if we were starting from a
greenfield environment. However I think in the current CA environment
we're faced with a situation where in practice roots don't necessarily
always accept direct responsibility for the actions of their
subordinates (or for those of other root CAs that they've issued cross
certificates for). From a practical standpoint the issuance of
subordinate CA certificates or cross certificates has been seen as more
of a technical issue: "A needs to treat B as a subordinate CA because B
wants/needs to take advantage of A's inclusion in IE/Firefox/etc."
This predominant attitude toward subordinates is a defect to be sure.
The question is, to what extent (and in what circumstances) is it a
security-relevant defect.
> One problem with this is that it might also not be realistic. Consider
> two CAs, one of which does "style A" and another does "style B". In the
> doco and audit for the root CA, there will be a need somehow to capture
> that distinction. The natural direction here will end up that the
> root's policies will tend to say "see the subroot's policies for more
> detail."
Right, and that's a quite common situation: There will be a root CA that
really acts just as a convenient "gathering point" for a bunch of
different subordinates to get CA certs from, with the root's policies
just having to do with subordinates, and every relevant to end-entity
certs pushed down to the subordinate CAs. This is the model for a lot of
government-sponsored PKIs where the PKI is not just government-specific
but serves as an unmbrella for commercial and nonprofit groups to set up
their own CAs under the government-operated and-authorized root.
> Either way we look at it, I feel that the more controls are put in
> place, the more we end up putting in "paper fixes" and the more we
> complicate things for a gain that we don't fully understand.
Yes, and I'm going to use your comment as a jumping off point for a
broader comment:
We have traditionally treated CA inclusion as a security issue, with the
purpose of evaluating CAs for inclusion to ensure that we didn't suffer
major security vulnerabilities due to CA actions or omissions. However I
could also make the case that the CA is less like the other
security-related stuff we do (e.g., security testing, fixing reported
vulnerabilities in the code, etc.) and more like what we've been doing
in the licensing/copyright area.
I think there's general agreement that browser exploits are a "clear and
present danger", and it's worth our spending whatever time it takes to
make sure they're fixed as expeditiously as possible. Over on the
legal/licensing/copyright front, there are certainly bad things that
could happen to us, like getting code in the tree that was not
authorized by the creator, getting code in that was under an
incompatible license, and so on. Based on our experience and judgment
over time, we've deemed it adequate to set up some safeguards in place:
having formal license policies and a formal committers agreement, having
people vouch for others seeking commit access, and so on. However we
haven't gone overboard with double- and triple-checking everyone who
contributes code, vetting every single code contribution for legal
issues, and so on. This would greatly raise the bar to getting code
contributions from people, and we just don't see that as being justified
based on experience and the perceived risks.
So, which is the better model for including CAs? I'm beginning to think
that the licensing/copyright situation is perhaps a better model for us:
set up a documented framework, perform some reasonable due diligence,
and be transparent in terms of what we're doing (as happens when
approving new committers), but when making judgment calls err on the
side of inclusion rather than exclusion.
> This does somewhat put the finger on the relationship between the CA and
> Mozilla. Currently, this is an informal agreement based on the policy,
> bug filing, and other communications. What might be better is a single
> document (or mod to the policy) that specified what the complete
> agreement was (listing the others). In this we could typically include
> the disclaimers of liability, and how we would deal with the disputes,
> e.g., over the activities of the CA's wilder subroots, and at an extreme
> level, any root revocation at Mozilla's discretion.
I'd like at some point to consider formalizing our relationships with
CAs, e.g., through some sort of formal legal agreement associated with
Mozilla including a root. That would take a bit of work and involve a
number of people to get it done right, and unfortunately I have more
pressing priorities right now in the CA area. (Basically: getting
requests processed in a timely manner and doing the work necessary to
have someone else take over these duties sometime in 2009.)
However I think these sorts of discussions are useful, as they will
provide good context if/when we actually get down to drafting a formal
CA agreement.
Frank Hecker
> On 11/15/2008 06:29 PM, Ian G:
>> Either way we look at it, I feel that the more controls are put in
>> place, the more we end up putting in "paper fixes" and the more we
>> complicate things for a gain that we don't fully understand.
>
> I don't perceive it as such at all. What do we not understand? There is
> a very competent team at work (Kathleen, Gerv, Frank) and a few of us
> here. I think the issues are fully understood.
Not to speak for Ian, but I interpreted his comments as follows: We can
add more provisions to the policy to address particular situations, but
what do we ultimately gain in terms of enhanced security for end users?
It's like adding more and more provisions to laws or regulations in
order to cover special cases, to close loopholes, and so on. Is the
extra complexity (in terms of writing the laws and regulations,
interpreting them, enforcing them, etc.) worth the trouble? And in our
case we have to remember that me, Kathleen, and others don't have
infinite time and resources at our disposal.
> One of the problems is of course that no follow ups exist currently as
> you correctly stated above. So far nobody has ever dedicated time to
> review CAs not up for inclusion.
As I said, our time is finite.
Frank Hecker
> Eddy Nigg wrote:
<snip>
>> Right. It was suggested to require a yearly audit or by other frequency.
Related to this point: I don't know if anyone's noticed this, but
WebTrust seems to be getting clogged in terms of getting new audit
reports out and published. I periodically do a web script that downloads
reports from webtrust.org by number (so I catch all reports issued), and
it seems like there aren't a whole lot of new reports coming out -- at
least, I would have have expected to have seen more reports given the
number of CAs out there supposedly doing WebTrust audits.
This is by way of saying that even if we required annual audit reports,
it's not clear to me that CAs could produce them. There seem to be some
bottlenecks in the CA audit realm, at least in the WebTrust case. I
don't know if this is a problem with WebTrust specifically (i.e.,
central program administrators) or with the availability of
WebTrust-authorized audit teams.
> Yes, that is frequently suggested. I don't know why anyone believes it
> will work. I can sort of understand that everyone feels that if we just
> try harder and double the checks, it will be good, but surely we have
> passed the age of innocence by now? Sarbanes-Oxley and all that. More
> checking doesn't solve the issue, but it sure makes someone a lotta dosh.
Well, it doesn't make any extra money for me, or for the Mozilla
Foundation :-) More seriously, I think the analogy to Sarbanes-Oxley is
relevant, for reasons I've previously expressed.
>> That's what we had previously. Some easy-to-find flaws already have
>> been detected (DigiNotar, Staat der Nederlanden). Those were just the
>> ones we came across by chance, I don't even want to know about
>> everything we don't know.
>
> Can you describe those flaws for me or us? Case studies are helpful.
Eddy's talking about cases where CAs issued certificates with email
addresses but did not apparently validate control of those addresses by
the applicant. These were fairly straightforward violations of our
policy, and also were directly relevant to the intent of the policy to
provide some base-level assurance relative to using certificates.
Eddy Nigg
> Eddy Nigg wrote:
>> I believe that the policy (and/or other relevant policy guiding
>> statements) should be clear in respect what Mozilla requires from the
>> CAs.
>
>
> It's a nice ideal, but I wonder myself whether it can be achieved. This
> is one of the reasons why we have ended up with the race-to-the-bottom
> in secure browsing; necessitating (?) the EV thing, etc etc.
It's not an ideal, but very real, implementable and actually done not
only here, but also elsewhere. The trend is not a race to the bottom,
but higher the overall level of quality of PKI after we reached the
bottom - for the good of all parties involved.
I'm not in favor to invent unnecessary requirements, but a sound clear
reasonable policy with the basic security requirements covered. This was
the intention of the Mozilla CA policy in first place which is very
reasonable. Of course not everything was understood back then and it's
time to fix a few points.
> Not that I disagree with your central point that it *should be* clear,
> it is just that I wonder if it can be clear.
Of course it can and I don't see any reason whatsoever why not.
>
> I think if the subroots were managed by the lead CA, and the CPS said
> they were under the same set of policies, then there would be little
> point in requiring separate audits.
>
Exactly. As opposed to sub roots which aren't operated by the CA, not
physically at the same infrastructure and not under the same
responsibility. An audit must cover the full infrastructure even in case
the sub ordinate CA is elsewhere.
> The problem then being that between those two points there is an awful
> lot of space.
>
I don't think so and a policy requirement can be clear-cut. More or less
in one sentence.
Eddy Nigg
>
> Not to speak for Ian, but I interpreted his comments as follows: We can
> add more provisions to the policy to address particular situations, but
> what do we ultimately gain in terms of enhanced security for end users?
> It's like adding more and more provisions to laws or regulations in
> order to cover special cases, to close loopholes, and so on. Is the
> extra complexity (in terms of writing the laws and regulations,
> interpreting them, enforcing them, etc.) worth the trouble? And in our
> case we have to remember that me, Kathleen, and others don't have
> infinite time and resources at our disposal.
With more users and more CAs grows the responsibility. That's natural.
You might need to request more resources, I don't know.
However, my point is simply, that something central and principal as the
audit requirement isn't something we should compromise on. Basically the
policy has a few major requirements of
- domain validation,
- email validation,
- identity/organization validation for code signing,
- relevance to the typical user,
- accepted norms of CA management, controls, etc. (covered by WebTrust,
ETSI)
- audit requirement.
There is a loophole as you call it, it's been something of concern to me
what sub ordinate or cross signed CAs concerns and something admittedly
not foreseen. This issue stands out from all other "problematic
practices" IMO, because it may effectively circumvent all principal and
basic requirements from above.
What I suggest to change is, that the audit MUST cover the full PKI
infrastructure and that CAs external (physical and logical) must be
audited (with the parent CA or independently).
This wouldn't prevent CAs like GlobalSign to cross and sub sign external
CAs in order to facilitate better coverage. Please note that GlobalSign
apparently does exactly that (signing WebTrust audited CAs).
It is easy to implement and govern, easy to understand and easy to
detect. I don't anticipate any implications nor higher overhead than
currently. Kathleen does that excellent, btw...
If it's worth the trouble? You'll know only after you've got CAs trusted
in NSS which never should have been there in first place. Mozilla
doesn't have to facilitate a specific business model unique to some CAs,
but *ensure the basic adherence to proper functioning of PKI and
reliance in relation to its software*!
Eddy Nigg
>
> This is by way of saying that even if we required annual audit reports,
> it's not clear to me that CAs could produce them.
Microsoft made it a requirement and you might ask them how it goes. But
there are many CAs supported by MS, apparently they are capable to
request the audit statements on a yearly basis.
kgb
> On 11/14/2008 11:12 PM, Frank Hecker:
> >...in the short term I'm going to try to restart CA public
> In this particular case I think that the practice in question doesn't
> meet the requirements of the Mozilla CA policy. This includes in
> particular section 6 and 7 of the Mozilla CA Policy.
>
I believe that WISeKey's practices and polices do meet the
requirements of section 6 and 7 of Mozilla's CA policy, and a review
of the posted documentation and audit guidelines in the report should
confirm that.
WISeKey has made some changes to its practices, since the last public
discussion period. BlackBox Subordinate CAs are restricted to issue
certificates for domains that are owned by the company that is
responsible for them, quite unlike the typical root signing done by
other companies. BlackBox subordinate CAs are also audited onsite at
least once annually.
>
> > WISeKey has been through an initial comment period a while back, during
> > which we got nvolved in a lengthy discussion about WISeKey's Blackbox
> > product (a "CA in a box" product intended for enterprise deployment) and
> > whether and how auditing was done for WISeKey's subordinate CAs
> > associated with that product. WISeKey supplied more information about
> > their arrangements, which you can find in the bug.
>
> Frank, I greatly missed the thorough and systematic work of Kathleen in
> this bug and it's a pity she didn't perform another round of
> "information gathering" in case some new evidence was provided. Anyhow,
> I couldn't find anything new in the bug since the last time. I'm not
> sure what is supposed to have changed.
>
There have been changes to the policies and practices. The CIDClassed
document is a summary of WK practices and certificate classes.
> Since I can't find anything new, I assume that nothing has changed and
> therefore the condition for inclusion didn't change at all. If we
> consider that all recent inclusion requests were specifically tested for
> such practices - most notably CAs like Comodo, but also T-Systems who's
> inclusion has been delayed as a result of it - I can't see any
> particular reason for making an exception here. Not only do their
> products circumvent the audit requirement, they might be in direct
> conflict with the basic requirements of the Mozilla CA policy such as
> email and domain validation (IIRC - see comment 32 in bug 371362).
>
WISekey's products do not circumvent the audit requirement.
WISeKey's products conform with the basic requirements of the Mozilla
CA policy. WISeKey subordinate CAs in the BlackBox category can only
issue certificates containing domain names that have been validated as
being owned by the customer. These CAs are audited physically onsite,
there are technical controls preventing the issuance of certificates
containing any other domain name, and there are additional monitoring
controls.
> (Additionally, I couldn't confirm that this CA commands any significant
> market share with the information at my disposal. I'm the opinion that
> it would be a mistake to make an exception on the audit requirement for
> sub-CAs, which in the future could serve as an argument in favor for
> similar scenarios.
> It was also pointed out at the bug that this CA is in MS software,
> however I suspect their policies to be also in conflict of the MS root
> program. Just some side-note...)
WISeKey is part of the MS Windows RCA program, and have had extensive
discussions with Microsoft's team prior to joining the program. The
conformance of MS products with the IETF PKIX standard enable its
product to work efficiently and cost effectively. They have supported
WISeKey extensively in testing. WISeKey has signed the Microsoft
Windows Root Certificate Program - CA agreement.
>
> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd.
> Jabber: start...@startcom.org
> Blog: https://blog.startcom.org
regards,
Kevin Blackman
WISeKey SA
Eddy Nigg
Hi Kevin,
> WISeKey has made some changes to its practices, since the last public
> discussion period.
I'm glad to hear that! Can you point to what specifically has been
changed since then?
> BlackBox Subordinate CAs are restricted to issue
> certificates for domains that are owned by the company that is
> responsible for them, quite unlike the typical root signing done by
> other companies.
How are email certificates validated beyond that? Are they validated -
or is it a catch-all verification for all email certificates under the
respective domain name(s)?
> BlackBox subordinate CAs are also audited onsite at
> least once annually.
By whom? I remember from the last discussion that you weren't performing
on-site visits or only randomly, download of the software and CA keys
were provided via Internet download.
>
> There have been changes to the policies and practices. The CIDClassed
> document is a summary of WK practices and certificate classes.
OK, I will examine this document further then...
> WISekey's products do not circumvent the audit requirement.
> WISeKey's products conform with the basic requirements of the Mozilla
> CA policy. WISeKey subordinate CAs in the BlackBox category can only
> issue certificates containing domain names that have been validated as
> being owned by the customer. These CAs are audited physically onsite,
> there are technical controls preventing the issuance of certificates
> containing any other domain name, and there are additional monitoring
> controls.
Did your auditor perform random verifications of those visits, verify
some of these installations and the technical controls? You don't have
to answer this question, but it would be nevertheless interesting to
understand the extend of the audit performed.
What are your requirements and controls concerning physical and logical
access to the system(s)? (pointer to the CPS section is fine)
> WISeKey is part of the MS Windows RCA program, and have had extensive
> discussions with Microsoft's team prior to joining the program. The
> conformance of MS products with the IETF PKIX standard enable its
> product to work efficiently and cost effectively. They have supported
> WISeKey extensively in testing. WISeKey has signed the Microsoft
> Windows Root Certificate Program - CA agreement.
I think some enterprise scenarios are explicitly disallowed by Microsoft
which your product however could implement nevertheless, specially since
it's based on MSCA (as I understood). But this is beyond the scope of
what we do here, it was only a side note from me.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org
Ian G
> Ian G wrote:
>> One way to short-circuit this is to simply state that the root CA is
>> responsible for any/all subroots. So this would imply that the root
>> CA's policies and audit drill down through the subroots, and they
>> apply. Then, it would be up to the root auditor to decide whether a
>> subroot needed a separate audit or not.
>
> I think this approach would be good if we were starting from a
> greenfield environment. However I think in the current CA environment
> we're faced with a situation where in practice roots don't necessarily
> always accept direct responsibility for the actions of their
> subordinates (or for those of other root CAs that they've issued cross
> certificates for).
Hmmm... So, who takes responsibility for these CAs, or is this part of
the unanswered question?
Is there some agreement with the subsidiaries? Is the agreement
submitted as part of the Mozo review?
> From a practical standpoint the issuance of
> subordinate CA certificates or cross certificates has been seen as more
> of a technical issue: "A needs to treat B as a subordinate CA because B
> wants/needs to take advantage of A's inclusion in IE/Firefox/etc."
Right.
> This predominant attitude toward subordinates is a defect to be sure.
> The question is, to what extent (and in what circumstances) is it a
> security-relevant defect.
and, to whom? Obviously, the security of the subordinate CA is well
improved by this "defect" ;)
>> One problem with this is that it might also not be realistic.
>> Consider two CAs, one of which does "style A" and another does "style
>> B". In the doco and audit for the root CA, there will be a need
>> somehow to capture that distinction. The natural direction here will
>> end up that the root's policies will tend to say "see the subroot's
>> policies for more detail."
>
> Right, and that's a quite common situation: There will be a root CA that
> really acts just as a convenient "gathering point" for a bunch of
> different subordinates to get CA certs from, with the root's policies
> just having to do with subordinates, and every relevant to end-entity
> certs pushed down to the subordinate CAs. This is the model for a lot of
> government-sponsored PKIs where the PKI is not just government-specific
> but serves as an unmbrella for commercial and nonprofit groups to set up
> their own CAs under the government-operated and-authorized root.
Yes, and at a technical level I don't see an issue. At a
legal/liabilities level I see an open question: who is taking on the
liability, how is it shared, etc.
>> Either way we look at it, I feel that the more controls are put in
>> place, the more we end up putting in "paper fixes" and the more we
>> complicate things for a gain that we don't fully understand.
>
> Yes, and I'm going to use your comment as a jumping off point for a
> broader comment:
>
> We have traditionally treated CA inclusion as a security issue, with the
> purpose of evaluating CAs for inclusion to ensure that we didn't suffer
> major security vulnerabilities due to CA actions or omissions. However I
> could also make the case that the CA is less like the other
> security-related stuff we do (e.g., security testing, fixing reported
> vulnerabilities in the code, etc.) and more like what we've been doing
> in the licensing/copyright area.
OK.
> I think there's general agreement that browser exploits are a "clear and
> present danger", and it's worth our spending whatever time it takes to
> make sure they're fixed as expeditiously as possible. Over on the
> legal/licensing/copyright front, there are certainly bad things that
> could happen to us, like getting code in the tree that was not
> authorized by the creator, getting code in that was under an
> incompatible license, and so on. Based on our experience and judgment
> over time, we've deemed it adequate to set up some safeguards in place:
> having formal license policies and a formal committers agreement, having
> people vouch for others seeking commit access, and so on. However we
> haven't gone overboard with double- and triple-checking everyone who
> contributes code, vetting every single code contribution for legal
> issues, and so on. This would greatly raise the bar to getting code
> contributions from people, and we just don't see that as being justified
> based on experience and the perceived risks.
>
> So, which is the better model for including CAs? I'm beginning to think
> that the licensing/copyright situation is perhaps a better model for us:
> set up a documented framework, perform some reasonable due diligence,
> and be transparent in terms of what we're doing (as happens when
> approving new committers), but when making judgment calls err on the
> side of inclusion rather than exclusion.
This is an interesting approach and I certainly don't disagree with the
basic thrust. If anything I would say that there isn't one "superior
model" but there are aspects from both models (bugs v. licence) that can
help, or there are aspects from both models that we are sorely missing.
I also think it helps a lot to define the target of the security model.
Who are we trying to protect? I say the end-user (and have said so in
recent documents) rather than say Mozo or the CA or whoever else we
might encounter in the path.
If one were to then ask about how certs and CAs can present risks,
liabilities and obligations, as well as benefits and protection to the
end-user, it is not entirely clear how this is done. Not only is the UI
somewhat and arbitrarily opaque as to who the CA is, there is no clear
legal relationship with the CA.
So, CAs might make a good case for end-user benefit; but this all comes
to nought because the end-user has no relationship with the CA. So if
anything goes wrong there is no apparent way to perfect the benefit /
loss. And, according to some schools of thought, if you can't perfect
it, it doesn't exist.
If I was captaining the good ship CA Policy, I would look for this sort
of added clause:
x. The CA makes an offer to typical end-users of our product
(perhaps similar to an open source licence).
i. it should be clear, understandable and accessible;
ii. it should offer permission to USE the certs;
iii. it should cover everyone who has no other agreement;
iv. it should state that there is no other permission, in
absence of an agreement that is specifically entered into by the user.
x. The offer to end-users should disclaim all liability.
x. CAs may have other arrangements for customers and others who have
higher needs.
The nice thing about this is that it is pretty much in place already.
Major CAs have some form of RPA on their site, and they match the terms
above, more or less, already.
Now, if this were to be standardised as Mozo-level policy, it clears the
way for a number of other fixes.
>> This does somewhat put the finger on the relationship between the CA
>> and Mozilla. Currently, this is an informal agreement based on the
>> policy, bug filing, and other communications. What might be better is
>> a single document (or mod to the policy) that specified what the
>> complete agreement was (listing the others). In this we could
>> typically include the disclaimers of liability, and how we would deal
>> with the disputes, e.g., over the activities of the CA's wilder
>> subroots, and at an extreme level, any root revocation at Mozilla's
>> discretion.
>
> I'd like at some point to consider formalizing our relationships with
> CAs, e.g., through some sort of formal legal agreement associated with
> Mozilla including a root. That would take a bit of work and involve a
> number of people to get it done right,
I'm not actually sure a "formal legal agreement" is needed. Although we
understand the lawyers like to have these things reviewed and signed in
blood to the Nth degree ... we should also note that the whole open
source regime is gaining a lot of traction as a respectable legal
tradition, and there is no formal contract involved there.
From which I would say that a good model is to simply state the policy
as a "posted notice" with a clause that states "by submitting your root
to the bugzilla for consideration, you agree to the terms and conditions
of this policy." Adding that sort of clause to the policy should be a
lot easier than trying to craft some sort of "mutual agreement."
> and unfortunately I have more
> pressing priorities right now in the CA area. (Basically: getting
> requests processed in a timely manner and doing the work necessary to
> have someone else take over these duties sometime in 2009.)
> However I think these sorts of discussions are useful, as they will
> provide good context if/when we actually get down to drafting a formal
> CA agreement.
Yes, I understand that it will require some serious work to do this.
When we saw this at the CA I know, it took a good year to write the
framework, another year to get it approved, and then the rollout is
still going on.
If we can toss the principles around in advance, it might be easier.
iang
Eddy Nigg
The Wisekey case could be where we might draw the line. Provided that
- there is a *good compelling reason* for using sub-ordinate
certificates in first place, limited to the domains under the control of
the owner (via name-constraints) and with reasonable controls in place
(like annual site visits, proper CA key generation, distribution and
storage);
- name constraints in certificates are working as expected with NSS and
Mozilla software *;
- reasonable verifications are performed of the sub-ordinate certificate
owner;
I tend to suggest to exclude the audit requirement for this specific
case. It should however represent the line between the other cases.
* One thing I'm not sure about is concerning S/MIME certificates and
their verification requirements. And do name-constraints work with S/MIME?
Kevin (from Wisekey):
Why is a sub-ordinate CA certificate needed for this product, if it's
limited to a certain set of domain names? Can't the same be achieved by
simply issuing from a general sub CA under the control of the parent CA?
What are the differences for the customer (I mean, it doesn't really
matter if a site certificate or email certificate is issued from a sub
CA under the control of the parent CA or from a different sub CA under
the control of the owner. In the end of the day there may be only a
certain set of domain names for the same set of web sites)?
Nelson:
Do name-constraints work as expected with NSS and Firefox/Thunderbird
etc.? I didn't had a chance to test this ever...Are there some test
cases with correctly and wrongfully issued certificate which would
demonstrate the correct functioning? What about S/MIME certificates?
Michael Ströder
>
> The Wisekey case could be where we might draw the line. Provided that
>
> - there is a *good compelling reason* for using sub-ordinate
> certificates in first place, limited to the domains under the control of
> the owner (via name-constraints) and with reasonable controls in place
> (like annual site visits, proper CA key generation, distribution and
> storage);
I wonder how you want to limit the domains via name constraint extension
in current business practice. I have a customer who has ~20000
registered domains. They bought another big company with ~30000
registered domains. They usually register all variants of product names
under all top-level domains so the number is growing quite fast. For
each domain there MAY be SSL certs issued by an own sub CA.
In this environment the naming constraints are just defined by contract
with the root CA owner not by cert extension.
Ciao, Michael.
Eddy Nigg
>
> I wonder how you want to limit the domains via name constraint extension
> in current business practice. I have a customer who has ~20000
> registered domains. They bought another big company with ~30000
> registered domains. They usually register all variants of product names
> under all top-level domains so the number is growing quite fast. For
> each domain there MAY be SSL certs issued by an own sub CA.
>
> In this environment the naming constraints are just defined by contract
> with the root CA owner not by cert extension.
>
Well, this is what the CPS of Wisekey apparently says, not my invention.
It wouldn't be our problem how this would be implemented in the case
above. I stated what would be acceptable in my opinion - with naming
constraints being clearly conditional.
Basically your customer wouldn't fall under this category and would have
to be audited as any other CA, certainly with 20K and more domains under
their control. Make sense in my opinion (because of the higher risk and
wider audience of the relying parties).
Eddy Nigg
>
> Yes, and at a technical level I don't see an issue. At a
> legal/liabilities level I see an open question: who is taking on the
> liability, how is it shared, etc.
>
...and I might add, how are the basic requirements of the Mozilla CA
Policy governed...
> I also think it helps a lot to define the target of the security model.
> Who are we trying to protect? I say the end-user (and have said so in
> recent documents) rather than say Mozo or the CA or whoever else we
> might encounter in the path.
100%! Certification is about the relying party, nothing else.
>
> I'm not actually sure a "formal legal agreement" is needed.
I suggested and supported the call for a formal agreement between the
CAs and Mozilla a while ago. It would strengthen the relationship and
commitment to the Mozilla CA Policy. Without it, governing CAs is rather
difficult.
>
> From which I would say that a good model is to simply state the policy
> as a "posted notice" with a clause that states "by submitting your root
> to the bugzilla for consideration, you agree to the terms and conditions
> of this policy." Adding that sort of clause to the policy should be a
> lot easier than trying to craft some sort of "mutual agreement."
>
This could be another way doing the same thing. Obviously signing a real
paper is a stronger act than simply agreeing to a policy statement.
kb
> On 11/19/2008 01:59 AM, kgb:
>
> Hi Kevin,
>
> > WISeKey has made some changes to its practices, since the last public
> > discussion period.
>
> I'm glad to hear that! Can you point to what specifically has been
> changed since then?
>
Probably the most important change in stated practice, is that it is
reflected that every CA is audited at least once annually. This is the
case for all active CAs.
> > BlackBox Subordinate CAs are restricted to issue
> > certificates for domains that are owned by the company that is
> > responsible for them, quite unlike the typical root signing done by
> > other companies.
>
> How are email certificates validated beyond that? Are they validated -
> or is it a catch-all verification for all email certificates under the
> respective domain name(s)?
>
Email certificates are also restricted to the organisation's domains.
We include a Constraint in the Issuing CA itself, preventing the same
CA software to issue certificates that don’t comply with this Domain
Restriction (web, email, User Principal Name, etc.)
The company database (such as existing HR, or IDM) of organisation,
with details of the organisation's users, including their email
addresses, is the principal source of data for certificates.
Bounce back email verification procedure proving access to the email
account is also accepted, but this is inefficient in the enterprise
context, as the enterprises IT systems are aware of the email address
book.
In addition other identity data in the certificate must come from a
verified source, e.g. HR database of identity data that is well-
maintained and was created based on face to face or direct
verification of the person.
> > BlackBox subordinate CAs are also audited onsite at
> > least once annually.
>
> By whom? I remember from the last discussion that you weren't performing
> on-site visits or only randomly, download of the software and CA keys
> were provided via Internet download.
>
Currently it is WISeKey that audits all our CAs, we review the CAs at
least once annually, or more regularly as we are more often present on
some client sites. In addition to the controls we place on issuance,
we also place monitoring controls and obtain regular reports.
All CA keys are generated within accredited HSMs. No CA private Keys
are provided via Internet download - this has never been the case. CA
keys have, and are always generated within a protected HSM.
>
>
> > There have been changes to the policies and practices. The CIDClassed
> > document is a summary of WK practices and certificate classes.
>
> OK, I will examine this document further then...
>
> > WISekey's products do not circumvent the audit requirement.
> > WISeKey's products conform with the basic requirements of the Mozilla
> > CA policy. WISeKey subordinate CAs in the BlackBox category can only
> > issue certificates containing domain names that have been validated as
> > being owned by the customer. These CAs are audited physically onsite,
> > there are technical controls preventing the issuance of certificates
> > containing any other domain name, and there are additional monitoring
> > controls.
>
> Did your auditor perform random verifications of those visits, verify
> some of these installations and the technical controls? You don't have
> to answer this question, but it would be nevertheless interesting to
> understand the extend of the audit performed.
>
Our auditor has reviewed all of our policies and practices, controls,
and has accepted them as being sufficient. The auditor reviews audit
information from all CAs, and can request to visit any or all CA sites
at any time. Which ones, how many, they have done for the last year,
audit etc., is and remains confidential.
> What are your requirements and controls concerning physical and logical
> access to the system(s)? (pointer to the CPS section is fine)
>
For systems hosted in our DC, section 4 of the Issuing CA CPSs in the
repository applies (www.wisekey.com/repository).
For TrustCenter (BB) CAs - those CAs on customer sites, the relevant
excerpt is as follows:-
4. PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS
4.1. Physical Controls for the Issuing CA
The hardware and software for the Issuing CA is maintained on-line in
a secured facility with perimeter security and enforced internal
access controls.
4.2. Procedural Controls
No member of staff is allowed to gain physical access or operate any
component of the Issuing CA without the presence of other designated
members of staff who have the skills required to confirm that no
unauthorized or inappropriate actions are conducted.
Procedures are defined and documented for all operations upon the
Issuing CA. Operating procedures are regularly reviewed in the light
of new operational requirements.
4.3. Personnel Controls
All ISSUING CA OPERATOR staff involved in the operation of the Issuing
CA is subjected to background checks and vetting according to ISSUING
CA OPERATOR internal security policies.
Personnel involved in the control and operation of the Issuing CA
shall be sufficiently trained to comply with the functions allocated
to their role and shall be provided with ongoing training to ensure
the appropriate levels of awareness of the security policies and
procedures.
> > WISeKey is part of the MS Windows RCA program, and have had extensive
> > discussions with Microsoft's team prior to joining the program. The
> > conformance of MS products with the IETF PKIX standard enable its
> > product to work efficiently and cost effectively. They have supported
> > WISeKey extensively in testing. WISeKey has signed the Microsoft
> > Windows Root Certificate Program - CA agreement.
>
> I think some enterprise scenarios are explicitly disallowed by Microsoft
> which your product however could implement nevertheless, specially since
> it's based on MSCA (as I understood). But this is beyond the scope of
> what we do here, it was only a side note from me.
>
> --
Regards,
Kevin
WISeKey SA
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd.
> Jabber: start...@startcom.org
> Blog: https://blog.startcom.org
kb
On Nov 19, 3:14 am, Eddy Nigg <eddy_n...@startcom.org> wrote:
> Frank:
>
> TheWisekeycase could be where we might draw the line. Provided that
>
> - there is a *good compelling reason* for using sub-ordinate
> certificates in first place, limited to the domains under the control of
> the owner (via name-constraints) and with reasonable controls in place
> (like annual site visits, proper CA key generation, distribution and
> storage);
> - name constraints in certificates are working as expected with NSS andMozillasoftware *;
> - reasonable verifications are performed of the sub-ordinate certificate
> owner;
>
> I tend to suggest to exclude the audit requirement for this specific
> case. It should however represent the line between the other cases.
>
> * One thing I'm not sure about is concerning S/MIME certificates and
> their verification requirements. And do name-constraints work with S/MIME?
>
Name-constraints work on the level of the CA, and this is what we rely
on together with the audit and monitoring tools. The CA looks at its
certificate, and won't issue a request SMIME or otherwise that
violates the name constraints.
> Kevin (fromWisekey):
>
> Why is a sub-ordinate CA certificate needed for this product, if it's
> limited to a certain set of domain names? Can't the same be achieved by
> simply issuing from a general sub CA under the control of the parent CA?
> What are the differences for the customer (I mean, it doesn't really
> matter if a site certificate or email certificate is issued from a sub
> CA under the control of the parent CA or from a different sub CA under
> the control of the owner. In the end of the day there may be only a
> certain set of domain names for the same set of web sites)?
>
We offer both types of delivery. We have many managed PKI customers.
However some agencies don't wish their ID information to leave their
premises, or to cross national borders; or desire to have closer
integration with the ID lifecycle management software and internal
directory, which is far easier and more efficient with the BlackBox
system, and its also far more cost effective especially in large user
populations. There are also other reasons, but those are probably the
most important.
> Nelson:
>
> Do name-constraints work as expected with NSS and Firefox/Thunderbird
> etc.? I didn't had a chance to test this ever...Are there some test
> cases with correctly and wrongfully issued certificate which would
> demonstrate the correct functioning? What about S/MIME certificates?
>
> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd.
> Jabber: start...@startcom.org
> Blog: https://blog.startcom.org
Frank Hecker
> The Wisekey case could be where we might draw the line.
I'm not sure exactly which message (of mine or someone else's) you're
responding to.
In any case I don't think there's a "bright line" between the various
scenarios involving independently-operated subordinate CAs. However in
general I would look at the extent to which the subordinates are
operating within a restricted context. E.g., they're associated with a
single enterprise, they're technically and contractually constrained to
operate within a relatively small set of domains, etc. At the other end
of the spectrum the subordinates are essentially general-purpose public
CAs, issuing certs to multiple customers, for arbitrary domains, etc.
Based on the information available to us, WISeKey's subordinate CAs seem
to be at the restricted context end of the spectrum.
> Provided that
>
> - there is a *good compelling reason* for using sub-ordinate
> certificates in first place, limited to the domains under the control of
> the owner (via name-constraints) and with reasonable controls in place
> (like annual site visits, proper CA key generation, distribution and
> storage);
Based on what Kevin Blackman wrote, one major reason for the approach
taken by WISeKey is the desire of customers to keep subscriber
information within enterprise boundaries and/or national borders. Given
the complexities of, e.g., privacy regulations in the US vs. the EU vs.
other jurisdictions, this seems to me a good reason for an enterprise to
operate its own subordinate CA as opposed to, for example, just acting
as a Registration Authority for a subordinate CA operated elsewhere.
> - name constraints in certificates are working as expected with NSS and
> Mozilla software *;
Whether certificate-based name constraints are properly working or not,
I think this is more our problem than the CA's problem, provided that
the CA's cert don't cause actual technical errors in NSS/Mozilla. If a
CA is implementing technical measures we consider sound, then I think
they have done what we expect and require.
(And I should add that if there problems in NSS that need additional
work to fix them, the Mozilla Foundation does have the ability to fund
such work.)
Eddy Nigg
> Eddy Nigg wrote:
>> The Wisekey case could be where we might draw the line.
>
> I'm not sure exactly which message (of mine or someone else's) you're
> responding to.
I refereed to the general discussion about sub roots.
>
> In any case I don't think there's a "bright line" between the various
> scenarios involving independently-operated subordinate CAs.
On the other hand I think we should be clear in relation to the
requirements placed upon the CAs. We should define them as clearly as
possible in order to allow CAs prepare accordingly.
>
> Based on the information available to us, WISeKey's subordinate CAs seem
> to be at the restricted context end of the spectrum.
Yes. Additionally one of the major concerns have apparently been
corrected! As I mentioned earlier, I think that name-constraints and
mandatory self-auditing by the CA seem to me sufficient.
>
> Based on what Kevin Blackman wrote, one major reason for the approach
> taken by WISeKey is the desire of customers to keep subscriber
> information within enterprise boundaries and/or national borders. Given
> the complexities of, e.g., privacy regulations in the US vs. the EU vs.
> other jurisdictions, this seems to me a good reason for an enterprise to
> operate its own subordinate CA as opposed to, for example, just acting
> as a Registration Authority for a subordinate CA operated elsewhere.
I think that argument is somewhat far-fetched as the customer could work
with a local authority instead. As I understood the subscriber
information have to be disclosed to the CA anyway (monitoring, evidence
and audit trail etc), hence I'm not really convinced. Integration into
enterprise infrastructure however seems to me more logical...
> Whether certificate-based name constraints are properly working or not,
> I think this is more our problem than the CA's problem, provided that
> the CA's cert don't cause actual technical errors in NSS/Mozilla. If a
> CA is implementing technical measures we consider sound, then I think
> they have done what we expect and require.
In this case, name-constraints are clearly part of the policy regulating
those sub CAs and in my opinion the most convincing argument in favor
for self-auditing of those installation as opposed to the general audit
requirement. If name-constrains don't work as expected, an inclusion
will have to be conditional on implementation. There shouldn't be a
situation where the issuance of the sub-CA is based clearly on
name-constraints regulation and NSS can't support it. Right now it's a
hypothetical concern because I don't know what the situation is.
Hopefully Nelson or somebody else will provide this information within
reasonable time.
>
> (And I should add that if there problems in NSS that need additional
> work to fix them, the Mozilla Foundation does have the ability to fund
> such work.)
>
Great!
Eddy Nigg
>
> Probably the most important change in stated practice, is that it is
> reflected that every CA is audited at least once annually. This is the
> case for all active CAs.
>
Kevin, thanks for clarifying this. It indeed was one of the concerns
raised last time.
> The company database (such as existing HR, or IDM) of organisation,
> with details of the organisation's users, including their email
> addresses, is the principal source of data for certificates.
OK.
>
> Bounce back email verification procedure proving access to the email
> account is also accepted, but this is inefficient in the enterprise
> context...
That's why I asked... ;-)
>
> In addition other identity data in the certificate must come from a
> verified source, e.g. HR database of identity data that is well-
> maintained and was created based on face to face or direct
> verification of the person.
Excellent!
>
> Currently it is WISeKey that audits all our CAs, we review the CAs at
> least once annually, or more regularly as we are more often present on
> some client sites. In addition to the controls we place on issuance,
> we also place monitoring controls and obtain regular reports.
Last question: Are there any sub CAs besides the blackbox product (with
name-constraints) which are external to your physical infrastructure? I
think there is not, but can you confirm that?
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org
kgb
There is not.
There are no sub CAs within our public hierarchy, that are not of the
BlackBox type, which are external to our physical infrastructure.
There are several PRIVATE CAs (linked to a private customer Root CA)
that use our software and practices and processes, including
Government Root and Subordinate CAs.
Regards,
Kevin
> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd.
> Jabber: start...@startcom.org
> Blog: https://blog.startcom.org
Eddy Nigg
>
> There is not.
> There are no sub CAs within our public hierarchy, that are not of the
> BlackBox type, which are external to our physical infrastructure.
> There are several PRIVATE CAs (linked to a private customer Root CA)
> that use our software and practices and processes, including
> Government Root and Subordinate CAs.
>
Which isn't of our concern obviously! Thanks Keven for all your answers.
Frank: I think the critical issues what Mozilla concerns have been
addressed! We need to make sure that naming constraints work as expected.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org
Eddy Nigg
> On 11/18/2008 03:54 AM, Eddy Nigg:
>>
>> Frank, I greatly missed the thorough and systematic work of Kathleen in
>> this bug and it's a pity she didn't perform another round of
>> "information gathering" in case some new evidence was provided. Anyhow,
>> I couldn't find anything new in the bug since the last time. I'm not
>> sure what is supposed to have changed.
>>
>
> I forgot to mention, that in case inclusion is relevant we should gather
> additional information about the auditor and independent confirmation of
> the audit report.
>
Frank, can you also check the above mentioned?
kgb
On Nov 20, 9:21 pm, Frank Hecker <hec...@mozillafoundation.org> wrote:
> Eddy Nigg wrote:
> > The Wisekey case could be where we might draw the line.
>
> I'm not sure exactly which message (of mine or someone else's) you're
> responding to.
>
> In any case I don't think there's a "bright line" between the various
> scenarios involving independently-operated subordinate CAs. However in
> general I would look at the extent to which the subordinates are
> operating within a restricted context. E.g., they're associated with a
> single enterprise, they're technically and contractually constrained to
> operate within a relatively small set of domains, etc. At the other end
> of the spectrum the subordinates are essentially general-purpose public
> CAs, issuing certs to multiple customers, for arbitrary domains, etc.
>
> Based on the information available to us, WISeKey's subordinate CAs seem
> to be at the restricted context end of the spectrum.
>
Correct. We are at the extremely restricted context end of the
spectrum.
> > Provided that
>
> > - there is a *good compelling reason* for using sub-ordinate
> > certificates in first place, limited to the domains under the control of
> > the owner (via name-constraints) and with reasonable controls in place
> > (like annual site visits, proper CA key generation, distribution and
> > storage);
>
We implement all of the above mentioned controls.
> Based on what Kevin Blackman wrote, one major reason for the approach
> taken by WISeKey is the desire of customers to keep subscriber
> information within enterprise boundaries and/or national borders. Given
> the complexities of, e.g., privacy regulations in the US vs. the EU vs.
> other jurisdictions, this seems to me a good reason for an enterprise to
> operate its own subordinate CA as opposed to, for example, just acting
> as a Registration Authority for a subordinate CA operated elsewhere.
>
This is exactly right. In fact several clients sensitive to this
issue
(Government Central Bank, Judicial Court, etc.) chose specifically
the
BlackBox system for this purpose. In some instances they also use
managed PKI for issuing certificates to external collaborators. MPKI
uses a CA in our data center and WISeKey performs the the email
verification as it is not within the BB's client's domain.
> > - name constraints in certificates are working as expected with NSS and
> > Mozilla software *;
>
> Whether certificate-based name constraints are properly working or not,
> I think this is more our problem than the CA's problem, provided that
> the CA's cert don't cause actual technical errors in NSS/Mozilla. If a
> CA is implementing technical measures we consider sound, then I think
> they have done what we expect and require.
>
Frank, I agree with you.
Our CA controls, audits, etc. are
designed to ensure that all identities are validated appropriately
prior to
certificate issuance. BlackBox CAs are an extremely
restricted CA context where certificates issued
at the CA are restricted to domains owned by the organisation.
It is not necessary for domain constraints to work in NSS software
for
our Root to be accepted, as the control's primary point of operation
is PRIOR to certificate issuance.
Even if domain constraints are not interpreted properly by NSS today,
they
will be in the future, and the certificates issued by our MPKI system
using
CAs in our DCs will be perfectly unaffected.
I am sure that the name constraints implementation process will be
much further along, and our Root still will not have propogated very
far
through the typical update mechanisms.
On our behalf, I thus submit that it would be
a fairly extreme and an unfair penalty to wait an additional year
(the first discussion period was in January of this year) to be
embedded,
whereas the primary controls and practices we use have not changed
significantly from that point in time.
> (And I should add that if there problems in NSS that need additional
> work to fix them, the Mozilla Foundation does have the ability to fund
> such work.)
>
Mozilla will have our complete support, especially with QA.
Regards,
Kevin
Eddy Nigg
Kevin, are you recording all domain names and/or email addresses of the
subject line also in the subject alt name extension? If yes, the problem
is solved, if not, could you modify your issuance of end user
certificates to include all of the validated domain names and/or email
addresses in the SAN extension?
BTW, this is the information I could gather about the state of NSS, it
seems to me trivial to achieve adherence and correct functioning of the
software.
kgb
On Nov 21, 8:16 pm, Eddy Nigg <eddy_n...@startcom.org> wrote:
> On 11/21/2008 05:16 PM, kgb:
>
>
>
>
>
> > Frank, I agree with you.
> > Our CA controls, audits, etc. are
> > designed to ensure that all identities are validated appropriately
> > prior to
> > certificate issuance. BlackBox CAs are an extremely
> > restricted CA context where certificates issued
> > at the CA are restricted to domains owned by the organisation.
> > It is not necessary for domain constraints to work in NSS software
> > for
> > ourRootto be accepted, as the control's primary point of operation
> > is PRIOR to certificate issuance.
> > Even if domain constraints are not interpreted properly by NSS today,
> > they
> > will be in the future, and the certificates issued by our MPKI system
> > using
> > CAs in our DCs will be perfectly unaffected.
> > I am sure that the name constraints implementation process will be
> > much further along, and ourRootstill will not have propogated very
> > far
> > through the typical update mechanisms.
> > On our behalf, I thus submit that it would be
> > a fairly extreme and an unfair penalty to wait an additional year
> > (the first discussion period was in January of this year) to be
> > embedded,
> > whereas the primary controls and practices we use have not changed
> > significantly from that point in time.
>
> Kevin, are you recording all domain names and/or email addresses of the
> subject line also in the subject alt name extension? If yes, the problem
> is solved, if not, could you modify your issuance of end user
> certificates to include all of the validated domain names and/or email
> addresses in the SAN extension?
>
> BTW, this is the information I could gather about the state of NSS, it
> seems to me trivial to achieve adherence and correct functioning of the
> software.
>
For e.g. S/MIME certs, If you mean if subject alt name email
contains the email address, not just SubjectDN-E, then yes this is
the case with the majority of certificates issued by the
BlackBox CAs, but not all.
I took a quick look at some customer SMIME certificates and
sometimes E is only included in the Subject DN.
Some customers don't include the SAN in their certificate
templates, it seems particularly those that use non-western
character sets.
I am interpreting that you mean
"modify the issuance of end user certs to
always include the SAN extension, as well as only validated
domain names and/or email addresses." ?
Only validated and approved domain names can be included
in a cert, whether in the Subject DN or the SAN.
It is the default template, and best practice that the SAN
(e.g. RFC822, dnsName) to be filled in the certificates.
Its the case for some but not all customers.
I really hope its not necessary once we can guarantee that
only validated domains are used in the certificates.
Regards,
Kevin
> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd.
> Jabber: start...@startcom.org
> Blog: https://blog.startcom.org- Hide quoted text -
>
> - Show quoted text -
Eddy Nigg
>
> Only validated and approved domain names can be included
> in a cert, whether in the Subject DN or the SAN.
> It is the default template, and best practice that the SAN
> (e.g. RFC822, dnsName) to be filled in the certificates.
> Its the case for some but not all customers.
>
> I really hope its not necessary once we can guarantee that
> only validated domains are used in the certificates.
>
The issue I care mostly about is, what happens when one if these systems
get compromised without you (the CA) ever detecting. Since those system
aren't under your control, this is entirely possible and the risk is
certainly higher than at your infrastructure. The threats may come from
unknown source or from the customer himself (or their employees).
The from you issued CA certificate with a path length of 0 and naming
constraints limitation is what convinces me as a reasonable protection
regarding above case. However it would have to be enforced by SAN
extension. How come your customers can decide if to include the relevant
alternative name or not? Isn't this something you should control?
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org
kgb
We have allowed the inclusion or not of the SAN extension in a
certificate,
because the constraints are always applied, whether the domain name
is in the SAN or in the Subject DN. For us allowing this flexibility
has thus
not caused any issues, till now.
Mandatory inclusion of the SAN extension in a certificate is a policy
we
can apply and monitor in the future.
Regards,
Kevin
> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd.
> Jabber: start...@startcom.org
> Blog: https://blog.startcom.org
Eddy Nigg
> Mandatory inclusion of the SAN extension in a certificate is a policy
> we can apply and monitor in the future.
>
To my understanding NSS ignores the subject line according to the RFC.
DNS name constraints constrain subject alt name extensions, not CN=
attributes in subject names. The same applies for email addresses.
(Obviously a compromised system in some form or the other might be able
to circumvent an SAN policy as well, but makes it perhaps somewhat
harder still. In the meantime I think the above suggested would be
sufficient, Frank might look into if NSS should implement non-standard
behavior and also check for fields in the subject line.)
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org
Nelson B Bolyard
> On 11/22/2008 12:32 PM, kgb:
>> Mandatory inclusion of the SAN extension in a certificate is a policy
>> we can apply and monitor in the future.
>
> To my understanding NSS ignores the subject line according to the RFC.
I think you mean subject NAME, not subject line.
> DNS name constraints constrain subject alt name extensions, not CN=
> attributes in subject names.
That's right. NSS applies name constraints to DNS names found in subject
alternative names extensions but does not apply them to DNS names found
within the Common Name attributes in cert subject names, per the RFC.
There are several reasons for that. One is that the RFC only defines
DNS name constraints as applying to DNS names in subject Alt Names.
But the greater reason is that Common Names may legitimately carry
values that are not DNS names. Indeed, they were never intended to
carry DNS names at all, but rather were intended to carry the names of
persons. You wouldn't want to reject a cert on the grounds that it
failed the DNS name constraint if the CN contained "Eddy Nigg" and the
DNS constraint said "startcom.org".
> The same applies for email addresses.
The story for email addresses isn't quite as simple as for DNS names.
There are numerous different subject name attributes that can carry
email addresses. There are two of those types of attributes to which
NSS does apply email name constraints. They are the attributes commonly
displayed with E= and MAIL=. But other attributes are not constrained
by email address constraints.
In practice this means that email addresses in subject names are more
likely to be constrained than are DNS names in subject names. This is
not an issue for certs that are issued in conformance with the RFC,
putting the DNS names and email addresses into the Subject Names.
But certs that put those names SOLELY in the subject name and not in
the subject Alt Name may not be adequately constrained. Sadly, there
are Many CAs that still put those names ONLY in the subject name, and
not in the subject alt name where they belong.
> Frank might look into if NSS should implement non-standard
> behavior and also check for fields in the subject line.)
There's no foolproof test for determining if a string is a DNS name or
some other kind of name. Various heuristics can be devised, but they
all have problems. Consider an algorithm that will find the right answer
for all of these strings:
"Eddy Nigg"
"www.startcom.org"
"Eddy"
"www"
"e.nigg"
Eddy Nigg
>
> There's no foolproof test for determining if a string is a DNS name or
> some other kind of name. Various heuristics can be devised, but they
> all have problems.
This worries me somewhat and I question the usefulness of the
name-constraints then...
Consider the following scenario at a customer of a blackbox product:
- Employee gains physical access to the machine, shuts down the machine
by force (removing machine from electricity source).
- He removes the hardware token from the machine and connects it to a
different system.
- He prints and signs a few certificates for www.paypal.com and
www.microsoft.com
- Returns the token back to the blackbox. Returns power source and
starts the machine.
Now in this case, no reporting from the blackbox is done - except that a
power failure happened perhaps. Nobody will ever know the existence of
those certificates. Now, name-constrains will fail for those
certificates under the various scenarios you explained, including the
cases where no SAN DNS is present in first place :S
Note that no third party (besides the wonderful services of the parent
CA) ever confirmed the physical controls of the customer above. It's
still a sub root in the hands of a customer with questionable restraints
then. Nothing will prevent the customer from misusing the system - even
if the intentions of Wisekey are sincere.
Nelson B Bolyard
> On 11/23/2008 12:32 AM, Nelson B Bolyard:
>> There's no foolproof test for determining if a string is a DNS name or
>> some other kind of name. Various heuristics can be devised, but they
>> all have problems.
>
> This worries me somewhat and I question the usefulness of the
> name-constraints then...
>
> Consider the following scenario at a customer of a blackbox product:
>
> - Employee gains physical access to the machine, shuts down the machine
> by force (removing machine from electricity source).
> - He removes the hardware token from the machine and connects it to a
> different system.
> - He prints and signs a few certificates for www.paypal.com and
> www.microsoft.com
... certificates that do not use standard Subject Alt Names extensions
but rather use the old non-standard Subject Common Name
> - Returns the token back to the blackbox. Returns power source and
> starts the machine.
>
> [...] Now, name-constrains will fail for those
> certificates under the various scenarios you explained, including the
> cases where no SAN DNS is present in first place :S
The only solution to this that is apparent to me is for the web to
evolve to the point where browsers no longer accept DNS names in
non-standard locations in the cert, such as in the Subject Common Name.
Eddy Nigg
> The only solution to this that is apparent to me is for the web to
> evolve to the point where browsers no longer accept DNS names in
> non-standard locations in the cert, such as in the Subject Common Name.
Which in itself might create quite some problems. I guess we don't need
any more problems right now when considering the current UI
implementation and complaints coming in... Just imagine CN fields
wouldn't be checked anymore by NSS:
"OMG, my openssl cert doesn't work anymore. Firefox is broken!" :-)
Nelson B Bolyard
> On 11/24/2008 07:33 PM, Nelson B Bolyard:
>> The only solution to this that is apparent to me is for the web to
>> evolve to the point where browsers no longer accept DNS names in
>> non-standard locations in the cert, such as in the Subject Common Name.
>
> Which in itself might create quite some problems. I guess we don't need
> any more problems right now when considering the current UI
> implementation and complaints coming in... Just imagine CN fields
> wouldn't be checked anymore by NSS:
>
> "OMG, my openssl cert doesn't work anymore. Firefox is broken!" :-)
There are 5 browser makers cooperating now as never before in the area
of SSL. If they all dropped support for CNs together...
Ian G
> There are 5 browser makers cooperating now as never before in the area
> of SSL. If they all dropped support for CNs together...
Yes, set a date after which Firefox won't support it, like 1/1/2010, or
Release 4. Just let all the others know, they'll follow suit.
I don't think there is a lot of point in discussing it broadly. If we
all know and agree it is an old deprecated feature, then there is some
merit in just drawing a line under it.
(If only we could also say the same about servers that don't do TLS/SNI
... old hobby horse!)
iang
Eddy Nigg
Well, ping Johnat and point him to this thread. From my point of view if
this becomes an agreed effort, the better...
Frank Hecker
> Frank: I think the critical issues what Mozilla concerns have been
> addressed!
I agree, and am going to proceed with approval of this request.
> We need to make sure that naming constraints work as expected.
I read through the thread on that, and will read it again to confirm my
understanding. However I've already commented on my views regarding name
constraints.
Frank Hecker
> Per the CA schedule, the next CA on the list for public comment is
> WISeKey, which has applied to add its (one) root CA certificate to the
> Mozilla root store, as documented in the following bug:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=371362
>
> and in the pending certificates list here:
>
> http://www.mozilla.org/projects/security/certs/pending/#WISeKey
We've now completed the scheduled time for public discussion on this
request. Based on my reading of the prior material for this request
(e.g., in the bug and in the newsgroup) and my reading of the discussion
thread for this discussion period, there were two issues of note:
First is auditing of subordinate CAs as implemented by the BloackBox
product. As noted by Kevin Blackman, WISeKey now does annual onsite
audits of BlackBox customers. This satisfies any concerns I might have
had on the subject of audits.
Second is constraining subordinate CAs to issue certificates only within
their own domain(s). My understanding from the WISeKey documents and
from Kevin Blackman's comments is that WISeKey implements both
contractual and technical constraints in connection with the BlackBox
products. Based on comments by Eddy, Nelson, et.al., there are
apparently theoretical cases where such constraints could be evaded and
the evasion would not be picked up by NSS (based on NSS not checking
domain constraints on CN or any other values outside of the SAN stuff).
On the WISeKey end, they could mandate use of SAN in BlackBox-issued
certificates (as opposed to just including it in the default template),
and from the NSS end we could disallow use of CN for storing domain
names. These may be good ideas for future consideration, but I can't
justify holding up this request till they get implemented.
Frank Hecker
> Frank Hecker wrote:
>> Per the CA schedule, the next CA on the list for public comment is
>> WISeKey, which has applied to add its (one) root CA certificate to the
>> Mozilla root store, as documented in the following bug:
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=371362
>>
>> and in the pending certificates list here:
>>
>> http://www.mozilla.org/projects/security/certs/pending/#WISeKey
>
> We've now completed the scheduled time for public discussion on this
> request. Based on my reading of the prior material for this request
> (e.g., in the bug and in the newsgroup) and my reading of the discussion
> thread for this discussion period, there were two issues of note:
And I forgot to add: In my opinion these issues have been resolved to my
satisfaction, and I'm therefore officially approving the WISeKey
request. I've filed bug 467138 against NSS for the actual certificate
inclusion:
https://bugzilla.mozilla.org/show_bug.cgi?id=467138
Eddy Nigg
> On the WISeKey end, they could mandate use of SAN in BlackBox-issued
> certificates (as opposed to just including it in the default template),
> and from the NSS end we could disallow use of CN for storing domain
> names.
>
At least you could have made it a requirement in order for the name
constraints to have any effect with NSS.
In regards to NSS we don't have to disallow subject CN fields, but have
NSS check also for these attributes in addition to the SAN.
Frank Hecker
> On 11/29/2008 06:43 AM, Frank Hecker:
>> On the WISeKey end, they could mandate use of SAN in BlackBox-issued
>> certificates (as opposed to just including it in the default template),
>> and from the NSS end we could disallow use of CN for storing domain
>> names.
>
> At least you could have made it a requirement in order for the name
> constraints to have any effect with NSS.
Made what a requirement? Mandating use of SAN in BlackBox? (In other
words, BlackBox customers would not be able to change the default
BlackBox certificate template to disable SAN.) But my understanding
(based on your hypothetical scenario) is that this would not be
sufficient, since someone could remove the key material and try to issue
certificates outside the context of the BlackBox product.
Also, at this point we don't have a good understanding why BlackBox
customers disable use of SAN in the first place. There may be some
special factors we're not aware of that cause a problem with SAN in
certain customer-specific contexts.
> In regards to NSS we don't have to disallow subject CN fields, but have
> NSS check also for these attributes in addition to the SAN.
My impression from Nelson's comments is that checking CN would be
subject to potential errors, since there is no well-defined standard for
what CN should contain. Thus the only foolproof approach would be to
move to a world where we prohibit use of CN in contexts like SSL-enbled
servers and force the use of SAN. But that would be a major undertaking
and one that would likely take several years in order to coordinate
action with other browser vendors and with CAs in general.
The bottom line is that I certainly encourage WISeKey to promote correct
use of SAN, including consideration of making its use mandatory in the
BlackBox templates, investigation of why some customers don't use it,
and resolution of any issues relating to use of SAN by BlackBox
customers. However I'm not going to make approval conditional on that,
given our uncertain state of knowledge and the dependence on future NSS
changes to fully address the SAN vs. CN issue.
Eddy Nigg
>
> Made what a requirement? Mandating use of SAN in BlackBox?
Yes, that's what I actually meant.
> But my understanding
> (based on your hypothetical scenario) is that this would not be
> sufficient, since someone could remove the key material and try to issue
> certificates outside the context of the BlackBox product.
Which is correct too...at least in the above scenario misusing the
system would require a higher effort and can't be performed directly
from the system.
>
> My impression from Nelson's comments is that checking CN would be
> subject to potential errors, since there is no well-defined standard for
> what CN should contain. Thus the only foolproof approach would be to
> move to a world where we prohibit use of CN in contexts like SSL-enbled
> servers and force the use of SAN. But that would be a major undertaking
> and one that would likely take several years in order to coordinate
> action with other browser vendors and with CAs in general.
Prohibiting the subject line would be a tough call - unrealistic in my
opinion. But checking for the CN field for SERVER certificate should be
entirely possible, because that's what NSS does anyway (for domain match).
>
> The bottom line is that I certainly encourage WISeKey to promote correct
> use of SAN, including consideration of making its use mandatory in the
> BlackBox templates, investigation of why some customers don't use it,
> and resolution of any issues relating to use of SAN by BlackBox
> customers.
OK, so I guess there will be no follow up later on ;-)
Kyle Hamilton
this issue and concept so they can update!"
-Kyle H
> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>