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 R&D 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 R&D 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
what is the new work requirement for the auditor?
So there appear to be several things that might require an additional audit interaction over some delivery to Mozilla, outside the normal audit opinion. Here's my list of things, as spotted recently: 1. a CA's clarification or comment over a key document (e.g., CPS). 2. an additional document of some import. 3. an extract from a key document. 4. a redacted document from a key document. 4. the mozilla criteria listed in policy. 5. any document / evidence. Secondly there appears in another axis several natures of comment [1]: a. an audit over that document. b. auditor's comment that the document was incorporated into the main audit as evidence. c. auditor's comment that the document is a reasonable view over another document, separate from an audit over the primary document. And, over perhaps a third axis there is the attest nature: i. assertion over document or over subject matter? ii. examination or review? Attestation or not? iv. relationship to an audit iii. comment of no particular relationship v. person of some relationship or no relationship? In order to deliver clarity to the community of CAs there, we probably need some guidance on this, written up in the wiki pages and/or policy. It might be: (a) case by case judgement by Mozilla. (b) a matrix where we look up what is required. (c) simply discount any additional information. (d) full audit attention over any additional information. (e) requirement to disclose any additional submission to auditor. Just some ideas [2] iang [1] As we know, when audit says something, it has to be interpreted carefully. Elsewhere, I comment that unless you know what all that means, you should be careful, because you don't know the code. Somethings can be taken to court, somethings not. Now, in this present context, Mozilla has decided to rely on the audit, and therefore they've made a conscious decision to learn the tricks. So we are covered, theoretically, as a community. But we still need to know what it is that is being requested. [2] Actually I think I am a long way from nailing down the issues here. But am inhibited from researching it fully atm. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: what is the new work requirement for the auditor?
On 02/12/2009 07:47 PM, Ian G: [2] Actually I think I am a long way from nailing down the issues here. Even though I agree usually on providing clear statements and requirements, I wonder if we really have to go into such details? You know, many times it was sufficient to receive a statement by the representative of the CA regarding clarifications when the overall "quality" of information we had wasn't lacking. I think everything should be also within reasonable boundaries - I think it was the first time that a CA didn't publish its CPS. -- 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: "pretty print" a cert from JSS
David Stutzman wrote:
Glen Beasley wrote:
you can code the same pretty print functionality but there is no
existing function that
duplicates certutil -l -n.
You can start with
http://mxr.mozilla.org/security/source/security/jss/org/mozilla/jss/tests/ListCerts.java
Which currently outputs:
java -cp ./jss4.jar org.mozilla.jss.tests.ListCerts . Client_RSA
main: jss library loaded
1 certs found with this nickname.
Subject: CN=ClientCert,OU=JSS Testing100,O=Mozilla,C=US
Signature oid {1 2 840 113549 1 1 11}
Convert to JDK cert
Subject CN=ClientCert, OU=JSS Testing100, O=Mozilla, C=US
Signature oid SHA256withRSA
no NON Critical Extensions
no Critical Extensions
END
Yeah, I was looking more like the NSS output or very similar to what
I'm currently using which is functionality that Dogtag CA uses (part
of their "security_deprecated" sdk...JSS is the "security" toolkit).
I'm just looking to drop a jar (nsutil) for that one thing I need and
it's probably something other people would like.
The class I'm using is
https://pki.fedoraproject.org/svn/pki/trunk/pki/base/util/src/netscape/security/util/CertPrettyPrint.java
and I need to convert my jss/java cert to a
https://pki.fedoraproject.org/svn/pki/trunk/pki/base/util/src/netscape/security/x509/X509CertImpl.java
to pass in to that thing. Since the Dogtag code is GPL...what are the
(legal) ramifications of attempting to port that functionality over
for JSS?
My belief is if there was a well written patch that did this clean up,
both the JSS and Dogtag teams would welcome it. So, if you desire
CertPrintPrint.java functionality to belong to JSS you can open a bug on
JSS and either attempt a patch or hopefully a JSS developer may have
some cycles to do it.
http://pki.fedoraproject.org/wiki/PKI_TechNote_Jar_files
nsutil.jar - "this jar file provides the basic ASN.1/DER encoding and
decoding functions for all X.509 objects such as keys, certificates,
certificate extensions. It is one of the two ASN.1 implementation in the
PKI server. The other one is JSS. The server currently is using a both
implementation. The long term plan is to migrate everything to JSS"
-glen
I guess it would be an interesting side project. I haven't really
looked at it to see how hard it would be but I imagine JSS can already
ASN.1 decode all the pieces, it's just a question of formatting it and
tossing out a String.
Dave
--
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: what is the new work requirement for the auditor?
On 12/2/09 19:00, Eddy Nigg wrote: On 02/12/2009 07:47 PM, Ian G: [2] Actually I think I am a long way from nailing down the issues here. Even though I agree usually on providing clear statements and requirements, I wonder if we really have to go into such details? You know, many times it was sufficient to receive a statement by the representative of the CA regarding clarifications when the overall "quality" of information we had wasn't lacking. I think everything should be also within reasonable boundaries - I think it was the first time that a CA didn't publish its CPS. Eddy, you change your tune so fast you must be salsa dancer ... you just wrote: 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. An audit is a big deal. It is billable hours, if nothing else. You just added a few thousand euros to their bill. Throwing random things into the mix, just to please someone far far away, is ridiculous and unprofessional. On a more serious note, consider that we are getting closer and closer to an issue that is very troubling. There are two reviews. One is the "WebTrust and friends." This is done completely independently of Mozilla. The second is the "Mozilla review" which is done after the auditor has left the scene and moved on to another (billable hours) job. Requiring the presence of the auditor for the second one is highly problematic. It's easy to demand, sure. It makes everyone here feel really good and righteous and comfortable, as we armchair-general our way along to winning this paper war. But out where the real shots are fired, the forces don't move around so easily as they do on a mapboard. iang PS: So, just to clarify my own audit position here. As far as I see it, it makes no odds to CAcert whether you add this requirement in or not, because I have included or thought about or am aware of Mozilla from the beginning, and probably won't be far away, afterwards. But that "Mozilla first" approach only applies rarely. Perhaps only to CAcert, maybe Startcom, dunno. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
how do we agree?
On 11/2/09 21:26, Eddy Nigg wrote: On 02/11/2009 06:43 PM, Ian G: OK, I made some changes on the wiki First of all I think we should edit this document only after some sort of agreement here. I think we haven't finished discussion concerning this issue yet, can you hold back for a minute? Nope. It's a wiki; and there have been frequent invitations to add comments and help. We can all add comments, and we can collect points of agreement that exist. Nothing on the wiki is binding, afaik. One clarified point is collected there, but even it is changeable. Also, point of order: there is no established way to agree and disagree in this forum, so "we agreeing here" is a statement that lacks agreement :) As I understand it, it is Mozilla's review, taken with public consultation, not the other way around. Once the CA desk decides that is how it is, after consultation, that's how it is. Frank held the line against requiring publication, and I for one will support that against the steamrolling. If Mozilla changes its mind on this point, that is fine; it's their review. Mozilla and endusers take on the liability, we don't. iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: what is the new work requirement for the auditor?
On 02/12/2009 09:04 PM, Ian G: Eddy, you change your tune so fast you must be salsa dancer ... I don't think so. I wondered if we need a list of 20 items in order to clarify what a CA should provide in terms of audited documents. As I already said, many times we need only clarifications - a big difference to an unpublished CPS. Publishing the CPS is and should be the norm I think, not sure what's the fuss about really. An audit is a big deal. It is billable hours, if nothing else. You just added a few thousand euros to their bill. Throwing random things into the mix, just to please someone far far away, is ridiculous and unprofessional. What are you talking about? I don't know about their relationship with their auditors, but your assumptions are most likely incorrect as so many other things you throw into the wild (but many times I prefer not to disprove your claims as it serves me other interests). On a more serious note, consider that we are getting closer and closer to an issue that is very troubling. I didn't knew that we are getting closer to a troubling issue, certainly not the one you mention now... One is the "WebTrust and friends." This is done completely independently of Mozilla. Mozilla doesn't perform an audit, Mozilla processes an inclusion request of a CA root certificate into their software according to their own stated policies. Requiring the presence of the auditor for the second one is highly problematic. It's easy to demand, sure. It makes everyone here feel really good and righteous and comfortable, as we armchair-general our way along to winning this paper war. But out where the real shots are fired, the forces don't move around so easily as they do on a mapboard. Nobody ever proposed at what you assume (again) above. In case of a deficiency or other problematic issue which might come up every here and now, solutions need to be found. It's not the goal of Mozilla to prevent inclusion of CAs, but to reasonably assure that the to-be-included CA conforms to its policy. Where is now the problem again? PS: So, just to clarify my own audit position here. As far as I see it, it makes no odds to CAcert whether you add this requirement in or not, because I have included or thought about or am aware of Mozilla from the beginning, and probably won't be far away, afterwards. But that "Mozilla first" approach only applies rarely. Perhaps only to CAcert, maybe Startcom, dunno. What are you talking about? Can you clarify? -- 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: how do we agree?
On 02/12/2009 09:11 PM, Ian G: First of all I think we should edit this document only after some sort of agreement here. I think we haven't finished discussion concerning this issue yet, can you hold back for a minute? Nope. It's a wiki; It's a wiki because that's the media Frank decided would be best suitable for the task. and we can collect points of agreement that exist. Yes, this is very correct: "points of agreement that exist" Nothing on the wiki is binding, afaik. These pages serve as a basis for Kathleen's work and were mostly agreed upon here. Also, point of order: there is no established way to agree and disagree in this forum, so "we agreeing here" is a statement that lacks agreement :) Well, when needed, Frank has made the call. Not everything I proposed here was agreed upon as far as I can tell. As I understand it, it is Mozilla's review, taken with public consultation, not the other way around. Absolutely. Once the CA desk decides that is how it is, after consultation, that's how it is. Frank held the line against requiring publication, and I for one will support that against the steamrolling. But there were calls made by David and me (others would perhaps join) that in the absence of a published CPS, any information provided instead of the lacking CPS must be confirmed by the auditor. If I understand Franks position, this is exactly what he proposed as well in the Certigna case. So we have agreement. Now, do we really need a discussion about how to agree? Feel free, but we should use our energy and time for other efforts, like reviewing the next CA in the queue. -- 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: Hongkong Post Root Inclusion Request
Michael Ströder wrote, On 2009-02-10 00:27: > Nelson B Bolyard wrote: >> This is probably a policy question, but: are we willing to accept CAs >> that use CRLs that we cannot parse? > > I'd say no. > >> Does this CA also implement OCSP? Can we justify this on the grounds >> that we do implement OCSP, and that OCSP will effectively displace CRLs >> as the preferred revocation channel? > > I'd say no. Use of OCSP should not be made mandantory. No one has proposed anything that would make OCSP mandatory. At the present time, we support OCSP and "full" CRLs. We do not support "partitioned" CRLs. Very few CAs use partitioned CRLs. Support of partitioned CRLs is separate from support for CRLDP and fetching of CRLs from URLs in CRLDP extensions. Support for One of those does not automatically imply support for the other. Recently, a CA that uses partitioned CRLs applied to admission to the Mozilla/NSS root CA list. Our choices appear to be: 1) Do not admit their root until support for partitioned CRLs is done. (There is no active plan of record to do that work at this time.) 2) IF they also support OCSP, admit them on that basis 3) If not, admit their root anyway, knowing that their CRLs will not work with NSS, not even when CRLDP work is done. I think the last option is not a good choice. I'm OK with either of the others. The responses I've seen don't seem to clearly indicate which of the above 3 choices are acceptable. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Hongkong Post Root Inclusion Request
On 02/13/2009 05:58 AM, Nelson B Bolyard: Recently, a CA that uses partitioned CRLs applied to admission to the Mozilla/NSS root CA list. Our choices appear to be: 1) Do not admit their root until support for partitioned CRLs is done. (There is no active plan of record to do that work at this time.) 2) IF they also support OCSP, admit them on that basis 3) If not, admit their root anyway, knowing that their CRLs will not work with NSS, not even when CRLDP work is done. I think the last option is not a good choice. I'm OK with either of the others. The responses I've seen don't seem to clearly indicate which of the above 3 choices are acceptable. Obviously #2 would be preferred. On the other hand, we lived without any revocation checking before FF3 by default, why should we require it now? From the CA point of view, I wouldn't want to be in the situation of #3, neither if we look at it from the Mozilla side. At least in pre FF3 we had OCSP and CRL support, but the user had to enabled either of it manually. The CP/CPSs of CAs require usually revocation checking by the relying party, but with a software which doesn't support it at all, it's not reasonable to expect out-of-band revocation checking by the relying party. That's the main difference, hence #3 is kind of irresponsible, because it's known not to work. -- 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
