Re: Dealing with third-party subordinates of T-Systems and others
On 10/10/2008 01:45 PM, Ian G: Finally, if it ever did get to court, I don't see any good reasons why it would not stand up? Well, I prefer to refrain from commenting on this, but the fact that I mentioned it could give you some hint ;-) ( I should clarify things here: there is certainly an agreement between each CA and Mozilla. It's however not a written agreement with only one form, rather it is a compilation including: * the policy, * and in the case of EV, the Guidelines are incorporated, * audit criteria, * any side agreements or historical understandings, * the filed documents under the ascension process, * etc. Actually the request made by the CA to have their root included is/should/might be interpreted as a waiver for any special requirements, agreements, conditions except if specifically conditioned in the bug. The inclusion request is obviously an implicit agreement. I suggested in the past to have CAs - make a request also in writing - provide audit statements, root certificates and other documents in hard copy - sign a standard agreement with Mozilla This is the common approach with all major browsers besides Mozilla. So, you are saying that Mozilla, by way of its software agent (Firefox and/or NSS) are standing in for some of the risks, liabilities, obligations expressed in the CA's RPA ? No, but a user can easily prove that by using the browser he adheres to the RP obligations (except if he overrides the browser configuration - adds an exception) So, what happens in any real case? If grandma stands up and says I don't know how, but I was robbed! That's not a case for the CA. Grandma has to sue the party which robbed her. Provided that there was no flaw in the certification, the CA is clean and not party of such circumstances. A judge might knock the RPA down on the basis that there is a better agreement, but I don't know what that would be No, that's not the case, but I'm not really inclined to give ideas here... This is bad, but I think most CAs have stopped doing that so blatantly. Really? I haven't seen that -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] 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: Microtec CA inclusion request
On 10/03/2008 12:43 AM, Frank Hecker: I am now opening the first public discussion period for a request from Microtec Ltd to add the Microsec e-Szigno Root CA root certificate to Mozilla. This is bug 370505, and Kathleen has produced an information document attached to the bug. Besides the issue with the OCSP responder and their including of the OCSP URI in the AIA extension with EE certificates, I have not found any issues with this request. My recommendation for Microsec is to refrain from including the OCSP service URI if and until they can provide an OCSP responder which is usable with Firefox and other browsers (when relying on AIA extension). I must note that a I couldn't read the CP/CSP of Microsec and my information is based solemnly on the bug entries and comments from István, even though István posted a text version of one of their CP/CPS at the bug. I believe that Mozilla should have the basic tools to perform at least machine translations of such documents in case no English version exists. It's important for me to inspect the CP/CPS and browse through the documents provided by the CA. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] 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: Setting a schedule for CA evaluations
On 10/02/2008 07:37 PM, Frank Hecker: OK, if no one cares one way or the other I'll move the start of public comments to Thursdays. Shouldn't have been there an announcement for bug 371362 or shall we simply follow the schedule? I guess a summary from you would be in any case useful as you've done with Microsec. Please advice... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] 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: Microtec CA inclusion request
István Zsolt BERTA wrote, On 2008-10-07 07:07: As I see we all agree on the fact that a 'trusted responder' can exist according to RFC 2560, and it is possible that an OCSP responder certificate is under a separate root. (There are various scenarios for providing OCSP service, it can be provided by a CA directly or by proxy responders, etc. but RFC 2560 does not deal with such issue.) Thus, I refuse any statement that would claim that our solution is not RFC 2560 conformant. It is conformant IF and only IF the user (not the CA) chooses to trust that responder. If the CERTIFICATE issued by the issuer says to go to that responder for OCSP, but the responder's cert is not either a) the the issuer's cert, or b) a cert issued by the same issuer as the cert under test, then it is not conformant. The RFC is very clear about that. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
I vote no on this proposal due to OCSP interoperability issues. -Kyle H On Sat, Oct 11, 2008 at 1:58 PM, Nelson B Bolyard [EMAIL PROTECTED] wrote: István Zsolt BERTA wrote, On 2008-10-07 07:07: As I see we all agree on the fact that a 'trusted responder' can exist according to RFC 2560, and it is possible that an OCSP responder certificate is under a separate root. (There are various scenarios for providing OCSP service, it can be provided by a CA directly or by proxy responders, etc. but RFC 2560 does not deal with such issue.) Thus, I refuse any statement that would claim that our solution is not RFC 2560 conformant. It is conformant IF and only IF the user (not the CA) chooses to trust that responder. If the CERTIFICATE issued by the issuer says to go to that responder for OCSP, but the responder's cert is not either a) the the issuer's cert, or b) a cert issued by the same issuer as the cert under test, then it is not conformant. The RFC is very clear about that. ___ 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
