For these, it may help to make sure the context is available on the thread - https://bugzilla.mozilla.org/show_bug.cgi?id=675060 is the bug, and the current CPS at time of writing is 4.1 ( https://s3-us-west-2.amazonaws.com/comsign/CPS/CPS_4.1_eng.pdf )
Section 1.3.2.5: - It remains unclear whether or not DTPs can perform domain validation (which is no longer permitted under the BRs). ComSign does employ DTPs as RAs for other forms of information, such as organization information, and does make it clear it supports Enterprise RAs (which are permitted under the BRs, provided the domain namespace is scoped to something the CA validated). Section 3.2.2.4 touches on this by stating it'll be performed by their own staff, so I think this is just highlighting an ambiguous inconsistency. Section 3.2.2.4 - ComSign makes use of the (problematic) 3.2.2.4.1 method. This method is presently permitted under the BRs, but worth highlighting as a concern, given the attacks demonstrated in the CA/Browser Forum as to the reliability of this method. - ComSign makes use of the (problematic) 3.2.2.4.5 method. This method is presently permitted under the BRs, but worth highlighting as a concern, given the attacks demonstrated in the CA/Browser Forum as to the reliability of this method. - ComSign makes use of the (problematic) 3.2.2.4.9 method. This method is presently permitted under the BRs, but worth highlighting as a concern, given the attacks demonstrated in the CA/Browser Forum as to the reliability of this method. ComSign has not yet disclosed to this list how they use it, and whether their use of this method is affected by the same vulnerabilities that affected GlobalSign and Let's Encrypt. Section 3.2.2.8 - ComSign does not document ComSign's CAA identifier here or in Section 2.2. It is, however, documented in 4.2.1.1 (iv). Section 3.4 - ComSign does not seem to permit revocation requests in the event of misissuance, at least within this section. This means the domain holder of a misissued certificate seemingly cannot request ComSign revoke that certificate, nor can they request ComSign revoke pre-existing certificates potentially obtained by prior domain holders. This seems supported by the process in Section 4.9.2 Particularly Concerning: This CP/CPS is the same set that ComSign uses for all of its issuance practices. During the course of Chrome development and improving our compliance checks to RFC5280 (which we require by policy and by virtue of the BRs), we discovered that ComSign had issued "tens of thousands" of misencoded client certificates [1]. The result was due to using RSA Keon Certificate Authority [2]. These details were provided by someone representing themselves as the CEO of ComSign [3]. As best we can tell, RSA was calling the product "Keon Certificate Authority" at least as recent as 2007, based on CVE-2006-4991 [4], although based on RSA's current information [5], it appears to have been rebranded around that time to "RSA Certificate Manager" (no longer being called Keon CA). The version known as "Keon CA" at least had vulnerabilities that allowed for the overwriting of CA's audit logs It's unclear if this means that ComSign is using CA software written in 2007, or whether they're using a more recent version. Based on the documentation in [5], it does seem RSA Certificate Manager is reached End of Product Support sometime in 2017, although it seems at least some updates [6] were provided. I think this demonstrates a violation of ComSign's commitment to RFC5280, and to its CP/CPS regarding the use of names (c.f. Section 3.1.1), but also raises deeper concerns about their commitment to quality in issuance, and to past practices - particularly those outside of the audited window. Given that ComSign has stated they plan to find new CA software [7], perhaps it may be advisable to reject this request (and the key associated), and wait until such a time as a new CA, with a new key, and an unblemished and unquestioned audit sequence, can be established. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=770323#c3 [2] https://bugs.chromium.org/p/chromium/issues/detail?id=770323#c4 [3] https://bugs.chromium.org/p/chromium/issues/detail?id=770323#c29 [4] https://nvd.nist.gov/vuln/detail/CVE-2006-4991 [5] https://community.rsa.com/docs/DOC-73367 [6] https://community.rsa.com/docs/DOC-81493 [7] https://bugs.chromium.org/p/chromium/issues/detail?id=770323#c5 On Tue, Jan 16, 2018 at 4:05 PM, Wayne Thayer via dev-security-policy < [email protected]> wrote: > To recap, we've established that this root was first BR audited on > 26-April 2015 and has received clean period-of-time audits over the next > two years. ComSign has disclosed 36 certificates issued by this root prior > to the BR point-in-time audit, of which one remains unexpired. This does > not meet the requirements of BR section 8.1 both because the point-in-time > readiness assessment was not completed prior to issuing a publicly-trusted > certificate, and because the first period-of-time audit was not completed > within 90 days of issuing a publicly-trusted certificate. Mozilla policy, > however, does not require a root to have maintained BR compliance over its > entire lifetime to be included in the program. ComSign's current annual > WebTrust for CAs and BR audits are enough to meet Mozilla's requirements. > > The questions I raised have been addressed to my satisfaction. If anyone > has further concerns, please raise them this week so that we can complete > the public discussion period for this inclusion request. > > - Wayne > > On Sunday, December 24, 2017 at 2:46:03 AM UTC-7, YairE wrote: > > Hi Wayne, > > > > as requested i added the file with the certificates issued since > 26/10/2014 until 31/03/2015 to the bug, > > > > Back then it seems we didn’t have a WebTrust audit (I believe we started > in 2015) but only external CPA and governmental audits as are attached > already. > > The reason we didn’t have a WebTrust audit is that we were already being > audited by other auditors and the external WebTrust auditor was qualified > only around that time. > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
