Re: StartCom & Qihoo Incidents
Le jeudi 27 octobre 2016 09:55:09 UTC+2, Percy a écrit : > So this is it? Qihoo can continue to get away with this MITM browser? I'm afraid that can't be solved by Mozilla. Qihoo is free to sell or freely distribute their browser. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Guang Dong Certificate Authority (GDCA) root inclusion request
"When facing any requirements of laws and regulations or any demands for undergoing legal process of court and other agencies, GDCA must provide confidential information in this CP" Can GDCA specify what other agencies are included? In China, many requests are relayed simply through a phone call without any paper trail or IM and the service providers must meet the demand very quickly. Are such informal procedures honored by GDCA? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Guang Dong Certificate Authority (GDCA) root inclusion request
在 2016年10月27日星期四 UTC+8下午6:22:03，wangs...@gmail.com写道： > 在 2016年10月27日星期四 UTC+8上午8:09:06，Peter Kurrasch写道： > > I think these are both good points and my recommendation is that Mozilla > > deny GDCA's request for inclusion. > > > > > > We should not have to explain something as basic as document versioning and > > version control. If GDCA can not demonstrate sufficient controls over their > > documentation, there is no reason for the Internet community to place > > confidence in any of the other versioning systems that are needed to > > operate a CA. > > > > > > Question: Are auditors expected to review translations of CP or CPS docs > > and verify consistency between them? > > > > > > > > > > > > > > > > > > > > > > > > From: Jakob Bohm > > Sent: Saturday, October 22, 2016 9:07 AM > > To: mozilla-dev-s...@lists.mozilla.org > > Subject: Re: Guang Dong Certificate Authority (GDCA) root inclusion request > > > > > > On 21/10/2016 10:38, Han Yuwei wrote: > > > > > > I think this is a major mistake and a investgation should be conducted > > > for CPS is a critical document about CA. This is not just a translation > > > problem but a version control problem. Sometimes it can be lying. > > > > > > > Let me try to be more specific: > > > > When publishing a document called CPS version 4.3 the document with > > that number must have the same contents in all languages that have a > > document with that name and version number. > > > > When making any change, even just correcting a mistyped URL, the > > document becomes a new document version which should have a new and > > larger number than the number of the document before the change. > > Thus when a published document refers to a broken URL on your own > > server, it is often cheaper to repair the server than to publish a new > > document version. Some of the oldest CAs have been proudly > > publishing their various important files at multiple URLs corresponding > > to whatever was mentioned in old CP and CPS documents etc., only > > shutting down those URLs years after the corresponding CA roots were > > shut down. > > > > There can also be a "draft" document which has no number and which > > contains the changes that will go into the next numbered edition. Such > > a "draft" would have no official significance, as it has not been > > officially "published". For a well-planned change, the final "draft" > > would be translated and checked into the relevant languages (e.g. > > Chinese with mainland writing system, Chinese with Hong Kong and Macao > > Special Administrative Regions old writing system, English), before > > simultaneously publishing the matching documents with the same number > > on the same day. > > > > There are infinitely many version numbers in the universe to choose > > from. There are also computer programs that can generate new version > > numbers every time a draft is changed, but computers cannot decide when > > a version is good enough in all languages to make an official > > publication, and the computer generated version numbers are often > > impractical for publication because they count all the small steps that > > were not published. > > > > > > Enjoy > > > > Jakob > > -- > > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 > > This public discussion message is non-binding and may contain errors. > > WiseMo - Remote Service Management for PCs, Phones and Embedded > > ___ > > dev-security-policy mailing list > > dev-secur...@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > We’d like to explain a few points. > > 1. We have already implemented version control on Chinese version CP/CPS, the > revision and release of CP/CPS are reviewed and approved by the security > policy committee (see section 1.5 in CP/CPS). The Chinese version CP/CPS is > also reviewed by our auditor. > > 2. The Chinese version CP/CPS is the formal documents we published in our > Website. In the initial phase of "Bug 1128392", we have summited the Chinese > version CP/CPS to Mozilla, and Mozilla release a basic review list in file > "1128392-CAInformation.pdf" which contains instructions for us to summit some > chapters of the CP/CPS in English version. We are not able to provide an > accurate English version CP/CPS, but we will do our best
Re: Guang Dong Certificate Authority (GDCA) root inclusion request
在 2016年10月28日星期五 UTC+8上午2:12:32，Percy写道： > On Thursday, October 27, 2016 at 3:22:03 AM UTC-7, wangs...@gmail.com wrote: > > 在 2016年10月27日星期四 UTC+8上午8:09:06，Peter Kurrasch写道： > > > I think these are both good points and my recommendation is that Mozilla > > > deny GDCA's request for inclusion. > > > > > > > > > We should not have to explain something as basic as document versioning > > > and version control. If GDCA can not demonstrate sufficient controls over > > > their documentation, there is no reason for the Internet community to > > > place confidence in any of the other versioning systems that are needed > > > to operate a CA. > > > > > > > > > Question: Are auditors expected to review translations of CP or CPS docs > > > and verify consistency between them? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Jakob Bohm > > > Sent: Saturday, October 22, 2016 9:07 AM > > > To: mozilla-dev-s...@lists.mozilla.org > > > Subject: Re: Guang Dong Certificate Authority (GDCA) root inclusion > > > request > > > > > > > > > On 21/10/2016 10:38, Han Yuwei wrote: > > > > > > > > I think this is a major mistake and a investgation should be conducted > > > > for CPS is a critical document about CA. This is not just a translation > > > > problem but a version control problem. Sometimes it can be lying. > > > > > > > > > > Let me try to be more specific: > > > > > > When publishing a document called CPS version 4.3 the document with > > > that number must have the same contents in all languages that have a > > > document with that name and version number. > > > > > > When making any change, even just correcting a mistyped URL, the > > > document becomes a new document version which should have a new and > > > larger number than the number of the document before the change. > > > Thus when a published document refers to a broken URL on your own > > > server, it is often cheaper to repair the server than to publish a new > > > document version. Some of the oldest CAs have been proudly > > > publishing their various important files at multiple URLs corresponding > > > to whatever was mentioned in old CP and CPS documents etc., only > > > shutting down those URLs years after the corresponding CA roots were > > > shut down. > > > > > > There can also be a "draft" document which has no number and which > > > contains the changes that will go into the next numbered edition. Such > > > a "draft" would have no official significance, as it has not been > > > officially "published". For a well-planned change, the final "draft" > > > would be translated and checked into the relevant languages (e.g. > > > Chinese with mainland writing system, Chinese with Hong Kong and Macao > > > Special Administrative Regions old writing system, English), before > > > simultaneously publishing the matching documents with the same number > > > on the same day. > > > > > > There are infinitely many version numbers in the universe to choose > > > from. There are also computer programs that can generate new version > > > numbers every time a draft is changed, but computers cannot decide when > > > a version is good enough in all languages to make an official > > > publication, and the computer generated version numbers are often > > > impractical for publication because they count all the small steps that > > > were not published. > > > > > > > > > Enjoy > > > > > > Jakob > > > -- > > > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > > > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 > > > This public discussion message is non-binding and may contain errors. > > > WiseMo - Remote Service Management for PCs, Phones and Embedded > > > ___ > > > dev-security-policy mailing list > > > dev-secur...@lists.mozilla.org > > > https://lists.mozilla.org/listinfo/dev-security-policy > > > > We’d like to explain a few points. > > > > 1. We have already implemented version control on Chinese version CP/CPS, > > the revision and release of CP/CPS are reviewed and approved by the > > security policy committee (see section 1.5 in CP/CPS). The Chinese version > > CP/CPS is also reviewed by our auditor. > > > > 2. The Chinese version CP/CPS is the formal documents we published in our > > Website. In the initial phase of "Bug 1128392", we have summited the > > Chinese version CP/CPS to
Re: Draft Email - Non-Disclosed SubCAs
I have sent the email to the following CAs. Root Owner | # Certs still to add to Salesforce Actalis 2 Asseco Data Systems S.A. (previously Unizeto Certum)1 Atos3 Autoridad de Certificacion Firmaprofesional 6 Camerfirma 19 certSIGN6 China Internet Network Information Center (CNNIC) 1 Chunghwa Telecom Corporation1 Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert) 2 Cybertrust Japan / JCSI 1 Dhimyotis / Certigna24 EDICOM 1 e-tugra 4 Government of Japan, Ministry of Internal Affairs and Communications1 Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV)3 Government of Taiwan, Government Root Certification Authority (GRCA)15 Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM) 3 Internet Security Research Group (ISRG) 4 Izenpe S.A. 9 Microsec e-Szignó CA4 NetLock Ltd.5 QuoVadis9 RSA the Security Division of EMC20 SECOM Trust Systems Co. Ltd.13 Swisscom (Switzerland) Ltd 8 SwissSign AG20 Trustis 4 TurkTrust 12 Visa2 WISeKey 1 ~~ Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Guang Dong Certificate Authority (GDCA) root inclusion request
On Thursday, October 27, 2016 at 3:22:03 AM UTC-7, wangs...@gmail.com wrote: > 在 2016年10月27日星期四 UTC+8上午8:09:06，Peter Kurrasch写道： > > I think these are both good points and my recommendation is that Mozilla > > deny GDCA's request for inclusion. > > > > > > We should not have to explain something as basic as document versioning and > > version control. If GDCA can not demonstrate sufficient controls over their > > documentation, there is no reason for the Internet community to place > > confidence in any of the other versioning systems that are needed to > > operate a CA. > > > > > > Question: Are auditors expected to review translations of CP or CPS docs > > and verify consistency between them? > > > > > > > > > > > > > > > > > > > > > > > > From: Jakob Bohm > > Sent: Saturday, October 22, 2016 9:07 AM > > To: mozilla-dev-s...@lists.mozilla.org > > Subject: Re: Guang Dong Certificate Authority (GDCA) root inclusion request > > > > > > On 21/10/2016 10:38, Han Yuwei wrote: > > > > > > I think this is a major mistake and a investgation should be conducted > > > for CPS is a critical document about CA. This is not just a translation > > > problem but a version control problem. Sometimes it can be lying. > > > > > > > Let me try to be more specific: > > > > When publishing a document called CPS version 4.3 the document with > > that number must have the same contents in all languages that have a > > document with that name and version number. > > > > When making any change, even just correcting a mistyped URL, the > > document becomes a new document version which should have a new and > > larger number than the number of the document before the change. > > Thus when a published document refers to a broken URL on your own > > server, it is often cheaper to repair the server than to publish a new > > document version. Some of the oldest CAs have been proudly > > publishing their various important files at multiple URLs corresponding > > to whatever was mentioned in old CP and CPS documents etc., only > > shutting down those URLs years after the corresponding CA roots were > > shut down. > > > > There can also be a "draft" document which has no number and which > > contains the changes that will go into the next numbered edition. Such > > a "draft" would have no official significance, as it has not been > > officially "published". For a well-planned change, the final "draft" > > would be translated and checked into the relevant languages (e.g. > > Chinese with mainland writing system, Chinese with Hong Kong and Macao > > Special Administrative Regions old writing system, English), before > > simultaneously publishing the matching documents with the same number > > on the same day. > > > > There are infinitely many version numbers in the universe to choose > > from. There are also computer programs that can generate new version > > numbers every time a draft is changed, but computers cannot decide when > > a version is good enough in all languages to make an official > > publication, and the computer generated version numbers are often > > impractical for publication because they count all the small steps that > > were not published. > > > > > > Enjoy > > > > Jakob > > -- > > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 > > This public discussion message is non-binding and may contain errors. > > WiseMo - Remote Service Management for PCs, Phones and Embedded > > ___ > > dev-security-policy mailing list > > dev-secur...@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > We’d like to explain a few points. > > 1. We have already implemented version control on Chinese version CP/CPS, the > revision and release of CP/CPS are reviewed and approved by the security > policy committee (see section 1.5 in CP/CPS). The Chinese version CP/CPS is > also reviewed by our auditor. > > 2. The Chinese version CP/CPS is the formal documents we published in our > Website. In the initial phase of "Bug 1128392", we have summited the Chinese > version CP/CPS to Mozilla, and Mozilla release a basic review list in file > "1128392-CAInformation.pdf" which contains instructions for us to summit some > chapters of the CP/CPS in English version. We are not able to provide an > accurate English version CP/CPS,
Re: Draft Email - Non-Disclosed SubCAs
On Thursday, October 27, 2016 at 4:14:35 AM UTC-7, Rob Stradling wrote: > So, to ensure that no CA can claim that they didn't know, I'd like to > see the "must keep disclosing intermediates to Salesforce on an ongoing > basis" requirement explicitly stated: > 1. in the next version of the Mozilla CA Policy. Noted here: https://wiki.mozilla.org/CA:CertificatePolicyV2.3#General_Policy_Cleanup > 2. in the next CA Communication. Noted in my list for the next CA Communication to all CAs. This is currently on hold, awaiting for when the New Validation Rules in BRs are all settled. I started the new section in the wiki page: https://wiki.mozilla.org/CA:SalesforceCommunity#CA_Responsibilities Will appreciate feedback on it. Note that the email draft has been updated to point to this section in the wiki page. Here's the updated text for this current email that I will hopefully send out today using the new email capability that we added to the production instance of the CA Community in Salesforce yesterday. ~~ Subject: ACTION REQUIRED: Non-Disclosed non-technically-constrained Intermediate Certs Message: Dear Certification Authority, You are receiving this email because we have become aware that there are non-technically-constrained intermediate certificates that chain up to your root certificates that are included in Mozilla’s program that have not been entered into the CA Community in Salesforce. The deadline for CAs to disclose their intermediate certificate data in the CA Community in Salesforce was June 2016. Mozilla is going to begin discussions in the mozilla.dev.security.policy forum about action to take for any remaining non-disclosed non-technically-constrained intermediate certificates and the CAs who are responsible for those CA hierarchies. Please see https://wiki.mozilla.org/CA:SalesforceCommunity#CA_Responsibilities for information about which intermediate certificate data you are expected to enter into the CA Community in Salesforce, and instructions on how to do so. The following was stated in Mozilla’s March 2016 CA Communication (https://wiki.mozilla.org/CA:Communications#March_2016): Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. In particular, CAs must add records to the CA Community in Salesforce for all certificates that are capable of being used to issue new certificates, and which directly or transitively chain to their certificate(s) included in Mozilla’s CA Certificate Program that are not Technically Constrained via Extended Key Usage and Name Constraint settings. Intermediate certificates are considered to be technically constrained, and do not need to be added to the CA Community in Salesforce if: - The intermediate certificate has the Extended Key Usage (EKU) extension and the EKU does not include any of these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth; or - The EKU extension in the intermediate certificate includes the anyExtendedKeyUsage or id-kp-serverAuth KeyPurposeIds, and the intermediate certificate includes the Name Constraints extension as described in section 7.1.5 of the CA/Browser Forum's Baseline Requirements; or - The root certificate is not enabled with the Websites trust bit. Records should also be added to the CA Community in Salesforce for revoked certificates that were capable of being used to issue new certificates, and which directly or transitively chain to their certificate(s) included in Mozilla’s CA Certificate Program and were not
Re: Draft Email - Non-Disclosed SubCAs
On 27/10/16 09:31, Gervase Markham wrote: > On 26/10/16 22:02, Kathleen Wilson wrote: >> Please see >> https://wiki.mozilla.org/CA:SalesforceCommunity#CA_Community_in_Salesforce >> and let me know if you still think we need to add a sentence to the >> wiki page stating that CAs are expected to maintain this data on an >> ongoing basis. > > Well, like I said, it should be obvious to anyone with half a brain but > explicit is always clearer than implicit. Being explicit also allows us > to set expectations about how quickly the info is updated after events, > e.g. how soon must new intermediates be reported. +1 Kathleen, >From previous discussions on this list and from reading... https://wiki.mozilla.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F ...and other wiki pages, it's obvious to me that you expect CAs to maintain this data on an ongoing basis. However... It was I who suggested to Gerv (at the CABForum F2F last week) that this point needs to be stated to CAs more explicitly. Yes, https://wiki.mozilla.org/CA:SalesforceCommunity is clear, but is it actually fair to assume that all CAs are aware that that wiki page essentially forms part of Mozilla's CA policy? The March 2016 CA Communication said... "Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016." "Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates...The date that you enter must be on or before June 30, 2016" ...which made it sound like a one-time census, rather than an ongoing requirement. Whilst I think it's obvious to all CAs that your CA Communications essentially form part of your CA Policy, I suspect it's _not_ obvious to all CAs that the same is true of (at least some of) your wiki pages. So, to ensure that no CA can claim that they didn't know, I'd like to see the "must keep disclosing intermediates to Salesforce on an ongoing basis" requirement explicitly stated: 1. in the next version of the Mozilla CA Policy. 2. in the next CA Communication. >> ~~ Subject: ACTION REQUIRED: Non-Disclosed >> non-technically-constrained Intermediate Certs >> >> Dear Certification Authority, >> >> You are receiving this email because our records indicate > > Well, Rob Stradling's records indicate :-) We might instead say that > "because we have become aware" +1 It's great that folks are finding https://crt.sh/mozilla-disclosures useful, but clearly it's not an authoritative Mozilla data source. Trust, but verify. :-) -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Guang Dong Certificate Authority (GDCA) root inclusion request
在 2016年10月27日星期四 UTC+8上午8:09:06，Peter Kurrasch写道： > I think these are both good points and my recommendation is that Mozilla deny > GDCA's request for inclusion. > > > We should not have to explain something as basic as document versioning and > version control. If GDCA can not demonstrate sufficient controls over their > documentation, there is no reason for the Internet community to place > confidence in any of the other versioning systems that are needed to operate > a CA. > > > Question: Are auditors expected to review translations of CP or CPS docs and > verify consistency between them? > > > > > > > > > > > > From: Jakob Bohm > Sent: Saturday, October 22, 2016 9:07 AM > To: mozilla-dev-s...@lists.mozilla.org > Subject: Re: Guang Dong Certificate Authority (GDCA) root inclusion request > > > On 21/10/2016 10:38, Han Yuwei wrote: > > > > I think this is a major mistake and a investgation should be conducted for > > CPS is a critical document about CA. This is not just a translation problem > > but a version control problem. Sometimes it can be lying. > > > > Let me try to be more specific: > > When publishing a document called CPS version 4.3 the document with > that number must have the same contents in all languages that have a > document with that name and version number. > > When making any change, even just correcting a mistyped URL, the > document becomes a new document version which should have a new and > larger number than the number of the document before the change. > Thus when a published document refers to a broken URL on your own > server, it is often cheaper to repair the server than to publish a new > document version. Some of the oldest CAs have been proudly > publishing their various important files at multiple URLs corresponding > to whatever was mentioned in old CP and CPS documents etc., only > shutting down those URLs years after the corresponding CA roots were > shut down. > > There can also be a "draft" document which has no number and which > contains the changes that will go into the next numbered edition. Such > a "draft" would have no official significance, as it has not been > officially "published". For a well-planned change, the final "draft" > would be translated and checked into the relevant languages (e.g. > Chinese with mainland writing system, Chinese with Hong Kong and Macao > Special Administrative Regions old writing system, English), before > simultaneously publishing the matching documents with the same number > on the same day. > > There are infinitely many version numbers in the universe to choose > from. There are also computer programs that can generate new version > numbers every time a draft is changed, but computers cannot decide when > a version is good enough in all languages to make an official > publication, and the computer generated version numbers are often > impractical for publication because they count all the small steps that > were not published. > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > ___ > dev-security-policy mailing list > dev-secur...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy We’d like to explain a few points. 1. We have already implemented version control on Chinese version CP/CPS, the revision and release of CP/CPS are reviewed and approved by the security policy committee (see section 1.5 in CP/CPS). The Chinese version CP/CPS is also reviewed by our auditor. 2. The Chinese version CP/CPS is the formal documents we published in our Website. In the initial phase of "Bug 1128392", we have summited the Chinese version CP/CPS to Mozilla, and Mozilla release a basic review list in file "1128392-CAInformation.pdf" which contains instructions for us to summit some chapters of the CP/CPS in English version. We are not able to provide an accurate English version CP/CPS, but we will do our best to finish this translations and upload for reviewing process. We will upload the new English version CP/CPS for reference ASAP. However the English version CP/CPS should not be considered as formal documents. In case of any discrepancy between two
Re: Technically Constrained Sub-CAs and the BRs
On 26/10/16 18:53, Ryan Sleevi wrote: > interpretation of #2. This is also why I support the mandatory > disclosure of TCSCs to Mozilla Salesforce, to ensure that the > Technical Constraints are properly implemented and conforming in > order for the CA to claim its exclusion. If we were to require this, would it present administrative issue? At the moment, we are dealing with approximately 2500 intermediates in Salesforce. If we added the TCSCs, do we have any idea what that number would go up to? Rob has only discovered 300 TCSCs, so perhaps the increase would not be so large? Or are lots of them hidden from public view? > Since we have precedent of using the BRs to set ecosystem-wide > minimum security requirements (to receive secure UI), such as using > unambiguous subjectAltNames, presenting the right EKU, and using > reasonably sufficient cryptographic key sizes (RSA-2048, ECC-256), I > think the interpretation that nothing below a TCSC can do any harm is > a bad interpretation. I think you are correct. The view "it can't hurt" was, at least in my mind, related to the risk of misissuance. And therefore I was not so concerned about them getting an audit, using a level 4 HSM and so on. Perhaps we did not give sufficient consideration to issues like use of SHA-1. > While I'm supportive, in general, of you're suggested modification, I > do want to highlight the implications that it brings. It means that > TCSCs must ensure FIPS 140-2 Level 3 HSMs and key protection, audit > logs, etc. In effect, the only benefit a TCSC provides is that it > allows you to avoid an independent auditor, but doesn't allow you to > avoid any of the substantial obligations in capital to conform to the > BRs and the netsec requirements. Right - but we would just be matching what the BRs already require, wouldn't we? So if we adopted this view, we wouldn't be giving anyone any costs they didn't already have. > Alternatively, we could try to suggest that a TCSCs' certificates > must conform to the certificate profile, but not other obligations > (like separation of duty, offline protection, etc), but then we still > have to figure out which elements of that technical profile are > relevant - for example, OCSP and CRL services for the TCSC. This seems like a route worth investigating; the work required to decide this would not be massive. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartCom & Qihoo Incidents
So this is it? Qihoo can continue to get away with this MITM browser? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
