On 04/03/15 14:34, Volkan Nergiz wrote:
<snip>
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.
+1
ISTM that RFC6960 only applies here because TurkTrust's CPS claims to be
compliant with it. That's more than is required by the Mozilla CA
Certificate Inclusion Policy, which references the CABForum Baseline
Requirements, which say...
'13.2.5 OCSP Signing
OCSP responses MUST conform to RFC2560 and/or RFC5019.'
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: [email protected]
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:[email protected]>
[email protected]
Web: <http://www.turktrust.com.tr/> www.turktrust.com.tr
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
