Re: Incident report: Certificates with error in subject: postalCode

[Jakob Bohm via dev-security-policy]

On 02/11/2017 13:27, Nick Lamb wrote:

My understanding is that postal codes written in this form are understood (even 
if not always specifically permitted) by many postal authorities and so this 
deviation would not be likely to impact deliverability of a snail mail letter 
sent (for whatever reason) to the address shown in the certificate.



The form usually understood by postal services is the one with
two-letter country code, though once unparseable addresses are handed
over for manual (human) resolution, such typos are usually handled
gracefully, but perhaps with a delivery delay.

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

Incident report: Certificates with error in subject: postalCode

[Nick Lamb via dev-security-policy]

My understanding is that postal codes written in this form are understood (even 
if not always specifically permitted) by many postal authorities and so this 
deviation would not be likely to impact deliverability of a snail mail letter 
sent (for whatever reason) to the address shown in the certificate.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Estonia e-residency instructing users not to update Firefox (on Mac)

[Henri Sivonen via dev-security-policy]

(Not sure if this is the right mailing list, but while I'm not sure
how exactly the PKI operations of the government of Estonia are
structured organizationally, on surface it looks like this is related
to client cert activities of a CA that is Mozilla-trusted for server
certs.)

A Medium post claiming[1] to represent Estonia e-residency
https://medium.com/e-residency-blog/estonia-is-enhancing-the-security-of-its-digital-identities-361b9a3c9c52
instructs Mac users not to update Firefox from December 15 2017 onwards.

The post claims that there is a Firefox release scheduled for December
15 2017, but I don't see one at
https://wiki.mozilla.org/RapidRelease/Calendar . (There is one
scheduled whose month and day are both off by one compared to the date
stated: November 14.)

Regardless of the date, instructing users not to update their browser
is not good in terms of security.

The post doesn't explain in technical detail the reason for the
recommendation not to update. Why is not updating being recommended?

[1] I don't understand why this wasn't published on a domain belonging
to the government of Estonia. I don't know how to validate that a
Medium blog belongs to who it claims to belong to. However, I hear
that a link to this post was distributed to e-residents in a manner
that suggests that this blog actually belongs to whom it claims to
belong.
-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom inclusion request: next steps

[Gervase Markham via dev-security-policy]

Dear Inigo,

On 14/09/17 09:49, Gervase Markham wrote:
> The Mozilla CA Certificates team has been considering what the
> appropriate next steps are for the inclusion request from the CA
> "StartCom".[0] As readers will know, this CA has previously been removed
> from trust[1], and so a re-application obviously involves particular
> scrutiny. In addition, several questions have been raised about the way
> in which the new StartCom PKI has been operated technically[2]. This is
> a proposal for the way forward, on which comments are invited.

A month ago we posted the above re: StartCom, in what was officially a
request for comments. The ensuing discussion did not lead us to conclude
that anything we were asking for was inappropriate. So we want to
formally confirm that it is indeed Mozilla's requirement that StartCom
begin again with a new-new hierarchy and do the other things outlined in
the original post before we will further consider a root inclusion
request from StartCom.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

AW: Swiss Government root inclusion request

[Michael von Niederhäusern via dev-security-policy]

Hi Julien

The link got cut by a linefeed in the original post:

 
http://www.pki.admin.ch/public/25-01-2017-BIT-ZertES-Certification-Confirmation-2017_Final.pdf

The annual audits are updated for the actual period. The certification 
confirmation is for 2017 where the audits were still performed ETSI TS.

Regards
Michael





-Ursprüngliche Nachricht-
Von: dev-security-policy 
[mailto:dev-security-policy-bounces+michael.vonniederhaeusern=bit.admin...@lists.mozilla.org]
 Im Auftrag von Julien Cristau via dev-security-policy
Gesendet: Donnerstag, 2. November 2017 10:03
An: Aaron Wu 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Betreff: Re: Swiss Government root inclusion request

On Thu, Nov 2, 2017 at 9:29 AM, Aaron Wu via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

>
> * Audit: Annual audits are performed by KPMG according to the ETSI TS 
> 102
> 042 for CA and BR audit criteria.
> http://www.pki.admin.ch/public/25-01-2017-BIT-ZertES-
> Certification-Confirmation-2017_Final.pdf
>
>
This returns 404.  Also, from the other thread, it sounded like ETSI TS should 
be replaced by ETSI EN standards nowadays?

Cheers,
Julien
___
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: Swiss Government root inclusion request

[Julien Cristau via dev-security-policy]

On Thu, Nov 2, 2017 at 9:29 AM, Aaron Wu via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> * Audit: Annual audits are performed by KPMG according to the ETSI TS 102
> 042 for CA and BR audit criteria.
> http://www.pki.admin.ch/public/25-01-2017-BIT-ZertES-
> Certification-Confirmation-2017_Final.pdf
>
>
This returns 404.  Also, from the other thread, it sounded like ETSI TS
should be replaced by ETSI EN standards nowadays?

Cheers,
Julien
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Swiss Government root inclusion request

[Aaron Wu via dev-security-policy]

This request from the Swiss Government is to include the “Swiss Government Root 
CA III” root certificate, turn on the Websites trust bit, and enable EV 
treatment.

The request is documented in the following bug: 
https://bugzilla.mozilla.org/show_bug.cgi?id=435026

BR Self Assessment is here:
https://bugzilla.mozilla.org/attachment.cgi?id=8859143

Summary of Information Gathered and Verified: 
https://bugzilla.mozilla.org/attachment.cgi?id=8924456

* Root Certificate Download URL: 
https://bugzilla.mozilla.org/attachment.cgi?id=8752168

* Documents are provided in English.
Document Repository: https://www.bit.admin.ch/adminpki/
CP/CPS Root CA III:  http://www.pki.admin.ch/cps/CPS_2_16_756_1_17_3_61_0.pdf

* CA Hierarchy:
 CPS section 1.3.1: This root signs subordinate CAs that are operated 
exclusively by Swiss Government PKI staff appointed to the task.

CPS section 1.3.1.2: This root currently has the following internally-operated 
subordinate CAs:
- Swiss Government Public Trust Standard CA 02
- Swiss Government Public Trust EV CA 02
- Swiss Government Public Trust Code Signing Standard CA 02
- Swiss Government Public Trust EV Code Signing EV CA 02

CPS section 1.3.1.2.1.1: The “Swiss Government Public Trust Standard CA 02” 
subCA has been cross-signed by QuoVadis Enterprise Trust CA 2 G3. The 
cross-signed certificate is technically constrained to the domains listed in 
Annex B (section 9.19) of the CPS.

* The request is to turn on the Websites trust bit and enable EV treatment.

CPS section 3.2.2 Authentication of organization and Domain Identity
SG PKI Root III does not process applications that contain Subject identity 
Information comprised only of the countryName field. 
SG PKI verifies the identity of all Applicants, and the authenticity of the 
applicant representative's certificate request using a verification process 
meeting the requirements of Section 3.2.2.1. 
SG PKI will inspect any document relied upon under this Section for alteration 
or falsification. SG PKI Root III and its Subordinated CAs do not issue 
certificates containing internationalized domain names (IDNs).

CPS section 3.2.2.4: Authorization by Domain Name Registrant
For each Fully-Qualified Domain Name listed in a Certificate, SG PKI confirms 
that, as of the date the Certificate was issued, the Applicant (or the 
Applicant’s Parent Company, Subsidiary Company or Affiliate, collectively 
referred to as “Applicant” for the purpose of this Section) either is the 
Domain Name Registrant or has control over the FQDN by:
- communicating directly with the Domain Name Registrant using the contact 
information listed in the WHOIS records “registrant”, “technical” or 
“administrative” field.
- Relying upon a Domain Authorization Document approved by the Domain Name 
Registrant. The document MUST be dated on or after the certificate request date 
or used by SG PKI to verify a previously issued certificate and that the Domain 
Name’s WHOIS record has not been modified since the previous certificate 
issuance.

CPS 3.2.3 Authentication of individual identity
For individual identity authentication a smart card based on a certificate of 
type “Klasse B” issued under the “Swiss Government Root CA I” [20] SHALL be 
used. Certificates of type “Klasse B” are combining the government identity 
directory (AdminDir) and a qualified identification process in combination with 
a strong authentication token (smart card) 

* EV Policy OID: 2.16.756.1.17.3.61.2

* Test Websites
Valid : https://www.valid-ev.pki.admin.ch 
Revoked : https://www.revoked-ev.pki.admin.ch 
Expired : https://www.expired-ev.pki.admin.ch 

* CRL URLs: 
http://www.pki.admin.ch/crl/RootCAIII.crl
CPS section 4.9.7.1: The value of the nextUpdate field is never more than ten 
days beyond the value of the thisUpdate field.

* OCSP URLs:
http://www.pki.admin.ch/aia/ocsp 
CPS section 4.9.9: certificate status database, used by the OCSP service, is 
updated every 4 hours during office hours.

* Audit: Annual audits are performed by KPMG according to the ETSI TS 102 042 
for CA and BR audit criteria.
http://www.pki.admin.ch/public/25-01-2017-BIT-ZertES-Certification-Confirmation-2017_Final.pdf

* Forbidden or Problematic Practices
None Noted

This begins the discussion of the request from the Swiss Government is to 
include the “Swiss Government Root CA III” root certificate, turn on the 
Websites trust bit, and enable EV treatment.

Aaron



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Incident report: Certificates with error in subject: postalCode

[Mads Egil Henriksveen via dev-security-policy]

Hi

Late last week we discovered three certificates issued from Buypass with an 
error in the subject:PostalCode for one dutch company. One of these 
certificates is available at https://crt.sh/?id=212774960

The postalcode should have been '3707BK' as registered in the European Business 
Register (EBR), but these three certificates were issued with the value 
'NLD-3707BK' where NLD is the 3 letter UN country code for the Netherlands.

The inclusion of the three letter country code was indirectly caused by 
retrieving a three letter UN country code, instead of the two letter ISO 3166 
country code. The three letter country code was then changed into a two letter 
country code to comply with BR 7.1.4.2.2 h). However, this change caused a 
formatting error in another data field used as input to the postalCode 
attribute and then again the inclusion of the three letter country code in the 
postalCode field in the certificates.

We have checked all issued certificates and concluded that these are the only 
three certificates with this error.

We consider this error to be minor since the certificates includes the zip or 
postal information as specified by BR 7.1.4.2.2 g),  only prefixed with the 
country code. We have decided to not revoke the affected certificates since we 
do not consider this to represent any security concern and since the 
information is not misleading. This decision has also been discussed with our 
auditor.

However, since this is a deviation from our standard procedures (and not 
necessarily in compliance with the requirements), we decided to handle this as 
a "misissuance" and therefore send this incident report.

We will add an additional check in our certificate issuance system to identify 
any errors in the formatting of the postalCode field - together with a 
cablint/certlint control which already is planned.  This will prevent issuance 
of certificates with this formatting error. These extra controls will be 
released by the end of this week.

We have also identified a bug fix for the country code formatting error, but 
this fix has not yet been scheduled.

Regards
Mads

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy