Re: New requirement: certlint testing

[Matt Palmer]

On Mon, Feb 08, 2016 at 12:42:46PM -0800, Kathleen Wilson wrote:
> One topic currently under discussion in Bug #1201423 is regarding root
> certificates with serial number of 0. The error being returned by
> http://cert-checker.allizom.org/ is "Serial number must be positive".
> 
> Arguments raised in the bug:
> 
> >>> RFC 5280 is not ambiguous as to whether zero is positive or not.
> >>> https://tools.ietf.org/html/rfc5280#section-4.2.1.10
> >>>Note: Non-conforming CAs may issue certificates with serial numbers
> >>>that are negative or zero.  Certificate users SHOULD be prepared to
> >>>gracefully handle such certificates.
> >>> So zero is clearly non-conforming.
> 
> >> The whole RFC5280 section 4.1 refers to the information associated with
> >> the subject of the certificate and the CA that issued it.  This is not
> >> a certificate issued by a CA, it is a self-signed certificate, which is
> >> the trust-anchor itself.
> 
> > We believe that this section applies to issued certificates.
> > Quoting the beginning of the section:
> >The sequence TBSCertificate contains information associated with the
> >subject of the certificate and the CA that issued it.
> >
> > Thus, it only applies to certificates issued by a CA, and not to the CA
> > itself.
> 
> Does section 4.1 of RFC5280 apply to root certificates?

My understanding of the terminology is that a CA is not a certificate, it is
a role (or person, or organisation, or function).  To put it another way,
"certificates don't issue certificates, CAs issue certificates".  In this
way, it becomes fairly clear that the self-signed certificate which is
usually used as the trust anchor is a "certificate issued by a CA", as much
as any other.

- Matt

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

Re: SSC Root Inclusion Request

[Moudrick M. Dadashov]

The updated CP/CPS are now under internal review and will be published 
before end of February.


Thanks,
M.D.

On 2/8/2016 8:00 PM, Kathleen Wilson wrote:

On 2/7/16 2:53 AM, winpackja...@gmail.com wrote:
And how much more time is this going to take? Since no issues have 
been highlighted...




We're waiting for SSC to update their CP/CPS to resolve the issues 
that were raised here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/W0st0yN9bTM/14_-nZ7jGAAJ 



But we can close this discussion for now, and re-open when the new 
CP/CPS is provided.


Kathleen


___
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: A-Trust Root Renewal Request

[Charles Reiss]

On 02/09/16 01:22, Kathleen Wilson wrote:
> This request is to include the ‘A-Trust-Root-05’ root certificate, turn
> on the Websites trust bit, and enable EV treatment. This new root
> certificate will replace the ‘A-Trust-nQual-03’ root certificate that
> was included via Bugzilla Bug #530797. The ‘A-Trust-nQual-03’ root
> certificate expired, so it was removed via Bugzilla Bug #1204997.
[snip]

> * CA Hierarchy: This root has internally-operated subordinate CAs:
> - a-sign-SSL-05 (http://www.a-trust.at/certs/a-sign-ssl-05.crt)

These certificates were issued last year for the internal name 'TRUE'
and are valid until at least 2018 (well past the deadline for internal
names under the BRs):
https://crt.sh/?dnsname=True=5662

These were issued last year for the internal name '1' and are valid
until at least 2017 (still well past the deadline):
https://crt.sh/?dnsname=1=5662

From those internal name certificates above, these certificates are
valid from 2015 until 2020, which is longer than the 39 months allowed
under the BRs:
https://crt.sh/?id=8991758=cablint
https://crt.sh/?id=9123894=cablint

This certificate was issued last year for the internal name 'BSB-oenb'
and is valid from 2015 until 2020:
https://crt.sh/?id=10540258=cablint

These certificates also seem to lack the at least 20 bits of entropy in
the certificate serial number that the BRs recommend in section 7.1.

> - a-sign-SSL-EV-05 (http://www.a-trust.at/certs/a-sign-ssl-ev-05.crt)

CT appears to know about several other subCAs; see child CAs here:
https://crt.sh/?caid=5661

My assumption is that the other subCAs are not supposed to issue SSL
certificates however, they still need to be in scope as they do not
appear technically constrained from doing so (e.g. by extendedKeyUsage).
(However, it appears that the prior root's subCA
a-sign-corporate-light-03 issued TLS server certificates (e.g.
https://crt.sh/?id=5669744=cablint) and it is presumably similar to
a-sign-corporate-05.)



> 
> * This request is to turn on the Websites trust bit, and enable EV
> treatment.
> 
> Translation of EV SSL CPS sections 3.1.7, 3.1.8, and 3.1.9:
> https://bug1092963.bugzilla.mozilla.org/attachment.cgi?id=8584406
> 
> 3.1.7 Authentication of organisations
> When ordering an a.sign SSL EV certficate, the domain and organisation
> has to be verified. If the ordering entity is registered in either the
> austrian commercial register or the European Business Register (EBR),
> A-Trust verifies the existence using the online - database of those
> registers. The registration number has to be inlcuded in the request.
> The physical address is also verified using the offical register. If not
> applicable, the check is performed using a duplicate of a document that
> confirms the organisations existence. Examples for such documents are
> extracts from legal registers or databases of trusted third parties.
> The checks are performed according to the requirements in EV-GL
> (guidelines v1.2, CAB Forum), section 10.
> 
> In case an a.sign SSL EV certificate is order, additional information
> has to be gathered:
> # confirmation issued by the bank of the ordering organisation,
> confirming the existance of an account related to the organisation
> # annual statement of the organisation, verified by a certified accountant
> # if an exchange embargos exist (inqury at responsible entity in the
> applicants country through A-Trust)
> # verification of the physical address. If the address provided in the
> legal register used for verification of the organisation is also stated
> in the annual statement gathered in point 2, the physical address is
> considered correct. If these requirements are not met, verification can
> only be achieved through a check on location. Possible costs of this
> check are charged to the applicant. Further information can be found at
> EV-GL, section 10.4.1.
> 
> If an entire obtaining of all required information is not possible
> within a reasonable amount of time, the application is rejected and the
> applicant will be informed.
> 
> 3.1.8 Check of Domain or IP Address
> The holder of a domain is verified using the databases provided by the
> applicable authority (such as www.nic.at, www.denic.de,...).
> The use of IP adresses in EV certficates is not permitted.
> 
> 3.1.9 Authentication of individuals
> The individuals, who are audited in the process of issuing an a.sign SSL
> EV certificate are
> # the domain owner
> and, if the domain order is acting in the name of an organisation
> # an organisational responsible person, that is allowed to sign in the
> ogranisations name and confirms the correctness of the application
> The people that are mentioned in the application have to provide an
> identification document (i.e. passport).
> If the organisational responsible person is not listed in the used
> register, additional confirmation of his status has to be provided (i.e.
> a certificate of authority).
> 
> * Root Certificate Download URL:
> 

Re: ComSign Root Renewal Request

[Eli Spitzer]

On Thursday, February 4, 2016 at 10:57:54 PM UTC+2, Ryan Sleevi wrote:
> Reposting this, as Kathleen confirmed it made it to her, but not the list:
> 
> On Thu, December 10, 2015 12:01 pm, Kathleen Wilson wrote:
> >  This request is to include the "ComSign Global Root CA" root
> > certificate, and enable the Websites and Email trust bits. This root
> > will eventually replace the "ComSign CA" root certificate that is
> > currently included in NSS, and was approved in bug #420705.
> >
> >  ComSign is owned by Comda, Ltd., and was appointed by the Justice
> > Ministry as a CA in Israel in accordance with the Electronic Signature
> > Law 5761-2001. ComSign has issued electronic signatures to thousands
> > of  business people in Israel.
> >
> >  The request is documented in the following bug:
> >  https://bugzilla.mozilla.org/show_bug.cgi?id=675060
> >
> >  And in the pending certificates list:
> >  https://wiki.mozilla.org/CA:PendingCAs
> >
> >  Summary of Information Gathered and Verified:
> >  https://bugzilla.mozilla.org/attachment.cgi?id=8697333
> 
> Kathleen,
> 
> I've attempted to complete a review of the CPS as if this was a new
> inclusion. I did not review the specific SSL CP, as I found enough
> concerning information in the CPS that it did not seem to warrant the time
> or energy.
> 
> Similar to past discussions, I've attempted to clarify this into three
> sections - Good (which I believe should serve as examples for other CAs),
> Meh (which are undesirable or inadvisable, but not strictly forbidden, or
> which require further clarification), and Bad (things which I believe are
> inconsistent with Mozilla policy or the interest of Mozilla users)
> 
> Per your email, I focused on
> http://www.comsign.co.uk/wp-content/uploads/Comsign%20CPS-EN-v%20311.pdf
> as the version of the CPS to review
> 
> == Good ==
> * Section 3.2.8 thoroughly details the methods for domain name validation.
> While I realize others have raised concerns (which I believe are unfounded
> and not relevant to the discussion, as they're permitted by the BRs), I do
> believe it's a positive sign to include such throughness within a CP/CPS.
> * Section 4.1.1 provides substantial documentation about the roles and
> parties involved in the issuance of certificates.
> 
> == 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.
> * 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?
> * 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.
> * 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)
> * Section 3.2.8.2.2 has a typo (trough -> through)
> * Sections 7.1 - 7.4 are unclear as to whether the EKUs enumerated
> represent examples (and thus, issued certificates may include other such
> EKUs), as the section titles imply, or whether they represent an
> exhaustive list of what can appear within that field. If it is merely
> exemplary, this does represent a concern as non-SSL certificates may
> inadvertently be enabled for SSL if the wrong EKUs are presented.
> * Section 7.1.4 documents multiple CRL locations may appear, but ComSign
> should be aware that virtually all major clients ignore these multiple
> URLs and will only check a single URL. Thus, it seems inefficient and
> wasteful to encode as such.
> 
> == Bad ==
> * The CPS does not appear to conform to either RFC 2527 or RFC 3647, as
> required by the Baseline Requirements. The CPS seemingly follows 3647,
> based on the rough outline, but 

SSC Root Inclusion Request

[winpackjason]

And how much more time is this going to take? Since no issues have been 
highlighted...
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSC Root Inclusion Request

[Kathleen Wilson]

On 2/7/16 2:53 AM, winpackja...@gmail.com wrote:

And how much more time is this going to take? Since no issues have been 
highlighted...



We're waiting for SSC to update their CP/CPS to resolve the issues that 
were raised here:

https://groups.google.com/d/msg/mozilla.dev.security.policy/W0st0yN9bTM/14_-nZ7jGAAJ

But we can close this discussion for now, and re-open when the new 
CP/CPS is provided.


Kathleen


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

New requirement: certlint testing

[Kathleen Wilson]

All,

We recently added two tests that CAs must perform and resolve errors for 
when they are requesting to enable the Websites trust bit for their root 
certificate.


Test 1) Browse to https://crt.sh/ and enter the SHA-1 Fingerprint for 
the root certificate. Then click on the 'Search' button. Then click on 
the 'Run cablint' link. All errors must be resolved/fixed.


Test 2) Browse to https://cert-checker.allizom.org/ and enter the test 
website and click on the 'Browse' button to provide the PEM file for the 
root certificate. Then click on 'run certlint'. All errors must be 
resolved/fixed.


I added these to item #15 of
https://wiki.mozilla.org/CA:Information_checklist#Technical_information_about_each_root_certificate

This has sparked some discussions in Bugzilla Bugs that I think we 
should move here to mozilla.dev.security.policy so that everyone may 
benefit from the resulting decisions.


So, if you have feedback or questions about these new tests, please add 
them here.


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

Re: New requirement: certlint testing

[Kathleen Wilson]

On 2/8/16 12:22 PM, Kathleen Wilson wrote:

On 2/8/16 12:18 PM, Kathleen Wilson wrote:

All,

We recently added two tests that CAs must perform and resolve errors for
when they are requesting to enable the Websites trust bit for their root
certificate.

Test 1) Browse to https://crt.sh/ and enter the SHA-1 Fingerprint for
the root certificate. Then click on the 'Search' button. Then click on
the 'Run cablint' link. All errors must be resolved/fixed.

Test 2) Browse to https://cert-checker.allizom.org/ and enter the test
website and click on the 'Browse' button to provide the PEM file for the
root certificate. Then click on 'run certlint'. All errors must be
resolved/fixed.

I added these to item #15 of
https://wiki.mozilla.org/CA:Information_checklist#Technical_information_about_each_root_certificate



This has sparked some discussions in Bugzilla Bugs that I think we
should move here to mozilla.dev.security.policy so that everyone may
benefit from the resulting decisions.

So, if you have feedback or questions about these new tests, please add
them here.

Thanks,
Kathleen



Also, to clarify...

Already-included root certificates are grandfathered in, but all new
root certificates need to meet the BRs and pass these certlint tests
without error before they can be included. However, we are open to
updating the certlint tests, as long as the updates are in line with the
BRs.

Kathleen





One topic currently under discussion in Bug #1201423 is regarding root 
certificates with serial number of 0. The error being returned by 
http://cert-checker.allizom.org/ is "Serial number must be positive".


Arguments raised in the bug:

>>> RFC 5280 is not ambiguous as to whether zero is positive or not.
>>> https://tools.ietf.org/html/rfc5280#section-4.2.1.10
>>>Note: Non-conforming CAs may issue certificates with serial numbers
>>>that are negative or zero.  Certificate users SHOULD be prepared to
>>>gracefully handle such certificates.
>>> So zero is clearly non-conforming.

>> The whole RFC5280 section 4.1 refers to the information associated 
with the

>> subject of the certificate and the CA that issued it. This is not a
>> certificate issued by a CA, it is a self-signed certificate, which 
is the

>> trust-anchor itself.


> We believe that this section applies to issued certificates.
> Quoting the beginning of the section:
>The sequence TBSCertificate contains information associated with the
>subject of the certificate and the CA that issued it.
>
> Thus, it only applies to certificates issued by a CA, and not to the CA
> itself.


Does section 4.1 of RFC5280 apply to root certificates?

Is a root certificate with serial number 00 compliant with RFC5280 and 
the BRs?


As always, I will appreciate your thoughtful and constructive 
contributions to this discussion.


Kathleen








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

Re: New requirement: certlint testing

[Kathleen Wilson]

On 2/8/16 1:07 PM, Peter Bowen wrote:

On Mon, Feb 8, 2016 at 12:18 PM, Kathleen Wilson  wrote:

We recently added two tests that CAs must perform and resolve errors for
when they are requesting to enable the Websites trust bit for their root
certificate.

Test 1) Browse to https://crt.sh/ and enter the SHA-1 Fingerprint for the
root certificate. Then click on the 'Search' button. Then click on the 'Run
cablint' link. All errors must be resolved/fixed.


Kathleen,

As I understand it, the currently policy for most CT logs (which is
where crt.sh gets data) is that the root must already be in a root
program (Apple, Google Android/Chrome OS, Microsoft, or Mozilla) or
cross-signed by a root in those programs to be included in the log.



Correct. In such cases no cert is found, but also no errors returned.



Therefore I think it is reasonable to expect that new roots are not
included in crt.sh.



Some are in crt.sh -- especially for those CAs who are new to Mozilla's 
program.




I'm assuming the second test checks the uploaded
root certificate, so that should be sufficient for testing.


I could be wrong, but I think there is value in both tests, especially 
for those CAs who are in other root programs, and not yet in Mozilla's 
root program.


Kathleen


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

Re: New requirement: certlint testing

[Kurt Roeckx]

On Mon, Feb 08, 2016 at 12:18:12PM -0800, Kathleen Wilson wrote:
> All,
> 
> We recently added two tests that CAs must perform and resolve errors for
> when they are requesting to enable the Websites trust bit for their root
> certificate.
> 
> Test 1) Browse to https://crt.sh/ and enter the SHA-1 Fingerprint for the
> root certificate. Then click on the 'Search' button. Then click on the 'Run
> cablint' link. All errors must be resolved/fixed.
> 
> Test 2) Browse to https://cert-checker.allizom.org/ and enter the test
> website and click on the 'Browse' button to provide the PEM file for the
> root certificate. Then click on 'run certlint'. All errors must be
> resolved/fixed.
> 
> I added these to item #15 of
> https://wiki.mozilla.org/CA:Information_checklist#Technical_information_about_each_root_certificate
> 
> This has sparked some discussions in Bugzilla Bugs that I think we should
> move here to mozilla.dev.security.policy so that everyone may benefit from
> the resulting decisions.

So you're requesting this for new CAs?  What about existing CAs?
Should we file bugs in bugzilla about the issues it found?  Are
they supposed to look at it themself and fix things?


Kurt

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

Re: New requirement: certlint testing

[Kathleen Wilson]

On 2/8/16 12:18 PM, Kathleen Wilson wrote:

All,

We recently added two tests that CAs must perform and resolve errors for
when they are requesting to enable the Websites trust bit for their root
certificate.

Test 1) Browse to https://crt.sh/ and enter the SHA-1 Fingerprint for
the root certificate. Then click on the 'Search' button. Then click on
the 'Run cablint' link. All errors must be resolved/fixed.

Test 2) Browse to https://cert-checker.allizom.org/ and enter the test
website and click on the 'Browse' button to provide the PEM file for the
root certificate. Then click on 'run certlint'. All errors must be
resolved/fixed.

I added these to item #15 of
https://wiki.mozilla.org/CA:Information_checklist#Technical_information_about_each_root_certificate


This has sparked some discussions in Bugzilla Bugs that I think we
should move here to mozilla.dev.security.policy so that everyone may
benefit from the resulting decisions.

So, if you have feedback or questions about these new tests, please add
them here.

Thanks,
Kathleen



Also, to clarify...

Already-included root certificates are grandfathered in, but all new 
root certificates need to meet the BRs and pass these certlint tests 
without error before they can be included. However, we are open to 
updating the certlint tests, as long as the updates are in line with the 
BRs.


Kathleen


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

RE: Policy revision proposal - transitive disclosure exception

[Ben Wilson]

That makes sense.

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On 
Behalf Of Peter Bowen
Sent: Monday, February 8, 2016 12:50 PM
To: Kathleen Wilson 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Policy revision proposal - transitive disclosure exception

On Mon, Feb 8, 2016 at 11:29 AM, Kathleen Wilson  wrote:
> On 2/6/16 11:45 AM, Peter Bowen wrote:
>>
>> The Mozilla CA Certificate policy says, in part:
>>
>> "8. All certificates that are capable of being used to issue new 
>> certificates, and which directly or transitively chain to a 
>> certificate included in Mozilla’s CA Certificate Program, MUST be 
>> operated in accordance with Mozilla’s CA Certificate Policy and MUST 
>> either be technically constrained or be publicly disclosed and 
>> audited.
>>
>> * A certificate is deemed as capable of being used to issue new 
>> certificates if it contains an X.509v3 basicConstraints extension, 
>> with the cA boolean set to true.
>> * These requirements include all cross-certified certificates which 
>> chain to a certificate that is included in Mozilla’s CA Certificate 
>> Program."
>>
>> I would propose that transitive disclosure not be required when the 
>> subject of the CA-certificate is also the subject of a certificate 
>> included directly in the Mozilla trust store.
>>
>
>
> I think we want such relationships to be clearly disclosed. In the 
> future, in the case that there is an incident that requires blocking a 
> particular CA-certificate, we would be able to use Salesforce to find 
> all the relationships with other CA-Certificates in the program.

I'm not proposing that they not be disclosed.  Consider this situation:

Example Corp Root CA is in the Mozilla trust store.
Contoso Corp Root CA is in the Mozilla trust store.

Example has two subordinates: Example Server CA and Example Client CA.
Contoso has two subordinates: Contoso CA - S1A and Contoso CA - C1B.
Example issues a cross certificate signed by Example Corp Root CA to Contoso 
Corp Root CA.

I'm proposing that Example has to disclose the Example Server CA, Example 
Client CA, and Contoso Corp Root CA certificates.  Contoso has to disclose the 
Contoso CA - S1A and Contoso CA - C1B certificates.
However Example would not have to separately disclose the Contoso CA - S1A and 
C1B certificates, even though they transitively chain to the Example Root.

Everything would be in Salesforce, but only one CA would be managing it 
Salesforce, rather that having two CAs separately report the same information.

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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New requirement: certlint testing

[Kurt Roeckx]

On Mon, Feb 08, 2016 at 02:30:05PM -0800, Kathleen Wilson wrote:
> 
> Not much you can do about a currently-included root certificate other than
> re-issue the root certificate which can cause many other problems.

So I was under the impression that they needed to check their
currently signed certificates.  Should they only check their own
root CA certicate for lint errors?


Kurt

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

Re: New requirement: certlint testing

[Kathleen Wilson]

On 2/8/16 2:36 PM, Kurt Roeckx wrote:

On Mon, Feb 08, 2016 at 02:30:05PM -0800, Kathleen Wilson wrote:


Not much you can do about a currently-included root certificate other than
re-issue the root certificate which can cause many other problems.


So I was under the impression that they needed to check their
currently signed certificates.  Should they only check their own
root CA certicate for lint errors?


Kurt




Yes, CAs should check the certificates chaining up to their included 
root certs.


Bugzilla Bugs may be filed for non-BR-compliant certificates chaining up 
to included root certificates, and added to the dependency list for 
https://bugzilla.mozilla.org/show_bug.cgi?id=1029147


Unfortunately I do not have the bandwidth to chase these down, but I can 
help get the bugs directed to the responsible CA representative.


Note that I think there are still some things with the certlint tests 
that need to be ironed out, before filing bugs for every reported error.


Thanks,
Kathleen

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

Re: New requirement: certlint testing

[Peter Bowen]

On Mon, Feb 8, 2016 at 2:46 PM, Kathleen Wilson  wrote:
>
> Note that I think there are still some things with the certlint tests that
> need to be ironed out, before filing bugs for every reported error.

I am unaware of anything that is flagged as Fatal or Error on non-CA
certificates that is an open issue.

The one item on CA certificates that is a questionable Error is
whether a CA must have a commonName.  I don't think Mozilla requires
such, so this should not be considered an error for Mozilla purposes.

Thanks,
Peter

(author of certlint)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New requirement: certlint testing

[Kathleen Wilson]

On 2/8/16 1:36 PM, Kurt Roeckx wrote:

On Mon, Feb 08, 2016 at 12:18:12PM -0800, Kathleen Wilson wrote:

All,

We recently added two tests that CAs must perform and resolve errors for
when they are requesting to enable the Websites trust bit for their root
certificate.

Test 1) Browse to https://crt.sh/ and enter the SHA-1 Fingerprint for the
root certificate. Then click on the 'Search' button. Then click on the 'Run
cablint' link. All errors must be resolved/fixed.

Test 2) Browse to https://cert-checker.allizom.org/ and enter the test
website and click on the 'Browse' button to provide the PEM file for the
root certificate. Then click on 'run certlint'. All errors must be
resolved/fixed.

I added these to item #15 of
https://wiki.mozilla.org/CA:Information_checklist#Technical_information_about_each_root_certificate

This has sparked some discussions in Bugzilla Bugs that I think we should
move here to mozilla.dev.security.policy so that everyone may benefit from
the resulting decisions.


So you're requesting this for new CAs?  What about existing CAs?
Should we file bugs in bugzilla about the issues it found?  Are
they supposed to look at it themself and fix things?


Kurt




Not much you can do about a currently-included root certificate other 
than re-issue the root certificate which can cause many other problems.


We will let the currently-included root certificates remain as-is 
(assuming proper CP/CPS/audits...), but all new root certificates must 
pass the tests before they may be included.


Thanks,
Kathleen

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

A-Trust Root Renewal Request

[Kathleen Wilson]

This request is to include the ‘A-Trust-Root-05’ root certificate, turn 
on the Websites trust bit, and enable EV treatment. This new root 
certificate will replace the ‘A-Trust-nQual-03’ root certificate that 
was included via Bugzilla Bug #530797. The ‘A-Trust-nQual-03’ root 
certificate expired, so it was removed via Bugzilla Bug #1204997.


A-Trust’s product range comprises user certificates, developer 
certificates and corporate certificates as well as consultation services 
and support with the development of e-commerce and signature 
applications in accordance with the Directive 1999/93/EC. A-Trust’s CA 
hierarchy is used to issue Austrian Citizen Cards and A-Trust SSL 
certificates.


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

And in the pending certificates list:
https://wiki.mozilla.org/CA:PendingCAs

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

Noteworthy points:


* The primary documents are the CP and CPS, provided in German, with 
some translations into English.


Document Repository: http://www.a-trust.at/ATrust/Downloads.aspx
CP: https://www.a-trust.at/docs/cp/a-sign-ssl-ev/a-sign-ssl-ev.pdf
CPS: https://www.a-trust.at/docs/cps/a-sign-ssl-ev/a-sign-ssl-ev_cps.pdf

* CA Hierarchy: This root has internally-operated subordinate CAs:
- a-sign-SSL-05 (http://www.a-trust.at/certs/a-sign-ssl-05.crt)
- a-sign-SSL-EV-05 (http://www.a-trust.at/certs/a-sign-ssl-ev-05.crt)

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


Translation of EV SSL CPS sections 3.1.7, 3.1.8, and 3.1.9:
https://bug1092963.bugzilla.mozilla.org/attachment.cgi?id=8584406

3.1.7 Authentication of organisations
When ordering an a.sign SSL EV certficate, the domain and organisation 
has to be verified. If the ordering entity is registered in either the 
austrian commercial register or the European Business Register (EBR), 
A-Trust verifies the existence using the online - database of those 
registers. The registration number has to be inlcuded in the request.
The physical address is also verified using the offical register. If not 
applicable, the check is performed using a duplicate of a document that 
confirms the organisations existence. Examples for such documents are 
extracts from legal registers or databases of trusted third parties.
The checks are performed according to the requirements in EV-GL 
(guidelines v1.2, CAB Forum), section 10.


In case an a.sign SSL EV certificate is order, additional information 
has to be gathered:
# confirmation issued by the bank of the ordering organisation, 
confirming the existance of an account related to the organisation

# annual statement of the organisation, verified by a certified accountant
# if an exchange embargos exist (inqury at responsible entity in the 
applicants country through A-Trust)
# verification of the physical address. If the address provided in the 
legal register used for verification of the organisation is also stated 
in the annual statement gathered in point 2, the physical address is 
considered correct. If these requirements are not met, verification can 
only be achieved through a check on location. Possible costs of this 
check are charged to the applicant. Further information can be found at 
EV-GL, section 10.4.1.


If an entire obtaining of all required information is not possible 
within a reasonable amount of time, the application is rejected and the 
applicant will be informed.


3.1.8 Check of Domain or IP Address
The holder of a domain is verified using the databases provided by the 
applicable authority (such as www.nic.at, www.denic.de,...).

The use of IP adresses in EV certficates is not permitted.

3.1.9 Authentication of individuals
The individuals, who are audited in the process of issuing an a.sign SSL 
EV certificate are

# the domain owner
and, if the domain order is acting in the name of an organisation
# an organisational responsible person, that is allowed to sign in the 
ogranisations name and confirms the correctness of the application
The people that are mentioned in the application have to provide an 
identification document (i.e. passport).
If the organisational responsible person is not listed in the used 
register, additional confirmation of his status has to be provided (i.e. 
a certificate of authority).


* Root Certificate Download URL:
http://www.a-trust.at/certs/A-Trust-Root-05.crt

* EV Policy OID: 1.2.40.0.17.1.22

* Test Website: https://ca-train.a-trust.at/

* CRL URLs:
http://crl.a-trust.at/crl/A-Trust-Root-05
http://crl.a-trust.at/crl/a-sign-SSL-EV-05

* OCSP URL:
http://ocsp.a-trust.at/ocsp
Max expiration time of OCSP responses: 10 minutes

* Audit: Annual audits are performed by Ernst & Young, according to the 
WebTrust criteria.

Standard Audit: https://cert.webtrust.org/SealFile?seal=1932=pdf
BR Audit: https://cert.webtrust.org/SealFile?seal=1934=pdf
EV Audit: