Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

[Adrian R. via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: AC Camerfirma misissued certificates automated analysis results

[Wayne Thayer via dev-security-policy]

Thank you for sharing this information.

On Mon, Mar 26, 2018 at 9:24 AM, juanangel.martingomez--- via
dev-security-policy  wrote:

>
>
> We've done an automated analysis on 2018-03-13 of TSL/SSL certificates
> that have been issued by our CAs:
> - Camerfirma Corporate Server II - 2015
> - Camerfirma Corporate Server - 2009
> - AC CAMERFIRMA AAPP
>
> We discovered 81 certificates that we didn't discover in our previous
> manual analyzes of crt.sh. These misissued certificates were due to the
> fact that we had incorrect implementations of TSL/SSL certificates, each of
> the errors was previously corrected.
>
> The reasons why they are incorrect are:
> - (3) cablint ERROR commonNames in BR certificates must be from SAN entries
> - (1) cablint ERROR DNSName is not FQDN
> - (1) cablint ERROR DNSName is not in preferred syntax
> - (11) cablint ERROR Incorrectly encoded TeletexString in Certificate
> - (15) cablint FATAL ASN.1 Error in X520countryName: BER decoding failed
> at octet 0: Parse error
> - (30) cablint ERROR BR certificates must not contain directoryName type
> alternative name
> - (18) x509lint ERROR organizationName too long
> - (2) x509lint ERROR The string contains non-printable control characters
>
> For all of these certificates, the registration process of the domains and
> organizations included in them was carried out correctly.
>
> From the moment they were detected, we began the process of replacing them.
>
> There're 4 that have already expired.
>
> We've revoked 44 of the aforementioned certificates and we are in contact
> with the rest of the subscribing organizations to proceed with their
> substitution, given that most of them are Spanish public administration
> bodies that offer public services and they are unable to replace them in an
> agile way.
>
> I will expect this to be reflected on your next audit reports as a
violation of BR 4.9.1.1 (9).

All of these certificates are issued prior to the implementation of
> technical controls that eliminate the possibility of repeating the issuance
> of erroneous certificate with these errors.
>
> That is good news.

We've implemented at 2018-02-14 a technical control that prevents the
> issuance of a TSL/SSL certificate in case cablint or x509lint show an error
> of type 'FATAL' or 'ERROR' so it is expected that there are no new
> certificates with these errors issued by 'Camerfirma Corporate Server II -
> 2015'. 'AC CAMERFIRMA AAPP' & 'Camerfirma Corporate Server - 2009' are
> disabled for the issuance of certificates in our system.
>
> A report with the detected certificates is avaliable at:
> https://bugzilla.mozilla.org/attachment.cgi?id=8962396
>
> Best Regards
> Juan Angel
>
>
___
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

[Wayne Thayer via dev-security-policy]

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.

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.


> Best Regards
> Ramiro
> ___
> 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

Re: Policy 2.6 Proposal: Remove obsolete ETSI audit requirements

[Wayne Thayer via dev-security-policy]

There has been a lot of confusion about the transition to the new
standards, and I believe that this change makes it clearer that Mozilla no
longer accepts audits based on the older ETSI standards.

On Tue, Mar 27, 2018 at 4:28 AM, Julian Inza via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> European Conformity Assessment Bodies are nowadays issuing Audit
> Certificates aligned with EN 319 401, EN 319-411-1 and EN 319 411-2
> standards.
>
> There is no need to explicitly deny validity to previous standars, because
> as Jakob states, they can reflect the chain of audits.
>
> In fact, TS 102 042 and TS 101 456 are basically the same standards, but
> instead of changing only the version number, ETSI opted to renew the full
> reference code, more in the approach of IETF for RFCs.
>
> The Mozilla rule also is aligned with CAB Forum Baseline Requirements for
> the Issuance and Management of Publicly-Trusted Certificates and Extended
> Validation SSL Certificate Guidelines, and any change to those documents
> would need a ballot.
>
> This is the kind of confusion that I hope to avoid. Mozilla policy is not
aligned with the BRs now that Mozilla does not accept TS 102 042 and TS 101
456 audits.

Regards,
>
> Julian Inza
>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Remove obsolete ETSI audit requirements

[Ryan Sleevi via dev-security-policy]

I support this change. Previously accepted audits are covered by previously
accepted policies, so there's no issue since there should be no new audits
going forward using these criteria, much in the same way all new, valid
WebTrust audits are using the new criteria.

On Mon, Mar 26, 2018 at 4:41 PM, Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Mozilla policy section 3.1.2.2 states:
>
> ETSI TS 102 042 and TS 101 456 audits are only acceptable for audit periods
> > ending in July 2017 or earlier.
> >
>
> Now that we are past this deadline, I propose that we remove all references
> to ETSI TS 102 042 and 101 456 from the policy.
>
> This is: https://github.com/mozilla/pkipolicy/issues/108
>
> ---
>
> This is a proposed update to Mozilla's root store policy for version
> 2.6. Please keep discussion in this group rather than on GitHub. Silence
> is consent.
>
> Policy 2.5 (current version):
> https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
> ___
> 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

Re: Policy 2.6 Proposal: Remove obsolete ETSI audit requirements

[Julian Inza via dev-security-policy]

European Conformity Assessment Bodies are nowadays issuing Audit Certificates 
aligned with EN 319 401, EN 319-411-1 and EN 319 411-2 standards.

There is no need to explicitly deny validity to previous standars, because as 
Jakob states, they can reflect the chain of audits.

In fact, TS 102 042 and TS 101 456 are basically the same standards, but 
instead of changing only the version number, ETSI opted to renew the full 
reference code, more in the approach of IETF for RFCs.

The Mozilla rule also is aligned with CAB Forum Baseline Requirements for the 
Issuance and Management of Publicly-Trusted Certificates and Extended 
Validation SSL Certificate Guidelines, and any change to those documents would 
need a ballot.

Regards,

Julian Inza

 El martes, 27 de marzo de 2018, 8:43:31 (UTC+2), Jakob Bohm  escribió:
> On 26/03/2018 22:41, Wayne Thayer wrote:
> > Mozilla policy section 3.1.2.2 states:
> > 
> > ETSI TS 102 042 and TS 101 456 audits are only acceptable for audit periods
> >> ending in July 2017 or earlier.
> >>
> > 
> > Now that we are past this deadline, I propose that we remove all references
> > to ETSI TS 102 042 and 101 456 from the policy.
> > 
> > This is: https://github.com/mozilla/pkipolicy/issues/108
> > 
> > ---
> > 
> > This is a proposed update to Mozilla's root store policy for version
> > 2.6. Please keep discussion in this group rather than on GitHub. Silence
> > is consent.
> > 
> > Policy 2.5 (current version):
> > https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
> > 
> 
> Will that make such audits (prior to the deadline) unacceptable as part
> of the unbroken audit chain back to first issuance for new roots?
> 
> 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: Policy 2.6 Proposal: Remove obsolete ETSI audit requirements

[Jakob Bohm via dev-security-policy]

On 26/03/2018 22:41, Wayne Thayer wrote:

Mozilla policy section 3.1.2.2 states:

ETSI TS 102 042 and TS 101 456 audits are only acceptable for audit periods

ending in July 2017 or earlier.



Now that we are past this deadline, I propose that we remove all references
to ETSI TS 102 042 and 101 456 from the policy.

This is: https://github.com/mozilla/pkipolicy/issues/108

---

This is a proposed update to Mozilla's root store policy for version
2.6. Please keep discussion in this group rather than on GitHub. Silence
is consent.

Policy 2.5 (current version):
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md



Will that make such audits (prior to the deadline) unacceptable as part
of the unbroken audit chain back to first issuance for new roots?

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