Re: Drafting Q1 2016 CA Communication
On 03/22/16 16:33, kwil...@mozilla.com wrote:
> The following 'ACTION #1c' has been added to the communication, which
> is here: https://wiki.mozilla.org/CA:Communications#March_2016 and
> click on "Link to DRAFT of March 2016 CA Communication".
With the current wordings of #1a and #1b, if
- a CA has both the email and websites trust bits; and
- their last SHA-1 S/MIME certificate {was issued,expires} later than
their last SHA-1 TLS server certificate,
then they should give the TLS date. Is this intentional?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
CA ownership (re: Q1 2016 CA communication)
Over the last year or so there seems to be a lot of movement in CA ownership. Would it be worth asking for each root to provide an indication of company/organization ownership? For example, NetLock indicates on their website they were acquired by Docler Holding in 2013. Similarly, TrustWave says they are now part of SingTel. These are not reflected in the CA list today. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: FNMT Root Inclusion Request
On Friday, March 11, 2016 at 5:50:47 AM UTC-8, raf...@gmail.com wrote: > El viernes, 15 de enero de 2016, 13:42:41 (UTC+1), raf...@gmail.com escribió: > > Hi all. > > > > We have developed a solution plan for this issues. > > > > We are going to audit in-scope CAs. Finally our FNMT-RCM CAs hierarchy > > audit scheme will be as follows: > > > > + AC RAIZ FNMT-RCM > >+ AC Administración Pública > > - Issues: SSL certs, QCP certs > > - Audits: WebTrust for CAs, WebTrust SSL BRs, ETSI 101 456 > >+ AC Componentes Informáticos > > - Issues: SSL certs > > - Audits: WebTrust for CAs, WebTrust SSL BRs > >+ AC FNMT Usuarios > > - Issues: issues QCP certs, not restricted by EKU extension > > - Audits: (ETSI 101 456 or WebTrust for CAS) and audit of > > non-existence of SSL certs > >+ ISA CA Will be revoked in early 2016 > >+ AC APE No longer used. Will be revoked in early 2016 > > > > As we committed, we have been working intensively to follow this plan. > > We migrated all of our ISA CA's customers and last week this subCA was > revoked. > > In the next days, "AC APE" will be revoked. > > Next month we have date with TÜViT for "AC Administración Pública" and "AC > FNMT Usuarios" ETSI auditing. > > Currently, after corresponding audit, WebTrust for CAs seal and WebTrust SSL > BRs audit report are beeing transacted and we hope to have them available in > the coming days. > > We migrated all of our ISA CA's customers and last week this subCA was > revoked. > > In the next days, "AC APE" will be revoked. > > Next month we have date with TÜViT for "AC Administración Pública" and "AC > FNMT Usuarios" ETSI auditing. > > Currently, after corresponding audit, WebTrust for CAs seal and WebTrust SSL > BRs audit report are beeing transacted and we hope to have them available in > the coming days. I believe there is consensus that we may proceed with the inclusion of the current AC RAIZ FNMT-RCM root certificate as outlined by Rafa. With the following clarifications / action items: 1) FNMT and Mozilla will need to make sure the revoked intermediate certificates get added to OneCRL. 2) The "AC FNMT Usuarios" intermediate certificate will need to be audited annually to ensure that it never issues TLS/SSL certificates. If the audit ever comes back inconclusive or if there is ever any doubt that such an audit could detect any inadvertent issuance, the assumption should be that miss-issuance has occurred and it would be reasonable to act accordingly. 3) FNMT will work with the CAB Forum to resolve the conflicts between the BRs and the requirements that Spanish CAs must follow (i.e. the certlint errors, https://bugzilla.mozilla.org/show_bug.cgi?id=435736#c160). Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ComSign Root Renewal Request
Just one minor typo issue:
On 22/03/2016 17:42, Eli Spitzer wrote:
Hello,
In response to the issues raised by Mr. Sleevi, we are making a number
> of changes in to ComSign's CPS.
>
Some of the issues raised here will be addressed by the changes in the
> CPS, while others will remain the same because we feel that they do
> not represent problems with our compliance to the Mozilla Policy.
Listed here are all of the replies in order of Mr. Sleevi's remarks
> (and with the division between 'Meh' and 'Bad').
>
The draft of the revised CPS can be viewed in this address:
>
http://www.comsign.co.uk/wp-content/uploads/Comsign CPS-EN-v312-Draft.pdf
>
It includes most of the suggested changed (red-lined), but it still has
> the existing CPS structure. We are planning to change the structure and
> order of sections as well.
>
Also, I would like to thank Mr. Sleevi, since this is an opportunity
> for us to improve our CPS and do some serious housekeeping, which we
> may not have done without his objections.
...
* Section 10.15.1 reserves ComSign the right to unilaterally employ
additional methods at ComSign's discretion. This seems to run counter to
the Mozilla Policy which obligates the CA to notify Mozilla of any
meaningful changes to the CP/CPS.
This is a "General Statement of Conformity" section, which states that
> all of ComSign's methods of performing tasks related to certificate
> issuance will comply with the policies of the Certification Authority
> / Browser Forum ("CAB Forum").
>
It also stated that "In case multiple or alternative methods or options
> are possible by the baseline requirements or guidelines ... ComSign
> reserves the right to choose any of the methods or options
> applicable". The methods themselves are listed and enumerated
> throw-out the CPS.
>
I think you mean through-out, which is something completely different.
There is no mention in this section of the option to add additional
> methods, or to make any major or meaningful change to the CP/CPS. Of
> course ComSign is obligated and WILL notify Mozilla of any meaningful
> change in its CP/CPS, but this is not relevant to this section.
...
Eli Spitzer, Information security & System Management, Comsign
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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: Drafting Q1 2016 CA Communication
On Tuesday, March 22, 2016 at 9:33:19 AM UTC-7, kwi...@mozilla.com wrote: > The following 'ACTION #1c' has been added to the communication, which is here: > https://wiki.mozilla.org/CA:Communications#March_2016 > and click on "Link to DRAFT of March 2016 CA Communication". > Also, I have filled in proposed dates, assuming I send the communication next week. I used two dates... April 22,2016 -- the date by which CAs must enter their initial response to this communication into the CA Community in Salesforce. June 30, 2016 -- the date by which CAs must take the requested actions: enter intermediate cert data into the CA Community in Salesforce, and stop issuing certs with the problems listed in ACTION #4. I would especially like to hear from CAs in regards to if these dates are reasonable. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ComSign Root Renewal Request
Hello, In response to the issues raised by Mr. Sleevi, we are making a number of changes in to ComSign's CPS. Some of the issues raised here will be addressed by the changes in the CPS, while others will remain the same because we feel that they do not represent problems with our compliance to the Mozilla Policy. Listed here are all of the replies in order of Mr. Sleevi's remarks (and with the division between 'Meh' and 'Bad'). The draft of the revised CPS can be viewed in this address: "http://www.comsign.co.uk/wp-content/uploads/Comsign CPS-EN-v312-Draft.pdf" It includes most of the suggested changed (red-lined), but it still has the existing CPS structure. We are planning to change the structure and order of sections as well. Also, I would like to thank Mr. Sleevi, since this is an opportunity for us to improve our CPS and do some serious housekeeping, which we may not have done without his objections. > == Meh == > * Page 7 of the CPS clearly documents the Hebrew version of the document > as binding. While this is likely relevant to their role within Israel of > issuing certificates qualified under the national scheme, to the Mozilla > community, I believe the English version is of interest and relevance. For > example, does Page 7 imply that ComSign may unilaterally update the Hebrew > version, without a corresponding update to the English version? Does that > facilitate Mozilla community review? At a minimum, the English version > should be seen as 'as binding' as the Hebrew version, which provides some > assurances about the consistency therein. The Hebrew version of this CPS is binding in regards to matters of Israeli law and regulations, specifically for the purpose of issuing personal certificates in accordance with the Israeli Law of Electronic Signature - Hebrew being the formal and common language of the state of Israel. The scope of personal certificates which are bound to the Israeli law is defined by the Intermediate CA's that issue only this type of certificates - and no other types: a. ComSign Professionals CA b. ComSign Corporations CA The English version of this CPS is binding in regards to matters of SSL certificates, Code signing and International Email certificates - which are not covered by the Israeli law of Electronic Signature. The scope of certificates which are managed and operated according to the English version of this CPS is defined by the Intermediate CA that issues these certificates: c. ComSign Organizational CA These clarification will be added to the upcoming revision of the CPS and can be reviewd in the linked draft. > * Section 2.1 states that "The list of revoked certificates containing > their serial number and date of revocation is accessible for controlled > viewing." This implies that the revocation information is not freely and > publicly available, which contradicts the statements about the CRLs and > OCSP information being freely publicized within the Repository. Could > ComSign clarify what is meant by this section? The language in this section is indeed vague and unclear. We are revising this paragraph to make it clear that certificate revocation is always freely and publically accessible, including the list of serial numbers of certificates that were revoked and the date and time of the revocation. This information is of course part of ComSign's signed CRL files and signed OCSP responses, as required by Mozilla's policy. > * Section 2.3 disclaims any responsibility if CRLs are not fetched every > time, every verification. This defeats many of the purposes of CRLs having > validity periods, and seems to discourage a scalable infrastructure. The reservation that appears in this section states that the most updated CRL is the one published by ComSign. This is pretty straight-forward: certificate may be revoked at any time, and according to some standards that we are committed to (e.g. CWA 14167-1 [RM2.2]) any revocation is reflected immediately in our CRL and OCSP service. If any client software is configured to retrieve revocation information only according to the "Next Update" field of the CRL, then it will be aware of new revocation entries some time after they are first published. > * Section 3.2.5 indicates that certificate renewal is permitted. ComSign > should be aware that for the purposes of the Mozilla policy, the act of > renewal is seen as if it was a new certificate issuance. That is, at time > of "renewal", the renewed certificate must comply with all current and > in-force policies - it CANNOT violate the requirements in effect at the > time of signing (for example, a SHA-1 certificate CANNOT be renewed after > 2016-01-01, as this would be new issuance) Agreed. The section regarding renewal of certificate has no precedence over other sections of the CPS which explicitly declare compliance to Mozilla's or CA/B forum's policies (e.g. validity periods). In the upcoming revision the CPS we
Re: ComSign Root Renewal Request
Hello, In response to the issues raised by Mr. Sleevi, we are making a number of changes in to ComSign's CPS. Some of the issues raised here will be addressed by the changes in the CPS, while others will remain the same because we feel that they do not represent problems with our compliance to the Mozilla Policy. Listed here are all of the replies in order of Mr. Sleevi's remarks (and with the division between 'Meh' and 'Bad'). The draft of the revised CPS can be viewed in this address: http://www.comsign.co.uk/wp-content/uploads/Comsign CPS-EN-v312-Draft.pdf It includes most of the suggested changed (red-lined), but it still has the existing CPS structure. We are planning to change the structure and order of sections as well. Also, I would like to thank Mr. Sleevi, since this is an opportunity for us to improve our CPS and do some serious housekeeping, which we may not have done without his objections. > == Meh == > * Page 7 of the CPS clearly documents the Hebrew version of the document > as binding. While this is likely relevant to their role within Israel of > issuing certificates qualified under the national scheme, to the Mozilla > community, I believe the English version is of interest and relevance. For > example, does Page 7 imply that ComSign may unilaterally update the Hebrew > version, without a corresponding update to the English version? Does that > facilitate Mozilla community review? At a minimum, the English version > should be seen as 'as binding' as the Hebrew version, which provides some > assurances about the consistency therein. The Hebrew version of this CPS is binding in regards to matters of Israeli law and regulations, specifically for the purpose of issuing personal certificates in accordance with the Israeli Law of Electronic Signature - Hebrew being the formal and common language of the state of Israel. The scope of personal certificates which are bound to the Israeli law is defined by the Intermediate CA's that issue only this type of certificates - and no other types: a. ComSign Professionals CA b. ComSign Corporations CA The English version of this CPS is binding in regards to matters of SSL certificates, Code signing and International Email certificates - which are not covered by the Israeli law of Electronic Signature. The scope of certificates which are managed and operated according to the English version of this CPS is defined by the Intermediate CA that issues these certificates: c. ComSign Organizational CA These clarification will be added to the upcoming revision of the CPS and can be reviewd in the linked draft. > * Section 2.1 states that "The list of revoked certificates containing > their serial number and date of revocation is accessible for controlled > viewing." This implies that the revocation information is not freely and > publicly available, which contradicts the statements about the CRLs and > OCSP information being freely publicized within the Repository. Could > ComSign clarify what is meant by this section? The language in this section is indeed vague and unclear. We are revising this paragraph to make it clear that certificate revocation is always freely and publically accessible, including the list of serial numbers of certificates that were revoked and the date and time of the revocation. This information is of course part of ComSign's signed CRL files and signed OCSP responses, as required by Mozilla's policy. > * Section 2.3 disclaims any responsibility if CRLs are not fetched every > time, every verification. This defeats many of the purposes of CRLs having > validity periods, and seems to discourage a scalable infrastructure. The reservation that appears in this section states that the most updated CRL is the one published by ComSign. This is pretty straight-forward: certificate may be revoked at any time, and according to some standards that we are committed to (e.g. CWA 14167-1 [RM2.2]) any revocation is reflected immediately in our CRL and OCSP service. If any client software is configured to retrieve revocation information only according to the "Next Update" field of the CRL, then it will be aware of new revocation entries some time after they are first published. > * Section 3.2.5 indicates that certificate renewal is permitted. ComSign > should be aware that for the purposes of the Mozilla policy, the act of > renewal is seen as if it was a new certificate issuance. That is, at time > of "renewal", the renewed certificate must comply with all current and > in-force policies - it CANNOT violate the requirements in effect at the > time of signing (for example, a SHA-1 certificate CANNOT be renewed after > 2016-01-01, as this would be new issuance) Agreed. The section regarding renewal of certificate has no precedence over other sections of the CPS which explicitly declare compliance to Mozilla's or CA/B forum's policies (e.g. validity periods). In the upcoming revision the CPS we
Re: Drafting Q1 2016 CA Communication
The following 'ACTION #1c' has been added to the communication, which is here: https://wiki.mozilla.org/CA:Communications#March_2016 and click on "Link to DRAFT of March 2016 CA Communication". ~~ ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1. To what extent are SHA-1 based signatures still used in your infrastructure, including your root certificates that you currently have included in Mozilla's CA Certificate Program, as well as any CAs subordinate to them? Please check all the boxes below that apply. (Required) (a) There is no use of SHA-1 based signatures in our infrastructure. (b) We use SHA-1 to sign OCSP responses, but only under a dedicated OCSP responder certificate. (c) We use SHA-1 to sign OCSP responses, directly under a CA certificate. (d) We use SHA-1 to sign certificates. (e) We use SHA-1 signing in some other way. ACTION #1c TEXT INPUT: If you have selected (c), (d), or (e), please provide an explanation. If you selected (c), there is a potential for collision attacks, especially if your OCSP responder supports the nonce extension. Please indicate whether you support the OCSP nonce extension, and any measures you have in place to prevent SHA-1 based attacks. If you selected (d), what type of SHA-1 certificates are you issuing that chain up to your root certificates that you currently have included in Mozilla's CA Certificate Program? When do you plan to stop issuing such certificates? What measures do you have in place to prevent SHA-1 based attacks? If you selected (e), please explain how you are using SHA-1 signing, and what measures you have in place to prevent SHA-1 based attacks. ~~ As always, I will appreciate your thoughtful and constructive feedback on this. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
