Hi Jesus and Erwann, I belive the problem you mentioned about our OCSP responder accepting URL-encoded OCSP requests is fixed. Could you be so kind to check this again?
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: Thursday, March 5, 2015 12:32 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: TurkTrust Root Renewal Request Hi Volkan, Look at RFC2560/6960 section A.1, describing the format of a request sent over HTTP: An OCSP request using the GET method is constructed as follows: GET {url}/{url-encoding of base-64 encoding of the DER encoding of the OCSPRequest} That is, some characters from the base64 representation of the request are transformed: / is transformed into %2F + is transformed into %2B = is transformed into %3D and your OCSP responder is supposed to reverse that transformation (only once), then base-64 decode the string, and continue with the process (OCSP request parsing, etc). It seems your OCSP responder doesn't accept URL-encoded OCSP requests, or at least the "%2F". For exemple, http://ocsp.turktrust.com.tr/MG8wbTBGMEQwQjAJBgUrDgMCGgUABBQQ2AK0bL%2FGhSj1k0wefmhq3OpH2QQUm2YLShhBeYBnKwY4pSPDzSCPzccCCQFsT3pmwByBWqIjMCEwHwYJKwYBBQUHMAECBBIEEHVUJl9ozL9EVAJGSJJt7yA%3D gives a 400 error, and if I change "%2F" into "/", I get an OCSP response. May this can help you: I think this is the same error that Mr Erwann Abalea detected on this OCSP Responder in May 2012 (See "TURKTRUST Additional Root Inclusion Request" discussion). Cheers, J El miércoles, 4 de marzo de 2015, 17:33:02 (UTC+1), Volkan Nergiz escribió: > Hi All, > > #1: As far as we know, our OCSP server already works with HTTP GET requests. > When we analyze the logs, we see many GET requests that are being responded > successfully. > > For example, we have generated the OCSP request below, using the > openssl tool, for the certificate of > https://testsuite12002.turktrust.com.tr/ > > MG8wbTBGMEQwQjAJBgUrDgMCGgUABBQQ2AK0bL/GhSj1k0wefmhq3OpH2QQUm2YLShhBeY > BnKwY4pSPDzSCPzccCCQFsT3pmwByBWqIjMCEwHwYJKwYBBQUHMAECBBIEEHVUJl9ozL9E > VAJGSJJt7yA= > > When we paste this request to the address bar of Firefox 36.0 as: > > http://ocsp.turktrust.com.tr/MG8wbTBGMEQwQjAJBgUrDgMCGgUABBQQ2AK0bL/Gh > Sj1k0wefmhq3OpH2QQUm2YLShhBeYBnKwY4pSPDzSCPzccCCQFsT3pmwByBWqIjMCEwHwY > JKwYBBQUHMAECBBIEEHVUJl9ozL9EVAJGSJJt7yA= > > we get a successful "good" answer using HTTP GET. > > Could you please share with us the name of the OCSP client tool and the > content of the request, or any other clue that made you think that our OCSP > server does not support HTTP GET? > > Best Regards, > > Volkan Nergiz > TURKTRUST, Inc. > > -----Original Message----- > From: dev-security-policy > [mailto:dev-security-policy-bounces+volkan.nergiz=turktrust.com.tr@lis > ts.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 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
