Hi All, #1: We will answer separately.
#2: RFC 6960 includes the following text about generating "revoked" responses for non-issued certificates (in Section 2.2): -------------------------------------------------- The "revoked" state indicates that the certificate has been revoked, either temporarily (the revocation reason is certificateHold) or permanently. This state MAY also be returned if the associated CA has no record of ever having issued a certificate with the certificate serial number in the request, using any current or previous issuing key (referred to as a "non-issued" certificate in this document). ....... The "revoked" status is still optional for non-issued certificates in order to maintain backwards compatibility with deployments of RFC 2560. -------------------------------------------------- As far as we understand from the "MAY" keyword above, and the last sentence quoted, generating "revoked" responses (instead of "unknown") for non-issued certificates is not a MUST in RFC 6960. Thus, we think that this should not be a blocking issue for our root inclusion process. Best Regards, Volkan Nergiz TURKTRUST, Inc. -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+volkan.nergiz=turktrust.com...@lists.mozilla.org] On Behalf Of Jesus F Sent: Tuesday, March 3, 2015 6:28 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: TurkTrust Root Renewal Request Hi all, After some quick test of the OCSP Service I detect the following issues related to the conformity with CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates (hereinafter BR) as required by section 12 of Mozilla CA Certificate Inclusion Policy v2.2: Test site: https://testsuite12001.turktrust.com.tr Test site: https://testsuite12002.turktrust.com.tr Ocsp: http://ocsp.turktrust.com.tr/ #1: OCSP do not respond using GET method. (BR section 13.2.2) #2: Although the OCSP do not respond "good" to a non-issued certifcate (serials FFFFFFFFFFFFFFFFFF and 000000000000000000) (BR Section 13.2.6), it responds "unknown". This is not in accordance with RFC 6960 (section 2.2) contrary to what is stated in section 7.3 of the CP (http://dl.turktrust.com.tr/pdf/TURKTRUST-CP-v09-SSL.pdf) Cheers, J El martes, 3 de marzo de 2015, 16:37:21 (UTC+1), Volkan Nergiz escribió: > Dear All, > > > > The issue is actually quite clear and explicitly stated in TURKTRUST > CP and CPS documents. Please see > <http://dl.turktrust.com.tr/pdf/TURKTRUST-CP-v09-SSL.pdf> > http://dl.turktrust.com.tr/pdf/TURKTRUST-CP-v09-SSL.pdf and > <http://dl.turktrust.com.tr/pdf/TURKTRUST-CPS-v09-SSL.pdf> > http://dl.turktrust.com.tr/pdf/TURKTRUST-CPS-v09-SSL.pdf for the > English versions of TURKTRUST CP and CPS regarding SSL, EV SSL and > Object Signing > (OSC) certificate services. > > > > Currently, TURKTRUST has three explicit OIDs for SSL, EV SSL and OSC > certificates as follows with dedicated policies: > > > > 1. TURKTRUST SSL Certificate Policy (2.16.792.3.0.3.1.1.2) covers > OV SSL certificates for servers. SSL Certificates are issued and > maintained in conformity with "Normalized Certificate Policy" defined > in ETSI TS 102 042. > > 2. TURKTRUST OSC Policy (2.16.792.3.0.3.1.1.4) covers > certificates related to object signing operations. OSC is issued and > maintained in conformity with "Normalized Certificate Policy" defined > in ETSI TS 102 042. > > 3. TURKTRUST EV SSL Policy (2.16.792.3.0.3.1.1.5) covers > certificates related to EV SSL certificates. EV SSL certificates are > issued and maintained in conformity with ""Extended Validity Certificate > Policy" > defined in ETSI TS 102 042. > > > > For EV SSL services, we have a separate EV root in our new hierarchies > as mandated by the CA/Browser Forum EV Guidelines. This is the > "TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H6" root certificate. > > > > For OV SSL and code signing (OSC), we have another separate root > certificate, namely "TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5" > root certificate. > > > > For our qualified electronic certificate (QEC) services related to our > e-signature based operations, we have a totally different root called H4. > This is out of discussion in this context. > > > > Hence, the primary distinction related to our discussion is that we > have two separate roots for EV SSL services and the others. > > > > The second distinction is that, we have separate sub-root certificates, i.e. > intermediate certificates, for our OV SSL and OSC certificate > services under the root H5. That is to say, all certificate types have > different policies, different OIDs, different intermediates and > different operational processes. > > > > We hope, these explanations clarify the issue for all. Should you have > and further questions, please do not hesitate to contact us. > > > > Best regards, > > > > Volkan NERGİZ > > > Quality Management System Specialist > > > > > > TURKTRUST Information Security Services Inc. > > Address: Hollanda Caddesi 696. Sokak No: 7 Yıldız, Çankaya 06550 - > ANKARA > > Phone: (312) 439 10 00 - 226 Fax: (312) 439 10 01 > > E-Mail: <mailto:volkan.ner...@turktrust.com.tr> > volkan.ner...@turktrust.com.tr > > Web: <http://www.turktrust.com.tr/> www.turktrust.com.tr _______________________________________________ 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
