Re: Certigna Root Inclusion Request Round 2
Many thanks to those of you who have participated in the discussions for this root inclusion request, and reviewed the information that has been provided. Certigna met the request from the first round of public discussion to post and translate the relevant portions of their CPS. During the discussions two items have been requested: 1) The public portion of the Certigna CPS should be made public and posted on their website. 2) The internal document for code signing should be made part of the CPS. While Certigna is encouraged to do these two action items, these will not block the inclusion request. This concludes the public discussions about Certigna’s request to add one new root CA certificate to the Mozilla root store, as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=393166 I will post a summary of the request and my recommendation for approval in the bug. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request Round 2
Certigna met our request to post and translate the relevant portions of their CPS. There has been very little resulting discussion. Are there still questions that need to be addressed in this public discussion phase? Or shall I move forward with making the recommendation to approve this request? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request Round 2
On 03/13/2009 07:34 PM, Kathleen Wilson: Certigna met our request to post and translate the relevant portions of their CPS. There has been very little resulting discussion. Are there still questions that need to be addressed in this public discussion phase? Or shall I move forward with making the recommendation to approve this request? The internal document for code signing should have been made part of the CP/CPS. Apart from that I've not seen anything of concern. Unfortunately my knowledge in the French language is not sufficient enough in order to understand the CPS. Preferable we should be able to review (and understand) the CPS in its entirety, however I don't feel this to be a reason at this stage to question their inclusion after they complied to our requests from the first round. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request Round 2
On 03/03/2009 11:35 PM, kathleen95...@yahoo.com: The relevant, public portion of their CPS has been attached to the bug: https://bugzilla.mozilla.org/attachment.cgi?id=364343 Translations of portions of this document have also been attached to the bug: https://bugzilla.mozilla.org/attachment.cgi?id=364146 As a by-note I'd like to state that that ETSI 101 456 and ETSI TS 102 042 speak very clearly about The CA shall make available to subscribers and relying parties its certification practice statement, and other relevant documentation, as necessary to assess conformance to the qualified certificate policy. As such Certigna is not complying to the audit criteria it chose! -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request Round 2
On 10/3/09 09:22, Eddy Nigg wrote: On 03/03/2009 11:35 PM, kathleen95...@yahoo.com: Kathleen, are we planning to move the discussions of accepting CAs into the root list over to the other list? I think that dev-security-policy is going now? iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request Round 2
are we planning to move the discussions of accepting CAs into the root list over to the other list? I think that dev-security-policy is going now? OK. If no one objects, I will post all future root inclusion request discussions on mozilla.dev.security.policy instead of dev.tech.crypto. Kathleen -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request Round 2
I second this motion, no objections. -Kyle H On Tue, Mar 10, 2009 at 10:48 AM, Kathleen Wilson kathleen95...@yahoo.com wrote: are we planning to move the discussions of accepting CAs into the root list over to the other list? I think that dev-security-policy is going now? OK. If no one objects, I will post all future root inclusion request discussions on mozilla.dev.security.policy instead of dev.tech.crypto. Kathleen -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request Round 2
Kyle Hamilton wrote, On 2009-03-10 14:14: I second this motion, no objections. -Kyle H On Tue, Mar 10, 2009 at 10:48 AM, Kathleen Wilson kathleen95...@yahoo.com wrote: are we planning to move the discussions of accepting CAs into the root list over to the other list? I think that dev-security-policy is going now? OK. If no one objects, I will post all future root inclusion request discussions on mozilla.dev.security.policy instead of dev.tech.crypto. Kathleen Me too. I'll bet there are some web pages that need to be updated to point to the new list instead of the crypto list. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request Round 2
On Tue, Mar 3, 2009 at 1:35 PM, kathleen95...@yahoo.com wrote: Email: CPS section 5.2.6 specifies the controls for applications for the Certigna ID certificates. It says that in addition to verifying the identity of the applicant, they check the email address as follows as per the supplied translation: “On left part of the email address, we have to found, in a non equivoque form, the name and the first name of the future bearer. In the opposite case, and in case of a doubt on the intention of usurpation, it is important to report that at the security responsible who will defined the actions to make (exhaustive check of the order, reject or acceptation). On the right part of the email address is located the name of the web site of the entity or the name of a FAI (and name of another entity).” I'll be so bold as to try to translate this into better English (this is obviously NOT to be considered authoritative): The left-hand side of the email address must contain both the first and last name of the person in order to pass the automatic issuance procedure [[NB: this is due to the word 'and' in the translation; I would assume that it should actually be an 'or', and the email address has to at least be the last name of the subscriber]]. If the left-hand side of the email address does not contain the first and[or] last name of the person, then it gets passed up the line for manual review. [[NB: the mechanism for manual review is not defined, but allows for a more exhaustive verification, automatic denial (such as 'georgewb...@thisisnottheofficialbushdomain.com', I presume), or immediate acceptance (under some unknown criteria).]] On the right-hand side (sitename) part of the email address must be either the name of the web site [[NB: this suggests that it must be, for example, 'hec...@www.mozillafoundation.org' instead of 'hec...@mozillafoundation.org']], or the name of a [[??What is an FAI??]] and another entity. [[NB: presumably 'gmail.com' would be the 'name of another entity', but I'm still unable to parse this sentence.]] To Certigna: I am very sorry if I have mangled the meaning of your CPS through the apparently-automated translation. This begins phase 2 of the public discussion of the request from Certigna to add the Certigna CA root certificate to Mozilla. Thank you, Kathleen. (And thank you, Frank, for getting Mozilla to hire her. :)) -Kyle H -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
Le 14 févr. 09 à 15:09, Frank Hecker a écrit : Yannick LEPLARD wrote: Another alternative is to publish just those portions of the CPS that address the question of email verification, and have your auditor confirm to us that the section(s) in question are from the CPS that was referenced in your audit. Frank This is a good alternative for us. If everybody agree with, we can send you the fair portion of CPS in english and our auditor will confirm you the genuineness of the document. To repeat what I wrote elsewhere: This plan is acceptable to us. Fran We are working on the translation and we make contact with the auditor. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
Yannick LEPLARD wrote: Another alternative is to publish just those portions of the CPS that address the question of email verification, and have your auditor confirm to us that the section(s) in question are from the CPS that was referenced in your audit. Frank This is a good alternative for us. If everybody agree with, we can send you the fair portion of CPS in english and our auditor will confirm you the genuineness of the document. To repeat what I wrote elsewhere: This plan is acceptable to us. Fran -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
First of all, i would like to express my astonishment about the discussion phase. It sounds like Mozilla's discussion how to evaluate the CAs / changes to do in the benchmarks rather than a Certigna discussion. We asked for inclusion in Mozilla on 2007 (august). Mozilla agrees with ETSI 102 042 (like Apple and Microsoft. We are in these two systems). There was a long technical verification phase made by three people : Gervase Markham, Frank Hecker, and Kathleen Wilson. And now, it seems to be a reconsideration of ETSI 102 042. About CP /CPS : I think a public CP and a audit of compliance with a reference norm (like ETSI, WebTrust, ... ) provide garantees to third party. CPS and other internal documents are checked by auditors (and they control that the company do what is written !). They contain know-how of the company (technical and organizational measurements), and don't have to be published. Yannick LEPLARD Directeur RD 20, allée de la râperie 59650 Villeneuve d'Ascq tél. : 03 20 79 24 09 fax. : 03 20 34 20 52 www.dhimyotis.fr -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
On 02/12/2009 12:31 PM, Yannick LEPLARD: First of all, i would like to express my astonishment about the discussion phase. It sounds like Mozilla's discussion how to evaluate the CAs / changes to do in the benchmarks rather than a Certigna discussion. Yes, unfortunately we make the mistake again and again by not changing the subject line when discussing (un)related issues. However this is a discussion group as compared to Bugzilla. There was a long technical verification phase made by three people : Gervase Markham, Frank Hecker, and Kathleen Wilson. And now, it seems to be a reconsideration of ETSI 102 042. No, only Kathleen has reviewed and gathered the information about your CA. Unfortunately there was a backlog which Mozilla is now working up. The issue at hand is not the audit criteria of ETSI per se, but the disclosure of your practices. I think this is the first time that a CA wasn't willing to disclose the practice statement. About CP /CPS : I think a public CP and a audit of compliance with a reference norm (like ETSI, WebTrust, ... ) provide garantees to third party. CPS and other internal documents are checked by auditors (and they control that the company do what is written !). Right, and in order to judge what your CA is doing we would like to know about it. Please note that WebTrust requires public disclosure of the practices. They contain know-how of the company (technical and organizational measurements), and don't have to be published. Well, considering that the top 20 CAs all disclosed their practices, I can't see which know-how you are trying to protect, but if you are doing something completly different than all the others than it's perhaps reason more to know about it. Please also note that ETSI doesn't require particular validation methods upon which we can be assumed that you are compliant to the Mozilla CA policy. And I really wonder if you didn't had to disclose the CPS to Microsoft as well. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
Eddy Nigg wrote: On 02/11/2009 07:19 PM, Yannick LEPLARD: So What should we do ? Should we ask our auditor a certified document about our practices for e-mail validation ? Yannick, what are the chances to publish the CPS? Please note that all CAs which have been included into Mozilla NSS during the last few years published their CPS, this is common practice. To add to Eddy's question: If there is Certigna-confidential information in the CPS that is not relevant to the questions we have, you could publish a version of the CPS with the confidential material redacted [1]. Another alternative is to publish just those portions of the CPS that address the question of email verification, and have your auditor confirm to us that the section(s) in question are from the CPS that was referenced in your audit. Frank [1] For anyone interested, the US National Security Agency has published a useful set of guidelines for how to properly redact Microsoft Work documents published as PDF files: http://www.fas.org/sgp/othergov/dod/nsa-redact.pdf -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
Another alternative is to publish just those portions of the CPS that address the question of email verification, and have your auditor confirm to us that the section(s) in question are from the CPS that was referenced in your audit. Frank This is a good alternative for us. If everybody agree with, we can send you the fair portion of CPS in english and our auditor will confirm you the genuineness of the document. ( I think our CPS is not very different from others, but it refers to a lot of internal documents. ) Yannick LEPLARD Directeur RD 20, allée de la râperie 59650 Villeneuve d'Ascq tél. : 03 20 79 24 09 fax. : 03 20 34 20 52 www.dhimyotis.fr -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
On 02/12/2009 05:13 PM, Yannick LEPLARD: This is a good alternative for us. If everybody agree with, we can send you the fair portion of CPS in english and our auditor will confirm you the genuineness of the document. In my opinion this would solve the problem. I would like to request that the auditor confirms that their audit statement confirms the exact extracts of the CPS. I also would like to request to include all relevant bits for domain control validation in addition to email. Additionally if code signing was part of the CPS during your audit, also the bits relating to code signing. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
On 02/11/2009 06:20 AM, Frank Hecker: Ian G wrote: The policy says, we need published information, *eg* the CPS. Not, CPS must be published. Yes, exactly. We typically use the CPS and/or CP because almost all CAs publish those documents; however there is no requirement that the information published by the CA be in the form of a CPS or CP. But it must have relevance to what was audited, no? If the document wasn't an official and binding part of the audit, it shouldn't be used in this context either I think. Nor shouldn't it be provided and published after the audit was performed. Speaking personally, I think think that it is good practice for CAs to publish a CPS. If a CA has private information relating to detailed internal processes that it does not wish to make public, I suggest that it put such material in a separate CA operations manual that is internal-only. That's of course what CAs usually do. They disclose those procedures to the auditor, but not publicly. WebTrust has a defined set of criterion about what exactly needs to be disclosed publicly. In this respect I question the usefulness of the ETSI audit criteria and I suggest/recommend to make the publishing of the CPS a requirement in the Mozilla CA policy. I assumed wrongly that this is a requirement by the audit criterion which Mozilla accepts. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
Eddy Nigg wrote: Well no, than any CA can write whatever it feels in such a document which would be entirely non-binding and not audited. Yes in theory, but I'm not convinced that this is a real risk in practice. In the past we've had several cases where we've accepted public statements by CAs that went beyond what was in their CPS or CP. In some cases these were clarifications of CP/CPS langusge, in other cases they covered stuff that was not in the CP or CPS at all. In a number of cases the CAs updated (or committed to update) their CP/CPS to reflect their supplementary statements, and for purposes of our evaluation we accepted the statements in advance of their actually completing an audit against the new CPS. So, again, I'm not prepared to make a blanket statement that we must always have a published CPS and cannot rely on documents apart from the CPS. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
On 02/11/2009 04:12 PM, Frank Hecker: Yes in theory, but I'm not convinced that this is a real risk in practice. In the past we've had several cases where we've accepted public statements by CAs that went beyond what was in their CPS or CP. In some cases these were clarifications of CP/CPS langusge, in other cases they covered stuff that was not in the CP or CPS at all. Clarifications I think yes. Something which isn't in the CPS must be easily verifiable, something critical and not covered in the CPS is in my opinion not sufficient. In a number of cases the CAs updated (or committed to update) their CP/CPS to reflect their supplementary statements, and for purposes of our evaluation we accepted the statements in advance of their actually completing an audit against the new CPS. Yes, also this is in my opinion sufficient, but there are some problems. First Mozilla hasn't been on record to follow up - neither on EV nor on other matters. Second we need to draw a clear line here...I believe that CAs weren't approved generally if they couldn't demonstrate clearly through their published CPS and audit statements compliance to the Mozilla CA policy. Some CAs were sent back to the drawing board for fixing. I believe this case isn't any different. So, again, I'm not prepared to make a blanket statement that we must always have a published CPS and cannot rely on documents apart from the CPS. Yes, everything within reasons. But that should be established during information gathering and perhaps receive your approval prior to arriving here. It should be disclosed during the presentation statement at the list and such a document shouldn't be provided AFTER it gets to the comments and review week here. This clearly means, there is no audit behind it, it would be just hot air. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
On 11/2/09 05:20, Frank Hecker wrote: Ian G wrote: The policy says, we need published information, *eg* the CPS. Not, CPS must be published. Yes, exactly. We typically use the CPS and/or CP because almost all CAs publish those documents; however there is no requirement that the information published by the CA be in the form of a CPS or CP. Speaking personally, I think think that it is good practice for CAs to publish a CPS. If a CA has private information relating to detailed internal processes that it does not wish to make public, I suggest that it put such material in a separate CA operations manual that is internal-only. OK, I made some changes on the wiki and added these words: https://wiki.mozilla.org/CA:Recommended_Practices#Recommended_practices # (we rely on public documents only). # If you do not publish the CP/CPS (not recommended), you will need to publish an extract that summarizes the portions that are of most interest to us. This only reflects my understanding of the situation. Also, I recognise that the words on the wiki already almost nailed it, so we are in danger of bureaucratic freefall... Hack away... iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
On 2/10/2009 8:16 PM, Frank Hecker wrote: David E. Ross wrote: On 2/10/2009 12:06 PM, Frank Hecker wrote: If you cannot publish the CPS because it contains private information, I suggest as an alternative that you provide some sort of official Certigna document that summarizes the portions of the CPS that are of most interest to us (i.e., those relating to validation of subcriber information). snip However, not only should they provide some alternative documentation but also that documentation should be considered during the required audit. My assumption was that if the material in the document was based on the CPS then it would have been covered in the audit, since presumably the audit was based on what was in the CPS. Frank If the information is critical for determining whether a CA's root should be in the certificate store, then the document should be audited. In the case at hand, the issue is whether the root should be enabled for E-mail validation. Because that issue is addressed in the CPS, which we cannot see, we don't have any way to judge if the E-mail bit should be enabled. With an unaudited supplemental document, we would have no assurance that Certigna operates in compliance with that document. We should either see an audit statement for the supplemental document or a certification from the auditor or other trusted outside party that the document substantially echoes the audited CPS. -- David E. Ross http://www.rossde.com/. Don't ask Why is there road rage? Instead, ask Why NOT Road Rage? or Why Is There No Such Thing as Fast Enough? http://www.rossde.com/roadrage.html -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
On 2/11/2009 8:43 AM, Ian G wrote: On 11/2/09 05:20, Frank Hecker wrote: Ian G wrote: The policy says, we need published information, *eg* the CPS. Not, CPS must be published. Yes, exactly. We typically use the CPS and/or CP because almost all CAs publish those documents; however there is no requirement that the information published by the CA be in the form of a CPS or CP. Speaking personally, I think think that it is good practice for CAs to publish a CPS. If a CA has private information relating to detailed internal processes that it does not wish to make public, I suggest that it put such material in a separate CA operations manual that is internal-only. OK, I made some changes on the wiki and added these words: https://wiki.mozilla.org/CA:Recommended_Practices#Recommended_practices # (we rely on public documents only). # If you do not publish the CP/CPS (not recommended), you will need to publish an extract that summarizes the portions that are of most interest to us. This only reflects my understanding of the situation. Also, I recognise that the words on the wiki already almost nailed it, so we are in danger of bureaucratic freefall... Hack away... iang This would then tie into the later section: * CAs should supply evidence of their being evaluated according to one or more of the criteria accepted as suitable per the Mozilla policy. . . . * All documents supplied as evidence should be publicly available. However, the last sentence should be modified to say: * All documents supplied as evidence should be publicly available and must be addressed in any audit. I don't have (don't want) an account to update the Wiki. -- David E. Ross http://www.rossde.com/. Don't ask Why is there road rage? Instead, ask Why NOT Road Rage? or Why Is There No Such Thing as Fast Enough? http://www.rossde.com/roadrage.html -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
If the information is critical for determining whether a CA's root should be in the certificate store, then the document should be audited. In the case at hand, the issue is whether the root should be enabled for E-mail validation. Because that issue is addressed in the CPS, which we cannot see, we don't have any way to judge if the E-mail bit should be enabled. With an unaudited supplemental document, we would have no assurance that Certigna operates in compliance with that document. We should either see an audit statement for the supplemental document or a certification from the auditor or other trusted outside party that the document substantially echoes the audited CPS. -- So What should we do ? Should we ask our auditor a certified document about our practices for e-mail validation ? Yannick LEPLARD Directeur RD Dhimyotis S.A. 20, allée de la râperie 59650 Villeneuve d'Ascq tél. : 03 20 79 24 09 fax. : 03 20 34 20 52 www.dhimyotis.fr -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
On 02/11/2009 07:12 PM, David E. Ross: However, the last sentence should be modified to say: * All documents supplied as evidence should be publicly available and must be addressed in any audit. I don't have (don't want) an account to update the Wiki. I agree on this definition. Is there anybody objecting to it? (I can update the page accordingly). -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
On 02/11/2009 07:19 PM, Yannick LEPLARD: So What should we do ? Should we ask our auditor a certified document about our practices for e-mail validation ? Yannick, what are the chances to publish the CPS? Please note that all CAs which have been included into Mozilla NSS during the last few years published their CPS, this is common practice. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
On 11/2/09 21:29, Eddy Nigg wrote: On 02/11/2009 07:12 PM, David E. Ross: However, the last sentence should be modified to say: * All documents supplied as evidence should be publicly available and must be addressed in any audit. I don't have (don't want) an account to update the Wiki. I agree on this definition. Is there anybody objecting to it? (I can update the page accordingly). I object. All documents supplied to Mozilla is within a Mozilla context. Audit does an audit context. The two are different. Don't mix them; most all audits are done according to defined audit criteria, such as WebTrust or ETSI or DRC. Asking an auditor to sign off on random documents that have nothing to do with the criteria, the audit world and the direct process raises questions. I would claim that no (or few) auditors to date has been asked to verify a CA according to Mozilla review. If you want evidence quality documents then ask for a notary? iang PS: I for one would definately champion rewriting the WebTrust process but this is not the way to do it. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
A notary does not verify content, a notary verifies identity. What we need is an opinion (hey! using your own terminology, Ian, that means AUDIT, and thus AUDITOR) that the document substantially reflects the CP/CPS. If not an auditor, who would you suggest to do it, given that a notary isn't authoritative for opinions other than on the signer having shown identity? I think the entire CA approval process is completely FUBARed. I think Mozilla has managed to paint itself into a corner from which people like Ian will not let it escape, and has thus been bullied and intimidated into accepting things into its root program that are analytically damaging to the PKI and the pursuit of commerce to be enabled by it. I also believe that it has allowed commerce to define its operations and criteria for far too long. -Kyle H On Wed, Feb 11, 2009 at 3:37 PM, Ian G i...@iang.org wrote: On 11/2/09 21:29, Eddy Nigg wrote: On 02/11/2009 07:12 PM, David E. Ross: However, the last sentence should be modified to say: * All documents supplied as evidence should be publicly available and must be addressed in any audit. I don't have (don't want) an account to update the Wiki. I agree on this definition. Is there anybody objecting to it? (I can update the page accordingly). I object. All documents supplied to Mozilla is within a Mozilla context. Audit does an audit context. The two are different. Don't mix them; most all audits are done according to defined audit criteria, such as WebTrust or ETSI or DRC. Asking an auditor to sign off on random documents that have nothing to do with the criteria, the audit world and the direct process raises questions. I would claim that no (or few) auditors to date has been asked to verify a CA according to Mozilla review. If you want evidence quality documents then ask for a notary? iang PS: I for one would definately champion rewriting the WebTrust process but this is not the way to do it. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
On 02/12/2009 01:37 AM, Ian G: I object. OK, then back to square one. All documents supplied to Mozilla is within a Mozilla context. Huuu? Audit does an audit context. The two are different. Don't mix them; most all audits are done according to defined audit criteria, such as WebTrust or ETSI or DRC. Yes, and Mozilla relies on them, period. Asking an auditor to sign off on random documents that have nothing to do with the criteria, the audit world and the direct process raises questions. Right, that's why CAs MUST publish their CPS. I would claim that no (or few) auditors to date has been asked to verify a CA according to Mozilla review. Not Mozilla Review, but if we want to facilitate other documents beyond CSP than I have no problem accepting them if an auditor agrees to confirm those documents. It's really not our problem. If you want evidence quality documents then ask for a notary? No, what has that to do with it? PS: I for one would definately champion rewriting the WebTrust process but this is not the way to do it. PS: PS: Why not? Go for it. Talk to them. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
On 12/2/09 00:58, Kyle Hamilton wrote: A notary does not verify content, a notary verifies identity. Actually I meant a notary rather than a notary public, but the difference is moot. What we need is an opinion (hey! using your own terminology, Ian, that means AUDIT, and thus AUDITOR) that the document substantially reflects the CP/CPS. If not an auditor, who would you suggest to do it, given that a notary isn't authoritative for opinions other than on the signer having shown identity? Right, that's on the other point. It would be entirely valid to ask for the AUDITOR to attest (or otherwise) that the extract substantially or otherwise reflected the CPS, *iff* one were that concerned. (I would not be that paranoid, and I claim you will get a better system if you don't demand a priori audit opinion over this document. The ground breaking work in this was done by Rothschild Stiglitz, 1976, and the latter shared in the nobel prize awarded for asymmetric markets for the consequent rewriting of two industries around their work on declarations.) However, the statement originally suggested goes far further, it says *all documents*. I think the entire CA approval process is completely FUBARed. Well, Ok, we may share some drinks on that. I'd prefer to say it is a good starting point for a better system, but your more blunt description will win you more friends ! I think Mozilla has managed to paint itself into a corner from which people like Ian will not let it escape, and has thus been bullied and intimidated into accepting things into its root program that are analytically damaging to the PKI and the pursuit of commerce to be enabled by it. I also believe that it has allowed commerce to define its operations and criteria for far too long. I'd agree with ... some of that :) I also wonder what you mean by commerce ... but more drinks required. iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
On 12/2/09 01:17, Eddy Nigg wrote: On 02/12/2009 01:37 AM, Ian G: Audit does an audit context. The two are different. Don't mix them; most all audits are done according to defined audit criteria, such as WebTrust or ETSI or DRC. Yes, and Mozilla relies on them, period. Yes, it's just another relying party to an audit opinion, just like any other user. This means it gets to read the opinion. It doesn't get to stipulate any conditions. (Maybe it should, that's another story.) Imagining conditions doesn't help. Asking an auditor to sign off on random documents that have nothing to do with the criteria, the audit world and the direct process raises questions. Right, that's why CAs MUST publish their CPS. I agree this whole thing would go away if all CAs published their CPSs. But reasons have been outlined why this is not the case, and Mozilla (/Frank) has decided that's OK. It's their review, as you mentioned above. I would claim that no (or few) auditors to date has been asked to verify a CA according to Mozilla review. Not Mozilla Review, but if we want to facilitate other documents beyond CSP than I have no problem accepting them if an auditor agrees to confirm those documents. It's really not our problem. Well, that depends on our metrics of success and efficiency. For my part, I think it good to hold down costs and only add burden where there is a commensurate benefit. If a CA provides a document, there is no commensurate benefit in asking the auditor to play notary for them. Indeed, there is a benefit in asking them to provide documents as is knowing that a future auditor can read the submissions and verify the claims made. And, as those provided documents are there and form part of the public record, there is plenty of scope for later verification. PS: I for one would definately champion rewriting the WebTrust process but this is not the way to do it. PS: PS: Why not? Go for it. Talk to them. lol I see you also have a copy of OSS's sabotage manual :) iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
On 02/12/2009 01:58 AM, Kyle Hamilton: ...and has thus been bullied and intimidated into accepting things into its root program that are analytically damaging to the PKI I believe - and that's another reason why I'm here, that this can be reversed and improved. It requires some work and we've came already close in the past to actually achieve some results. enabled by it. I also believe that it has allowed commerce to define its operations and criteria for far too long. Commerce or not, here is another interesting one: https://bugzilla.mozilla.org/show_bug.cgi?id=477783 -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
Le 9 févr. 09 à 20:54, Eddy Nigg a écrit :On 02/09/2009 09:35 PM,kathleen95...@yahoo.com:Of course. I will await your next post to this discussion.Just browsing through the various documents and I noticed the following so far.It seems to me that the code signing bit *should not* be activated, it should be reflected in the "Pending" page as well.The initial comment was written on august 2008, and now we have code signingcertificates, and it appears in our CP/CPS.Email validation seems to me ambiguous at least and apparently not defined in their CP/CPS. Neither is domain ownership/control validation defined as I understand.Yes it is not defined in our CP but in our internal operational processesand in our CPS too.Unfortunately, CPS are not published (they described internal technical andorganizational measurements)RA operators must obtain guarantee than the e-mail address is owned by therequester.It's difficult in fact to make such controls. In practice the name of therequester must appear in the left part of the e-mail address... If not, RAoperators are likely to get proof of possession (the request can be rejectedin case of doubt). For employees it's easier : the name of the suscriber anddomain name of the company can be easily checked.It's the same for domain ownership/control :RA operators verify the names of owner, administrator... in databases (like whois).They visit the website to look at the content, and the request can be rejected if any doubt.Repeated requests for translating the relevant parts have not been complied. Comments in this respect (bug 393166, comment 15, d) ) have no relevance to the question asked and your questions in comment 13 have partly not been answered, in particular 2.d. Besides a general denial in regards of problematic practices, no details have been provided.-Our DV SSL certificates have maximum expiration time of 3 years in thefuture.- Software private keys are generated on the suscriber computer with asigned applet- When the suscriber is using a smartcard, the private key is generatedonboard.In particular I couldn't find out for how long their certificates are valid and how S/MIME certificates are provided to the subscriber ("We send the certificate to the subscriber by mail").- Certificates are valid 1, 2 or 3 years.- S/MIME certificates are provided to the suscriber by email (not mail,sorry). the suscriber must agree with the certificate and send a returnreceipt with certificate eacceptance.There is a signed applet for the suscriber to ask for a certificate, and toinstall the issued certificate.Overall I think there is very little information available about this CA (in English) and I'm hesitant to continue without a more thorough review of critical aspects.We are at the same level than the DCSSI CA that was approved a few days ago.On february 2009, the 5th, we obtain the compliance with PRIS/RGS for ourCAs ( and our CP, CPS are compliant with the exemplifications CP/CPS ofhttp://www.mozilla.org/projects/security/certs/pending/#DCSSI)( cf :http://www.references.modernisation.gouv.fr/outil-de-suivi-des-qualifications-et-des-referencements-des-offres-de-certificats)Mr Bouchet from LSTI is the lead auditor mandated by the french government for the ETSI and PRIS/RGS audits.If case of doubt about our practices, you can obtain more informations from himHis phone number is : +33 1 30 61 50 60--RegardsYannick LEPLARDDirecteur RD20, allée de la râperie59650 Villeneuve d'Ascqtél. : 03 20 79 24 09fax. : 03 20 34 20 52www.dhimyotis.frCe mail est signé électroniquement grâce à un certificat Certigna. Il a valeur légale.Pour plus d'informations, rendez-vous surwww.certigna.fr.--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
On 2/10/2009 6:25 AM, Yannick LEPLARD wrote: Le 9 févr. 09 à 20:54, Eddy Nigg a écrit : On 02/09/2009 09:35 PM, kathleen95...@yahoo.com mailto:kathleen95...@yahoo.com: Of course. I will await your next post to this discussion. Just browsing through the various documents and I noticed the following so far. It seems to me that the code signing bit *should not* be activated, it should be reflected in the Pending page as well. The initial comment was written on august 2008, and now we have code signing certificates, and it appears in our CP/CPS. Email validation seems to me ambiguous at least and apparently not defined in their CP/CPS. Neither is domain ownership/control validation defined as I understand. Yes it is not defined in our CP but in our internal operational processes and in our CPS too. Unfortunately, CPS are not published (they described internal technical and organizational measurements) RA operators must obtain guarantee than the e-mail address is owned by the requester. It's difficult in fact to make such controls. In practice the name of the requester must appear in the left part of the e-mail address... If not, RA operators are likely to get proof of possession (the request can be rejected in case of doubt). For employees it's easier : the name of the suscriber and domain name of the company can be easily checked. It's the same for domain ownership/control : RA operators verify the names of owner, administrator... in databases (like whois). They visit the website to look at the content, and the request can be rejected if any doubt. Repeated requests for translating the relevant parts have not been complied. Comments in this respect (bug 393166, comment 15, d) ) have no relevance to the question asked and your questions in comment 13 have partly not been answered, in particular 2.d. Besides a general denial in regards of problematic practices, no details have been provided. - Our DV SSL certificates have maximum expiration time of 3 years in the future. - Software private keys are generated on the suscriber computer with a signed applet - When the suscriber is using a smartcard, the private key is generated onboard. In particular I couldn't find out for how long their certificates are valid and how S/MIME certificates are provided to the subscriber (We send the certificate to the subscriber by mail). - Certificates are valid 1, 2 or 3 years. - S/MIME certificates are provided to the suscriber by email (not mail, sorry). the suscriber must agree with the certificate and send a return receipt with certificate eacceptance. There is a signed applet for the suscriber to ask for a certificate, and to install the issued certificate. Overall I think there is very little information available about this CA (in English) and I'm hesitant to continue without a more thorough review of critical aspects. We are at the same level than the DCSSI CA that was approved a few days ago. On february 2009, the 5th, we obtain the compliance with PRIS/RGS for our CAs ( and our CP, CPS are compliant with the exemplifications CP/CPS of http://www.mozilla.org/projects/security/certs/pending/#DCSSI ) ( cf : http://www.references.modernisation.gouv.fr/outil-de-suivi-des-qualification s-et-des-referencements-des-offres-de-certificats ) Mr Bouchet from LSTI is the lead auditor mandated by the french government for the ETSI and PRIS/RGS audits. If case of doubt about our practices, you can obtain more informations from him His phone number is : +33 1 30 61 50 60 You state . . . CPS are not published . . . Repeatedly, the WebTrust Program for Certification Authorities indicates that the CPS is PUBLISHED. This means it is made available to the public, to both those who have certificates and those who trust those certificates. If you were audited in conformance with WebTrust criteria, how did you pass the audit without publishing your CPS? -- 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. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
On 02/10/2009 04:25 PM, Yannick LEPLARD: The initial comment was written on august 2008, and now we have code signing certificates, and it appears in our CP/CPS. To my understanding the audit wasn't performed with those changes. Yes it is not defined in our CP but in our internal operational processes and in our CPS too. Unfortunately, CPS are not published (they described internal technical and organizational measurements) This must be stated in the CPS and publicly disclosed. I'm sorry, but in my opinion this is insufficient and will most likely not work. RA operators must obtain guarantee than the e-mail address is owned by the requester. It's difficult in fact to make such controls. Email validation isn't too difficult to implement, however we have seen various times that this isn't done sufficiently or correctly. - Software private keys are generated on the suscriber computer with a signed applet This is interesting! Can you provide us some more information about this applet? Can I test it somewhere? We are at the same level than the DCSSI CA that was approved a few days ago. Each CA is looked at independently and each CA has its own CP/CPS, audit etc. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
On 10/2/09 16:42, : The initial comment was written on august 2008, and now we have code signing certificates, and it appears in our CP/CPS. To my understanding the audit wasn't performed with those changes. In general terms, and without commenting at all on the current case, here are a few observations. I think this is another area where there is a misunderstanding as to the role of audit. a. Time. There is always some element of change between the last audit and current practice. Audits are snapshots of the past not proofs over the present nor future. And, there is an expectation that audits are repeated over time, the new guy has to have something to work with. Also, factor in 40 week + distro delays, and consider asking CAs to sit on their hands for a year or so. b. The emphasis of the audit is over whether management has put in place policies and procedures, sticks to them. Any check over particular activities is not there to audit those activities in themselves but to provide evidence of the policies and procedures in general as a reliable guide to the reading public. E.g., they do what they write, they write what they do. d. Having said that, a specific audit criteria may state a check is needed on X. One would have to go back and read WebTrust to see if it has a criteria on X==codesigning. That still doesn't change the other issues, but it may give you something to rely on when it comes to codesigning specifically. c. One of the policies and practices that audits look at is generally whether CPSs and so forth are updated according to a reliable regime. Of course, we can really only do that when we see that change is done, so this is actually a positive chance for the next auditor to check the progress. I say this with some relish, because extracting good evidence is quite hard when most things are just written because the auditor says it is needed, and then ignored forever more.. That's my view at the moment, I'm looking forward to others! iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
We are at the same level than the DCSSI CA that was approved a few days ago. Each CA is looked at independently and each CA has its own CP/CPS, audit etc. I just wanted to explain that DCSSI is the french government CA, and PRIS/RGS is the new highest level standard for french CAs. It is ETSI TS 102 042 compliant, and ETSI 101 456 compliant for qualified signing certificates. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
You state . . . CPS are not published . . . Repeatedly, the WebTrust Program for Certification Authorities indicates that the CPS is PUBLISHED. This means it is made available to the public, to both those who have certificates and those who trust those certificates. If you were audited in conformance with WebTrust criteria, how did you pass the audit without publishing your CPS? we have ETSI TS 102 042 audits and only CP have to be published. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
On 02/10/2009 06:30 PM, Ian G: a. Time. There is always some element of change between the last audit and current practice. Audits are snapshots of the past not proofs over the present nor future. So far correct. And, there is an expectation that audits are repeated over time, the new guy has to have something to work with. Correct, but it's not audited - whatever it is. Also, factor in 40 week + distro delays, and consider asking CAs to sit on their hands for a year or so. No, did anybody suggest that and where? b. The emphasis of the audit is over whether management has put in place policies and procedures, sticks to them. Any check over particular activities is not there to audit those activities in themselves but to provide evidence of the policies and procedures in general as a reliable guide to the reading public. No, that statement is basically bullshit :-) Particular activities are audited including evidence of the specific policies and procedures. d. Having said that, a specific audit criteria may state a check is needed on X. One would have to go back and read WebTrust to see if it has a criteria on X==codesigning. That still doesn't change the other issues, but it may give you something to rely on when it comes to codesigning specifically. Wrong! If the CPS doesn't mention code signing than it's not audited. No samples of those procedures are taken by the auditor either. Audits pretty much confirm what the CA claims to do. That's my view at the moment, I'm looking forward to others! Audits are very specific and you can forget about the general references. As such we have precedence in this respect (in particular code signing). -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
Eddy Nigg wrote: On 02/10/2009 04:25 PM, Yannick LEPLARD: snip RA operators must obtain guarantee than the e-mail address is owned by the requester. It's difficult in fact to make such controls. Email validation isn't too difficult to implement, however we have seen various times that this isn't done sufficiently or correctly. Note that the official Mozilla policy doesn't attempt to dictate exactly what mechanisms a CA uses to verify ownership of email addresses, it simply requires that the CA takes reasonable measures to verify this. We can quibble about whether particular measures are reasonable or not. However traditionally the major concerns we've had were with CAs that did not have any CPS or CP language at all about verifying email addresses. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
On 02/10/2009 10:19 PM, Frank Hecker: Email validation isn't too difficult to implement, however we have seen various times that this isn't done sufficiently or correctly. Note that the official Mozilla policy doesn't attempt to dictate exactly what mechanisms a CA uses to verify ownership of email addresses, it simply requires that the CA takes reasonable measures to verify this. Correct. I haven't attempted to dictate about how to do it, but we've seen cases where it's not done at all. However some (affected) CAs turned directly to me for advice in the past concerning email validation and I provided my suggestions and advice. Some of them might still be subscribed to this list btw. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
On 2/10/2009 12:06 PM, Frank Hecker wrote: Yannick LEPLARD wrote: Unfortunately, CPS are not published (they described internal technical and organizational measurements) I acknowledge your comment that ETSI TS 102 042 does not require the CPS to be published. However we depend on public documents to document the exact claims that CAs make and whether these meet our policy requirement. So this causes a problem for us when we do not have access to CPSs and related documents. If you cannot publish the CPS because it contains private information, I suggest as an alternative that you provide some sort of official Certigna document that summarizes the portions of the CPS that are of most interest to us (i.e., those relating to validation of subcriber information). Frank THANK YOU!! That was indeed the point of my earlier comment. However, not only should they provide some alternative documentation but also that documentation should be considered during the required audit. -- 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. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
Ian G wrote: The policy says, we need published information, *eg* the CPS. Not, CPS must be published. Yes, exactly. We typically use the CPS and/or CP because almost all CAs publish those documents; however there is no requirement that the information published by the CA be in the form of a CPS or CP. Speaking personally, I think think that it is good practice for CAs to publish a CPS. If a CA has private information relating to detailed internal processes that it does not wish to make public, I suggest that it put such material in a separate CA operations manual that is internal-only. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
Certigna’s root inclusion request has been in public discussion for a week now. No issues or concerns about this request have been raised. According to https://wiki.mozilla.org/CA:How_to_apply “If there are no open issues or action items after the first discussion period, and there is general agreement that you comply with our policy requirements, then at the Foundation's discretion the second phase of public discussion may be skipped, the request will be immediately approved, and the request will move into the inclusion phase…” If no issues or concerns are raised in the next couple of days, then I will post the summary in the bug and request approval for inclusion. Kathleen -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
On 02/09/2009 08:38 PM, kathleen95...@yahoo.com: Certigna’s root inclusion request has been in public discussion for a week now. No issues or concerns about this request have been raised. According to https://wiki.mozilla.org/CA:How_to_apply “If there are no open issues or action items after the first discussion period, and there is general agreement that you comply with our policy requirements, then at the Foundation's discretion the second phase of public discussion may be skipped, the request will be immediately approved, and the request will move into the inclusion phase…” If no issues or concerns are raised in the next couple of days, then I will post the summary in the bug and request approval for inclusion. Kathleen, I request another few days if you allow. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
Of course. I will await your next post to this discussion. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
On 02/09/2009 09:35 PM, kathleen95...@yahoo.com: Of course. I will await your next post to this discussion. Just browsing through the various documents and I noticed the following so far. It seems to me that the code signing bit *should not* be activated, it should be reflected in the Pending page as well. Email validation seems to me ambiguous at least and apparently not defined in their CP/CPS. Neither is domain ownership/control validation defined as I understand. Repeated requests for translating the relevant parts have not been complied. Comments in this respect (bug 393166, comment 15, d) ) have no relevance to the question asked and your questions in comment 13 have partly not been answered, in particular 2.d. Besides a general denial in regards of problematic practices, no details have been provided. In particular I couldn't find out for how long their certificates are valid and how S/MIME certificates are provided to the subscriber (We send the certificate to the subscriber by mail). Overall I think there is very little information available about this CA (in English) and I'm hesitant to continue without a more thorough review of critical aspects. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
Eddy Nigg wrote, On 2009-02-09 11:54: On 02/09/2009 09:35 PM, kathleen95...@yahoo.com: Of course. I will await your next post to this discussion. Just browsing through the various documents and I noticed the following so far. It seems to me that the code signing bit *should not* be activated, it should be reflected in the Pending page as well. Because ? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certigna Root Inclusion Request
On 02/10/2009 03:14 AM, Nelson B Bolyard: Eddy Nigg wrote, On 2009-02-09 11:54: On 02/09/2009 09:35 PM, kathleen95...@yahoo.com: Of course. I will await your next post to this discussion. Just browsing through the various documents and I noticed the following so far. It seems to me that the code signing bit *should not* be activated, it should be reflected in the Pending page as well. Because ? Because their CPS doesn't define code signing. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
