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&iCAID=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&iCAID=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&opt=cablint https://crt.sh/?id=9123894&opt=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&opt=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&opt=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: > 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&file=pdf > BR Audit: https://cert.webtrust.org/SealFile?seal=1934&file=pdf > EV Audit: https://cert.webtrust.org/SealFile?seal=1933&file=pdf > > * Potentially Problematic Practices: None Noted > (http://wiki.mozilla.org/CA:Problematic_Practices) > > This begins the discussion of the request from A-Trust to include the > ‘A-Trust-Root-05’ root certificate, turn on the Websites trust bit, and > enable EV treatment. > > At the conclusion of this discussion I will provide a summary of issues > noted and action items. If there are outstanding issues, then an > additional discussion may be needed as follow-up. If there are no > outstanding issues, then I will recommend approval of this request in > the bug. > > Kathleen > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
