TURKTRUST Additional Root Inclusion Request

[Kathleen Wilson]

TÜRKTRUST has applied to add the “TÜRKTRUST Elektronik Sertifika Hizmet
Sağlayıcısı” root certificate, turn on the websites and code signing
trust bits, and enable EV.

TÜRKTRUST Information Security Services Inc. is an IT company based in
Turkey. TÜRKTRUST is an authorized qualified electronic certificate
service provider according to the Turkish Electronic Signature Law.
TÜRKTRUST issues qualified certificates, time-stamping services, SSL
certificates, and object signing certificates.

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

And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#TURKTRUST

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

Noteworthy points:

* The primary documents are the CP and CPS, which are provided in English.

Document Repository: http://www.turktrust.com.tr/en/bilgideposu.html
CP:
http://www.turktrust.com.tr/en/files/bilgidepo/TURKTRUST_CP_V-05_%5BEN%5D_(01.11.2011).pdf
CPS: https://bugzilla.mozilla.org/attachment.cgi?id=612540

This is an offline root with internally-operated subordinate CAs which
sign end-entity certificates. The subCAs are:
1) “TÜRKTRUST Nitelikli Elektronik Sertifika Hizmetleri” -- Issues
Qualified Certificates
2) “TÜRKTRUST Bilgi İletişim ve Bilişim Güvenliği Hizmetleri”– Issues
SSL Certificates
3) “TÜRKTRUST EV SSL Sunucu Sertifikası Hizmetleri H3 - Sürüm 2” –
Issues EV SSL Certificates

The request is to turn on the websites and code signing trust bits.

* CPS section 1: As regards to SSL (Secure Socket Layer) Certificate, EV
(Extended Validation) SSL Certificate and OSC (Object Signing
Certificate) services, TURKTRUST conforms to the current version of the
CA/Browser Forum Guidelines for Issuance and Management of Extended
Validation Certificates published at http://www.cabforum.org and “ETSI
TS 102 042 Electronic Signatures Infrastructure (ESI); Policy
Requirements for Certification Authorities Issuing Public Key
Certificates”.

* CPS section 1.2:
- SSL Certificates are issued and maintained in conformity with
“Normalized Certificate Policy” defined in ETSI TS 102 042.
- OSC is issued and maintained in conformity with “Normalized
Certificate Policy” defined in ETSI TS 102 042.
- EV SSL certificates are issued and maintained in conformity with
“Extended Validity Certificate Policy” defined in ETSI TS 102 042.

* CPS section 3.1.5.4: DN in TURKTRUST OSC is formed as below:
-- “CN” contains complete name of the subscriber, which is based on the
official documentation according to the legislation of residence. --
“SERIALNUMBER” contains a trade registration number or code of the
subscriber, where the number or code is based on the official
documentation according to the legislation of residence.

* CPS section 3.2.2.1: The name of legal entity is verified against the
official documents of the country of residence of the applicant.
Verification herein is executed according to the TURKTRUST procedures.
The e-mail address submitted by the authorized person who conducts the
application operations on behalf of the subscriber should be verified.
This verification is done with a unique user name and activation code
sent to the authorized person’s e-mail address.

* CPS section 3.2.5: In cases where the name of a legal entity is to be
contained in a certificate, the applicant must submit an official
document showing the authority of the applicant to act on behalf of the
legal entity.


The request is to also enable EV.

* CPS section 3.2.2.2: In verification of an EV SSL application, minimum
criteria to be met are as follows:
- The name of legal entity is verified against the official documents of
the country of residence of the applicant. Additional to this
verification, circular of signature or an equivalent official document
in applicable legislation, showing the authority of the applicant to act
on behalf of the legal entity is required.
- Operational existence of the legal entity is confirmed via a third
party, who is a buyer of a product or service of the legal entity. Where
possible, an official document, obtained from a public agency or a
legally authorized person to do so, proving the operational existence
suffices to verify.
- Address of the legal entity’s place of business is verified according
to the legal documents of the country of residence. Moreover, telephone
numbers, submitted by the applicant, are checked if they are exactly
matched with the official records. In case of mismatch, correction is
required. Verified telephone is the called for applicant to confirm the
application.
- The e-mail address submitted by the authorized person who conducts the
application operations on behalf of the subscriber should be verified.
This verification is done with a unique user name and activation code
sent to the authorized person’s e-mail address.
- The following conditions should be met as well:
-- The legal entity is the owner of the DNS registry, or
-- The legal entity is given the exclusive right and authority to use the
DNS name.
All conditions that apply for authentication of legal entity for an EV
SSL applicant are given in Appendix. Given the conditions here, the
process of authentication of legal persons is conducted according to the
TURKTRUST procedures.

* CPS Appendix 6.I: To verify the Applicant’s registration, or exclusive
control, of the Domain Name(s) to be listed in the EV Certificate,
TURKTRUST verifies that each such Domain Name is registered with an
Internet Corporation for Assigned Names and Numbers (ICANN)- approved
registrar or a registry listed by the Internet Assigned Numbers
Authority (IANA). For Government Entity Applicants, TURKTRUST relies on
the Domain Name listed for that entity in the records of the QGIS in the
Applicant’s Jurisdiction.
TURKTRUST compares any registration information that is publicly
available from the WHOIS database with the verified Subject organization
information and confirms that it is neither misleading nor inconsistent.
TURKTRUST further confirms that the Applicant is aware of its
registration or exclusive control of the Domain Name.

* EV Policy OID: 2.16.792.3.0.3.1.1.5

* Root Cert URL:
http://www.turktrust.com.tr/sertifikalar/TURKTRUST_Elektronik_Sertifika_Hizmet_Saglayicisi_s3.crt

* Test Website: https://evssl.turktrust.com.tr

* CRL
http://www.turktrust.com.tr/sil/TURKTRUST_Kok_SIL_s3.crl
http://www.turktrust.com.tr/sil/TURKTRUST_SSL_SIL_s3.crl
http://www.turktrust.com.tr/sil/TURKTRUST_EV_SSL_H3_S2.crl
CPS Section 4.10.1: TURKTRUST publishes CRL twice a day within 12
(twelve) hour intervals with a validity period of 24 (twentyfour) hours
even if there is no change in the status of certificates.

* OCSP
http://ocsp.turktrust.com.tr

* Audit: Audits are performed by the Turkish Information and
Communication Technologies Authority (ICTA) and the BSI Group The
Netherlands B.V. according to the ETSI TS 101 456 and ETSI TS 102 042 -
SSL NCP & EV-CP criteria. TURKTRUST is listed as an Electronic
Certificate Service Provider and a statement from ICTA is provided here:
http://www.btk.gov.tr/bilgi_teknolojileri/elektronik_imza/eshs.php
The ETSI certificate from BSI was attached to the bug,
https://bugzilla.mozilla.org/attachment.cgi?id=585759.
TURKTRUST is also listed as a certified provider on the BSI website, and
can be found using “ETS 019” as the Certificate Number:
http://www.bsigroup.com/en/Assessment-and-certification-services/Client-directory/CertificateClient-Directory-Search/

* Potentially Problematic Practices
(http://wiki.mozilla.org/CA:Problematic_Practices):

** External Registration Authorities may be used.
* CPS 1.3.2: Registration authorities are CA units that offer services
to end users directly such as certificate application, renewal and
revocation. These units establish customer records; perform
identification and authentication processes and direct relevant
certificate requests to issuing certification authorities.
Actions associated with registration centers may be performed by
registration units within the TURKTRUST center in response to
certificate requests arriving from TURKTRUST sales representatives as
well as by registration centers affiliated with TURKTRUST. In both
cases, certificate requests are relayed to the TURKTRUST’s issuing
certification authority and the certificates are issued.

This begins the discussion of the request from TÜRKTRUST to add the
“TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı” root certificate,
turn on the websites and code signing trust bits, and enable EV. 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

[Erwann Abalea]

Le lundi 7 mai 2012 22:27:12 UTC+2, Kathleen Wilson a écrit :
> TÜRKTRUST has applied to add the “TÜRKTRUST Elektronik Sertifika Hizmet
> Sağlayıcısı” root certificate, turn on the websites and code signing
> trust bits, and enable EV.

No random data in the example certificate, produced in Jan 2012 and signed with SHA1withRSA.

The jurisdictionOfIncorporationCountryName attribute is not compliant with EV guidelines and RFC5280 (UTF8String used when PrintableString is required).

Intermediate and root certificate do not comply with RFC5280 attribute limits (organizationName are limited to 64 characters in length).

OCSP responder doesn't respond to GET requests (400, Bad Request).
POST requests are OK, but the dedicated responder doesn't show the OCSPNoCheck extension, so the browser should also download the CRL to validate its revocation status, making OCSP requests useless.
And in the OCSP response, the whole certificate chain, up to the root, is included. Not problematic, but useless (only the dedicated responder certificate is needed).

I haven't seen any validity limit on Mozilla CA Policy (or have missed it), but what about including in 2012 a root certificate that will expire in 2017?

[Mert Özarar (TÜRKTRUST)]

Dear Erwann,

Thanks a lot for your invaluable comments that have certainly helped
us to revise our infrastructure.

Here are the answers:

Before all, we are going to reissue a new end-entity certificate for
the test site (https://evssl.turktrust.com.tr).

1. This new end-entity certificate is going to contain at least 20
bits of unpredictable random data embedded in the "serial number"
field. We will adapt this scheme for further.

2. "jurisdictionOfIncorporationCountryName" is going to turn out to be
a PrintableString instead of UTF8String.

3. Due to Turkish Legislation, we had to put our complete company name
to that field. Yet our root certificates are fully compatible with
browsers and
other third party applications. Hence I think we should have
determined a field with less than 64 chars yet this one won't cause
any practical problem as well.

4. We have reconfigured our OCSP Responder. It answers to GET requests
now. You can check them.

5. Even though 5 years is not a long time, there is no restriction
like at least 6 or more years in the policy.

Best Regards,

Mert Özarar
Project Manager
TURTKRUST Inc.

[Erwann Abalea]

Bonjour,

Le jeudi 17 mai 2012 15:23:11 UTC+2, TÜRKTRUST Mert Özarar a écrit :
> Before all, we are going to reissue a new end-entity certificate for
> the test site (https://evssl.turktrust.com.tr).
>
> 1. This new end-entity certificate is going to contain at least 20
> bits of unpredictable random data embedded in the "serial number"
> field. We will adapt this scheme for further.
>
> 2. "jurisdictionOfIncorporationCountryName" is going to turn out to be
> a PrintableString instead of UTF8String.

I'll check this new certificate, then.

> 3. Due to Turkish Legislation, we had to put our complete company name
> to that field. Yet our root certificates are fully compatible with
> browsers and
> other third party applications. Hence I think we should have
> determined a field with less than 64 chars yet this one won't cause
> any practical problem as well.

"You haven't detected any problem yet" is different from "this won't cause any practical problem".
I was talking about the root and intermediate certificates, which contain " (c) Ocak 2012" or " (c) Aralik 2007". That doesn't seem to be part of a company name.

> 4. We have reconfigured our OCSP Responder. It answers to GET requests
> now. You can check them.

I just did, it still fails. HTTP 400 error, "bad request".

All these "GET failures" prevent Mozilla to switch to an OCSP GET strategy (I think I'm not the only one who'd really love to see Mozilla go for GET requests). And I don't really know how such applications could have succeeded with other vendors, with the same requirements (working OCSP, random data in serials, ...).

> 5. Even though 5 years is not a long time, there is no restriction
> like at least 6 or more years in the policy.

It was in fact a question to the other contributors, sorry. Microsoft, for example, asks for an 8 years validity at a minimum (at the application date). I'm not saying they've got everything right, just that Mozilla doesn't have such criteria.

[Mert Özarar (TÜRKTRUST)]

Hi Erwann,

- We are going to update our test site certificate on May 30th.
PrintableString and Random Serial fields shall be updated in the new
certificate in accordance with your warning. You can check it starting
from next midweek.
- We are going to shorten the company name in our future roots.There
is nothing that we can do for previous roots yet they are obviousy not
fatal errors.
- I have personally seen that our OCSP responder answers to GET
requests. Besides, I have just installed a third-party tool called
"Send HTTP Tool" to cross-check it. You can find a snapshot for a
positive proof at the URL: http://d1205.hizliresim.com/x/q/6gkmb.jpg

Regards,

Mert

[Erwann Abalea]

Bonsoir,

Le mardi 22 mai 2012 16:59:05 UTC+2, TÜRKTRUST Mert Özarar a écrit :
[...]

> - I have personally seen that our OCSP responder answers to GET
> requests. Besides, I have just installed a third-party tool called
> "Send HTTP Tool" to cross-check it. You can find a snapshot for a
> positive proof at the URL: http://d1205.hizliresim.com/x/q/6gkmb.jpg

The provided "proof" is an empty request, followed by an unsigned response (5 bytes).

It seems your OCSP responder doesn't accept URL-encoded OCSP requests.

For exemple,
http://ocsp.turktrust.com.tr/MEMwQTA%2FMD0wOzAJBgUrDgMCGgUABBSM%2FQRkbw6yhfp525xpuLIoMG%2FOugQU0qTSFzahTJsAMxuBPeeGj8frpzECAidT
gives a 400 error, and if I change every "%2F" into "/", I get an OCSP response.

Please read RFC2560, Appendix A, A.1.1. The request MUST be URL-encoded.

[Mert Özarar (TÜRKTRUST)]

Hi Erwann,

Thanks for your important warning. We have fixed the responder:

http://ocsp.turktrust.com.tr/MEIwQDA%2BMDwwOjAJBgUrDgMCGgUABBSvJIfo5Qyfg0OhRBeKi5gfnYoxLQQU2TezTgX92c%2BfEhautokv6yU6iBwCAQI%3D
http://ocsp.turktrust.com.tr/MEIwQDA+MDwwOjAJBgUrDgMCGgUABBSvJIfo5Qyfg0OhRBeKi5gfnYoxLQQU2TezTgX92c+fEhautokv6yU6iBwCAQI=

It handles both requests now. We have a doubt in our minds about "%2F"
since it can cause "Directory Traversal Attack" in our systems. We can
also change a configuration parameter in our web server to handle it
as well yet we first want to consult the group about its potential
disadvantages. What do you prefer?

Regards,

Mert

On 22 Mayıs, 22:31, Erwann Abalea <eaba...@gmail.com> wrote:
> Bonsoir,
>
> Le mardi 22 mai 2012 16:59:05 UTC+2, TÜRKTRUST Mert Özarar a écrit :
> [...]
>
> > - I have personally seen that our OCSP responder answers to GET
> > requests. Besides, I have just installed a third-party tool called
> > "Send HTTP Tool" to cross-check it. You can find a snapshot for a
> > positive proof at the URL:http://d1205.hizliresim.com/x/q/6gkmb.jpg
>
> The provided "proof" is an empty request, followed by an unsigned response (5 bytes).
>
> It seems your OCSP responder doesn't accept URL-encoded OCSP requests.
>

> For exemple,http://ocsp.turktrust.com.tr/MEMwQTA%2FMD0wOzAJBgUrDgMCGgUABBSM%2FQRk...

[Erwann Abalea]

Bonjour,

Le samedi 26 mai 2012 12:39:48 UTC+2, TÜRKTRUST Mert Özarar a écrit :
> Thanks for your important warning. We have fixed the responder:
>
> http://ocsp.turktrust.com.tr/MEIwQDA%2BMDwwOjAJBgUrDgMCGgUABBSvJIfo5Qyfg0OhRBeKi5gfnYoxLQQU2TezTgX92c%2BfEhautokv6yU6iBwCAQI%3D
> http://ocsp.turktrust.com.tr/MEIwQDA+MDwwOjAJBgUrDgMCGgUABBSvJIfo5Qyfg0OhRBeKi5gfnYoxLQQU2TezTgX92c+fEhautokv6yU6iBwCAQI=
>
> It handles both requests now. We have a doubt in our minds about "%2F"
> since it can cause "Directory Traversal Attack" in our systems. We can
> also change a configuration parameter in our web server to handle it
> as well yet we first want to consult the group about its potential
> disadvantages. What do you prefer?

It's not "what I prefer". It's "how clients will request your OCSP responder". And the definitive answer is RFC2560 behaviour, stating that URL-encoding MUST be done for GET requests.
I don't get how "/" instead of "%2F" might change something against directory traversal. Do you serve OCSP tokens as static files spread accross a filesystem?

[Mert Özarar (TÜRKTRUST)]

Dear All,

We have updated our test certificate located at
"evssl.turktrust.com.tr". I hope everything is fine with this new one.

Thanks & Regards,

Mert

On May 22, 5:59 pm, Mert Özarar (TÜRKTRUST) <mert.oza...@gmail.com>
wrote:

[Mert Özarar (TÜRKTRUST)]

We have modified the OCSP responder. It can answer any kind of
requests suitable with defined in RFC 2560. '%2F' problem has been
fixed as well.

Regards,

Mert

On May 28, 12:12 pm, Erwann Abalea <eaba...@gmail.com> wrote:
> Bonjour,
>
> Le samedi 26 mai 2012 12:39:48 UTC+2, TÜRKTRUST Mert Özarar a écrit :
>
> > Thanks for your important warning. We have fixed the responder:
>

> >http://ocsp.turktrust.com.tr/MEIwQDA%2BMDwwOjAJBgUrDgMCGgUABBSvJIfo5Q...
> >http://ocsp.turktrust.com.tr/MEIwQDA+MDwwOjAJBgUrDgMCGgUABBSvJIfo5Qyf...

[Mert Özarar (TÜRKTRUST)]

Hello,

We have the modified the responder in a manner that it can answer any
kind of requests that are suitable with RFC 2560. '%2F' problem is
solved as well.

Regards,

Mert

On May 28, 12:12 pm, Erwann Abalea <eaba...@gmail.com> wrote:
> Bonjour,
>
> Le samedi 26 mai 2012 12:39:48 UTC+2, TÜRKTRUST Mert Özarar a écrit :
>
> > Thanks for your important warning. We have fixed the responder:
>

> >http://ocsp.turktrust.com.tr/MEIwQDA%2BMDwwOjAJBgUrDgMCGgUABBSvJIfo5Q...
> >http://ocsp.turktrust.com.tr/MEIwQDA+MDwwOjAJBgUrDgMCGgUABBSvJIfo5Qyf...

[Kathleen Wilson]

Thank you to those of you who have reviewed and commented on this

request from TÜRKTRUST to add the “TÜRKTRUST Elektronik Sertifika Hizmet
Sağlayıcısı” root certificate, turn on the websites and code signing
trust bits, and enable EV.

Here is a summary of the concerns that were raised during this discussion.

Concern #1: Insufficient random data in the test certificate
Concern #2: jurisdictionOfIncorporationCountryName attribute is
UTF8String instead of PrintableString
Concern #3: OCSP issues (GET, OCSPNoCheck, RFC 2560)

Status of #1, 2, and 3: These have been resolved, and a new test
certificate provided for the test website, https://evssl.turktrust.com.tr

Concern #4: organizationName is too long

Status of #4: TurkTrust plans to create new root and intermediate
certificates that will resolve this issue within the next year.
TurkTrust requests that in the meantime this current root be included in
NSS.

Concern #5: Root cert is only valid until 2017

Mozilla doesn’t currently have set criteria about the minimum validity
of a root cert at application date, but in practice we have considered
the cutoff to be 2 years. As stated earlier, TurkTrust plans to create
the rollover root cert within the next year.

If there are no further questions or concerns about this request, then I
plan to close this discussion and recommend approval of this request in
the bug.

Thanks,
Kathleen

[Peter Kurrasch]

I have 2 minor comments that have nothing to do with acceptance of the root
cert. I have no objection to its inclusion.

1) Mert--I noticed the "postal code" attribute was simply set to "-". I'm
assuming this was just something put in place for the evssl host since it's
temporary and for testing purposes. I would expect that proper certs would
either have a legitimate postal code or the field would be omitted. Is
that fair to say?


2) To the wider Mozilla community and developers--I noticed that
Certificate Viewer is displaying some OIDs using the dot notation instead
of a human-readable name. Specifically, this is what I saw for the evssl
host cert:

CN = evssl.turktrust.com.tr
O = TÜRKTRUST BİLGİ İLETİŞİM VE BİLİŞİM GÜV. HİZM. A.Ş.
OU = TEKNİK HİZMETLER
L = ANKARA
ST = ÇANKAYA
C = TR
Object Identifier (2 5 4 5) = 193425
Object Identifier (2 5 4 15) = Private Organization
Object Identifier (2 5 4 9) = HOLLANDA CADDESİ 696. SOKAK NO:7 YILDIZ
Object Identifier (2 5 4 17) = -
Object Identifier (1 3 6 1 4 1 311 60 2 1 3) = TR

Considering the 2.5.4.* series has been around a while and the
*.311.60.2.1.* series is for CABF stuff, I would expect we wouldn't need to
default to dot notation for the display. Is this likely to be changed in a
future release? This was on Firefox 12.0, btw.

Thanks.

[Mert Özarar (TÜRKTRUST)]

Hi Peter,

You can be sure that there will certainly be legitimate postal code in
proper certificates issued under this target root. We have put '-'
just because it was a test one.

Best Regards,

Mert

[Kathleen Wilson]

On 6/4/12 3:22 PM, Peter Kurrasch wrote:
> 2) To the wider Mozilla community and developers--I noticed that
> Certificate Viewer is displaying some OIDs using the dot notation instead
> of a human-readable name. Specifically, this is what I saw for the evssl
> host cert:
>
> CN = evssl.turktrust.com.tr
> O = TÜRKTRUST BİLGİ İLETİŞİM VE BİLİŞİM GÜV. HİZM. A.Ş.
> OU = TEKNİK HİZMETLER
> L = ANKARA
> ST = ÇANKAYA
> C = TR
> Object Identifier (2 5 4 5) = 193425
> Object Identifier (2 5 4 15) = Private Organization
> Object Identifier (2 5 4 9) = HOLLANDA CADDESİ 696. SOKAK NO:7 YILDIZ
> Object Identifier (2 5 4 17) = -
> Object Identifier (1 3 6 1 4 1 311 60 2 1 3) = TR
>
> Considering the 2.5.4.* series has been around a while and the
> *.311.60.2.1.* series is for CABF stuff, I would expect we wouldn't need to
> default to dot notation for the display. Is this likely to be changed in a
> future release? This was on Firefox 12.0, btw.
>

Hi Peter,

I would file a bug for you, but I don't understand the issue. I don't
see these Object Identifiers when I view the certificate. Maybe it's
because I've installed an Add-On?

Anyways, please feel free to file a bug:
https://bugzilla.mozilla.org/

Product: Core
Component: Security: PSM

Thanks,
Kathleen

[Kathleen Wilson]

Thanks again to those of you who have reviewed and commented on this
request.

I am now closing this discussion, and I will post a summary of this
request and my recommendation for approval in the bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=433845

Any further follow-up on this request should be added directly to the bug.

Thanks,
Kathleen

[Rob Stradling]

Peter, Kathleen,

There's no need to file a new bug.

See https://bugzilla.mozilla.org/show_bug.cgi?id=500333

On 19/06/12 00:48, Kathleen Wilson wrote:
> On 6/4/12 3:22 PM, Peter Kurrasch wrote:

>> 2) To the wider Mozilla community and developers--I noticed that
>> Certificate Viewer is displaying some OIDs using the dot notation instead
>> of a human-readable name. Specifically, this is what I saw for the evssl
>> host cert:
>>
>> CN = evssl.turktrust.com.tr
>> O = TÜRKTRUST BİLGİ İLETİŞİM VE BİLİŞİM GÜV. HİZM. A.Ş.
>> OU = TEKNİK HİZMETLER
>> L = ANKARA
>> ST = ÇANKAYA
>> C = TR
>> Object Identifier (2 5 4 5) = 193425
>> Object Identifier (2 5 4 15) = Private Organization
>> Object Identifier (2 5 4 9) = HOLLANDA CADDESİ 696. SOKAK NO:7 YILDIZ
>> Object Identifier (2 5 4 17) = -
>> Object Identifier (1 3 6 1 4 1 311 60 2 1 3) = TR
>>
>> Considering the 2.5.4.* series has been around a while and the
>> *.311.60.2.1.* series is for CABF stuff, I would expect we wouldn't
>> need to
>> default to dot notation for the display. Is this likely to be changed
>> in a
>> future release? This was on Firefox 12.0, btw.
>>
>
>

> Hi Peter,
>
> I would file a bug for you, but I don't understand the issue. I don't
> see these Object Identifiers when I view the certificate. Maybe it's
> because I've installed an Add-On?
>
> Anyways, please feel free to file a bug:
> https://bugzilla.mozilla.org/
>
> Product: Core
> Component: Security: PSM
>
> Thanks,
> Kathleen

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> 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.