Verizon Root Inclusion and EV-enablement Request
Kathleen Wilson
is the next request in the queue for public discussion.
Verizon Business Security Solutions Powered by Cybertrust operates a
commercial certificate authority service for businesses and
governments internationally. This CA has been formerly known as
Cybertrust, Betrusted, Baltimore Technologies and GTE CyberTrust.
Verizon has applied to EV-enable two root certificates that are
already included in the Mozilla root store, and add a new root
certificate to the Mozilla root store and EV-enable it. The requests
are documented in the following three bugs.
EV-enable the GTE CyberTrust Global Root certificate, which is already
included in NSS:
https://bugzilla.mozilla.org/show_bug.cgi?id=430694
EV-enable and add the Code Signing trust bit to the Baltimore
CyberTrust Root certificate, which is already included in NSS:
https://bugzilla.mozilla.org/show_bug.cgi?id=430698
Add the Cybertrust Global Root certificate to NSS and enable it for
EV:
https://bugzilla.mozilla.org/show_bug.cgi?id=430700
These requests are in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#Verizon%20/%20Cybertrust
Summary of Information Gathered and Verified for all three requests:
https://bugzilla.mozilla.org/attachment.cgi?id=371269
Some comments regarding noteworthy points:
* The GTE CyberTrust Global Root certificate is already in NSS, and
the request is to EV-enable this root. It is presently Verizon’s
mainstream root, issuing their standard validation SSL server
certificates, user authentication and secure email certificates, and
code signing certificates. It has 4 internally-operated subordinate
CAs: Cybertrust SureServer Standard Validation CA, Cybertrust
Surecredential CA, Cybertrust SureCodesign CA, and Cybertrust
SureServer EV CA (relies on the Cybertrust Global Root's cross-
certificate to the GTE CyberTrust Global Root for legacy browsers).
** The certificate version of this root is 1, and modulus length of
this root is 1024. The plan is to migrate the hierarchy under this
root to the Baltimore CyberTrust Root. There are still many mobile
devices in APAC that cannot handle 2048-bit keys. Current web server
technology forces Verizon’s customers to make a choice between EV and
mobile support. In the APAC market, the majority of SSL terminations
are with a mobile device. Without enabling EV on a 1024 bit root, the
APAC market adoption of EV is obstructed. The JCAF has made similar
comments in this regard in the CAB Forum discussion lists.
** All three trust bits are already enabled in the GTE CyberTrust
Global Root built-in object.
* The Baltimore CyberTrust Root certificate is already in NSS, and the
request is to EV-enable this root and add the Code Signing trust bit.
At this time, no subordinate CAs have been issued under this root.
However, this root will supersede the GTE CyberTrust Global Root, and
the internal and external hierarchies under the GTE CyberTrust Global
Root will be migrated to this root. This root is certificate version 3
and modulus length 2048.
** Currently the Websites and Email trust bits are enabled in the
Baltimore CyberTrust Root built-in object. This request is to also
enable the Code Signing trust bit.
* The Cybertrust Global Root is requested to be added to NSS and EV-
enabled. Relying on the GTE CyberTrust Global Root for ubiquity
through cross-certification, this is Verizon’s main root for issuance
of EV SSL certificates. This Cybertrust Global Root has one internally-
operated subordinate CA, the Cybertrust SureServer EV CA, which only
issues EV SSL server certificates. In response to a completed WebTrust
EV point in time readiness check, it has issued one subordinate CA for
reseller use. This root is certificate version 3 and modulus length
2048.
** Only the Websites trust bit is requested for this root.
* The CP and CPS documents are in English.
*SSL certs are OV or EV. SSL Verification:
**CPS section 1.5.7, SureServer Issuing Procedures: Cybertrust
verifies the submitted information by checking organisational, payment
and any other information as it sees fit. This may also include checks
in third party databases or resources.
** CPS section 1.6.5, SureServer EV Data Verification: As to data
verification, Cybertrust ensures that the following Subject
organization information has been submitted by the applicant and shall
be verified by the CA in accordance with the EV Guidelines (Sections
14 through 25) by taking all verification steps reasonably necessary:
1 Applicant’s existence and identity, including: (a) Applicant’s legal
existence and identity (as established with an Incorporating Agency),
(b) Applicant’s physical existence (business presence at a physical
address), and (c) Applicant’s operational existence (business
activity)
2 Applicant’s exclusive control of the domain name to be included in
certificate;
** CPS section 1.7.6, SureCredential Professional Issuing Procedure:
Cybertrust verifies the submitted information by checking
organisational and any other information as it sees fit. This may also
include checks in third party databases or resources and independent
verification through telephone.
*Email Ownership Verification:
** CPS section 1.3.7, SureCredential Personal Issuing Procedure: When
the applicant receives an email from the automated system, it contains
a unique single use URL which the applicant is instructed to click on
or load in their browser to continue.
** CPS section 1.4.6, SureCredential Professional Issuing Procedure:
When the applicant receives an email from the automated system, it
contains a unique single use URL which the applicant is instructed to
click on or load in their browser to continue.
*Code Signing Verification:
** CPS section 1.8, SureCodesign Issuing Procedure: Cybertrust
verifies the submitted information by checking organisational, payment
and any other information as it sees fit also through third party
databases or resources. This may also include checks in third party
databases or resources and independent verification through telephone.
*CRL issuing frequency for end-entity certificates: every three hours
with four day grace period for DR/BCP
* OCSP is not provided under any of these roots.
*Externally Operated Subordinate CAs
** The GTE CyberTrust Global Root has signed sub-CAs that are operated
by third parties. However, no list has been provided due to
confidentiality. The number of sub-CAs operated at enterprise
customers for their own use is approximately 35. The number of
resellers is 5.
** There are currently no subordinate CAs under the Baltimore
CyberTrust Root at this time. This root will issue the same sub-CA’s
that are operated by third-parties as the GTE CyberTrust Global Root
currently does when it supersedes the GTE root. The Belgian
government intends to move their eID program under this root.
** In response to a completed WebTrust EV point in time readiness
check, Cybertrust Global Root has issued one subordinate CA for
reseller use.
More information about the externally-operated sub-CAs are provided in
https://bugzilla.mozilla.org/attachment.cgi?id=371269
* Verizon has been audited by Ernst and Young against both the
WebTrust CA and the WebTrust EV criteria. The most recent audit
reports are dated 7/28/2008. The WebTrust CA audit covers the
Cybertrust Global Root and the GTE CyberTrust Global Root. The
Baltimore CyberTrust Root is still long-term vaulted, and has no
operational CAs at this time. The WebTrust EV audit covers the
Cybertrust Global Root CA, which is the only root issuing operational
EV CAs.
This begins the one-week discussion period. After that week, I will
provide a summary of issues noted and action items. If there are no
outstanding issues, then this request can be approved for inclusion.
If there are outstanding issues or action items, then an additional
discussion may be needed as follow-up.
Kathleen
Johnathan Nightingale
> *CRL issuing frequency for end-entity certificates: every three hours
> with four day grace period for DR/BCP
>
> * OCSP is not provided under any of these roots.
While this doesn't constitute a principled objection to this root's
inclusion, it's worth noting that with the latest version of NSS in
use by Mozilla trunk does not give EV treatment to certificates that
offer CRL-based revocation, because support for crlDistributionPoint
CRL-fetching is not yet implemented (bug 321755).
Rob Stradling has a patch in bug 485052 that helps resolve this
problem by specifying a "default OCSP responder" for EV CAs, even if
their certs don't specify a responder. This allows a CRL-based CA
provide revocation information, and hence get EV treatment, even given
our current limitations with respect to CRLs.
Again, I don't think this should impact this root's evaluation, but
it's worth noting that, even if approved for EV, the current trunk
Firefox code will not give the root EV treatment (without the
workaround in 485052). If Verizon is interested in having a default
OCSP responder added to Rob's patch, we can do that.
Cheers,
Johnathan
---
Johnathan Nightingale
Human Shield
joh...@mozilla.com
Eddy Nigg
As per the CA Schedule at https://wiki.mozilla.org/CA:Schedule Verizon is the next request in the queue for public discussion.
Really well done, it makes it far easier to build an opinion about the CA and vastly more efficient to review. And here my preliminary opinion...
Some comments regarding noteworthy points: * The GTE CyberTrust Global Root certificate is already in NSS, and the request is to EV-enable this root. It is presently Verizon’s mainstream root, issuing their standard validation SSL server certificates, user authentication and secure email certificates, and code signing certificates. It has 4 internally-operated subordinate CAs: Cybertrust SureServer Standard Validation CA, Cybertrust Surecredential CA, Cybertrust SureCodesign CA, and Cybertrust SureServer EV CA (relies on the Cybertrust Global Root's cross- certificate to the GTE CyberTrust Global Root for legacy browsers). ** The certificate version of this root is 1, and modulus length of this root is 1024. The plan is to migrate the hierarchy under this root to the Baltimore CyberTrust Root. There are still many mobile devices in APAC that cannot handle 2048-bit keys. Current web server technology forces Verizon’s customers to make a choice between EV and mobile support. In the APAC market, the majority of SSL terminations are with a mobile device. Without enabling EV on a 1024 bit root, the APAC market adoption of EV is obstructed. The JCAF has made similar comments in this regard in the CAB Forum discussion lists.
Therefore I'm hesitant to recommend upgrade for legacy version 1 root with 1024 and smaller keys generally and Mozilla should consider gradual removal in corporation with the CAs of such roots - preferable during the next three years or earlier. NSS is clearly not affected by the deficiencies of mobiles and it doesn't make so much sense for a typical user of Mozilla software to enable EV for such roots. Also other modern devices are usually not affected, including iPhone for example (without relation to NSS).
*Code Signing Verification: ** CPS section 1.8, SureCodesign Issuing Procedure: Cybertrust verifies the submitted information by checking organisational, payment and any other information as it sees fit also through third party databases or resources. This may also include checks in third party databases or resources and independent verification through telephone.
* OCSP is not provided under any of these roots.
*Externally Operated Subordinate CAs ** The GTE CyberTrust Global Root has signed sub-CAs that are operated by third parties. However, no list has been provided due to confidentiality. The number of sub-CAs operated at enterprise customers for their own use is approximately 35. The number of resellers is 5.
More information about the externally-operated sub-CAs are provided in https://bugzilla.mozilla.org/attachment.cgi?id=371269
WebTrust audits annually and these audits are currently in progress. Hallelujah!
I wonder why Verizon didn't went all the way and applied that requirement to all their sub roots? Also can we (or Mozilla) receive confirmation of the audits the resellers and sub-ordinate CAs performed? I believe this could be handled informally between Frank and E&Y?
Additionally I recommend that Frank requests the list of sub CAs issued under the various Verizon roots. Certificates might be relied on by any third party and this is a public CA, hence I don't understand entirely why there needs to be confidentiality. Neither I'm 100% sure which intellectual property is being protected by refusing to disclose the entities holding intermediate CA certificates under these roots. I'm the opinion that this information should be disclosed publicly. Other CAs were clearly required to do so and to disclose their policies in place etc.
* Verizon has been audited by Ernst and Young against both the WebTrust CA and the WebTrust EV criteria. The most recent audit reports are dated 7/28/2008. The WebTrust CA audit covers the Cybertrust Global Root and the GTE CyberTrust Global Root. The Baltimore CyberTrust Root is still long-term vaulted, and has no operational CAs at this time. The WebTrust EV audit covers the Cybertrust Global Root CA, which is the only root issuing operational EV CAs.
Not only should the Baltimore root not be enabled for EV, but also the code signing bit should not be enabled until a relevant audit statement has been presented for this root. Due to preceding handling - enabling trust bits have been refused without proper audit statements - I expect that this applies here too.
-- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: star...@startcom.org Blog: https://blog.startcom.org
Nelson Bolyard
> As per the CA Schedule at https://wiki.mozilla.org/CA:Schedule Verizon
> is the next request in the queue for public discussion.
>
> Verizon Business Security Solutions Powered by Cybertrust operates a
> commercial certificate authority service for businesses and
> governments internationally. This CA has been formerly known as
> Cybertrust, Betrusted, Baltimore Technologies and GTE CyberTrust.
That's interesting info. Now I understand why certain people's email
signatures have changed to say "Verizon".
> Verizon has applied to EV-enable two root certificates that are
> already included in the Mozilla root store, and add a new root
> certificate to the Mozilla root store and EV-enable it. The requests
> are documented in the following three bugs.
So this request concerns 3 roots, named
Baltimore CyberTrust Root
GTE CyberTrust Global Root
Cybertrust Global Root
I expect to see LOTS of confusion over these names, going forward.
People will file bugs mentioning certs that chain to "the Cybertrust root".
These names clearly weren't chosen by people with support responsibilities.
Sigh. (I need cheese to go with this whine. :)
> Some comments regarding noteworthy points:
>
> * The GTE CyberTrust Global Root certificate is already in NSS, and
> the request is to EV-enable this root. It is presently Verizon’s
> mainstream root, issuing their standard validation SSL server
> certificates, user authentication and secure email certificates, and
> code signing certificates. It has 4 internally-operated subordinate
> CAs: Cybertrust SureServer Standard Validation CA, Cybertrust
> Surecredential CA, Cybertrust SureCodesign CA, and Cybertrust
> SureServer EV CA (relies on the Cybertrust Global Root's cross-
> certificate to the GTE CyberTrust Global Root for legacy browsers).
Verizon is also one of the USA's largest ISPs. If I was one of their
ISP customers, I would be worried about their ability to MITM me.
I would probably disable trust in their roots.
I had the same concern a few years ago when I used another large American
ISP who also had (have) one or more roots in Firefox. Some folks there
REALLY wanted to be able to gather marketing information from the https
connections that flowed through their ISP lines by MITMing them. It would
have been easy. I disabled the trust bits for their root.
But this is probably not relevant to Mozilla's decisions for these roots.
> ** The certificate version of this root is 1,
That's OK for roots. Roots don't really need all those extensions.
> and modulus length of this root is 1024.
Well, that does seem to be a policy issue with regard to EV. That's the
main issue in my remarks that follow.
> There are still many mobile devices in APAC that cannot handle 2048-bit
> keys.
I'm willing to believe that there are many mobile devices whose present
software (which is not Mozilla client software) cannot handle larger key
sizes. But I am not convinced that this is of much relevance to Mozilla's
decision to EV enable this root.
> Current web server technology forces Verizon’s customers to make a
> choice between EV and mobile support.
I don't accept that statement as fact. It appears to be a position
statement by the applicant. We should be careful not to parrot it, as
if we ourselves are saying it, believing it to be true. I don't mind
if we say that, "According to Verizon, web server admins who acquire
certificates from Cybertrust are forced to choose between EV certs and
certs that work with limited mobile devices." If that's their position,
it's OK to attribute it to them.
> In the APAC market, the majority of SSL terminations are with a mobile
> device. Without enabling EV on a 1024 bit root, the APAC market adoption
> of EV is obstructed. The JCAF has made similar comments in this regard in
> the CAB Forum discussion lists.
I believe there exists a solution that works for both. I am sure I know how
to construct one. So I don't accept the statements above as fact.
In my opinion, if Mozilla does decide to EV enable any 1024 bit roots,
it MUST be with the understanding that that EV enablement will be
terminated in new browsers that are released near the end of year 2010.
(We could even go so far as to "time bomb" browsers, so that browsers
released next month stop treating 1k bit roots as EV roots at the end
of 2010, and I would support doing that.)
People replace cell phones more frequently than once every 24 months,
according to some statistics I read (don't remember the citation).
In the USA, Verizon's "new every two" (years) program actually allows
customers to replace their phones every 20 months, if I'm not mistaken.
So, this really should not be a big issue by 21 months from now.
Eddy Nigg
> So this request concerns 3 roots, named
>
> Baltimore CyberTrust Root
> GTE CyberTrust Global Root
> Cybertrust Global Root
>
> I expect to see LOTS of confusion over these names, going forward.
> People will file bugs mentioning certs that chain to "the Cybertrust root".
> These names clearly weren't chosen by people with support responsibilities.
> Sigh. (I need cheese to go with this whine. :)
>
Which is perhaps similar to this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=481723
And apparently CAs can use names unrestricted as to their liking (as
opposed to end-user certificates which need to follow clear rules and
verifications...well, well). BTW, this was mentioned previously various
times with different CAs, some of which you seem to be rather supportive
of...not sure what makes you concerned this time around....?! :-)
> Verizon is also one of the USA's largest ISPs. If I was one of their
> ISP customers, I would be worried about their ability to MITM me.
>
>
There is perhaps a conflict of interests, but in the same manner it's
also perhaps for CAs which are also domain name registrars and/or
hosting providers. If you'd combine all those which are ISPs, domain
name registrars and hosting providers, you'd be left with perhaps less
than 20 % of all issued certificates if you'd remove the trust of all of
them....which gives?
> But this is probably not relevant to Mozilla's decisions for these roots.
>
As such I believe that those are different departments which have clear
separation in the business practice and perhaps even physically. I
expect those aspects were clearly looked at during auditing.
> I don't accept that statement as fact. It appears to be a position
> statement by the applicant. We should be careful not to parrot it, as
> if we ourselves are saying it, believing it to be true. I don't mind
> if we say that, "According to Verizon, web server admins who acquire
> certificates from Cybertrust are forced to choose between EV certs and
> certs that work with limited mobile devices." If that's their position,
> it's OK to attribute it to them.
>
LOL
> In my opinion, if Mozilla does decide to EV enable any 1024 bit roots,
> it MUST be with the understanding that that EV enablement will be
> terminated in new browsers that are released near the end of year 2010.
>
In this specific case Mozilla can't enable EV for this root anyway,
since this root isn't covered in the audit. I know that if E&Y would
have audited that root for EV and wanted Mozilla (and other browser
vendors) to have that root enabled it would have clearly indicated that
in the management assertion and audit report. However only the
Cybertrust Global root is covered, not GTE.
Ian G
> xxxxxx is also one of the USA's largest ISPs. If I was one of their
> ISP customers, I would be worried about their ability to MITM me.
> I would probably disable trust in their roots.
>
> I had the same concern a few years ago when I used another large American
> ISP who also had (have) one or more roots in Firefox. Some folks there
> REALLY wanted to be able to gather marketing information from the https
> connections that flowed through their ISP lines by MITMing them. It would
> have been easy. I disabled the trust bits for their root.
The trust bits in your own browser? Sure, but that means the end-users
never had a fair protection. We're left with the false security of
"protected against MITM except when someone bigger and nastier than us
does it."
> But this is probably not relevant to Mozilla's decisions for these roots.
Right, because it is an issue likely to occur outside the conventional
application and audit approach. That is, it likely occurs after the
root goes in.
But, it puts the point on the current lack; the after-the-event
response system for Mozilla is a bit too weak to deal with this.
For one, there is no safe harbour for people making important claims of
bad practices. And for another, there is no protection for CAs from the
attacks of competitors.
iang
Eddy Nigg
>
> The trust bits in your own browser? Sure, but that means the
> end-users never had a fair protection. We're left with the false
> security of "protected against MITM except when someone bigger and
> nastier than us does it."
I think that's a bit unfair. First of all, if we believe that CAs have
been audited according to their CPS, then these claims are pure FUD...I
mean, the CPS doesn't allow the CA to issue certificates to themselves
in order to make such an attack work.
But funnily, if we speak about domain control validation...well, there
are some CAs which control a few million domain names at least. Starting
from Verisign over Godaddy to Network Solutions, they all might be in
the same category. Together with Verizon that's a huge number of certs
and sites ;-)
>
>> But this is probably not relevant to Mozilla's decisions for these
>> roots.
>
>
> Right, because it is an issue likely to occur outside the conventional
> application and audit approach.
During a conversation recently with an auditor (WebTrust accredited), he
explained to me that the overall business, the management and owners are
clearly looked at. I believe that this specific case is no different.
Ian G
> On 04/07/2009 05:05 PM, Ian G:
>>
>> The trust bits in your own browser? Sure, but that means the end-users
>> never had a fair protection. We're left with the false security of
>> "protected against MITM except when someone bigger and nastier than us
>> does it."
>
> I think that's a bit unfair. First of all, if we believe that CAs have
> been audited according to their CPS, then these claims are pure FUD...I
> mean, the CPS doesn't allow the CA to issue certificates to themselves
> in order to make such an attack work.
It may be unfair; that's what the rest of the post was about: how to
deal with Nelson's claim that they were wanting to do MITMs on their
customers.
Fair or FUD, that is the question? Of course, it is easy for us to
simply assume that Nelson is talking out his ear, so of course it is FUD.
But happens when he is right? Or someone else is right? What does the
whistleblower do, knowing that he can come on this list and his claim
will be judged by like a popularity contest?
This is a completely different question to audit, CPS, etc because audit
only covers a reasonable level of protection, it doesn't protect so well
against the aggressive exceptions (by which I mean, like Madoff).
(We might also ask ourself what is it in the process that stops a CA
from writing the words "And we provide deep-level debugging support for
our customers in order to deliver customer satisfaction..." into the CPS?)
> But funnily, if we speak about domain control validation...well, there
> are some CAs which control a few million domain names at least. Starting
> from Verisign over Godaddy to Network Solutions, they all might be in
> the same category. Together with Verizon that's a huge number of certs
> and sites ;-)
Right, many conflicts might exist in any given situation.
>>> But this is probably not relevant to Mozilla's decisions for these
>>> roots.
>>
>>
>> Right, because it is an issue likely to occur outside the conventional
>> application and audit approach.
>
> During a conversation recently with an auditor (WebTrust accredited), he
> explained to me that the overall business, the management and owners are
> clearly looked at.
Yes, no argument here.
> I believe that this specific case is no different.
OK, to clarify, I should probably have written "will likely happen after
the first audit is done."
iang
Eddy Nigg
>
> It may be unfair; that's what the rest of the post was about: how to
> deal with Nelson's claim that they were wanting to do MITMs on their
> customers.
By providing some facts for example...
>
> Fair or FUD, that is the question? Of course, it is easy for us to
> simply assume that Nelson is talking out his ear, so of course it is FUD.
There might be some obvious suspicion and it's Nelson's right to be
suspicious. He handles that correctly by editing the trust settings.
>
> But happens when he is right? Or someone else is right? What does
> the whistleblower do, knowing that he can come on this list and his
> claim will be judged by like a popularity contest?
I believe that the information will be judged and evaluated accordingly.
Hope this isn't wishful thinking of mine...
>
> This is a completely different question to audit, CPS, etc because
> audit only covers a reasonable level of protection, it doesn't protect
> so well against the aggressive exceptions (by which I mean, like Madoff).
>
Haha...Madoff...guess he won't have a problem finding an old-age-home. :-)
>> During a conversation recently with an auditor (WebTrust accredited), he
>> explained to me that the overall business, the management and owners are
>> clearly looked at.
>
>
> Yes, no argument here.
Which is important to know for Mozilla and any other relying party.
Ian G
> On 04/07/2009 06:00 PM, Ian G:
>>
>> It may be unfair; that's what the rest of the post was about: how to
>> deal with Nelson's claim that they were wanting to do MITMs on their
>> customers.
>
> By providing some facts for example...
U-huh... and how is he going to do that? If I stand up and say VeryFine
CA is selling its soul to the highest bidder (CIA? RBN?), they might
turn around and sue me. Especially if I've got the evidence, they can
lock me up in court for years.
>> Fair or FUD, that is the question? Of course, it is easy for us to
>> simply assume that Nelson is talking out his ear, so of course it is FUD.
>
> There might be some obvious suspicion and it's Nelson's right to be
> suspicious. He handles that correctly by editing the trust settings.
Oh, sure. That's fine for him. But note Gerv's recent comment about
the 99.9%. We are here for the end-users, not for Nelson. Sorry Nelson ;)
>> But happens when he is right? Or someone else is right? What does the
>> whistleblower do, knowing that he can come on this list and his claim
>> will be judged by like a popularity contest?
>
> I believe that the information will be judged and evaluated accordingly.
> Hope this isn't wishful thinking of mine...
The case at hand was already squashed, that's why we talk about it. We
know it was there; we just don't know the details. That would seem to
support the "wishful" hypothesis :)
>> This is a completely different question to audit, CPS, etc because
>> audit only covers a reasonable level of protection, it doesn't protect
>> so well against the aggressive exceptions (by which I mean, like Madoff).
>>
>
> Haha...Madoff...guess he won't have a problem finding an old-age-home. :-)
Yup, and it looks like he won't be lonely :)
>>> During a conversation recently with an auditor (WebTrust accredited), he
>>> explained to me that the overall business, the management and owners are
>>> clearly looked at.
>>
>>
>> Yes, no argument here.
>
> Which is important to know for Mozilla and any other relying party.
<cough> That sounds like one of those "leaps of faith" so popular in the
PKI world :) How exactly did we leap from "looks at overall business"
to reliance? Just exactly what is the business statement here that
Mozilla can rely on? Won't go broke? Does good stuff? Sells at an
honest price? Doesn't do evil, a la Google?
Certainly an auditor looks at the overall business. But, he looks at it
for other purposes than for Mozilla and for any relying party.
E.g., if the business model is clearly stated as "rape & pillage" then
he might be looking to see that the various business processes are
aligned with that. He won't be looking to adopt our do-goody outrage on
such a mission. Why should he? He's employed by the business. If he
doesn't do that job ... then he isn't doing the next job.
E.g., you will be hard-pressed to find an auditor to accept your current
difficulties with certificate-inspired marketing offers. It's business.
It's not the auditor's job to adopt our views about hatred of spam,
it's the auditor's job to opine over whether the CA is losing any
opportunities with customer lists (if that's what they were engaged to
opine over...).
Perhaps the question we might put to an auditor (WebTrust accredited) is
to tell us what we can rely on, when he looks at the overall business,
the management and owners? Probably the answer is, as per the criteria,
which says something like "Business practices are disclosed, including
the CPS and the address." Gee thanks.
iang
Eddy Nigg
>> By providing some facts for example...
>
>
> U-huh... and how is he going to do that? If I stand up and say
> VeryFine CA is selling its soul to the highest bidder (CIA? RBN?),
> they might turn around and sue me. Especially if I've got the
> evidence, they can lock me up in court for years.
Huuu? Your logic is beyond me... :-(
>
>> There might be some obvious suspicion and it's Nelson's right to be
>> suspicious. He handles that correctly by editing the trust settings.
>
>
> Oh, sure. That's fine for him. But note Gerv's recent comment about
> the 99.9%. We are here for the end-users, not for Nelson. Sorry
> Nelson ;)
Well, as long as there hasn't been any reasonable evidence or other
knowledge on the subject it's not relevant for 99.9% of the users.
Besides that, most likely only a small percentage connects to the
Internet through this ISP, so only a small percentage is affected. At
least I'm not subscribed to this ISP and neither are you I guess.
>
>>
>> I believe that the information will be judged and evaluated accordingly.
>> Hope this isn't wishful thinking of mine...
>
>
> The case at hand was already squashed, that's why we talk about it.
> We know it was there; we just don't know the details. That would
> seem to support the "wishful" hypothesis :)
I don't know "it was there"...perhaps you can share the information you
know which some others here don't?
>
> Yup, and it looks like he won't be lonely :)
Hehe :-)
>
>> Which is important to know for Mozilla and any other relying party.
>
>
> Certainly an auditor looks at the overall business. But, he looks at
> it for other purposes than for Mozilla and for any relying party.
As I understood that they look at the overall business risk. This might
be relevant for Mozilla.
>
> E.g., if the business model is clearly stated as "rape & pillage" then
> he might be looking to see that the various business processes are
> aligned with that. He won't be looking to adopt our do-goody outrage
> on such a mission. Why should he? He's employed by the business. If
> he doesn't do that job ... then he isn't doing the next job.
I think auditors have to risk a lot too. At least some of them...
>
> E.g., you will be hard-pressed to find an auditor to accept your
> current difficulties with certificate-inspired marketing offers. It's
> business. It's not the auditor's job to adopt our views about hatred
> of spam
Which is absolutely irrelevant.
>
> Perhaps the question we might put to an auditor (WebTrust accredited)
> is to tell us what we can rely on, when he looks at the overall
> business, the management and owners? Probably the answer is, as per
> the criteria, which says something like "Business practices are
> disclosed, including the CPS and the address." Gee thanks.
>
And confirmed. The claims made in the CPS are confirmed.
Nelson Bolyard
> In this specific case Mozilla can't enable EV for this root anyway, since
> this root isn't covered in the audit.
Interesting. After reading Kathleen's "information gathering document"
I had the distinct (but maybe wrong) understanding that they were explicitly
requesting EV recognition for this cert with a 1k bit key.
There was a significant paragraph justifying that request, and explaining
this conflict between EV or 1k bit certs. What was the point of that whole
write up if EV is NOT being requested for that cert?
> I know that if E&Y would have audited that root for EV and wanted Mozilla
> (and other browser vendors) to have that root enabled it would have
> clearly indicated that in the management assertion and audit report.
> However only the Cybertrust Global root is covered, not GTE.
OK, I guess I misunderstood multiple aspects of the request in that document. :(
Nelson Bolyard
> On 7/4/09 07:20, Nelson Bolyard wrote:
>> xxxxxx is also one of the USA's largest ISPs. If I was one of their
>> ISP customers, I would be worried about their ability to MITM me.
>> I would probably disable trust in their roots.
>>
>> I had the same concern a few years ago when I used another large American
>> ISP who also had (have) one or more roots in Firefox. Some folks there
>> REALLY wanted to be able to gather marketing information from the https
>> connections that flowed through their ISP lines by MITMing them. It would
>> have been easy. I disabled the trust bits for their root.
>
>
> The trust bits in your own browser?
Yes, sorry, I should have been more clear about that.
I forget my super powers. :)
> Sure, but that means the end-users never had a fair protection. We're
> left with the false security of "protected against MITM except when
> someone bigger and nastier than us does it."
Well, the problem with *all* trust models is that the parties you trust
are the ones who can defeat your security.
Eddy Nigg
> Interesting. After reading Kathleen's "information gathering document"
> I had the distinct (but maybe wrong) understanding that they were explicitly
> requesting EV recognition for this cert with a 1k bit key.
> There was a significant paragraph justifying that request, and explaining
> this conflict between EV or 1k bit certs. What was the point of that whole
> write up if EV is NOT being requested for that cert?
>
Well, Nelson....so what if they have requested it? This root can not be
enabled for EV since it hasn't been audited and confirmed for EV, simple
as that. In this respect there might be roots in Mozilla which are EV
enabled and which should not have been. That's most likely due to some
missing knowledge on my part back when most were enabled. Hopefully I'm
wrong on that and all roots are eligible.
Concerning this request, there is only one root which can be enabled for
EV, discussion on the 1024 bit root (should) address other concerns with
roots like that.
Kathleen Wilson
The recommendation on the table is to decline the first two requests.
Request #1) EV-enable the GTE CyberTrust Global Root certificate,
which is already included in NSS:
https://bugzilla.mozilla.org/show_bug.cgi?id=430694
The main concerns are in regards to EV-enabling a root with a modulus
length of 1024, and the WebTrust EV audit does not appear to cover
this root.
Request #2) EV-enable and add the Code Signing trust bit to the
Baltimore CyberTrust Root certificate, which is already included in
NSS:
https://bugzilla.mozilla.org/show_bug.cgi?id=430698
Currently no subordinate CAs have been issued under the Baltimore
CyberTrust Root, so operational intermediate CAs for Code Signing and
EV do not exist. Therefore, they could not have been audited.
Precedence has been set with prior requests that the trust bits cannot
be enabled without proper audit statements. Likewise for EV-
enablement.
I believe that only one concern has been raised in this discussion
that is applicable to the third request, which is to add the
Cybertrust Global Root certificate to NSS and enable it for EV:
https://bugzilla.mozilla.org/show_bug.cgi?id=430700
This root is clearly covered by the WebTrust CA and WebTrust EV
audits.
* The Cybertrust Global Root is requested to be added to NSS and EV-
enabled. Relying on the GTE CyberTrust Global Root for ubiquity
through cross-certification, this is Verizon’s main root for issuance
of EV SSL certificates. This Cybertrust Global Root has one internally-
operated subordinate CA, the Cybertrust SureServer EV CA, which only
issues EV SSL server certificates. In response to a completed WebTrust
EV point in time readiness check, it has issued one subordinate CA for
reseller use. This root is certificate version 3 and modulus length
2048.
** Only the Websites trust bit is requested for this root.
Concern: OCSP is not provided for this root, nor for it’s intermediate
CA.
From Johnathan:
While this doesn't constitute a principled objection to this root's
inclusion, it's worth noting that with the latest version of NSS in
use by Mozilla trunk does not give EV treatment to certificates that
offer CRL-based revocation, because support for crlDistributionPoint
CRL-fetching is not yet implemented (bug 321755).
Rob Stradling has a patch in bug 485052 that helps resolve this
problem by specifying a "default OCSP responder" for EV CAs, even if
their certs don't specify a responder. This allows a CRL-based CA
provide revocation information, and hence get EV treatment, even
given our current limitations with respect to CRLs.
Again, I don't think this should impact this root's evaluation, but
it's worth noting that, even if approved for EV, the current trunk
Firefox code will not give the root EV treatment (without the
workaround in 485052). If Verizon is interested in having a default
OCSP responder added to Rob's patch, we can do that.
Please reply to this thread to correct any of the above information,
or to provide further feedback in regards to the request to add and EV-
enable the Cybertrust Global Root.
Thanks,
Kathleen
steve...@cybertrust.com
>
> Rob Stradling has a patch in bug 485052 that helps resolve this
> problem by specifying a "default OCSP responder" for EV CAs, even if
> their certs don't specify a responder. This allows a CRL-based CA
> provide revocation information, and hence get EV treatment, even given
> our current limitations with respect to CRLs.
Jonathan, how would that react if we don't operate a responder at the
default URI? Our issue at the moment is not that we have certificates
that omit the responder, but rather that the practice of creating a
responder for SSL certificates led to the extensive discussion of CA
impact I had with Yngve at the San Antonio CA/Browser Forum meeting.
It is inherently an unpredictable bandwidth impact that needs to be
scaled to holiday season e-commerce loads and represents a one user
agent one response traffic level as compared to a CRL which
authoritatively responds for our entire issuance base and is more
favorable to current technology proxy servers commonly used at mass
market broadband providers.
We left that meeting with a hope that even with the existing precedent
for OCSP development as the status checking preference in Opera,
Firefox, and Konqueror and no real reason to take a step backward to
CRL checking, we'd wait for TLS stapling of OCSP responses to emerge
before mandating OCSP for UI indication of an Extended Validation
process.
It is presumably too little too late to expect support of CRLs
although some preliminary but brief discussions with Kai implied it
might be possible. I'm also in a different place than I was at San
Antonio as Cybertrust, bandwidth is arguably more a competitive
advantage for Verizon than any of my peers.
Suffice to say, no option on the matter then? EV UI in Firefox means
I fire up SSL on our CoreStreet infrastructure?
steve...@cybertrust.com
>
> > *Code Signing Verification:
> > ** CPS section 1.8, SureCodesign Issuing Procedure: Cybertrust
> > verifies the submitted information by checking organisational, payment
> > and any other information as it sees fit also through third party
> > databases or resources. This may also include checks in third party
> > databases or resources and independent verification through telephone.
>
> I understand that a cross-verification with the subscriber (for example
> by phone) isn't guarantied. Would it be possible to receive a
> code-signing certificate merely by submitting the required information?
> I think this requires some more reviewing...
We consistently perform telephone validation of code signing
applicants and are willing to amend our CPS as such and subject that
assertion to WebTrust audit.
> Additionally I recommend that Frank requests the list of sub CAs issued
> under the various Verizon roots. Certificates might be relied on by any
> third party and this is a public CA, hence I don't understand entirely
> why there needs to be confidentiality. Neither I'm 100% sure which
> intellectual property is being protected by refusing to disclose the
> entities holding intermediate CA certificates under these roots. I'm the
> opinion that this information should be disclosed publicly. Other CAs
> were clearly required to do so and to disclose their policies in place etc.
Eddy, this would be grounds for my termination. Customer lists are
protected intellectual property assets of Verizon and I am bound to a
contract to protect confidential information. Certainly it is true
that a thorough Netcraft analysis would point out our premise-enabled
PKIs, but I have a responsibility to Verizon in my employment contract
and a responsibility to my customers in the non-publicity clauses of
their contracts. Frank, Kathleen, and I examined every possible angle
that we could on this topic in the months that led to the public
disclosure of our application. Because neither of our organizations
sign NDAs, I cannot communicate this data directly and kindly nudge
that it can be inferred from public surveys.
>
> > * Verizon has been audited by Ernst and Young against both the
> > WebTrust CA and the WebTrust EV criteria. The most recent audit
> > reports are dated 7/28/2008. The WebTrust CA audit covers the
> > Cybertrust Global Root and the GTE CyberTrust Global Root. The
> > Baltimore CyberTrust Root is still long-term vaulted, and has no
> > operational CAs at this time. The WebTrust EV audit covers the
> > Cybertrust Global Root CA, which is the only root issuing operational
> > EV CAs.
>
> However this would clearly mean that only the new "Cybertrust Global
> Root CA" can be enabled for EV. It makes the decision obvious in respect
> to the request to EV enable the legacy v1 GTE and the Baltimore roots.
>
> Not only should the Baltimore root not be enabled for EV, but also the
> code signing bit should not be enabled until a relevant audit statement
> has been presented for this root. Due to preceding handling - enabling
> trust bits have been refused without proper audit statements - I expect
> that this applies here too.
>
We foresee a migration to this root in the coming quarters and
therefore expect to establish an auditable practice record against
it. As it stands today, it performs no transactions and there is no
basis for an audit. All we can accurately offer to the Mozilla
community to consider is the care we take in our practice rooted in
the GTE CyberTrust Global Root. We operate a practice based on
policies and procedures that apply to every certificate we issue, not
to specific roots. We use a consolidated brand-centric CPS that
focuses on the methods we use to issue our certificate brands. Those
methods are and will be equal for every root we propose to the
Community for embedment. We need lead time enablement prior to our
migration to ensure that our customers can consume all the benefits of
our GTE CyberTrust Global Root when they are moved to our Baltimore
CyberTrust Root.
I empathize the point that the root does not have an audit record,
please acknowledge that we can be expected to preserve our position in
the public trust community by carrying forward and further improving
our current practices as a conscious ongoing effort. An audit done
today would state that we vault the root six months at a time only to
take it out for periodic CRL generation. Does that help you evaluate
our practice?
Kyle Hamilton
Is there at least a readiness audit on this particular root? EV
enablement requires EV readiness audits, not EV practice audits. If
you have a CA that isn't used anywhere, a readiness audit at least
shows that you have the policies and readiness to implement those
policies.
-Kyle H
Kyle Hamilton
(I'm just verifying this; the continued use of 1024-bit roots after
Dec 2009 is undesirable to me, and I appreciate your candor on the
issue.)
-Kyle H
On Fri, Apr 24, 2009 at 3:36 PM, Medin, Steven
<steve...@verizonbusiness.com> wrote:
> We have an EV readiness audit and annual audits on our business practice.
> We do not isolate our business based on roots, we do not have separate CP or
> CPS documents for each root. We have one consolidated statement of our
> policies, we have one audit of our practice. The root we use to enable that
> practice has been the GTE CyberTrust Global Root. It faced a readiness
> check audit, and it faced an annual WTCA/EV.
>
> There are CAs that have a separate CPS for their different roots, and a
> practice that has no execution is certainly a source of concern. I assert
> that the root is a pluggable component in our business and the status quo
> that allowed us to pass a WebTrust for CAs and WebTrust for EV CAs audit
> will carry forward regardless of the card we have plugged into the slot.
>
> When looking at the technical issuance base of the Baltimore CyberTrust
> Root, it offers nothing to audit and a WebTrust auditor cannot include it in
> an audit without basis of operation.
>
> We seek to be able to effectively move our business to the Baltimore root
> and maintain 100% of our practices. If it is not enabled, that perpetuates
> our use of our 1024-bit GTE root which is not desirous for us or our
> customers and relying parties.
>
> Kind regards,
> Steven Medin
> Product Manager, Identity and Access Management
> Verizon Business Security Solutions Powered by Cybertrust
>
>
> -----Original Message-----
> From: Kyle Hamilton [mailto:aero...@gmail.com]
> Sent: Friday, April 24, 2009 6:26 PM
> To: steve...@cybertrust.com
> Cc: dev-secur...@lists.mozilla.org
> Subject: Re: Verizon Root Inclusion and EV-enablement Request
>
> On Fri, Apr 24, 2009 at 3:09 PM, <steve...@cybertrust.com> wrote:
steve...@cybertrust.com
> This discussion involves three requests from Verizon.
>
> The recommendation on the table is to decline the first two requests.
> Request #1) EV-enable the GTE CyberTrust Global Root certificate,
> which is already included in NSS:https://bugzilla.mozilla.org/show_bug.cgi?id=430694
> The main concerns are in regards to EV-enabling a root with a modulus
> length of 1024, and the WebTrust EV audit does not appear to cover
> this root.
This is an acceptable result. We issue all of our EV SSL certificates
using an issuer signed by the Cybertrust Global Root and cross-
certified it to this root for legacy ubiquity. Given adequate
distribution of the CT Global Root, enablement of this soon to be
retired root is not critical for our operations.
> Request #2) EV-enable and add the Code Signing trust bit to the
> Baltimore CyberTrust Root certificate, which is already included in
> NSS:https://bugzilla.mozilla.org/show_bug.cgi?id=430698
> Currently no subordinate CAs have been issued under the Baltimore
> CyberTrust Root, so operational intermediate CAs for Code Signing and
> EV do not exist. Therefore, they could not have been audited.
> Precedence has been set with prior requests that the trust bits cannot
> be enabled without proper audit statements. Likewise for EV-
> enablement.
We are willing to discuss this further. I have respond to this topic
by categorizing our business practice as not centering on a root but
rather a brand of certificate that we sell. We operate under a
consolidated CPS that covers all our business regardless of the root
that has signed the subordinates. Before I discuss further, I await
responses based on my initial comments.
steve...@cybertrust.com
> Is there at least a readiness audit on this particular root? EV
> enablement requires EV readiness audits, not EV practice audits. If
> you have a CA that isn't used anywhere, a readiness audit at least
> shows that you have the policies and readiness to implement those
> policies.
>
We have an EV readiness audit and annual audits on our business
Eddy Nigg
I understand that a cross-verification with the subscriber (for example by phone) isn't guarantied. Would it be possible to receive a code-signing certificate merely by submitting the required information? I think this requires some more reviewing...We consistently perform telephone validation of code signing applicants and are willing to amend our CPS as such and subject that assertion to WebTrust audit.
their contracts. Frank, Kathleen, and I examined every possible angle that we could on this topic in the months that led to the public disclosure of our application. Because neither of our organizations sign NDAs, I cannot communicate this data directly and kindly nudge that it can be inferred from public surveys.
We foresee a migration to this root in the coming quarters and therefore expect to establish an auditable practice record against it. As it stands today, it performs no transactions and there is no basis for an audit. All we can accurately offer to the Mozilla community to consider is the care we take in our practice rooted in the GTE CyberTrust Global Root.
Our assertion is limited to the following Root and Issuing CA’s:
- The “Cybertrust Global Root” with serial number 04:00:00:00:00:01:0f:85:aa:2d:48;
- The “GTE CyberTrust Global Root” with serial number 01:a5;
It can't be clearer than that, right?
Eddy Nigg
> We are willing to discuss this further. I have respond to this topic
> by categorizing our business practice as not centering on a root but
> rather a brand of certificate that we sell. We operate under a
> consolidated CPS that covers all our business regardless of the root
> that has signed the subordinates. Before I discuss further, I await
> responses based on my initial comments.
>
Actually I have here a question to Frank, since some roots of yours are
already included in NSS. The question is, if those roots were inherited
(so-called legacy roots)? Or were they added since the Mozilla CA policy
came into existence? I couldn't find an entry in the included list, but
this list isn't complete and authoritative either.
Eddy Nigg
Our assertion is limited to the following Root and Issuing CA’s:
- The “Cybertrust Global Root” with serial number 04:00:00:00:00:01:0f:85:aa:2d:48;
- The “GTE CyberTrust Global Root” with serial number 01:a5;
...for the GTE CyberTrust Global Root CA and Cybertrust Global Root CA, during the period from May 1, 2007 to April 30, 2008... (regular WebTrust)
...for the Cybertrust Global Root CA, during the period from May 1, 2007 to April 30, 2008... (EV audit)
I think that's not by mistake :S
Eddy Nigg
On 04/25/2009 03:42 AM, Eddy Nigg:
Our assertion is limited to the following Root and Issuing CA’s:
- The “Cybertrust Global Root” with serial number 04:00:00:00:00:01:0f:85:aa:2d:48;
- The “GTE CyberTrust Global Root” with serial number 01:a5;
And further the audit statement states:
...for the GTE CyberTrust Global Root CA and Cybertrust Global Root CA, during the period from May 1, 2007 to April 30, 2008... (regular WebTrust)
...for the Cybertrust Global Root CA, during the period from May 1, 2007 to April 30, 2008... (EV audit)
I think that's not by mistake :S
Medin, Steven
Eddy, I appreciate your diligence in four separate responses, but I invite the community members who are not competitors to form an opinion as well.
Kind regards,
Steven Medin
Product Manager, Identity and Access Management
Verizon Business Security Solutions Powered by Cybertrust
From:
dev-security-policy-bounces+steve.medin=verizonbu...@lists.mozilla.org
[mailto:dev-security-policy-bounces+steve.medin=verizonbu...@lists.mozilla.org]
On Behalf Of Eddy Nigg
Sent: Friday, April 24, 2009 9:11
PM
To:
dev-secur...@lists.mozilla.org
Subject: Re: Verizon Root
Inclusion and EV-enablement Request
On 04/25/2009 03:58 AM, Eddy Nigg:
Eddy Nigg
On 04/27/2009 04:07 PM, Medin, Steven:
Eddy, I appreciate your diligence in four separate responses, but I invite the community members who are not competitors to form an opinion as well.
Medin, Steven
Telephone numbers are sourced through trusted external sources such as authoritative directories offered by line carriers in the territory of the customer. Main switchboard numbers are the only source of contact. The person subject to identification is requested by name. Any inability to route to the requestor is treated as a failed validation once reasonable but careful effort is used to determine if a different switchboard number should be used. Any alternate switchboard number is reverified as correlated to the organization using authoritative directories. Persons subject to validation are never contacted directly by any phone numbers provided during the application process, the data is kept on file to attempt to rapidly access legitimate applicants in the event of an issue after the certificate is issued.
This is the same process we perform for our non-EV SSL certificates which is also materially consistent with the methods prescribed in the EV Guidelines for EV SSL certificates.
Kind regards,
Steven Medin
Product Manager, Identity and Access Management
Verizon Business Security Solutions Powered by Cybertrust
From:
dev-security-policy-bounces+steve.medin=verizonbu...@lists.mozilla.org
[mailto:dev-security-policy-bounces+steve.medin=verizonbu...@lists.mozilla.org]
On Behalf Of Eddy Nigg
Sent: Monday, April 27, 2009 10:42
AM
To:
dev-secur...@lists.mozilla.org
Subject: Re: Verizon Root
Inclusion and EV-enablement Request
Hi Steve,
Eddy Nigg
Telephone numbers are sourced through trusted external sources such as authoritative directories offered by line carriers in the territory of the customer. Main switchboard numbers are the only source of contact. The person subject to identification is requested by name. Any inability to route to the requestor is treated as a failed validation once reasonable but careful effort is used to determine if a different switchboard number should be used. Any alternate switchboard number is reverified as correlated to the organization using authoritative directories. Persons subject to validation are never contacted directly by any phone numbers provided during the application process, the data is kept on file to attempt to rapidly access legitimate applicants in the event of an issue after the certificate is issued.
This is the same process we perform for our non-EV SSL certificates which is also materially consistent with the methods prescribed in the EV Guidelines for EV SSL certificates.
Kathleen Wilson
Would you please provide your opinion on these three requests from
Verizon that I will summarize below?
---Request #1---
Agreement has been reached that this request will be declined.
EV-enable the GTE CyberTrust Global Root certificate, which is already
included in NSS:
https://bugzilla.mozilla.org/show_bug.cgi?id=430694
The main concerns are in regards to EV-enabling a root with a modulus
length of 1024, and the WebTrust EV audit does not appear to cover
this root.
---Request #2---
Does anyone have anything further to say about this request?
Have I summarized the action items correctly below?
EV-enable and add the Code Signing trust bit to the Baltimore
CyberTrust Root certificate, which is already included in NSS:
https://bugzilla.mozilla.org/show_bug.cgi?id=430698
The following action items are requested of Verizon before proceeding
with this request:
1) Add information about their validation procedures for code signing
applicants to their CPS, and subject that assertion to a WebTrust CA
audit. Would this be sufficient to enable the Code Signing trust bit?
Or would Verizon first need to issue the Code Signing intermediate CA
from this root and get it audited?
2) Have a WebTrust EV Readiness audit performed on this root.
3) Provide evidence of the WebTrust audits that have been performed on
the third-parties who operate sub-CAs of this root. Since the names of
the sub-CAs are considered confidential to Verizon, perhaps a third-
party auditor can provide a statement that the WebTrust audits of the
third-parties have been reviewed, and that the sub-CAs meet the
requirements of section 7 of the Mozilla CA Certificate Policy?
Precedence has been set with prior requests that the trust bits cannot
be enabled without relevant verification information in the CPS and
corresponding audit statements. Likewise for EV-enablement.
Precedence has also been set with prior requests in regards to
requiring the CA to provide the information listed in
https://wiki.mozilla.org/CA:SubordinateCA_checklist for their
subordinate CAs that are operated by third parties.
---Request #3---
Does anyone have anything further to say about this request?
It appears that this request is ready for me to recommend for
approval.
Add the Cybertrust Global Root certificate to NSS and enable it for
EV:
https://bugzilla.mozilla.org/show_bug.cgi?id=430700
This root is clearly covered by the WebTrust CA and WebTrust EV
audits.
The only concern that applies to this request is in regards to working
around the issue of OCSP not being provided for this root and its
intermediate CA. While this will need to be figured out before EV
treatment will be visible, it does not prevent this root from being
approved.
Thanks,
Kathleen
Frank Hecker
Nelson Bolyard wrote:
> I'm willing to believe that there are many mobile devices whose present
> software (which is not Mozilla client software) cannot handle larger key
> sizes. But I am not convinced that this is of much relevance to Mozilla's
> decision to EV enable this root.
Nelson, how does this square with your comments in bug 420760? This
would seem at first glance to be a similar case.
> In my opinion, if Mozilla does decide to EV enable any 1024 bit roots,
> it MUST be with the understanding that that EV enablement will be
> terminated in new browsers that are released near the end of year 2010.
<snip>
> People replace cell phones more frequently than once every 24 months,
> according to some statistics I read (don't remember the citation).
> In the USA, Verizon's "new every two" (years) program actually allows
> customers to replace their phones every 20 months, if I'm not mistaken.
> So, this really should not be a big issue by 21 months from now.
I think the real issue here is not when people replace their cell
phones, but rather when web sites feel that have 2k roots won't cause
problems for their customers, and when CAs prod them to upgrade (e.g.,
by discontinuing issuance of EV certs terminating in 1k roots). But in
any case I agree that we should set some sort of timeframe on this, the
only question is exactly when.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Eddy Nigg
> I think the real issue here is not when people replace their cell
> phones, but rather when web sites feel that have 2k roots won't cause
> problems for their customers, and when CAs prod them to upgrade (e.g.,
> by discontinuing issuance of EV certs terminating in 1k roots). But in
> any case I agree that we should set some sort of timeframe on this,
> the only question is exactly when.
I think it would be also interesting to know about how much are secured
sites accessed by mobile phones compared to browsers for example and how
many of these can't access sites because of key size problems. Is there
any research somewhere available?
Medin, Steven
consulted my security officers on the matter and they explained that neither
of our WebTrust auditors is able to write an opinion on a root that does not
issue certificates.
As I have mentioned in our discussions, if we need to have an operational
period under this root before we can enable it for EV SSL, that prolongs the
time that I need to keep a 1024-bit MD5 root operational.
I am not asking for special treatment in our case, I feel entitled to none.
But if the precedent in the past has been that other certificate authorities
operate with a CPS that is specifically tied to the operation of a specific
root, then I call attention to the fact that we operate all our services
under a consolidated CPS and that the root involved is a pluggable
component. If this practice materially differs from the other CAs the
Community has reviewed, I ask for your careful consideration of this matter
and to infer (a stretch for some I clearly admit) that our practice under
the Baltimore root will be materially equal to our practice today.
When we move to the Baltimore root, we pull a few cards out of HSM slots,
push a few cards in, and drive the bus past the same houses as yesterday.
Kind regards,
Steven Medin
Product Manager, Identity and Access Management
Verizon Business Security Solutions Powered by Cybertrust
-----Original Message-----
From:
dev-security-policy-bounces+steve.medin=verizonbu...@lists.mozilla.or
g
[mailto:dev-security-policy-bounces+steve.medin=verizonbu...@lists.mo
zilla.org] On Behalf Of Kathleen Wilson
Sent: Thursday, April 30, 2009 1:16 PM
To: dev-secur...@lists.mozilla.org
Subject: Re: Verizon Root Inclusion and EV-enablement Request
All,
Thanks,
Kathleen
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Medin, Steven
Japanese partner because they are required by local market fact to support
these customers. 55% of SSL terminations in Japan are with a mobile device.
It is statistically imperative in the market to support those devices.
These devices present an accurate http_user_agent and a comprehensive list
of devices with wonderful video processors but core CPUs deemed by the OEM
to be too weak or power consuming to crank 2kbit keys could be assembled.
Web property owners could conceivably parse and route the transition from
plaintext to secure based on agent and realize 2048-bit chains on platforms
with more powerful processors. That concept isn't a reality, and the market
calls for lowest common denominator support.
Mobile devices are fashion accessories, we have limited ability to keep them
from breaking ankles when used on the internet's terrain.
Kind regards,
Steven Medin
Product Manager, Identity and Access Management
Verizon Business Security Solutions Powered by Cybertrust
-----Original Message-----
From:
dev-security-policy-bounces+steve.medin=verizonbu...@lists.mozilla.or
g
[mailto:dev-security-policy-bounces+steve.medin=verizonbu...@lists.mo
zilla.org] On Behalf Of Frank Hecker
Sent: Thursday, April 30, 2009 1:40 PM
To: dev-secur...@lists.mozilla.org
Subject: Re: Verizon Root Inclusion and EV-enablement Request
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Frank Hecker
> Actually I have here a question to Frank, since some roots of yours are
> already included in NSS. The question is, if those roots were inherited
> (so-called legacy roots)? Or were they added since the Mozilla CA policy
> came into existence?
I believe that all the Verizon/CyberTrust roots currently in NSS were
inherited from the Netscape days, i.e., they are "legacy roots" in the
sense we usually mean. I've searched through the archives of the
netscape.public.mozilla.crypto newsgroup, as well as for the newer
mozilla.dev.tech.crypto newsgroup. I couldn't find any indication that
we'd ever had a public discussion about adding Verizon, Cybertrust, or
Baltimore roots.
Moudrick M. Dadashov
>I am not asking for special treatment in our case, I feel entitled to none.
>But if the precedent in the past has been that other certificate authorities
>operate with a CPS that is specifically tied to the operation of a specific
>root, then I call attention to the fact that we operate all our services
>under a consolidated CPS and that the root involved is a pluggable
>component. If this practice materially differs from the other CAs the
>Community has reviewed, I ask for your careful consideration of this matter
>and to infer (a stretch for some I clearly admit) that our practice under
>the Baltimore root will be materially equal to our practice today.
Your case is quite typical, I'd say. CA's policies and practices are mostly 'generic', 'root independent' so to say.
However nothing prevents you to add your root specific provisions into your CPS but normally those provisons present in CA's operational documentation rather than in CP/CPS.
Thanks,
M.D.
Cell: +370-699-26662
Eddy Nigg
> I am not asking for special treatment in our case, I feel entitled to none.
> But if the precedent in the past has been that other certificate authorities
> operate with a CPS that is specifically tied to the operation of a specific
> root, then I call attention to the fact that we operate all our services
> under a consolidated CPS and that the root involved is a pluggable
> component. If this practice materially differs from the other CAs the
> Community has reviewed, I ask for your careful consideration of this matter
> and to infer (a stretch for some I clearly admit) that our practice under
> the Baltimore root will be materially equal to our practice today.
>
> When we move to the Baltimore root, we pull a few cards out of HSM slots,
> push a few cards in, and drive the bus past the same houses as yesterday.
>
>
I'm actually sympathetic to your cause to move away from the 1K root.
The problem I'm seeing here is the other way around, what to do if a
root clearly shouldn't be enabled in the future (same as yours, since
neither a just-in-time nor obviously a full EV audit has been provided)
because the audit statement doesn't cover the specific root. I can
clearly confirm that this distinction is made before engaging and during
auditing. So as of recently only roots covered by the audit statement
were enabled for EV IIRC.
Medin, Steven
local provider in the country where I provide public trust services. If I
switch, my business practices remain the same and do not put my audits into
question.
Changing roots for us is the same as changing fiber contracts. It has
entirely equal process impact.
Kind regards,
Steven Medin
Product Manager, Identity and Access Management
Verizon Business Security Solutions Powered by Cybertrust
-----Original Message-----
From: Moudrick M. Dadashov [mailto:m...@ssc.lt]
Sent: Thursday, April 30, 2009 2:04 PM
To: Medin, Steven
Cc: Kathleen Wilson; dev-secur...@lists.mozilla.org
Subject: RE: Verizon Root Inclusion and EV-enablement Request
Hi Steve,
>I am not asking for special treatment in our case, I feel entitled to none.
>But if the precedent in the past has been that other certificate
authorities
>operate with a CPS that is specifically tied to the operation of a specific
>root, then I call attention to the fact that we operate all our services
>under a consolidated CPS and that the root involved is a pluggable
>component. If this practice materially differs from the other CAs the
>Community has reviewed, I ask for your careful consideration of this matter
>and to infer (a stretch for some I clearly admit) that our practice under
>the Baltimore root will be materially equal to our practice today.
Your case is quite typical, I'd say. CA's policies and practices are mostly
Medin, Steven
that our business will be status quo the day we move to it? Does anyone
have evidence that I would suddenly shift practice radically on that day?
Don't we certainly have recourse if I do something that absurd?
I don't understand the risk this root presents that we are mitigating. You
either have a basis to trust my business practices or you don't. If you
don't, I'm going to listen to you and improve. I humbly submit that we are
already a trusted member of this community.
All I can ask at this point is that if the Foundation's policy allows our
current practice to be extrapolated forward regardless of the root in use,
we should be granted the right to have the Baltimore CyberTrust Root enabled
for EV. If the policy does not, I would be well served by an explanation of
the risk such a policy limitation prevents in our case.
Kind regards,
Steven Medin
Product Manager, Identity and Access Management
Verizon Business Security Solutions Powered by Cybertrust
-----Original Message-----
From:
dev-security-policy-bounces+steve.medin=verizonbu...@lists.mozilla.or
g
[mailto:dev-security-policy-bounces+steve.medin=verizonbu...@lists.mo
zilla.org] On Behalf Of Eddy Nigg
Sent: Thursday, April 30, 2009 2:11 PM
To: dev-secur...@lists.mozilla.org
Subject: Re: Verizon Root Inclusion and EV-enablement Request
--
Regards
_______________________________________________
Frank Hecker
> What is the root without issuance? Can we base this request on my assertion
> that our business will be status quo the day we move to it? Does anyone
> have evidence that I would suddenly shift practice radically on that day?
> Don't we certainly have recourse if I do something that absurd?
I'm sympathetic to the argument that practices are practices,
independent of the root in question. However I'm also mindful of the
fact that this is an EV request, and it is in fact a traditional
practice in the EV world to get EV readiness audit reports in advance of
issuing actual EV certificates. (We've also recently had a major
controversy regarding an accusation that a CA allegedly issued EV certs
prior to completion of a readiness audit.)
> All I can ask at this point is that if the Foundation's policy allows our
> current practice to be extrapolated forward regardless of the root in use,
> we should be granted the right to have the Baltimore CyberTrust Root enabled
> for EV.
It's not just a Foundation issue I think, it's also a potential CA/B
Forum issue. While I think Mozilla can and should reserve the right to
make its own decisions regarding CAs in general, I'm also mindful that
where EV is concerned the CA/B Forum is the body that is most
responsible for determining the ground rules for EV issuance. (And of
course again we've just recently had major arguments about the fine
details of EV compliance on the part of CAs, and what the EV guidelines
do or do not require.)
So before we make any final decision on this I'm interested in knowing
whether this particular issue has ever come up in the CA/B Forum. I also
want to go back and look at previous EV approvals we've done, and how we
handled this issue of an EV audit applying to a particular root (or not).
Frank Hecker
> Verizon is also one of the USA's largest ISPs. If I was one of their
> ISP customers, I would be worried about their ability to MITM me.
> I would probably disable trust in their roots.
>
> I had the same concern a few years ago when I used another large American
> ISP who also had (have) one or more roots in Firefox. Some folks there
> REALLY wanted to be able to gather marketing information from the https
> connections that flowed through their ISP lines by MITMing them. It would
> have been easy. I disabled the trust bits for their root.
>
> But this is probably not relevant to Mozilla's decisions for these roots.
Correct, for the most part. Before I expand on this point, full
disclosure: I am in fact myself a Verizon ISP customer, and have
published complimentary comments about Verizon's FiOS service.
Now, as to the potential MITM issue: Speaking generally, in practice any
large ISP, whether in the US or elsewhere, is likely to cooperate with
government intelligence agencies that want to do MITM schemes or similar
attacks against ISP customers in support of government actions. So that
type of MITM potential is I think out of scope from a Mozilla point of
view; unless I've missed something, we don't make claims, either formal
or informal, to provide Mozilla users robust protection against actions
of government intelligence agencies.
On the other hand, if an ISP were to implement MITM schemes with respect
to its users for its own commercial purposes, then I think that would be
a legitimate factor for us to consider. We might decide in the end that,
e.g., a particular scheme had sufficient "informed consent" to make it
at least minimally acceptable, but I still think it would be in scope
for us to discuss it. (But note that I'm referring to actual MITM scheme
known to be implemented, not to the mere possibility of an ISP
implementing such a scheme.)
Kyle Hamilton
that wouldn't allow the installation of any root with a key size
larger than 1024 bits. This tended to complicate IPsec deployments.
I don't know of any browsers that won't allow/verify a root of 2048 bits.
-Kyle H
Eddy Nigg
> To my knowledge, it was actually some Cisco hardware a few years ago
> that wouldn't allow the installation of any root with a key size
> larger than 1024 bits. This tended to complicate IPsec deployments.
>
I think CISCO routers have until this day a problem with larger keys.
Fortunately it's most of the time enough to install the issuing CA
certificate and omit the root (which makes a root with 4096 bit keys
work when the intermediate is 2048 bit).
> I don't know of any browsers that won't allow/verify a root of 2048 bits.
>
Must be a mobile browser not of recent builds.
Eddy Nigg
> Correct, for the most part. Before I expand on this point, full
> disclosure: I am in fact myself a Verizon ISP customer, and have
> published complimentary comments about Verizon's FiOS service.
Where? :-)
Eddy Nigg
I think we wouldn't add a version one 1024 bit with MD5 root these days,
but I guess it doesn't make sense to actually yank a root because of
that (and we haven't done so for other CAs either with similar roots
during reviews of legacy roots). But you've touched the same subject at
a different comment when replying to Nelson. Is there a basis for
creating a rule and target date to stop supporting such and similar roots?
Ian G
> ---Request #1---
> Agreement has been reached that this request will be declined.
> EV-enable the GTE CyberTrust Global Root certificate, which is already
> included in NSS:
> https://bugzilla.mozilla.org/show_bug.cgi?id=430694
> The main concerns are in regards to EV-enabling a root with a modulus
> length of 1024,
I would not see an issue with a 1024 length root. There are plenty of
business cases which suggest smaller keys, and no validated threats
against (by this, no experience that suggests there is a real threat as
opposed to a theoretical weakness). Pretty much all attacks on record
occur against 0 bit keys
It may be that EV says something about 1024 bit roots, but I would say
that is an CA/B Forum issue. Mozilla isn't CA/B Forum's judge, jury and
executioner. If they've got a problem with it, they can contact their
member or their member's auditor and discuss it.
Or it may be that we decide on our own to phase out anything around
1024. But that's a debate to be had, I would have thought. Set a date,
etc.
> and the WebTrust EV audit does not appear to cover
> this root.
That might be more of an issue!
> ---Request #2---
> Does anyone have anything further to say about this request?
> Have I summarized the action items correctly below?
> EV-enable and add the Code Signing trust bit to the Baltimore
> CyberTrust Root certificate, which is already included in NSS:
> https://bugzilla.mozilla.org/show_bug.cgi?id=430698
> The following action items are requested of Verizon before proceeding
> with this request:
> 1) Add information about their validation procedures for code signing
> applicants to their CPS, and subject that assertion to a WebTrust CA
> audit. Would this be sufficient to enable the Code Signing trust bit?
> Or would Verizon first need to issue the Code Signing intermediate CA
> from this root and get it audited?
> 2) Have a WebTrust EV Readiness audit performed on this root.
> 3) Provide evidence of the WebTrust audits that have been performed on
> the third-parties who operate sub-CAs of this root. Since the names of
> the sub-CAs are considered confidential to Verizon, perhaps a third-
> party auditor can provide a statement that the WebTrust audits of the
> third-parties have been reviewed, and that the sub-CAs meet the
> requirements of section 7 of the Mozilla CA Certificate Policy?
If the root is enabled as EV, would this imply that the sub-CAs could
enable as EV?
iang
Ian G
> What is the root without issuance? Can we base this request on my assertion
> that our business will be status quo the day we move to it? Does anyone
> have evidence that I would suddenly shift practice radically on that day?
I personally am sympathetic on this point, although it is somewhat
vexing. It may be one of these areas where audit proves its utility and
inutility all in one go.
> Don't we certainly have recourse if I do something that absurd?
Do we? I'm curious on this point. It has been shown abundantly that we
don't in the past. What do you have in mind?
> I don't understand the risk this root presents that we are mitigating. You
> either have a basis to trust my business practices or you don't. If you
> don't, I'm going to listen to you and improve. I humbly submit that we are
> already a trusted member of this community.
>
> All I can ask at this point is that if the Foundation's policy allows our
> current practice to be extrapolated forward regardless of the root in use,
In principle, this is the practice. You get through one policy review
and are accepted until the end of time. It isn't written up like this
so I don't think it is fair to say that it is policy.
> we should be granted the right to have the Baltimore CyberTrust Root enabled
> for EV. If the policy does not, I would be well served by an explanation of
> the risk such a policy limitation prevents in our case.
I suspect the question is more of a bureaucratic one. EV says that you
have to have an EV audit over the root. If that's what EV says, then
that's what it is. It is their product. Once you get that, you are
golden. Which also means that once you have the audit, it isn't up to
us to double-guess the results ... and be someone else's unpaid policeman.
At least, those are my thoughts. Rushed reply, no non-repudiation on
this one!
iang
Nelson Bolyard
> (My apologies for not making comments on this thread previously.)
>
> Nelson Bolyard wrote:
>> I'm willing to believe that there are many mobile devices whose present
>> software (which is not Mozilla client software) cannot handle larger key
>> sizes. But I am not convinced that this is of much relevance to Mozilla's
>> decision to EV enable this root.
>
> Nelson, how does this square with your comments in bug 420760? This
> would seem at first glance to be a similar case.
My comments in bug 420760 are more recent than those quoted above (I
think). I did not understand the problem thoroughly when I wrote the
comments quoted above. My statements quoted below still reflect my
current thinking.
Kathleen Wilson
moving forward.
Verizon was OK with not EV-enabling the GTE CyberTrust Global Root. So
I propose to close bug #430694 as won’t fix.
There does not seem to be any issue with Verizon’s request to include
and EV-enable the Cybertrust Global Root as per bug #430700.
Therefore, I plan to proceed with making the recommendation for
approval.
Verizon would like the Baltimore CyberTrust Root (bug #430698) to be
enabled for EV and Code-Signing. However, both the management
assertion and the audit findings specifically state that the EV audit
is for the Cybertrust Global Root: https://cybertrust.omniroot.com/repository/WT_EV_2008_SealFile.pdf
And both the management assertion and the audit finding specifically
state that the WebTrust CA audit is for the GTE CyberTrust Global Root
CA and Cybertrust Global Root CA: https://cert.webtrust.org/SealFile?seal=799&file=pdf
Verizon wants to have their Baltimore CyberTrust Root enabled for Code
Signing and EV while the root is still long-term vaulted. However
another approach could be that Verizon start operation of this root
for test and audit purposes.
I believe that the current discussion may be closed, and the action
items for Verizon in regards to bug #430698 are as follows. When these
action items are complete, this request may proceed directly to the
second round of discussion.
1) Issue the sub-CA that will have Code Signing certs, and issue a
test cert. Add information about their validation procedures for code
signing applicants to their CPS, and subject that assertion to a
WebTrust CA audit.
2) Have a WebTrust EV Readiness audit performed on this root. This, of
course, will include creating the sub-CA that will issue EV-SSL certs,
issuing a test EV-SSL cert, and having a point-in-time readiness audit
for EV.
3) We will also need a test website whose EV-SSL cert chains up to
this root.
4) Provide evidence of the WebTrust audits that have been performed on
the third-parties who will operate sub-CAs under this root. Since the
names of the sub-CAs are considered confidential to Verizon, perhaps a
third- party auditor can provide a statement that the WebTrust audits
of the third-parties have been reviewed, and that the sub-CAs meet the
requirements of section 7 of the Mozilla CA Certificate Policy?
Thanks,
Kathleen
Eddy Nigg
> 4) Provide evidence of the WebTrust audits that have been performed on
> the third-parties who will operate sub-CAs under this root. Since the
> names of the sub-CAs are considered confidential to Verizon, perhaps a
> third- party auditor can provide a statement that the WebTrust audits
> of the third-parties have been reviewed, and that the sub-CAs meet the
> requirements of section 7 of the Mozilla CA Certificate Policy?
>
By coincident I happened to come across one sub ordinate CA called
"InfoCert Certification Authority" from Italy. Apparently their
certificates can't be currently used with Firefox because of an invalid
OCSP signing certificate in OCSP response. I suggest to clarify and make
sure that the OCSP responders of subCAs are compliant when including the
OCSP URI in the AIA extension with end-user certificates.
Site tested: https://www.infocert.it/
Frank Hecker
> This discussion seems to have stalled, so here is my proposal for
> moving forward.
Thanks for making a concrete proposal on this; my comments are below.
> Verizon was OK with not EV-enabling the GTE CyberTrust Global Root. So
> I propose to close bug #430694 as won�t fix.
OK.
> There does not seem to be any issue with Verizon�s request to include
> and EV-enable the Cybertrust Global Root as per bug #430700.
> Therefore, I plan to proceed with making the recommendation for
> approval.
OK.
> Verizon would like the Baltimore CyberTrust Root (bug #430698) to be
> enabled for EV and Code-Signing. However, both the management
> assertion and the audit findings specifically state that the EV audit
> is for the Cybertrust Global Root: https://cybertrust.omniroot.com/repository/WT_EV_2008_SealFile.pdf
> And both the management assertion and the audit finding specifically
> state that the WebTrust CA audit is for the GTE CyberTrust Global Root
> CA and Cybertrust Global Root CA: https://cert.webtrust.org/SealFile?seal=799&file=pdf
Yes, and this concerns me. I'd prefer to postpone EV-enabling the
Baltimore CyberTrust root unless someone can demonstrate to me that
enabling it would be consistent with our past practices and with the
intent of the EV Guidelines and the CAB Forum. I understand
Verizon/CyberTrust's position on operational procedures being shared
across roots, but at present I'd prefer to take a conservative approach,
especially since we're dealing with EV.
> Verizon wants to have their Baltimore CyberTrust Root enabled for Code
> Signing and EV while the root is still long-term vaulted. However
> another approach could be that Verizon start operation of this root
> for test and audit purposes.
>
> I believe that the current discussion may be closed, and the action
> items for Verizon in regards to bug #430698 are as follows. When these
> action items are complete, this request may proceed directly to the
> second round of discussion.
> 1) Issue the sub-CA that will have Code Signing certs, and issue a
> test cert. Add information about their validation procedures for code
> signing applicants to their CPS, and subject that assertion to a
> WebTrust CA audit.
Forgive my poor memory here: Is there any existing WebTrust audit that
references either this root or issuance of code signing certs in
general? See also my comments below.
> 2) Have a WebTrust EV Readiness audit performed on this root. This, of
> course, will include creating the sub-CA that will issue EV-SSL certs,
> issuing a test EV-SSL cert, and having a point-in-time readiness audit
> for EV.
I agree that a WebTrust EV readiness audit would be appropriate here. As
we've noted before, a readiness audit by definition does not require
Verizon/CyberTrust to accumulate any operational history of actual
issuance to subscribers.
However, how does this interact with the basic WebTrust for CAs audit? I
can't remember if there's an equivalent WebTrust for CAs audit type that
could be done in the short term without requiring a lengthy period of
operation history.
> 3) We will also need a test website whose EV-SSL cert chains up to
> this root.
OK.
> 4) Provide evidence of the WebTrust audits that have been performed on
> the third-parties who will operate sub-CAs under this root. Since the
> names of the sub-CAs are considered confidential to Verizon, perhaps a
> third- party auditor can provide a statement that the WebTrust audits
> of the third-parties have been reviewed, and that the sub-CAs meet the
> requirements of section 7 of the Mozilla CA Certificate Policy?
This sounds reasonable as a proposal. However I'll note that this is the
item for which we have the fewest general precedents in a Mozilla
context, in terms of deciding exactly what is acceptable. Realistically
I'm more concerned with the EV aspects here, and (unless I'm missing
something) these subordinates aren't going to be issuing EV certs.
Frank Hecker
> On 04/30/2009 11:27 PM, Frank Hecker:
>> Correct, for the most part. Before I expand on this point, full
>> disclosure: I am in fact myself a Verizon ISP customer, and have
>> published complimentary comments about Verizon's FiOS service.
>
> Where? :-)
Where have I published favorable comments about Verizon's FIOS service?
Mainly in blog comments and tweets.
Frank Hecker
> I think we wouldn't add a version one 1024 bit with MD5 root these days,
> but I guess it doesn't make sense to actually yank a root because of
> that (and we haven't done so for other CAs either with similar roots
> during reviews of legacy roots). But you've touched the same subject at
> a different comment when replying to Nelson. Is there a basis for
> creating a rule and target date to stop supporting such and similar roots?
We've discussed before the general issue of transitioning away from
1024-bit roots, but never came to any firm conclusions. We should start
a new thread on this topic if we want to discuss it again.
Medin, Steven
Baltimore CyberTrust Root. Please leave the Bugzilla open so we can report
against it and provide the auditor's documents once complete.
Thank you all for your time and attention.
Kind regards,
Steven Medin
Product Manager, Identity and Access Management
Verizon Business Security Solutions Powered by Cybertrust
-----Original Message-----
From:
dev-security-policy-bounces+steve.medin=verizonbu...@lists.mozilla.or
g
[mailto:dev-security-policy-bounces+steve.medin=verizonbu...@lists.mo
zilla.org] On Behalf Of Frank Hecker
Sent: Tuesday, May 12, 2009 11:31 AM
To: dev-secur...@lists.mozilla.org
Subject: Re: Verizon Root Inclusion and EV-enablement Request
Kathleen Wilson wrote:
> This discussion seems to have stalled, so here is my proposal for
> moving forward.
Thanks for making a concrete proposal on this; my comments are below.
> Verizon was OK with not EV-enabling the GTE CyberTrust Global Root. So
> I propose to close bug #430694 as won't fix.
OK.
> There does not seem to be any issue with Verizon's request to include
OK.
OK.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Eddy Nigg
>
> This sounds reasonable as a proposal. However I'll note that this is
> the item for which we have the fewest general precedents in a Mozilla
> context, in terms of deciding exactly what is acceptable.
I think this is a special case here for various reasons. First of all,
with approving this CA, Mozilla is approving another 35 CAs apparently
located in various different countries with various different practices
about which Mozilla knows NOTHING about them. Mozilla doesn't even know
who those CAs are... CAs included into the browser by proxy without
having to comply to the Mozilla CA policy was addressed previously -
also in the problematic practices.
Just consider the minor issue I just happen to come across today with
the Infocert CA. A different CA which applied directly for inclusion had
to fix their OCSP responder issues before being approved for inclusion.
Why should another CA be any different? Now how Mozilla can judge the
risk it takes and be assured concerning the other 35 CAs without any
additional attestations and assurances and without having the chance to
evaluate the risk it's going to take?
In this respect I think Kathleen's proposal is realistically the minimum
Mozilla should request. Or have them disclosed properly which I'm
certain most would prefer here.
> Realistically I'm more concerned with the EV aspects here, and (unless
> I'm missing something) these subordinates aren't going to be issuing
> EV certs.
>
Nothing prevents Verizon to let intermediate external CAs issue EV
certificates, however the annual audit must cover the full
infrastructure including those subordinate CAs.
Kathleen Wilson
your feedback. Your time and commitment to this process is greatly
appreciated!
Verizon is OK with not EV-enabling the GTE CyberTrust Global Root, so
I have closed the following bug as won’t fix:
https://bugzilla.mozilla.org/show_bug.cgi?id=430694
There does not seem to be any issue with Verizon’s request to include
and EV-enable the Cybertrust Global Root, so I have posted my
recommendation for approval in the bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=430700
Verizon would like the Baltimore CyberTrust Root to be enabled for EV
and Code-Signing. However, some concerns remain open, so I have
summarized the requested action items in the bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=430698
This concludes the first comment period for these requests from
Verizon. If you have further comments, please post them directly into
the corresponding bug as per the list above.
Thanks,
Kathleen