Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request
On Tuesday, March 27, 2018 at 10:37:07 PM UTC+2, Wayne Thayer wrote:
> Hi Ramiro,
>
> On Fri, Mar 23, 2018 at 11:52 AM, ramirommunoz--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Hi Ryan
> >
> > Thanks again for your remarks.
> > In the end I am going to learn something of PKI :-).
> > Surely I do not get a full understanding of you solution, but public
> > administration is requiring a EU qualified Web certificate this means that
> > should be included in the EUTL. I do know other solution for a new root but
> > a new conformity assessment.
> >
> > If the "2016" roots are included in the EUTL, then they can be used to
> sign ("cross-sign") a new "2018" root (or roots) that will then inherit the
> trust from the "2016" root. From the perspective of the EUTL, the new root
> would look like a new intermediate CA certificate.
Wayne, the EUTL do not include ROOTS, only SubCA. It doesn't works in this way.
Our hypothetical new 2018 root should issue a SubCA for WEBSITE certificates
and this SubCA should be included in the EUTL, previously we should pass a new
conformity assessment and send it to our National Supervisor body..and so on.
>
> Nevertheless, let me insist. In which aspects a new root 2018 improve our
> > trustworthiness instead of the current root 2016?
> >
> > This is the wrong question to ask. For all the reasons stated in earlier
> messages, the Mozilla community appears to have concluded that the 2016
> roots are not trustworthy. If that is the case, then the proposal that you
> create a new root answers the question that I think you should be asking:
> "How can Camerfirma regain the community's trust?" Submitting a new root
> that has been audited, has no history of misissuance, and complies in every
> way with our policies has been proposed as one possible way to increase
> confidence in your CA. If you have been following this mailing list, you
> have seen that this same action has been recommended to other CAs that are
> in this situation.
>
Wayne, all issues stated are already resolved, Moreover actually 2016 root is
not affected by those problems. That's why I do not see the difference between
2016 root and a new 2018 root.
Nevertheless We offer a "Point in time audit" over 2016 root in order to
provide to the community a clear assurance that all technical controls are in
place and fulfill the BR requirements. Previously, to start from a clean point,
We offer as well to revoke all WebSite certificates issued under this root.
We think that this proposal should provide a similar situation that we would
have if a new 2018 root were set up.
Regards
Ramiro
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request
On Wednesday, March 28, 2018 at 7:34:25 AM UTC+2, Adrian R. wrote: > Hello > can you please sign the PDF files on that site? > > the very first page of CPS_eidas_EN_v_1_2_3.pdf says > "Document valid only in digital format digitally signed by the Policy > Authority" > > but the PDF that i was offered to download is not signed and was delivered > via a plain http link, are those working draft versions and not final? > > > I also looked at a few of the older/other versions published there: > > CPS_EN_v_3_3.pdf - PDF not signed but that phrase is not present either. > > CPS_eidas_v_1_2_1_EN.pdf - (april 2017) same phrase is present on the first > page but the PDF file is not signed. > > CPS_eidas_EN_v_1_1.pdf - (nov 2016) - signed PDF (and that phrase is not > present) > > > Adrian R. > > > > On Tuesday, 27 March 2018 12:42:50 UTC+3, ramiro...@gmail.com wrote: > > > > > > New versions of CPS are being published today in our WebSite. > > > > http://www.camerfirma.com/en/area-de-usuario/jerarquia-politicas-y-practicas-de-certificacion/ > > > > CPS-EIDAS (2016 root) v 1.2.3 > > CPS (2003 2008 roots) v.3.3 > > > > Regards > > Ramiro Hi Adrian Thank you for your feedback. Already signed and published. We have cleaned the webpage with the last CPS for the sake of simplicity. There is a historical CPS version inside the documents. Best Regards Ramiro ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Audits for new subCAs
Entrust does the following: - Each subCA certificate is created through a audited ceremony. The auditor creates a report indicating the key ID and the CPS which was used for key generation. - When it is time for the subCA to go into production, an intermediate certificate is issued from a root. The intermediate certificate will meet the requirements of the CPS and the BRs if applicable. - The subCA can now issue certificates. The end entity certificates will have a certificate policy which is stated in the CPS. As such, issuing a certificate is an assertion that the subCA is issuing in accordance with the certificate policy and CPS. - The new subCA is compliance audited at the next time in our annual audit cycle. Note the new subCA is operated the same as all other CAs meeting the same certificate policy. I would note that if there was a significant change such as data center location or new certificate policy, then we may want to consider a point-in-time readiness assessment. I think that all CAs required a point-in-time readiness assessment, before we started to issue EV certificates. I suppose that I am stating that I support option 1 as I think the option 2 attestments are already covered. However, option 3 may be required for a new data center or a policy which has not been previously audited. Thanks, Bruce. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Audits for new subCAs
Operating a technically unconstrained issuing CA, Siemens CA (aka TSP) does something very similar in case a new CA is necessary: * In an audited ceremony based on the operational and technical controls audited in the last annual audit a key pair is generated on one of the HSMs * A CSR is constructed and sent to our cross signing partner, together with the witness report of the auditor, filled with all the information required by Microsoft in the Audit Cover Letter Template * The cross signing partner checks the report and creates the certificate for the issuing CA After receiving the new certificate we update our CPS Only after the new CPS is published certificates are issued In the next annual audit the new CA is part of the normal audit. So I would recommend to choose a combination of options #1 and #2. With best regards, Rufus Buschart Siemens AG GS IT HR 7 4 Hugo-Junkers-Str. 9 90411 Nuernberg, Germany Tel.: +49 1522 2894134 mailto:rufus.busch...@siemens.com www.siemens.com/ingenuityforlife -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+rufus.buschart=siemens@lists.mozilla.org] On Behalf Of Bruce via dev-security-policy Sent: Mittwoch, 28. März 2018 23:38 To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Audits for new subCAs Entrust does the following: - Each subCA certificate is created through a audited ceremony. The auditor creates a report indicating the key ID and the CPS which was used for key generation. - When it is time for the subCA to go into production, an intermediate certificate is issued from a root. The intermediate certificate will meet the requirements of the CPS and the BRs if applicable. - The subCA can now issue certificates. The end entity certificates will have a certificate policy which is stated in the CPS. As such, issuing a certificate is an assertion that the subCA is issuing in accordance with the certificate policy and CPS. - The new subCA is compliance audited at the next time in our annual audit cycle. Note the new subCA is operated the same as all other CAs meeting the same certificate policy. I would note that if there was a significant change such as data center location or new certificate policy, then we may want to consider a point-in-time readiness assessment. I think that all CAs required a point-in-time readiness assessment, before we started to issue EV certificates. I suppose that I am stating that I support option 1 as I think the option 2 attestments are already covered. However, option 3 may be required for a new data center or a policy which has not been previously audited. Thanks, Bruce. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
