Re: WISeKey root inclusion request (re-start public discussion)
On 11/29/2008 06:43 AM, Frank Hecker: On the WISeKey end, they could mandate use of SAN in BlackBox-issued certificates (as opposed to just including it in the default template), and from the NSS end we could disallow use of CN for storing domain names. At least you could have made it a requirement in order for the name constraints to have any effect with NSS. In regards to NSS we don't have to disallow subject CN fields, but have NSS check also for these attributes in addition to the SAN. -- 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: WISeKey root inclusion request (re-start public discussion)
On 11/29/2008 05:27 PM, Frank Hecker: Made what a requirement? Mandating use of SAN in BlackBox? Yes, that's what I actually meant. But my understanding (based on your hypothetical scenario) is that this would not be sufficient, since someone could remove the key material and try to issue certificates outside the context of the BlackBox product. Which is correct too...at least in the above scenario misusing the system would require a higher effort and can't be performed directly from the system. My impression from Nelson's comments is that checking CN would be subject to potential errors, since there is no well-defined standard for what CN should contain. Thus the only foolproof approach would be to move to a world where we prohibit use of CN in contexts like SSL-enbled servers and force the use of SAN. But that would be a major undertaking and one that would likely take several years in order to coordinate action with other browser vendors and with CAs in general. Prohibiting the subject line would be a tough call - unrealistic in my opinion. But checking for the CN field for SERVER certificate should be entirely possible, because that's what NSS does anyway (for domain match). The bottom line is that I certainly encourage WISeKey to promote correct use of SAN, including consideration of making its use mandatory in the BlackBox templates, investigation of why some customers don't use it, and resolution of any issues relating to use of SAN by BlackBox customers. OK, so I guess there will be no follow up later on ;-) -- 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: WISeKey root inclusion request (re-start public discussion)
OMG, maybe just maybe the OpenSSL folks should perhaps be told of this issue and concept so they can update! -Kyle H On Mon, Nov 24, 2008 at 11:35 AM, Eddy Nigg [EMAIL PROTECTED] wrote: On 11/24/2008 07:33 PM, Nelson B Bolyard: The only solution to this that is apparent to me is for the web to evolve to the point where browsers no longer accept DNS names in non-standard locations in the cert, such as in the Subject Common Name. Which in itself might create quite some problems. I guess we don't need any more problems right now when considering the current UI implementation and complaints coming in... Just imagine CN fields wouldn't be checked anymore by NSS: OMG, my openssl cert doesn't work anymore. Firefox is broken! :-) -- 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 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: WISeKey root inclusion request (re-start public discussion)
Eddy Nigg wrote: Frank: I think the critical issues what Mozilla concerns have been addressed! I agree, and am going to proceed with approval of this request. We need to make sure that naming constraints work as expected. I read through the thread on that, and will read it again to confirm my understanding. However I've already commented on my views regarding name constraints. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: WISeKey root inclusion request (re-start public discussion)
Frank Hecker wrote: Per the CA schedule, the next CA on the list for public comment is WISeKey, which has applied to add its (one) root CA certificate to the Mozilla root store, as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=371362 and in the pending certificates list here: http://www.mozilla.org/projects/security/certs/pending/#WISeKey We've now completed the scheduled time for public discussion on this request. Based on my reading of the prior material for this request (e.g., in the bug and in the newsgroup) and my reading of the discussion thread for this discussion period, there were two issues of note: First is auditing of subordinate CAs as implemented by the BloackBox product. As noted by Kevin Blackman, WISeKey now does annual onsite audits of BlackBox customers. This satisfies any concerns I might have had on the subject of audits. Second is constraining subordinate CAs to issue certificates only within their own domain(s). My understanding from the WISeKey documents and from Kevin Blackman's comments is that WISeKey implements both contractual and technical constraints in connection with the BlackBox products. Based on comments by Eddy, Nelson, et.al., there are apparently theoretical cases where such constraints could be evaded and the evasion would not be picked up by NSS (based on NSS not checking domain constraints on CN or any other values outside of the SAN stuff). On the WISeKey end, they could mandate use of SAN in BlackBox-issued certificates (as opposed to just including it in the default template), and from the NSS end we could disallow use of CN for storing domain names. These may be good ideas for future consideration, but I can't justify holding up this request till they get implemented. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: WISeKey root inclusion request (re-start public discussion)
Frank Hecker wrote: Frank Hecker wrote: Per the CA schedule, the next CA on the list for public comment is WISeKey, which has applied to add its (one) root CA certificate to the Mozilla root store, as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=371362 and in the pending certificates list here: http://www.mozilla.org/projects/security/certs/pending/#WISeKey We've now completed the scheduled time for public discussion on this request. Based on my reading of the prior material for this request (e.g., in the bug and in the newsgroup) and my reading of the discussion thread for this discussion period, there were two issues of note: And I forgot to add: In my opinion these issues have been resolved to my satisfaction, and I'm therefore officially approving the WISeKey request. I've filed bug 467138 against NSS for the actual certificate inclusion: https://bugzilla.mozilla.org/show_bug.cgi?id=467138 Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: WISeKey root inclusion request (re-start public discussion)
On 11/23/2008 12:32 AM, Nelson B Bolyard: There's no foolproof test for determining if a string is a DNS name or some other kind of name. Various heuristics can be devised, but they all have problems. This worries me somewhat and I question the usefulness of the name-constraints then... Consider the following scenario at a customer of a blackbox product: - Employee gains physical access to the machine, shuts down the machine by force (removing machine from electricity source). - He removes the hardware token from the machine and connects it to a different system. - He prints and signs a few certificates for www.paypal.com and www.microsoft.com - Returns the token back to the blackbox. Returns power source and starts the machine. Now in this case, no reporting from the blackbox is done - except that a power failure happened perhaps. Nobody will ever know the existence of those certificates. Now, name-constrains will fail for those certificates under the various scenarios you explained, including the cases where no SAN DNS is present in first place :S Note that no third party (besides the wonderful services of the parent CA) ever confirmed the physical controls of the customer above. It's still a sub root in the hands of a customer with questionable restraints then. Nothing will prevent the customer from misusing the system - even if the intentions of Wisekey are sincere. -- 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: WISeKey root inclusion request (re-start public discussion)
Eddy Nigg wrote, On 2008-11-24 09:14: On 11/23/2008 12:32 AM, Nelson B Bolyard: There's no foolproof test for determining if a string is a DNS name or some other kind of name. Various heuristics can be devised, but they all have problems. This worries me somewhat and I question the usefulness of the name-constraints then... Consider the following scenario at a customer of a blackbox product: - Employee gains physical access to the machine, shuts down the machine by force (removing machine from electricity source). - He removes the hardware token from the machine and connects it to a different system. - He prints and signs a few certificates for www.paypal.com and www.microsoft.com ... certificates that do not use standard Subject Alt Names extensions but rather use the old non-standard Subject Common Name - Returns the token back to the blackbox. Returns power source and starts the machine. [...] Now, name-constrains will fail for those certificates under the various scenarios you explained, including the cases where no SAN DNS is present in first place :S The only solution to this that is apparent to me is for the web to evolve to the point where browsers no longer accept DNS names in non-standard locations in the cert, such as in the Subject Common Name. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: WISeKey root inclusion request (re-start public discussion)
On 11/24/2008 07:33 PM, Nelson B Bolyard: The only solution to this that is apparent to me is for the web to evolve to the point where browsers no longer accept DNS names in non-standard locations in the cert, such as in the Subject Common Name. Which in itself might create quite some problems. I guess we don't need any more problems right now when considering the current UI implementation and complaints coming in... Just imagine CN fields wouldn't be checked anymore by NSS: OMG, my openssl cert doesn't work anymore. Firefox is broken! :-) -- 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: WISeKey root inclusion request (re-start public discussion)
Eddy Nigg wrote, On 2008-11-24 11:35: On 11/24/2008 07:33 PM, Nelson B Bolyard: The only solution to this that is apparent to me is for the web to evolve to the point where browsers no longer accept DNS names in non-standard locations in the cert, such as in the Subject Common Name. Which in itself might create quite some problems. I guess we don't need any more problems right now when considering the current UI implementation and complaints coming in... Just imagine CN fields wouldn't be checked anymore by NSS: OMG, my openssl cert doesn't work anymore. Firefox is broken! :-) There are 5 browser makers cooperating now as never before in the area of SSL. If they all dropped support for CNs together... ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: WISeKey root inclusion request (re-start public discussion)
Hi Eddy, On Nov 21, 10:37 pm, Eddy Nigg [EMAIL PROTECTED] wrote: On 11/21/2008 10:12 PM, kgb: Only validated and approved domain names can be included in a cert, whether in the Subject DN or the SAN. It is the default template, and best practice that the SAN (e.g. RFC822, dnsName) to be filled in the certificates. Its the case for some but not all customers. I really hope its not necessary once we can guarantee that only validated domains are used in the certificates. The issue I care mostly about is, what happens when one if these systems get compromised without you (the CA) ever detecting. Since those system aren't under your control, this is entirely possible and the risk is certainly higher than at your infrastructure. The threats may come from unknown source or from the customer himself (or their employees). The from you issued CA certificate with a path length of 0 and naming constraints limitation is what convinces me as a reasonable protection regarding above case. However it would have to be enforced by SAN extension. How come your customers can decide if to include the relevant alternative name or not? Isn't this something you should control? We have allowed the inclusion or not of the SAN extension in a certificate, because the constraints are always applied, whether the domain name is in the SAN or in the Subject DN. For us allowing this flexibility has thus not caused any issues, till now. Mandatory inclusion of the SAN extension in a certificate is a policy we can apply and monitor in the future. Regards, Kevin -- 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: WISeKey root inclusion request (re-start public discussion)
On 11/22/2008 12:32 PM, kgb: Mandatory inclusion of the SAN extension in a certificate is a policy we can apply and monitor in the future. To my understanding NSS ignores the subject line according to the RFC. DNS name constraints constrain subject alt name extensions, not CN= attributes in subject names. The same applies for email addresses. (Obviously a compromised system in some form or the other might be able to circumvent an SAN policy as well, but makes it perhaps somewhat harder still. In the meantime I think the above suggested would be sufficient, Frank might look into if NSS should implement non-standard behavior and also check for fields in the subject line.) -- 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: WISeKey root inclusion request (re-start public discussion)
Eddy Nigg wrote, On 2008-11-22 04:10: On 11/22/2008 12:32 PM, kgb: Mandatory inclusion of the SAN extension in a certificate is a policy we can apply and monitor in the future. To my understanding NSS ignores the subject line according to the RFC. I think you mean subject NAME, not subject line. DNS name constraints constrain subject alt name extensions, not CN= attributes in subject names. That's right. NSS applies name constraints to DNS names found in subject alternative names extensions but does not apply them to DNS names found within the Common Name attributes in cert subject names, per the RFC. There are several reasons for that. One is that the RFC only defines DNS name constraints as applying to DNS names in subject Alt Names. But the greater reason is that Common Names may legitimately carry values that are not DNS names. Indeed, they were never intended to carry DNS names at all, but rather were intended to carry the names of persons. You wouldn't want to reject a cert on the grounds that it failed the DNS name constraint if the CN contained Eddy Nigg and the DNS constraint said startcom.org. The same applies for email addresses. The story for email addresses isn't quite as simple as for DNS names. There are numerous different subject name attributes that can carry email addresses. There are two of those types of attributes to which NSS does apply email name constraints. They are the attributes commonly displayed with E= and MAIL=. But other attributes are not constrained by email address constraints. In practice this means that email addresses in subject names are more likely to be constrained than are DNS names in subject names. This is not an issue for certs that are issued in conformance with the RFC, putting the DNS names and email addresses into the Subject Names. But certs that put those names SOLELY in the subject name and not in the subject Alt Name may not be adequately constrained. Sadly, there are Many CAs that still put those names ONLY in the subject name, and not in the subject alt name where they belong. Frank might look into if NSS should implement non-standard behavior and also check for fields in the subject line.) There's no foolproof test for determining if a string is a DNS name or some other kind of name. Various heuristics can be devised, but they all have problems. Consider an algorithm that will find the right answer for all of these strings: Eddy Nigg www.startcom.org Eddy www e.nigg ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: WISeKey root inclusion request (re-start public discussion)
Hi Eddy, On Nov 21, 12:36 am, Eddy Nigg [EMAIL PROTECTED] wrote: On 11/20/2008 06:34 PM, kb: Probably the most important change in stated practice, is that it is reflected that every CA is audited at least once annually. This is the case for all active CAs. Kevin, thanks for clarifying this. It indeed was one of the concerns raised last time. The company database (such as existing HR, or IDM) of organisation, with details of the organisation's users, including their email addresses, is the principal source of data for certificates. OK. Bounce back email verification procedure proving access to the email account is also accepted, but this is inefficient in the enterprise context... That's why I asked... ;-) In addition other identity data in the certificate must come from a verified source, e.g. HR database of identity data that is well- maintained and was created based on face to face or direct verification of the person. Excellent! Currently it is WISeKey that audits all our CAs, we review the CAs at least once annually, or more regularly as we are more often present on some client sites. In addition to the controls we place on issuance, we also place monitoring controls and obtain regular reports. Last question: Are there any sub CAs besides the blackbox product (with name-constraints) which are external to your physical infrastructure? I think there is not, but can you confirm that? There is not. There are no sub CAs within our public hierarchy, that are not of the BlackBox type, which are external to our physical infrastructure. There are several PRIVATE CAs (linked to a private customer Root CA) that use our software and practices and processes, including Government Root and Subordinate CAs. Regards, Kevin -- 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: WISeKey root inclusion request (re-start public discussion)
On 11/21/2008 10:57 AM, kgb: There is not. There are no sub CAs within our public hierarchy, that are not of the BlackBox type, which are external to our physical infrastructure. There are several PRIVATE CAs (linked to a private customer Root CA) that use our software and practices and processes, including Government Root and Subordinate CAs. Which isn't of our concern obviously! Thanks Keven for all your answers. Frank: I think the critical issues what Mozilla concerns have been addressed! We need to make sure that naming constraints work as expected. -- 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: WISeKey root inclusion request (re-start public discussion)
On 11/18/2008 05:31 AM, Eddy Nigg: On 11/18/2008 03:54 AM, Eddy Nigg: Frank, I greatly missed the thorough and systematic work of Kathleen in this bug and it's a pity she didn't perform another round of information gathering in case some new evidence was provided. Anyhow, I couldn't find anything new in the bug since the last time. I'm not sure what is supposed to have changed. I forgot to mention, that in case inclusion is relevant we should gather additional information about the auditor and independent confirmation of the audit report. Frank, can you also check the above mentioned? -- 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: WISeKey root inclusion request (re-start public discussion)
Hi Frank, On Nov 20, 9:21 pm, Frank Hecker [EMAIL PROTECTED] wrote: Eddy Nigg wrote: The Wisekey case could be where we might draw the line. I'm not sure exactly which message (of mine or someone else's) you're responding to. In any case I don't think there's a bright line between the various scenarios involving independently-operated subordinate CAs. However in general I would look at the extent to which the subordinates are operating within a restricted context. E.g., they're associated with a single enterprise, they're technically and contractually constrained to operate within a relatively small set of domains, etc. At the other end of the spectrum the subordinates are essentially general-purpose public CAs, issuing certs to multiple customers, for arbitrary domains, etc. Based on the information available to us, WISeKey's subordinate CAs seem to be at the restricted context end of the spectrum. Correct. We are at the extremely restricted context end of the spectrum. Provided that - there is a *good compelling reason* for using sub-ordinate certificates in first place, limited to the domains under the control of the owner (via name-constraints) and with reasonable controls in place (like annual site visits, proper CA key generation, distribution and storage); We implement all of the above mentioned controls. Based on what Kevin Blackman wrote, one major reason for the approach taken by WISeKey is the desire of customers to keep subscriber information within enterprise boundaries and/or national borders. Given the complexities of, e.g., privacy regulations in the US vs. the EU vs. other jurisdictions, this seems to me a good reason for an enterprise to operate its own subordinate CA as opposed to, for example, just acting as a Registration Authority for a subordinate CA operated elsewhere. This is exactly right. In fact several clients sensitive to this issue (Government Central Bank, Judicial Court, etc.) chose specifically the BlackBox system for this purpose. In some instances they also use managed PKI for issuing certificates to external collaborators. MPKI uses a CA in our data center and WISeKey performs the the email verification as it is not within the BB's client's domain. - name constraints in certificates are working as expected with NSS and Mozilla software *; Whether certificate-based name constraints are properly working or not, I think this is more our problem than the CA's problem, provided that the CA's cert don't cause actual technical errors in NSS/Mozilla. If a CA is implementing technical measures we consider sound, then I think they have done what we expect and require. Frank, I agree with you. Our CA controls, audits, etc. are designed to ensure that all identities are validated appropriately prior to certificate issuance. BlackBox CAs are an extremely restricted CA context where certificates issued at the CA are restricted to domains owned by the organisation. It is not necessary for domain constraints to work in NSS software for our Root to be accepted, as the control's primary point of operation is PRIOR to certificate issuance. Even if domain constraints are not interpreted properly by NSS today, they will be in the future, and the certificates issued by our MPKI system using CAs in our DCs will be perfectly unaffected. I am sure that the name constraints implementation process will be much further along, and our Root still will not have propogated very far through the typical update mechanisms. On our behalf, I thus submit that it would be a fairly extreme and an unfair penalty to wait an additional year (the first discussion period was in January of this year) to be embedded, whereas the primary controls and practices we use have not changed significantly from that point in time. (And I should add that if there problems in NSS that need additional work to fix them, the Mozilla Foundation does have the ability to fund such work.) Mozilla will have our complete support, especially with QA. Regards, Kevin Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: WISeKey root inclusion request (re-start public discussion)
On 11/21/2008 05:16 PM, kgb: Frank, I agree with you. Our CA controls, audits, etc. are designed to ensure that all identities are validated appropriately prior to certificate issuance. BlackBox CAs are an extremely restricted CA context where certificates issued at the CA are restricted to domains owned by the organisation. It is not necessary for domain constraints to work in NSS software for our Root to be accepted, as the control's primary point of operation is PRIOR to certificate issuance. Even if domain constraints are not interpreted properly by NSS today, they will be in the future, and the certificates issued by our MPKI system using CAs in our DCs will be perfectly unaffected. I am sure that the name constraints implementation process will be much further along, and our Root still will not have propogated very far through the typical update mechanisms. On our behalf, I thus submit that it would be a fairly extreme and an unfair penalty to wait an additional year (the first discussion period was in January of this year) to be embedded, whereas the primary controls and practices we use have not changed significantly from that point in time. Kevin, are you recording all domain names and/or email addresses of the subject line also in the subject alt name extension? If yes, the problem is solved, if not, could you modify your issuance of end user certificates to include all of the validated domain names and/or email addresses in the SAN extension? BTW, this is the information I could gather about the state of NSS, it seems to me trivial to achieve adherence and correct functioning of the software. -- 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: WISeKey root inclusion request (re-start public discussion)
Hi Eddy, On Nov 21, 8:16 pm, Eddy Nigg [EMAIL PROTECTED] wrote: On 11/21/2008 05:16 PM, kgb: Frank, I agree with you. Our CA controls, audits, etc. are designed to ensure that all identities are validated appropriately prior to certificate issuance. BlackBox CAs are an extremely restricted CA context where certificates issued at the CA are restricted to domains owned by the organisation. It is not necessary for domain constraints to work in NSS software for ourRootto be accepted, as the control's primary point of operation is PRIOR to certificate issuance. Even if domain constraints are not interpreted properly by NSS today, they will be in the future, and the certificates issued by our MPKI system using CAs in our DCs will be perfectly unaffected. I am sure that the name constraints implementation process will be much further along, and ourRootstill will not have propogated very far through the typical update mechanisms. On our behalf, I thus submit that it would be a fairly extreme and an unfair penalty to wait an additional year (the first discussion period was in January of this year) to be embedded, whereas the primary controls and practices we use have not changed significantly from that point in time. Kevin, are you recording all domain names and/or email addresses of the subject line also in the subject alt name extension? If yes, the problem is solved, if not, could you modify your issuance of end user certificates to include all of the validated domain names and/or email addresses in the SAN extension? BTW, this is the information I could gather about the state of NSS, it seems to me trivial to achieve adherence and correct functioning of the software. For e.g. S/MIME certs, If you mean if subject alt name email contains the email address, not just SubjectDN-E, then yes this is the case with the majority of certificates issued by the BlackBox CAs, but not all. I took a quick look at some customer SMIME certificates and sometimes E is only included in the Subject DN. Some customers don't include the SAN in their certificate templates, it seems particularly those that use non-western character sets. I am interpreting that you mean modify the issuance of end user certs to always include the SAN extension, as well as only validated domain names and/or email addresses. ? Only validated and approved domain names can be included in a cert, whether in the Subject DN or the SAN. It is the default template, and best practice that the SAN (e.g. RFC822, dnsName) to be filled in the certificates. Its the case for some but not all customers. I really hope its not necessary once we can guarantee that only validated domains are used in the certificates. Regards, Kevin -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org- Hide quoted text - - Show quoted text - ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: WISeKey root inclusion request (re-start public discussion)
On 11/21/2008 10:12 PM, kgb: Only validated and approved domain names can be included in a cert, whether in the Subject DN or the SAN. It is the default template, and best practice that the SAN (e.g. RFC822, dnsName) to be filled in the certificates. Its the case for some but not all customers. I really hope its not necessary once we can guarantee that only validated domains are used in the certificates. The issue I care mostly about is, what happens when one if these systems get compromised without you (the CA) ever detecting. Since those system aren't under your control, this is entirely possible and the risk is certainly higher than at your infrastructure. The threats may come from unknown source or from the customer himself (or their employees). The from you issued CA certificate with a path length of 0 and naming constraints limitation is what convinces me as a reasonable protection regarding above case. However it would have to be enforced by SAN extension. How come your customers can decide if to include the relevant alternative name or not? Isn't this something you should control? -- 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: WISeKey root inclusion request (re-start public discussion)
On Nov 19, 2:27 am, Eddy Nigg [EMAIL PROTECTED] wrote: On 11/19/2008 01:59 AM, kgb: Hi Kevin, WISeKey has made some changes to its practices, since the last public discussion period. I'm glad to hear that! Can you point to what specifically has been changed since then? Probably the most important change in stated practice, is that it is reflected that every CA is audited at least once annually. This is the case for all active CAs. BlackBox Subordinate CAs are restricted to issue certificates for domains that are owned by the company that is responsible for them, quite unlike the typical root signing done by other companies. How are email certificates validated beyond that? Are they validated - or is it a catch-all verification for all email certificates under the respective domain name(s)? Email certificates are also restricted to the organisation's domains. We include a Constraint in the Issuing CA itself, preventing the same CA software to issue certificates that don’t comply with this Domain Restriction (web, email, User Principal Name, etc.) The company database (such as existing HR, or IDM) of organisation, with details of the organisation's users, including their email addresses, is the principal source of data for certificates. Bounce back email verification procedure proving access to the email account is also accepted, but this is inefficient in the enterprise context, as the enterprises IT systems are aware of the email address book. In addition other identity data in the certificate must come from a verified source, e.g. HR database of identity data that is well- maintained and was created based on face to face or direct verification of the person. BlackBox subordinate CAs are also audited onsite at least once annually. By whom? I remember from the last discussion that you weren't performing on-site visits or only randomly, download of the software and CA keys were provided via Internet download. Currently it is WISeKey that audits all our CAs, we review the CAs at least once annually, or more regularly as we are more often present on some client sites. In addition to the controls we place on issuance, we also place monitoring controls and obtain regular reports. All CA keys are generated within accredited HSMs. No CA private Keys are provided via Internet download - this has never been the case. CA keys have, and are always generated within a protected HSM. There have been changes to the policies and practices. The CIDClassed document is a summary of WK practices and certificate classes. OK, I will examine this document further then... WISekey's products do not circumvent the audit requirement. WISeKey's products conform with the basic requirements of the Mozilla CA policy. WISeKey subordinate CAs in the BlackBox category can only issue certificates containing domain names that have been validated as being owned by the customer. These CAs are audited physically onsite, there are technical controls preventing the issuance of certificates containing any other domain name, and there are additional monitoring controls. Did your auditor perform random verifications of those visits, verify some of these installations and the technical controls? You don't have to answer this question, but it would be nevertheless interesting to understand the extend of the audit performed. Our auditor has reviewed all of our policies and practices, controls, and has accepted them as being sufficient. The auditor reviews audit information from all CAs, and can request to visit any or all CA sites at any time. Which ones, how many, they have done for the last year, audit etc., is and remains confidential. What are your requirements and controls concerning physical and logical access to the system(s)? (pointer to the CPS section is fine) For systems hosted in our DC, section 4 of the Issuing CA CPSs in the repository applies (www.wisekey.com/repository). For TrustCenter (BB) CAs - those CAs on customer sites, the relevant excerpt is as follows:- 4.PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS 4.1. Physical Controls for the Issuing CA The hardware and software for the Issuing CA is maintained on-line in a secured facility with perimeter security and enforced internal access controls. 4.2. Procedural Controls No member of staff is allowed to gain physical access or operate any component of the Issuing CA without the presence of other designated members of staff who have the skills required to confirm that no unauthorized or inappropriate actions are conducted. Procedures are defined and documented for all operations upon the Issuing CA. Operating procedures are regularly reviewed in the light of new operational requirements. 4.3. Personnel Controls All ISSUING CA OPERATOR staff involved in the operation of the Issuing CA is subjected to background checks and vetting according to ISSUING CA
Re: WISeKey root inclusion request (re-start public discussion)
Hi Eddy, On Nov 19, 3:14 am, Eddy Nigg [EMAIL PROTECTED] wrote: Frank: TheWisekeycase could be where we might draw the line. Provided that - there is a *good compelling reason* for using sub-ordinate certificates in first place, limited to the domains under the control of the owner (via name-constraints) and with reasonable controls in place (like annual site visits, proper CA key generation, distribution and storage); - name constraints in certificates are working as expected with NSS andMozillasoftware *; - reasonable verifications are performed of the sub-ordinate certificate owner; I tend to suggest to exclude the audit requirement for this specific case. It should however represent the line between the other cases. * One thing I'm not sure about is concerning S/MIME certificates and their verification requirements. And do name-constraints work with S/MIME? Name-constraints work on the level of the CA, and this is what we rely on together with the audit and monitoring tools. The CA looks at its certificate, and won't issue a request SMIME or otherwise that violates the name constraints. Kevin (fromWisekey): Why is a sub-ordinate CA certificate needed for this product, if it's limited to a certain set of domain names? Can't the same be achieved by simply issuing from a general sub CA under the control of the parent CA? What are the differences for the customer (I mean, it doesn't really matter if a site certificate or email certificate is issued from a sub CA under the control of the parent CA or from a different sub CA under the control of the owner. In the end of the day there may be only a certain set of domain names for the same set of web sites)? We offer both types of delivery. We have many managed PKI customers. However some agencies don't wish their ID information to leave their premises, or to cross national borders; or desire to have closer integration with the ID lifecycle management software and internal directory, which is far easier and more efficient with the BlackBox system, and its also far more cost effective especially in large user populations. There are also other reasons, but those are probably the most important. Nelson: Do name-constraints work as expected with NSS and Firefox/Thunderbird etc.? I didn't had a chance to test this ever...Are there some test cases with correctly and wrongfully issued certificate which would demonstrate the correct functioning? What about S/MIME certificates? -- 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: WISeKey root inclusion request (re-start public discussion)
Eddy Nigg wrote: The Wisekey case could be where we might draw the line. I'm not sure exactly which message (of mine or someone else's) you're responding to. In any case I don't think there's a bright line between the various scenarios involving independently-operated subordinate CAs. However in general I would look at the extent to which the subordinates are operating within a restricted context. E.g., they're associated with a single enterprise, they're technically and contractually constrained to operate within a relatively small set of domains, etc. At the other end of the spectrum the subordinates are essentially general-purpose public CAs, issuing certs to multiple customers, for arbitrary domains, etc. Based on the information available to us, WISeKey's subordinate CAs seem to be at the restricted context end of the spectrum. Provided that - there is a *good compelling reason* for using sub-ordinate certificates in first place, limited to the domains under the control of the owner (via name-constraints) and with reasonable controls in place (like annual site visits, proper CA key generation, distribution and storage); Based on what Kevin Blackman wrote, one major reason for the approach taken by WISeKey is the desire of customers to keep subscriber information within enterprise boundaries and/or national borders. Given the complexities of, e.g., privacy regulations in the US vs. the EU vs. other jurisdictions, this seems to me a good reason for an enterprise to operate its own subordinate CA as opposed to, for example, just acting as a Registration Authority for a subordinate CA operated elsewhere. - name constraints in certificates are working as expected with NSS and Mozilla software *; Whether certificate-based name constraints are properly working or not, I think this is more our problem than the CA's problem, provided that the CA's cert don't cause actual technical errors in NSS/Mozilla. If a CA is implementing technical measures we consider sound, then I think they have done what we expect and require. (And I should add that if there problems in NSS that need additional work to fix them, the Mozilla Foundation does have the ability to fund such work.) Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: WISeKey root inclusion request (re-start public discussion)
On 11/20/2008 10:21 PM, Frank Hecker: Eddy Nigg wrote: The Wisekey case could be where we might draw the line. I'm not sure exactly which message (of mine or someone else's) you're responding to. I refereed to the general discussion about sub roots. In any case I don't think there's a bright line between the various scenarios involving independently-operated subordinate CAs. On the other hand I think we should be clear in relation to the requirements placed upon the CAs. We should define them as clearly as possible in order to allow CAs prepare accordingly. Based on the information available to us, WISeKey's subordinate CAs seem to be at the restricted context end of the spectrum. Yes. Additionally one of the major concerns have apparently been corrected! As I mentioned earlier, I think that name-constraints and mandatory self-auditing by the CA seem to me sufficient. Based on what Kevin Blackman wrote, one major reason for the approach taken by WISeKey is the desire of customers to keep subscriber information within enterprise boundaries and/or national borders. Given the complexities of, e.g., privacy regulations in the US vs. the EU vs. other jurisdictions, this seems to me a good reason for an enterprise to operate its own subordinate CA as opposed to, for example, just acting as a Registration Authority for a subordinate CA operated elsewhere. I think that argument is somewhat far-fetched as the customer could work with a local authority instead. As I understood the subscriber information have to be disclosed to the CA anyway (monitoring, evidence and audit trail etc), hence I'm not really convinced. Integration into enterprise infrastructure however seems to me more logical... Whether certificate-based name constraints are properly working or not, I think this is more our problem than the CA's problem, provided that the CA's cert don't cause actual technical errors in NSS/Mozilla. If a CA is implementing technical measures we consider sound, then I think they have done what we expect and require. In this case, name-constraints are clearly part of the policy regulating those sub CAs and in my opinion the most convincing argument in favor for self-auditing of those installation as opposed to the general audit requirement. If name-constrains don't work as expected, an inclusion will have to be conditional on implementation. There shouldn't be a situation where the issuance of the sub-CA is based clearly on name-constraints regulation and NSS can't support it. Right now it's a hypothetical concern because I don't know what the situation is. Hopefully Nelson or somebody else will provide this information within reasonable time. (And I should add that if there problems in NSS that need additional work to fix them, the Mozilla Foundation does have the ability to fund such work.) Great! -- 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: WISeKey root inclusion request (re-start public discussion)
On 11/20/2008 06:34 PM, kb: Probably the most important change in stated practice, is that it is reflected that every CA is audited at least once annually. This is the case for all active CAs. Kevin, thanks for clarifying this. It indeed was one of the concerns raised last time. The company database (such as existing HR, or IDM) of organisation, with details of the organisation's users, including their email addresses, is the principal source of data for certificates. OK. Bounce back email verification procedure proving access to the email account is also accepted, but this is inefficient in the enterprise context... That's why I asked... ;-) In addition other identity data in the certificate must come from a verified source, e.g. HR database of identity data that is well- maintained and was created based on face to face or direct verification of the person. Excellent! Currently it is WISeKey that audits all our CAs, we review the CAs at least once annually, or more regularly as we are more often present on some client sites. In addition to the controls we place on issuance, we also place monitoring controls and obtain regular reports. Last question: Are there any sub CAs besides the blackbox product (with name-constraints) which are external to your physical infrastructure? I think there is not, but can you confirm 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: WISeKey root inclusion request (re-start public discussion)
Eddy Nigg wrote: The Wisekey case could be where we might draw the line. Provided that - there is a *good compelling reason* for using sub-ordinate certificates in first place, limited to the domains under the control of the owner (via name-constraints) and with reasonable controls in place (like annual site visits, proper CA key generation, distribution and storage); I wonder how you want to limit the domains via name constraint extension in current business practice. I have a customer who has ~2 registered domains. They bought another big company with ~3 registered domains. They usually register all variants of product names under all top-level domains so the number is growing quite fast. For each domain there MAY be SSL certs issued by an own sub CA. In this environment the naming constraints are just defined by contract with the root CA owner not by cert extension. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: WISeKey root inclusion request (re-start public discussion)
Eddy Nigg wrote: I believe that the policy (and/or other relevant policy guiding statements) should be clear in respect what Mozilla requires from the CAs. It's a nice ideal, but I wonder myself whether it can be achieved. This is one of the reasons why we have ended up with the race-to-the-bottom in secure browsing; necessitating (?) the EV thing, etc etc. Here we are, 14 years after this started, and we still haven't got a clear and reasonable regime. That should tell us something :) Not that I disagree with your central point that it *should be* clear, it is just that I wonder if it can be clear. This is important for planning and preparing for the CAs themselves, it's important for us in order to make the right judgment. I think that a case-by-case approach is at least unfair and hardly sustainable in the long term. Yep, exactly, but... I think in some cases it might make sense to require audits for all subordinates, and in some cases it might not. Can you define those cases? I think if the subroots were managed by the lead CA, and the CPS said they were under the same set of policies, then there would be little point in requiring separate audits. If on the other hand they were managed by other organisations, and they were not under some agreement, then there is an open-ended question, so it might make sense to say (in a Mozo requirement) that uncontrolled subroots are to be separately audited. The problem then being that between those two points there is an awful lot of space. What are the requirements and where doesn't and where does it make sense? How to draw the line? You must be specific in order for us to understand the differences! Well, I suspect Mozo doesn't know. Demanding a solution isn't going to result in a solution, but it might result in a line being drawn. Then, in 2 years we'll be back here challenging that line, and grumbling about how some smart CA crossed the line or bent it or broke it or made lotsa dosh or something. In such a circumstance, case-by-case makes sense. Mozo might benefit by letting the market experiment. That old socialism stuff where we tell everyone what they have to do is so out of style these days (although you wouldn't know it if you looked at the finance markets ;) . iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: WISeKey root inclusion request (re-start public discussion)
On 11/18/2008 05:14 PM, Ian G: Eddy Nigg wrote: I believe that the policy (and/or other relevant policy guiding statements) should be clear in respect what Mozilla requires from the CAs. It's a nice ideal, but I wonder myself whether it can be achieved. This is one of the reasons why we have ended up with the race-to-the-bottom in secure browsing; necessitating (?) the EV thing, etc etc. It's not an ideal, but very real, implementable and actually done not only here, but also elsewhere. The trend is not a race to the bottom, but higher the overall level of quality of PKI after we reached the bottom - for the good of all parties involved. I'm not in favor to invent unnecessary requirements, but a sound clear reasonable policy with the basic security requirements covered. This was the intention of the Mozilla CA policy in first place which is very reasonable. Of course not everything was understood back then and it's time to fix a few points. Not that I disagree with your central point that it *should be* clear, it is just that I wonder if it can be clear. Of course it can and I don't see any reason whatsoever why not. I think if the subroots were managed by the lead CA, and the CPS said they were under the same set of policies, then there would be little point in requiring separate audits. Exactly. As opposed to sub roots which aren't operated by the CA, not physically at the same infrastructure and not under the same responsibility. An audit must cover the full infrastructure even in case the sub ordinate CA is elsewhere. The problem then being that between those two points there is an awful lot of space. I don't think so and a policy requirement can be clear-cut. More or less in one sentence. -- 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: WISeKey root inclusion request (re-start public discussion)
On Nov 18, 2:54 am, Eddy Nigg [EMAIL PROTECTED] wrote: On 11/14/2008 11:12 PM, Frank Hecker: ...in the short term I'm going to try to restart CA public In this particular case I think that the practice in question doesn't meet the requirements of the Mozilla CA policy. This includes in particular section 6 and 7 of the Mozilla CA Policy. I believe that WISeKey's practices and polices do meet the requirements of section 6 and 7 of Mozilla's CA policy, and a review of the posted documentation and audit guidelines in the report should confirm that. WISeKey has made some changes to its practices, since the last public discussion period. BlackBox Subordinate CAs are restricted to issue certificates for domains that are owned by the company that is responsible for them, quite unlike the typical root signing done by other companies. BlackBox subordinate CAs are also audited onsite at least once annually. WISeKey has been through an initial comment period a while back, during which we got nvolved in a lengthy discussion about WISeKey's Blackbox product (a CA in a box product intended for enterprise deployment) and whether and how auditing was done for WISeKey's subordinate CAs associated with that product. WISeKey supplied more information about their arrangements, which you can find in the bug. Frank, I greatly missed the thorough and systematic work of Kathleen in this bug and it's a pity she didn't perform another round of information gathering in case some new evidence was provided. Anyhow, I couldn't find anything new in the bug since the last time. I'm not sure what is supposed to have changed. There have been changes to the policies and practices. The CIDClassed document is a summary of WK practices and certificate classes. Since I can't find anything new, I assume that nothing has changed and therefore the condition for inclusion didn't change at all. If we consider that all recent inclusion requests were specifically tested for such practices - most notably CAs like Comodo, but also T-Systems who's inclusion has been delayed as a result of it - I can't see any particular reason for making an exception here. Not only do their products circumvent the audit requirement, they might be in direct conflict with the basic requirements of the Mozilla CA policy such as email and domain validation (IIRC - see comment 32 in bug 371362). WISekey's products do not circumvent the audit requirement. WISeKey's products conform with the basic requirements of the Mozilla CA policy. WISeKey subordinate CAs in the BlackBox category can only issue certificates containing domain names that have been validated as being owned by the customer. These CAs are audited physically onsite, there are technical controls preventing the issuance of certificates containing any other domain name, and there are additional monitoring controls. (Additionally, I couldn't confirm that this CA commands any significant market share with the information at my disposal. I'm the opinion that it would be a mistake to make an exception on the audit requirement for sub-CAs, which in the future could serve as an argument in favor for similar scenarios. It was also pointed out at the bug that this CA is in MS software, however I suspect their policies to be also in conflict of the MS root program. Just some side-note...) WISeKey is part of the MS Windows RCA program, and have had extensive discussions with Microsoft's team prior to joining the program. The conformance of MS products with the IETF PKIX standard enable its product to work efficiently and cost effectively. They have supported WISeKey extensively in testing. WISeKey has signed the Microsoft Windows Root Certificate Program - CA agreement. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org regards, Kevin Blackman WISeKey SA ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: WISeKey root inclusion request (re-start public discussion)
On 11/19/2008 01:59 AM, kgb: Hi Kevin, WISeKey has made some changes to its practices, since the last public discussion period. I'm glad to hear that! Can you point to what specifically has been changed since then? BlackBox Subordinate CAs are restricted to issue certificates for domains that are owned by the company that is responsible for them, quite unlike the typical root signing done by other companies. How are email certificates validated beyond that? Are they validated - or is it a catch-all verification for all email certificates under the respective domain name(s)? BlackBox subordinate CAs are also audited onsite at least once annually. By whom? I remember from the last discussion that you weren't performing on-site visits or only randomly, download of the software and CA keys were provided via Internet download. There have been changes to the policies and practices. The CIDClassed document is a summary of WK practices and certificate classes. OK, I will examine this document further then... WISekey's products do not circumvent the audit requirement. WISeKey's products conform with the basic requirements of the Mozilla CA policy. WISeKey subordinate CAs in the BlackBox category can only issue certificates containing domain names that have been validated as being owned by the customer. These CAs are audited physically onsite, there are technical controls preventing the issuance of certificates containing any other domain name, and there are additional monitoring controls. Did your auditor perform random verifications of those visits, verify some of these installations and the technical controls? You don't have to answer this question, but it would be nevertheless interesting to understand the extend of the audit performed. What are your requirements and controls concerning physical and logical access to the system(s)? (pointer to the CPS section is fine) WISeKey is part of the MS Windows RCA program, and have had extensive discussions with Microsoft's team prior to joining the program. The conformance of MS products with the IETF PKIX standard enable its product to work efficiently and cost effectively. They have supported WISeKey extensively in testing. WISeKey has signed the Microsoft Windows Root Certificate Program - CA agreement. I think some enterprise scenarios are explicitly disallowed by Microsoft which your product however could implement nevertheless, specially since it's based on MSCA (as I understood). But this is beyond the scope of what we do here, it was only a side note from me. -- 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: WISeKey root inclusion request (re-start public discussion)
Frank: The Wisekey case could be where we might draw the line. Provided that - there is a *good compelling reason* for using sub-ordinate certificates in first place, limited to the domains under the control of the owner (via name-constraints) and with reasonable controls in place (like annual site visits, proper CA key generation, distribution and storage); - name constraints in certificates are working as expected with NSS and Mozilla software *; - reasonable verifications are performed of the sub-ordinate certificate owner; I tend to suggest to exclude the audit requirement for this specific case. It should however represent the line between the other cases. * One thing I'm not sure about is concerning S/MIME certificates and their verification requirements. And do name-constraints work with S/MIME? Kevin (from Wisekey): Why is a sub-ordinate CA certificate needed for this product, if it's limited to a certain set of domain names? Can't the same be achieved by simply issuing from a general sub CA under the control of the parent CA? What are the differences for the customer (I mean, it doesn't really matter if a site certificate or email certificate is issued from a sub CA under the control of the parent CA or from a different sub CA under the control of the owner. In the end of the day there may be only a certain set of domain names for the same set of web sites)? Nelson: Do name-constraints work as expected with NSS and Firefox/Thunderbird etc.? I didn't had a chance to test this ever...Are there some test cases with correctly and wrongfully issued certificate which would demonstrate the correct functioning? What about S/MIME certificates? -- 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: WISeKey root inclusion request (re-start public discussion)
On 11/14/2008 11:12 PM, Frank Hecker: ...in the short term I'm going to try to restart CA public discussions on a regular schedule. Nice to see you back here! First, the general issue of auditing subordinate CAs was something we didn't think through much when we did our Mozilla CA policy: We were thinking of a fairly simple model where a CA organization operated both its root CA(s) and also any subordinate CAs under those roots, with a CPS and associated audit that covered the both root and subordinates all. In actual practice things are more complicated, and our policy didn't really capture that complication. I'm glad that this issue is recognized as such! My personal opinion is that it doesn't make sense to try to address this complication by mandating traditional WebTrust-style audits of any and all subordinates under a root. I think this approach is impractical, and I don't think it's necessary. I'd rather look at the overall manner in which CAs exercise controls over subordinates, legally, technically, and otherwise, as well as the general nature of the subordinates and how they function in practice. Even though your statement would on general issues make sense, we must also recognize that it would be very difficult to implement. First of all it's a matter of policy and every time the policy didn't address a specific issue in the past we were in a Grey area. The problematic practices were implemented as a result of it. I believe that the policy (and/or other relevant policy guiding statements) should be clear in respect what Mozilla requires from the CAs. This is important for planning and preparing for the CAs themselves, it's important for us in order to make the right judgment. I think that a case-by-case approach is at least unfair and hardly sustainable in the long term. Incidentally those CAs which would be most likely acceptable by the terms you outlined above, are usually the ones which either audit their whole infrastructure or are not affected by the problematic practices of sub-ordinate CAs in first place. But obviously it's difficult to draw a clear line... There are various risks Mozilla needs to be prepared to take in case no clear policy is defined, mainly the inclusion-by-proxy of CAs (it rather would not have included) and questionable practices of sub-ordinate CAs. Additionally I believe that Mozilla shouldn't take the risk of including CAs (sub-ordinate or not) *without* having their physical and logical infrastructure confirmed and audited. Specially problematic are those which are independent entities in relation to the root CA and operate their own infrastructure (inclusion by proxy). It makes no sense whatsoever to require auditing of a root, if the issuing CA isn't audited at all. Recent examples have shown that it's no guaranty for adherence to the Mozilla CA policy - despite the fact that the very same (cross-signed or sub-ordinate) CAs were actually audited independently!!! (I refrain from getting into the auditing aspects, but it makes a great deal and difference for all parties involved. Otherwise Mozilla and the other browsers wouldn't made it a requirement from the beginning.) I think in some cases it might make sense to require audits for all subordinates, and in some cases it might not. Can you define those cases? What are the requirements and where doesn't and where does it make sense? How to draw the line? You must be specific in order for us to understand the differences! For purposes of this particular evaluation, my goal is for us to gain a shared understanding of what WISeKey actually does, including getting answers to any remaining questions, and then I'll make a judgement call as to whether what WISeKey is doing meets the general intent of our policy. In this particular case I think that the practice in question doesn't meet the requirements of the Mozilla CA policy. This includes in particular section 6 and 7 of the Mozilla CA Policy. WISeKey has been through an initial comment period a while back, during which we got nvolved in a lengthy discussion about WISeKey's Blackbox product (a CA in a box product intended for enterprise deployment) and whether and how auditing was done for WISeKey's subordinate CAs associated with that product. WISeKey supplied more information about their arrangements, which you can find in the bug. Frank, I greatly missed the thorough and systematic work of Kathleen in this bug and it's a pity she didn't perform another round of information gathering in case some new evidence was provided. Anyhow, I couldn't find anything new in the bug since the last time. I'm not sure what is supposed to have changed. Since I can't find anything new, I assume that nothing has changed and therefore the condition for inclusion didn't change at all. If we consider that all recent inclusion requests were specifically tested for such practices - most notably CAs like Comodo,
Re: WISeKey root inclusion request (re-start public discussion)
On 11/18/2008 03:54 AM, Eddy Nigg: Frank, I greatly missed the thorough and systematic work of Kathleen in this bug and it's a pity she didn't perform another round of information gathering in case some new evidence was provided. Anyhow, I couldn't find anything new in the bug since the last time. I'm not sure what is supposed to have changed. I forgot to mention, that in case inclusion is relevant we should gather additional information about the auditor and independent confirmation of the audit report. -- 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
WISeKey root inclusion request (re-start public discussion)
First, my sincere apologies for being missing from this group over the past few weeks. A combination of illness (both my own and family), out-of-town trips, and other Mozilla Foundation business kept me from having any significant time to devote to CA matters. I am working on ways to ensure that I am not the bottleneck in this process in the long term; in the short term I'm going to try to restart CA public discussions on a regular schedule. Per the CA schedule, the next CA on the list for public comment is WISeKey, which has applied to add its (one) root CA certificate to the Mozilla root store, as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=371362 and in the pending certificates list here: http://www.mozilla.org/projects/security/certs/pending/#WISeKey WISeKey has been through an initial comment period a while back, during which we got nvolved in a lengthy discussion about WISeKey's Blackbox product (a CA in a box product intended for enterprise deployment) and whether and how auditing was done for WISeKey's subordinate CAs associated with that product. WISeKey supplied more information about their arrangements, which you can find in the bug. We've had some lengthy discussions about the issue of auditing subordinate CAs. I'm not going to rehash all those discussions, I'll just summarize my current thinking: First, the general issue of auditing subordinate CAs was something we didn't think through much when we did our Mozilla CA policy: We were thinking of a fairly simple model where a CA organization operated both its root CA(s) and also any subordinate CAs under those roots, with a CPS and associated audit that covered the both root and subordinates all. In actual practice things are more complicated, and our policy didn't really capture that complication. My personal opinion is that it doesn't make sense to try to address this complication by mandating traditional WebTrust-style audits of any and all subordinates under a root. I think this approach is impractical, and I don't think it's necessary. I'd rather look at the overall manner in which CAs exercise controls over subordinates, legally, technically, and otherwise, as well as the general nature of the subordinates and how they function in practice. I think in some cases it might make sense to require audits for all subordinates, and in some cases it might not. For purposes of this particular evaluation, my goal is for us to gain a shared understanding of what WISeKey actually does, including getting answers to any remaining questions, and then I'll make a judgement call as to whether what WISeKey is doing meets the general intent of our policy. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
