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 OPERATOR internal security policies. Personnel involved in the control and operation of the Issuing CA shall be sufficiently trained to comply with the functions allocated to their role and shall be provided with ongoing training to ensure the appropriate levels of awareness of the security policies and procedures. > > 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, Kevin WISeKey SA > 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
