Information regarding SSL_BadCertHook
Hi, I extracted below information from the Mozilla help site ( http://www.mozilla.org/projects/security/pki/nss/ref/ssl/index.html ) 'SSL_BadCertHook Sets up a callback function to deal with a situation where the SSL_AuthCertificate callback function has failed. This callback function allows the application to override the decision made by the certificate authorization callback and authorize the certificate for use in the SSL connection.' I need to handle either SSL_AuthCertificate or at least SSL_BadCertHook callback functions in my Firefox 3 plug-in(XULRunner 1.9) code when there is failure of certificate authentication. I went through Mozilla firfox 3.0.1 code and I found below information. File: security\manager\ssl\src\nsNSSIOLayer.cpp Function /name: nsSSLIOLayerSetOptions Code line: .. if (SECSuccess != SSL_BadCertHook(fd, (SSLBadCertHandler) nsNSSBadCertHandler, infoObject)) . In the above line, default handler is always set during the process of building new socket connection for the https site. Hence, in case of SSL_AuthCertificate call back function fails (in ssl3_HandleCertificate() function present in security\nss\lib\ssl\ssl3con.c), nsNSSBadCertHandler function will get invoked. Please help me whether is it possible to override SSL_BadCertHook callback function in my plug-in code, if so please give small description how I can do that. Thanks and Regards, Varaprasad ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
"the OCSP URI in the CA root IS a problem" Nelson, does NSS ever attempt to check the revocation status of a built-in Root Certificate if that Root Certificate contains CRLDP(s) and/or OCSP URI(s) ? On Sunday 12 October 2008 16:40:11 Eddy Nigg wrote: > Eddy Nigg: > > Except if Nelson thinks otherwise, removing the AIA OCSP service URI > > solves this issue. More specific the Mozilla CA Policy calls for: > > > > cRLDistributionPoints or OCSP authorityInfoAccess extensions for which > > no operational CRL or OCSP service exists. > > > > Therefor the OCSP reference MUST NOT appear in the EE certificates of > > Microsec. I suggest to follow up on this to confirm compliance. > > I think we have a problem here! I wanted to make sure that the CA root > and intermediate CA certificates don't include OCSP AIA extensions and I > noticed the following when importing and examining the CA root... > > - The CA root includes the OCSP service URI in the AIA extension: >OCSP: URI: https://rca.e-szigno.hu/ocsp > - Upon going to https://srv.e-szigno.hu/ I received an > sec_error_unknown_issuer error. Apparently the certificate isn't > installed correctly and doesn't present the certificate chain. > > The later is just an annoyance which can be easily fixed, however the > OCSP URI in the CA root IS a problem. Additionally the intermediate CA > certificate might also feature the AIA extension (which I couldn't test). > > As mentioned earlier, the Mozilla CA Policy states: > > ...might cause technical problems with the operation of our software, > for example, with CAs that issue certificates that have... > > ...cRLDistributionPoints or OCSP authorityInfoAccess extensions for > which no operational CRL or OCSP service exists. > > Micorsec doesn't provide an operational OCSP responder when used in > conjunction with AIA service URI. Over to Frank. -- Rob Stradling Senior Research & Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Dealing with third-party subordinates of T-Systems and others
Ian G: One good way to achieve certainty is for Mozilla to require the documents to be declared in the process. That might be a good idea...actually that's what I assume when a CA makes a request for inclusion (but on the other hand, no CA has yet confirmed or signed an agreement in this respect with Mozilla). This is already explicit in that the CPS must be provided, and is implicit for other key documents. ...not sure which other key documents you refer to...there is no such requirement per se. Once so declared, it is agreed that this is "the agreement". That reduces uncertainty, because the CA, Mozo, and the reviewing community agree that it was the document Does that make sense? I think it does. 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. ??? That I don't follow. How can a request for adding a root be interpreted as a waiver? Special requirements? By requesting to have the CA root included and by the nature of Mozilla being a relying party (yes, yes, it is..) it can be assumed that because no special requirements were tied to that request (like, please also confirm our XYZ agreements and conditions) Mozilla is not bound not bound to any agreement set up before, during or after the inclusion. I expect that the RP obligations in the CP/CPS are the binding requirements, but not any other additional agreements - since none have been forwarded during the request. But the legal department of MoFo can answer these questions better. My basic default expectation is that, if there are any waivers, they would have to be specified in the bug request. They would have to be clear to the community. I think it's the other way around. With making a request for including a root, any additional agreements, conditions etc. not brought forward during the document gathering period or upon initial request for inclusion are void (and the request itself represents a waiver of any special agreements, conditions or requirements). The community might not agree to them, but at a minimum, we should know, right? Point 2 of the policy says that. Obviously any agreement, condition or requirement tied to including a CA root must be disclosed during request. Otherwise they are not binding for Mozilla. They do make a request in writing; it is the bug filing. Nonono...it's still harder to prove than with hard copies. A CA can claim that the request or anything else within the bug (like comments) were modified, tainted etc. Bugzilla is under the control of Mozilla and hence its use in court is questionable to some extend. + I saw Gerv mention that the CAs have to provide a digital copy from the auditor's website or email address. That's IMO good enough. And you believe that our NSS/CA Policy team archived CP/CPSs and audit statements upon approval? And you believe that they remain there forever at the auditors web site? And you believe CP/CPS don't change (or can be modified, including removal)? This doesn't need to be in the policy, it can be working practice, and the Mozo people can do it as well. Sending the root printed in paper would be just an added benefit...if we are already mailing hard-copies... Yes: it would allow mozo to protect themselves and their users. it would allow mozo to establish some baseline things (e.g., Nelson's comments a few weeks ago about one standard for all CAs). It would allow one law (choice & forum). It would allow some standard no-no clauses. It would simplify the complications of deciding what was in the agreement and what was just "wiki chatter". It would allow Mozo to push some CAs to tighten up their game. No: it would cramp the style -- slow down the development of things, as a single document has a lifetime of 2-8 years. It would subject us to a long argument as to what it should be. It would shift the power around a bit (EV v. Mozo v. big CAs). It would offend the techies. It would empower the lawyers. It isn't Mozo's policy nor style to slam an EULA on everything. Each CA is so different, it should have a different agreement. The browser is the proxy (relying? using?) party for the user and it is up to the CA to lay this down to user and browser alike. I can't befriend myself with the contra arguments...none are really valid...CA is not that much about technology, style and a lot about legalities if we are at it... (Might be true, not sure how relevant it is. Copying others isn't always the smart thing to do.) However the "others" aren't always idiots either...it's good to learn about what others do and come to a decision if it's also good for you. We agree that there is no special duty of care for certificates (as opposed to a general duty). That's an important point, because it might be that the only way to establish standing
Re: Microtec CA inclusion request
Eddy Nigg: I think we have a problem here! I wanted to make sure that the CA root and intermediate CA certificates don't include OCSP AIA extensions and I noticed the following when importing and examining the CA root... - The CA root includes the OCSP service URI in the AIA extension: OCSP: URI: https://rca.e-szigno.hu/ocsp - Upon going to https://srv.e-szigno.hu/ I received an sec_error_unknown_issuer error. Apparently the certificate isn't installed correctly and doesn't present the certificate chain. The later is just an annoyance which can be easily fixed, however the OCSP URI in the CA root IS a problem. Additionally the intermediate CA certificate might also feature the AIA extension (which I couldn't test). As mentioned earlier, the Mozilla CA Policy states: ...might cause technical problems with the operation of our software, for example, with CAs that issue certificates that have... ...cRLDistributionPoints or OCSP authorityInfoAccess extensions for which no operational CRL or OCSP service exists. Micorsec doesn't provide an operational OCSP responder when used in conjunction with AIA service URI. Over to Frank. More followup's on this issue...I found a correctly installed certificate at https://rca.e-szigno.hu/ and I could examine also the intermediate CA certificate which also features the OCSP AIA extension. This means that all certificates from the root up to the EE certificate include the AIA extension OCSP URI. Additionally the OCSP URI is a HTTPS URL which makes it even more unusable. How can the OCSP responder be accessed by HTTPS if it can't confirm the validity of the connection to the responder itself? IMO this is never going to work. OCSP responses are signed and SHOULD NOT be served over a secure connection. The only workaround would be to have the OCSP HTTPS connection signed by a certificate issued by a different 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: Microtec CA inclusion request
Eddy Nigg: Except if Nelson thinks otherwise, removing the AIA OCSP service URI solves this issue. More specific the Mozilla CA Policy calls for: cRLDistributionPoints or OCSP authorityInfoAccess extensions for which no operational CRL or OCSP service exists. Therefor the OCSP reference MUST NOT appear in the EE certificates of Microsec. I suggest to follow up on this to confirm compliance. I think we have a problem here! I wanted to make sure that the CA root and intermediate CA certificates don't include OCSP AIA extensions and I noticed the following when importing and examining the CA root... - The CA root includes the OCSP service URI in the AIA extension: OCSP: URI: https://rca.e-szigno.hu/ocsp - Upon going to https://srv.e-szigno.hu/ I received an sec_error_unknown_issuer error. Apparently the certificate isn't installed correctly and doesn't present the certificate chain. The later is just an annoyance which can be easily fixed, however the OCSP URI in the CA root IS a problem. Additionally the intermediate CA certificate might also feature the AIA extension (which I couldn't test). As mentioned earlier, the Mozilla CA Policy states: ...might cause technical problems with the operation of our software, for example, with CAs that issue certificates that have... ...cRLDistributionPoints or OCSP authorityInfoAccess extensions for which no operational CRL or OCSP service exists. Micorsec doesn't provide an operational OCSP responder when used in conjunction with AIA service URI. Over to Frank. -- 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: 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. I still disagree. RFC 2560 does allow the responder to be under a separate root as a 'trusted responder'. Naturally, no responder is trusted by everyone, there are users who accept a certain responder and there are users who do not accept it. I don't think that a responder is not conformant according to RFC 2560 just because there are users who do not trust it. I think the point Nelson was making that if the certificate issued to the users includes an OCSP URI it's not conforming to the RFC. We shall remove the OCSP URL from the AIA field for webserver certificates. Yes I vote no on this proposal due to OCSP interoperability issues. I think the removal of the OCSP URL should eliminate this problem. Except if Nelson thinks otherwise, removing the AIA OCSP service URI solves this issue. More specific the Mozilla CA Policy calls for: cRLDistributionPoints or OCSP authorityInfoAccess extensions for which no operational CRL or OCSP service exists. Therefor the OCSP reference MUST NOT appear in the EE certificates of Microsec. I suggest to follow up on this to confirm compliance. -- 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
> 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. I still disagree. RFC 2560 does allow the responder to be under a separate root as a 'trusted responder'. Naturally, no responder is trusted by everyone, there are users who accept a certain responder and there are users who do not accept it. I don't think that a responder is not conformant according to RFC 2560 just because there are users who do not trust it. > 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 agree, our responder is not useful for most Mozilla users. We shall remove the OCSP URL from the AIA field for webserver certificates. > I vote no on this proposal due to OCSP interoperability issues. I think the removal of the OCSP URL should eliminate this problem. Regards, István ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Dealing with third-party subordinates of T-Systems and others
Eddy Nigg wrote:
> 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 ;-)
Sounds a bit like the RIM/Blackberry case, "right" and "might" and
"justice" was on their side, all the way up to a $600m settlement :)
I don't think anyone wins by relying on hints and hopes. In a
business setting, it would be gambling at best to rely on the basis
that an agreement "might" be struck down if it ever needed to be
tested We need certainty.
One good way to achieve certainty is for Mozilla to require the
documents to be declared in the process. This is already explicit
in that the CPS must be provided, and is implicit for other key
documents. We might just want to recognise that the RPA or similar
forms a very important part of that which we call the overall "CPS
package".
Once so declared, it is agreed that this is "the agreement". That
reduces uncertainty, because the CA, Mozo, and the reviewing
community agree that it was the document; this only leaves the poor
end user with the possibility of saying otherwise.
Does that make sense?
>> ( 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.
??? That I don't follow. How can a request for adding a root be
interpreted as a waiver? Special requirements?
My basic default expectation is that, if there are any waivers, they
would have to be specified in the bug request. They would have to
be clear to the community.
The community might not agree to them, but at a minimum, we should
know, right? Point 2 of the policy says that.
Otherwise we would see all sorts of issues arising. The notion of
there being unknown waivers and exceptions would rip the guts out of
any public faith in the process, I would think?
But I admit to not understanding, can you rephrase?
> The inclusion request is obviously an implicit agreement. I suggested in
> the past to have CAs
>
> - make a request also in writing
They do make a request in writing; it is the bug filing.
> - provide audit statements, root certificates and other documents in
> hard copy
+ I saw Gerv mention that the CAs have to provide a digital copy
from the auditor's website or email address. That's IMO good enough.
+ Root certificates are provided, otherwise it wouldn't work :)
+ Hard copy is not necessary; what is sufficient is clearly
designated digital copies. If this is an issue, ask the CA to amend
their bug to add the hash of each digital copy uploaded or mailed.
This doesn't need to be in the policy, it can be working practice,
and the Mozo people can do it as well.
> - sign a standard agreement with Mozilla
This then is a good point. There is (AFAIK, me not being Mozo) any
real *single* agreement in a document form.
Should there be?
Yes: it would allow mozo to protect themselves and their users.
it would allow mozo to establish some baseline things (e.g.,
Nelson's comments a few weeks ago about one standard for all CAs).
It would allow one law (choice & forum).
It would allow some standard no-no clauses.
It would simplify the complications of deciding what was in the
agreement and what was just "wiki chatter".
It would allow Mozo to push some CAs to tighten up their game.
No: it would cramp the style -- slow down the development of
things, as a single document has a lifetime of 2-8 years.
It would subject us to a long argument as to what it should be.
It would shift the power around a bit (EV v. Mozo v. big CAs).
It would offend the techies. It would empower the lawyers.
It isn't Mozo's policy nor style to slam an EULA on everything.
Each CA is so different, it should have a different agreement.
The browser is the proxy (relying? using?) party for the user and it
is up to the CA to lay this down to user and browser alike.
(yes, big long open question. luckily nobody is paying me to answer
it today!)
> This is the common approach with all major browsers besides Mozilla.
(Might be true, not sure how relevant it is. Copying others isn't
always the smart thing to do.)
>> 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 easi
Re: Setting a schedule for CA evaluations
Eddy Nigg wrote: 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... Sorry, there wasn't an announcement because I was too busy with other stuff to close out phase 1 of public comment on Microsec. I'm going to make some comments on Microsec, and then push the whole schedule back a few days to account for my delays. My apologies... Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
