Full Listing of Included CAs
Kathleen Wilson
that are Builtin Object Tokens. It is posted at:
https://wiki.mozilla.org/CA:Overview
which has a link called "List of included root certificates" which
points to
https://wiki.mozilla.org/images/c/ce/BuiltIn-CAs.pdf
I look forward to feedback and recommendations on this.
Kathleen
Kyle Hamilton
root does not have a bug number associated with it, it is a "legacy"
root (one that was inherited from Netscape/AOL)? If so, this is an
even more useful list so that we can see which roots need additional
examination. :)
-Kyle H
On Mon, Jun 22, 2009 at 2:51 PM, Kathleen Wilson<kathle...@yahoo.com> wrote:
>> Is there an updated request in the queue for O=ABC.ECOM, INC?
>> That one expires 7/9/2009, which is less than a month from now.
>
> I cannot find a request regarding ABA.ECOM in Bugzilla.
>
>> Could I suggest that you also send a copy of this message
>> (including URLs) to dev-security-policy?
>
> Done
>
> Thanks,
> Kathleen
> --
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
Kyle Hamilton
-Kyle H
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
Kathleen Wilson
> root does not have a bug number associated with it, it is a "legacy"
> root (one that was inherited from Netscape/AOL)?
I think I would also need to scan through Bugzilla for each root, in
order to be able to say the list of authorization bugs is complete. I
only went through the included/index.xml page to get the current
numbers, so it may not be complete.
I can put that on my list of things to do, though I may not get to it
for a couple of weeks.
I'm glad that the list is useful.
Kathleen
David E. Ross
Thank you. I asked for such a listing a few years ago.
I would appreciate, however, if it were in the form of a Web page. Then
(1) it might be a smaller download and (2) the bug links would work.
Also, dates should be expressed in non-ambiguous formats. For the
second entry, is 7/9/2009 9 July 2009 or 7 September 2009? Yes, I know
that the other entries impliy the former; but all-digit dates are really
not good.
I notice that two "legacy" root certificates in the list expire this
year, one in less than three weeks. Three more expire next year. They
all have all three trust bits set, so removal might not be appropriate.
However, they do make a strong case for a formal policy on how to
handle expired certificates.
--
David E. Ross
<http://www.rossde.com/>
Go to Mozdev at <http://www.mozdev.org/> for quick access to
extensions for Firefox, Thunderbird, SeaMonkey, and other
Mozilla-related applications. You can access Mozdev much
more quickly than you can Mozilla Add-Ons.
Kathleen Wilson
> (1) it might be a smaller download and (2) the bug links would work.
Yes, putting the data into XML form is on my to-do list, but I won't
get to it for a few weeks.
> Also, dates should be expressed in non-ambiguous formats. For the
> second entry, is 7/9/2009 9 July 2009 or 7 September 2009? Yes, I know
> that the other entries impliy the former; but all-digit dates are really
> not good.
Will do in next version.
> I notice that two "legacy" root certificates in the list expire this
> year, one in less than three weeks. Three more expire next year. They
> all have all three trust bits set, so removal might not be appropriate.
> However, they do make a strong case for a formal policy on how to
> handle expired certificates.
Yes, it looks like there is a need to have a policy for handling
expiring and expired CAs.
Nelson Bolyard
>> https://wiki.mozilla.org/images/c/ce/BuiltIn-CAs.pdf
> Am I correct in inferring that to the best of your knowledge, if a root
> does not have a bug number associated with it, it is a "legacy" root (one
> that was inherited from Netscape/AOL)?
I don't think so. According to
https://bugzilla.mozilla.org/show_bug.cgi?id=233453#c12
Mozilla's Root CA cert policy went into effect in January 2006.
The full chronology of the additions of certificates to the list since NSS
version 3.0 in March 2000 is shown in
http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/security/nss/lib/ckfw/builtins/certdata.txt&mark=1.38
I believe that all the certs added beginning with revision 1.38 (and all
later revisions) were added according to the Mozilla policy and process.
Some of the certificates added since then do not appear to have bug numbers
in the pdf file cited above. For example, NetLock's "Class QA" cert was
added in revision 1.39 in June 2006 per bug 313942, but no bug number
appears beside that cert in the pdf file.
> If so, this is an even more useful list so that we can see which roots
> need additional examination. :)
I think more work is needed to populate the table with all the relevant
bug numbers. Fortunately, the bonsai page shown above should be a great
starting place to find all the missing bug numbers.
Frank Hecker
> On 2009-06-22 15:10 PDT, Kyle Hamilton wrote:
>> Am I correct in inferring that to the best of your knowledge, if a root
>> does not have a bug number associated with it, it is a "legacy" root (one
>> that was inherited from Netscape/AOL)?
>
> I don't think so. According to
> https://bugzilla.mozilla.org/show_bug.cgi?id=233453#c12
> Mozilla's Root CA cert policy went into effect in January 2006.
To expand on this point: For some amount of time before the official
Mozilla CA policy went into effect, I was approving CA requests based on
an informal policy roughly equivalent to what Microsoft was doing at the
time in terms of "WebTrust or equivalent" audits. Some at least of those
approvals would have had Bugzilla bug numbers associated with them.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Kathleen Wilson
the approval bug numbers, and to make the dates less ambiguous.
https://wiki.mozilla.org/images/c/ce/BuiltIn-CAs.pdf
Within the document, the Approval Bug # column shows the bug number in
which approval was achieved based on the Mozilla CA Policy.
- Bug numbers that are underlined were found in the pending/index.xml
page.
- Bug numbers that are not underlined were found by going through the
CVS Log of security/nss/lib/ckfw/builtins/certdata.txt, and reviewing
the content of the bugs to verify that the root was approved for
inclusion.
- “Legacy” means that I could not find any evidence in either Bugzilla
or the CVS Log that indicated that the root was approved via the
Mozilla CA Policy.
- “In Process” or “Reviewed” means that the root has undergone a
recent review (e.g. for enablement of an additional trust bit or of
EV) that has verified that the root follows the Mozilla CA Policy.
Note: Putting the data into XML form is on my to-do list…
Kathleen
Nelson Bolyard
> I have updated the BuiltIn CAs table based on further research into
> the approval bug numbers, and to make the dates less ambiguous.
>
> https://wiki.mozilla.org/images/c/ce/BuiltIn-CAs.pdf
Thanks, Kathleen. Looks like great work!
Kathleen Wilson
http://www.mozilla.org/projects/security/certs/BuiltIn-CAs/
I look forward to feedback on this.
For now I am keeping this project separate from the existing included
page at
http://www.mozilla.org/projects/security/certs/included/
At some point, it may make sense to converge both lists into one
format. That’ll depend on several factors, so it’s easier to keep the
BuiltIn-CAs list separate for now.
Kathleen
Eddy Nigg
> As requested, I have put the BuiltIn-CAs list into XML:
> http://www.mozilla.org/projects/security/certs/BuiltIn-CAs/
>
> I look forward to feedback on this.
>
Yuhuuuu! Fantastic! Terrific! You are the best!
(Is this the kind of feedback you wanted? ;-) )
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org
Varga Viktor
Myabe it shoudl be included in green?
Maybe this is the cause, why we should wait so long? :)
Üdvözlettel:
Varga Viktor
üzemeltetési és vevőszolgálati vezető
Netlock Kft.
--
Regards
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________________________________
Ezt az e-mailt virus- es SPAM-szuresnek vetettuk ala a filter:mail MessageLabs rendszerrel. Tovabbi informacio: http://www.filtermax.hu
This email has been scanned for viruses and SPAM by the filter:mail MessageLabs System. More information: http://www.filtermax.hu ________________________________________________________________________
_______________________________________________________________________
Ezt az e-mailt virus- es SPAM-szuresnek vetettuk ala a filter:mail MessageLabs rendszerrel. Tovabbi informacio: http://www.filtermax.hu
This email has been scanned for viruses and SPAM by the filter:mail MessageLabs System. More information: http://www.filtermax.hu ________________________________________________________________________________________
Kathleen Wilson
The inclusion request for this root is in
https://bugzilla.mozilla.org/show_bug.cgi?id=480966
The request is in the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
> Maybe this is the cause, why we should wait so long? :)
There was backlog in the queue for public discussion, and there were a
few discussions that took longer than the goal of one to two weeks.
Varga Viktor
It was just some kind of joke, to ask this, I am waiting.
regards:
Varga Viktor
it service and customers service executive
-----Original Message-----
From: dev-security-policy-bounces+varga_v=netlo...@lists.mozilla.org [mailto:dev-security-policy-bounces+varga_v=netlo...@lists.mozilla.org] On Behalf Of Kathleen Wilson
Sent: Thursday, September 17, 2009 10:45 PM
To: dev-secur...@lists.mozilla.org
Subject: Re: Full Listing of Included CAs
_______________________________________________
Ian G
> Yes, I follow the process, and i know, my estimations to get in are gone, with these long discusions.
>
> It was just some kind of joke, to ask this, I am waiting.
I sympathise. Last I heard it was a 40 week delay. To my mind that is
totally unacceptable. But I'm not sure I can offer any solutions.
I would't want a 1 week discussion period overage to slow down the next
or the others. I hope that's not happening?
iang
Eddy Nigg
> On 25/09/2009 19:07, Varga Viktor wrote:
>> Yes, I follow the process, and i know, my estimations to get in are
>> gone, with these long discusions.
>>
>> It was just some kind of joke, to ask this, I am waiting.
>
>
> I sympathise. Last I heard it was a 40 week delay. To my mind that
> is totally unacceptable. But I'm not sure I can offer any solutions.
40 weeks delay from which point? But I agree, it takes at times way too
long, in previous years for no apparent reason. Today we clearly have
many requests, but also are working on it, specially with the fantastic
work of Kathleen. I think we've improved a lot.
For the combined requests of Verisign, GeoTrust and Thawte it took us
some 6-7 weeks. Considering the size and importance of these requests,
but also the issues which did come up, I think that's acceptable IMO. We
could have shelved a week here or there, but it also depends on the
responses from the CA and so forth. I don't think it took a bit longer
because anybody is dragging their feet. Hope I'm not wrong with that
impression.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Varga Viktor
> > is totally unacceptable. But I'm not sure I can offer any solutions.
>
> 40 weeks delay from which point? But I agree, it takes at times way too
> long, in previous years for no apparent reason. Today we clearly have
> many requests, but also are working on it, specially with the fantastic
> work of Kathleen. I think we've improved a lot.
>
> For the combined requests of Verisign, GeoTrust and Thawte it took us
> some 6-7 weeks. Considering the size and importance of these requests,
> but also the issues which did come up, I think that's acceptable IMO.
> We
> could have shelved a week here or there, but it also depends on the
> responses from the CA and so forth. I don't think it took a bit longer
> because anybody is dragging their feet. Hope I'm not wrong with that
> impression.
I think, they should response as fast as they can. I am daily monitoring this list to answer the questions regarding to my company. :)
Now I know, why the Verisign has so large market share. :)
They have 7 weeks advantage before the others, because of their slow answer rate. :)
best regards.
Viktor Varga
Netlock.
Ian G
> On 09/26/2009 02:40 AM, Ian G:
>> I sympathise. Last I heard it was a 40 week delay. To my mind that is
>> totally unacceptable. But I'm not sure I can offer any solutions.
...
Is there any reason why they need to be done in series? Why can't they
be done in parallel?
E.g., if they were done 8 at a time, and given a 4 week comment period
each, we'd finish them twice as fast, and 40 weeks would become 20 weeks ...
Just speculating here...
iang
Varga Viktor
Next time he/she will be faster. :)
regards:
Varga Viktor
üzemeltetési és vevőszolgálati vezető
Netlock Kft.
> -----Original Message-----
> From: dev-security-policy-bounces+varga_v=netlo...@lists.mozilla.org
> [mailto:dev-security-policy-
> bounces+varga_v=netlo...@lists.mozilla.org] On Behalf Of Ian G
> Sent: Monday, September 28, 2009 5:00 PM
> Cc: dev-secur...@lists.mozilla.org
> Subject: Re: Full Listing of Included CAs
>
>
> > On 09/26/2009 02:40 AM, Ian G:
>
> >> I sympathise. Last I heard it was a 40 week delay. To my mind that
> is
> >> totally unacceptable. But I'm not sure I can offer any solutions.
> ...
>
>
> Is there any reason why they need to be done in series? Why can't they
> be done in parallel?
>
> E.g., if they were done 8 at a time, and given a 4 week comment period
> each, we'd finish them twice as fast, and 40 weeks would become 20
> weeks ...
>
> Just speculating here...
>
>
> iang
Ian G
> Or if somebody miss the week, drop it at the end of the list. :)
>
> Next time he/she will be faster. :)
The other possibility is to levy a fee. Say it's 1000. That makes for
52k per year. Probably enough to employ someone to help :)
iang
Kathleen Wilson
> be done in parallel?
>
> E.g., if they were done 8 at a time, and given a 4 week comment period
> each, we'd finish them twice as fast, and 40 weeks would become 20 weeks ...
The review and discussion of inclusion requests is done by volunteers
who are very busy with their paying jobs. Their time is greatly
appreciated!
I work on gathering information for multiple inclusion requests
(includes reviewing CP, CPS, audits, etc) at the same time, and I find
that it is difficult to switch context between the different requests.
I have to be meticulous in tracking the information so that I don't
get information confused between requests. Therefore, I try not to
overload the volunteers by asking them to review multiple requests at
the same time (unless there is a request up for a second-round of
discussion).
Eddy Nigg
>
>> On 09/26/2009 02:40 AM, Ian G:
>
>>> I sympathise. Last I heard it was a 40 week delay. To my mind that is
>>> totally unacceptable. But I'm not sure I can offer any solutions.
>
>
> Is there any reason why they need to be done in series? Why can't
> they be done in parallel?
>
> E.g., if they were done 8 at a time, and given a 4 week comment period
> each, we'd finish them twice as fast, and 40 weeks would become 20
> weeks ...
>
Yeah...and if you would start to review some CAs ina serious manner,
perhaps others could put down some of their load. Perhaps that would
make it a bit faster too.
Ian G
> The review and discussion of inclusion requests is done by volunteers
> who are very busy with their paying jobs. Their time is greatly
> appreciated!
Yes it is difficult. Question is ... how to get more people interested
1. And to get the right people? There is no point in just attracting
attention. The questions that are asked are deep and complicated.
2. CAs themselves are conflicted in several ways. Firstly, they just
want a result, they don't care about the process. Secondly, there is a
code of conduct in business that one never criticises a competitor,
because it looks bad, "unprofessional". Thirldy, mentioning a
competitor has an unfortunate effect of potentially endorsing its existance.
This all is unfortunate because the CAs have some knowledge in this area.
3. I wonder if there could be some reward system? Maybe those people
who commented ... could trade their good comments in for higher places
on the list? Just a thought?
> I work on gathering information for multiple inclusion requests
> (includes reviewing CP, CPS, audits, etc) at the same time, and I find
> that it is difficult to switch context between the different requests.
> I have to be meticulous in tracking the information so that I don't
> get information confused between requests.
OK, I understand this!
> Therefore, I try not to
> overload the volunteers by asking them to review multiple requests at
> the same time (unless there is a request up for a second-round of
> discussion).
It's not an issue for me, I generally use the threading capabilities of
the mailer (tb) to manage it. At the same time as a review is going on,
a dozen other things are too, without threading, we really would be
stuck with serial analysis. (But I understand we have different
perspectives.)
Another thing I'd be really interested in is speeding up the distro
process. Last I heard it was something like approximately quarterly.
So another 13 weeks delay? Once a decision is made, the update I
believe should be done in a week.
We have the tech. We have the developers. We have the need. Perhaps
the design is lacking ... but a good design starts with a real need? We
really need to update the root list quickly, and cost-effectively. For
this and other reasons, as discussed in another thread.........
(Sorry, I'm not offering to code this one :)
iang
Eddy Nigg
> Another thing I'd be really interested in is speeding up the distro
> process. Last I heard it was something like approximately quarterly.
> So another 13 weeks delay? Once a decision is made, the update I
> believe should be done in a week.
>
> We have the tech. We have the developers. We have the need. Perhaps
> the design is lacking ... but a good design starts with a real need?
> We really need to update the root list quickly, and cost-effectively.
> For this and other reasons, as discussed in another thread.........
Just FYK, other software vendors have 3-4 month release cycles,
sometimes longer. Apparently there is so much one can do, I think
Mozilla is in this respect quite good. But improvements are always
welcome when possible obviously.
Varga Viktor
regards:
Varga Viktor
> -----Original Message-----
> From: dev-security-policy-bounces+varga_v=netlo...@lists.mozilla.org
> [mailto:dev-security-policy-
> bounces+varga_v=netlo...@lists.mozilla.org] On Behalf Of Eddy Nigg
> Sent: Tuesday, September 29, 2009 12:52 AM
> To: dev-secur...@lists.mozilla.org
> Subject: Re: Full Listing of Included CAs
>
M.Hunstock
> I sympathise. Last I heard it was a 40 week delay.
"Deutsche Telekom Root CA 2" took almost 5 years to be included, so
don't talk about weeks
;)
greets
Varga Viktor
Did they quick email replies? :)
Viktor