TURKTRUST root CA certificate inclusion request
Frank Hecker
root store, as documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=380635
and in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#T%C3%9CRKTRUST
I have evaluated TÜRKTRUST's request, as per the mozilla.org CA
certificate policy:
http://www.mozilla.org/projects/security/certs/policy/
https://bugzilla.mozilla.org/show_bug.cgi?id=380635#c39
and propose to approve this request in two weeks time after a public
discussion period. If you have any objections, or know of facts which
might influence this decision, please make them known before then.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Eddy Nigg (StartCom Ltd.)
> TÜRKTRUST has applied to add two root CA certificates to the Mozilla
> root store, as documented in the following bug:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=380635
>
> discussion period. If you have any objections, or know of facts which
> might influence this decision, please make them known before then.
>
I've gone through the bug information and read the third revision of the
CPS of TÜRKTRUST. As usual I have a few questions to you concerning this
application.
- Audit statement/confirmation is from the *June 2005* supplied by the
CA. So the Mozilla CA policy doesn't require re-audits, shouldn't
initial audits be fairly recent? Maybe they have a newer confirmation
than this one?
- Under 4.2.1 it says: "*No authentication* shall be made when
processing applications for trial certificates." However as I
understand, this trial certificates are issued from the same root. This
is a problem which has also been highlighted by Gerv already in the bug
itself.
The answer supplied at comment
https://bugzilla.mozilla.org/show_bug.cgi?id=380635#c29 was:
"You understand trial(i.e. test) certificates wrong I guess. The
trial certificates are given without fee. They are not valid under
Law since they are not qualified thus spoofing does not bother."
There was no follow up on this since you (Frank) took over the bug from
Gerv.
I'd expect this not to be acceptable according to the Mozilla CA policy
section 7 for SSL-enabled servers (and code signing as well), since in
the same section it says: "When processing a server certificate
application, the domain name that belongs to the server, the server’s
name and the name of the domain owner and personal information for the
server administrator should be verified by TÜRKTRUST’s registration
authorities."
In case a so called "trial" certificate is processed and no
authentication is performed, this means that also domain ownership
verification is impossible. No alternative validation for domain
ownership is provided either. Only email addresses are validated by an
email ping.
Does this mean that only S/MIME certificates are issued as "trial"
certificates? It doesn't say that anywhere in their CPS, therefore I
assume that it applies to all types of certificates.
-- Non specific to this bug --
- Not relevant or conditional to the Mozilla CA policy, however how can
a period of three years guaranty in any form even that the domain name
is still under the same owner? I know this should be discussed outside
of this inclusion request, but I would like to mention the fact that
certificates issued for longer than one year (under certain
circumstances even less) might result in a valid certificate in the
wrong hands. Scenario: Buy a popular domain name for one year, acquire
a certificate for three years (or more at certain CAs), let the domain
expire and have it bought by somebody else...This is something I also
would like to have addressed in some form in a future revision of the
Mozilla CA policy (note for myself).
- How are non-latin characters interpreted? There is no provision in the
Mozilla CA policy, nevertheless this is something which might be
interesting to know how this is handled by this CA (and other CAs in
that situation). Can problems arise if non-latin letters are used and
how would this affect the larger audience of Mozilla (outside of Turkey)?
--
Regards
Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber: star...@startcom.org <xmpp:star...@startcom.org>
Blog: Join the Revolution! <http://blog.startcom.org>
Phone: +1.213.341.0390
Eddy Nigg (StartCom Ltd.)
> Hey there Frank, Eddy, auditors of all colors,
>
> I personally feel uncomfortable with the approval of this application
> prior to resolution of the section 7 violation Eddy and Gerv have
> noted. Also, the CPS is a .doc file... could we get a file format
> that can be reviewed by the public, please? HTML or plain text would
> be much more appealing.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=380635#c29
>
> One resolution for this issue (as I understand it) might would be for
> the requesting entity to create a sibling CA that is not shipped in
> the mozilla CA root. The sibling CA could then be used for these
> "test" certificates without triggering a section 7 violation. This
> type of approach is touched on in section 13.
>
> I am concerned, however, that TÜRKTRUST would even consider using a
> production CA to issue "test" certificates.
Using an intermediate CA wouldn't solve this problem (as you call it,
sibling?), but an unrelated CA root would.
The CPS provided by this CA as in attachment
https://bugzilla.mozilla.org/attachment.cgi?id=286696 is in PDF format I
think....
C.J. Adams-Collier
wrote:
> Using an intermediate CA wouldn't solve this problem (as you call it,
> sibling?), but an unrelated CA root would.
>
I would have referred to an intermediate CA cert as a "child" or "sub" CA
cert. By "unrelated" (yours) and "sibling" (mine), we are referring to the
same thing, I believe. I used the term "sibling" as both CA certs (one for
inclusion by mozilla, one for signing so-called "test" certificates, and not
included by mozilla) would be produced by the same entity.
> The CPS provided by this CA as in attachment
> https://bugzilla.mozilla.org/attachment.cgi?id=286696 is in PDF format I
> think....
>
It looks like one of the superseded versions was originally a PDF, yes:
https://bugzilla.mozilla.org/attachment.cgi?id=270893
I don't feel comfortable with the approval of inclusion based on an
obsoleted document, though. If the applicant could be requested to publish
the most recent daft as HTML, PDF or plain text, the public would be able to
review the document, and I would feel more comfortable.
I've placed a summary of the attachments below.
Cheers,
C.J.
Communique on Electronic Signature:
pdf <https://bugzilla.mozilla.org/attachment.cgi?id=264743&action=edit>.
Turkish Electronic Signature Law:
pdf <https://bugzilla.mozilla.org/attachment.cgi?id=264744&action=edit>.
Ordinance on Electronic Signature:
pdf <https://bugzilla.mozilla.org/attachment.cgi?id=264745&action=edit>.
Certificate Practices Statement:
zip containing doc<https://bugzilla.mozilla.org/attachment.cgi?id=264746&action=edit>.
pdf <https://bugzilla.mozilla.org/attachment.cgi?id=270893&action=edit>.
doc<https://bugzilla.mozilla.org/attachment.cgi?id=279568&action=edit%20>.
doc <https://bugzilla.mozilla.org/attachment.cgi?id=286696&action=edit>.
Letter of Official CA Statement:
jpg <https://bugzilla.mozilla.org/attachment.cgi?id=264748&action=edit>.
first root hierarchy:
jpg <https://bugzilla.mozilla.org/attachment.cgi?id=270888&action=edit>.
second hierarchy:
jpg <https://bugzilla.mozilla.org/attachment.cgi?id=270889&action=edit>.
Letter of Commitment:
pdf <https://bugzilla.mozilla.org/attachment.cgi?id=270895&action=edit>.
Qualified Electronic Certificate (QEC) Application Form:
pdf <https://bugzilla.mozilla.org/attachment.cgi?id=270894&action=edit>.
--
moo.
Eddy Nigg (StartCom Ltd.)
verification revised)" in PDF format, however it exceeds 300Kb :S
What kind of limit is that? Anyway, will send it directly to whomever
requests it...
Mert Özarar (TÜRKTRUST)
<eddy_n...@startcom.org> wrote:
> Upon request I tried to add the "Third Version of TURKTRUST-CPS (email
> verification revised)" in PDF format, however it exceeds 300Kb :S
>
> What kind of limit is that? Anyway, will send it directly to whomever
> requests it...
>
> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
You can access the "Third Version of TURKTRUST-CPS" in PDF format from
the URL:
http://www.turktrust.com.tr/pdf/cps_third.pdf
Regards,
Mert ÖZARAR
Mert Özarar (TÜRKTRUST)
Dear Mr. Nigg,
First of all, thank you very much for your efforts and invaluable
comments on out inclusion.
I will briefly explain your questions and observations in this post.
Please take care the lines starting with
Answer
-----------
Thank you very much again for your support.
Best regards,
Mert ÖZARAR
--------------------------------------------------------------------------------------------------------
Hi Frank,
I've gone through the bug information and read the third revision of
the
CPS of TÜRKTRUST. As usual I have a few questions to you concerning
this
application.
- Audit statement/confirmation is from the *June 2005* supplied by
the
CA. So the Mozilla CA policy doesn't require re-audits, shouldn't
initial audits be fairly recent? Maybe they have a newer confirmation
than this one?
Answer
-----------
The audit statement has been taken from the first audit date which was
on June 2005. The Turkish Telecommunications Authority visits us
annually. Comment #38 will guide you that this process has been
completed for 2007. We can supply the official letter for this year's
audit. Besides we have already agreed on this subject with Gerv.
- Under 4.2.1 it says: "*No authentication* shall be made when
processing applications for trial certificates." However as I
understand, this trial certificates are issued from the same root.
This
is a problem which has also been highlighted by Gerv already in the
bug
itself.
The answer supplied at comment
https://bugzilla.mozilla.org/show_bug.cgi?id=380635#c29 was:
"You understand trial(i.e. test) certificates wrong I guess. The
trial certificates are given without fee. They are not valid
under
Law since they are not qualified thus spoofing does not bother."
There was no follow up on this since you (Frank) took over the bug
from
Gerv.
I'd expect this not to be acceptable according to the for SSL-enabled
servers (and code signing as well), since in
the same section it says: "When processing a server certificate
application, the domain name that belongs to the server, the server's
name and the name of the domain owner and personal information for
the
server administrator should be verified by TÜRKTRUST's registration
authorities."
In case a so called "trial" certificate is processed and no
authentication is performed, this means that also domain ownership
verification is impossible. No alternative validation for domain
ownership is provided either. Only email addresses are validated by
an
email ping.
Does this mean that only S/MIME certificates are issued as "trial"
certificates? It doesn't say that anywhere in their CPS, therefore I
assume that it applies to all types of certificates.
IMPORTANT Answer
------------------------------
I think there was a misunderstanding at so called "trial
certificates". Trial certificates are a type of certificates which are
not valid under Turkish Law. As you suppose, "digital certificate"
concept is quite a new topic for most of the countries except USA or
EU. The past of digital certificates entitled by Turkish Government is
just 2.5 years. We have started to give trial certificates after our
establishment for educational and promotional purposes. People who
have gathered trial certificates can use and learn at the same time
the aim of Public Key Infrastructure. They are NOT in the same
template with "Qualified Electronic Certificates"(QEC). Besides, the
root of the qualified certificates is completely DIFFERENT. Thus,
since all your arguments on trial certificates were assuming the same
root with QEC, I think there is no problem with Mozilla CA policy
section 7 as well.
Unfortunately, we are converting out web site to English and it will
end in a month time. But the Turkish citizens or our customers who can
speak Turkish can reach the URL that is about TURKTRUST root
certificates and trust hierarchy:
http://www.turktrust.com.tr/yrd_ksr.jsp
Here at the last line it states; "TÜRKTRUST deneme sertifikalarına ait
Deneme Sertifikası Kökünü yüklemek için buraya tıklayınız."
The exact English translation is "Please click here to load the root
certificate which belongs to trial certificates issued by TURKTRUST".
Hence, it can be understood that the trial certificates are signed by
another dedicated root other than QEC.
-- Non specific to this bug --
- Not relevant or conditional to the Mozilla CA policy, however how
can
a period of three years guaranty in any form even that the domain
name
is still under the same owner? I know this should be discussed
outside
of this inclusion request, but I would like to mention the fact that
certificates issued for longer than one year (under certain
circumstances even less) might result in a valid certificate in the
wrong hands. Scenario: Buy a popular domain name for one year,
acquire
a certificate for three years (or more at certain CAs), let the
domain
expire and have it bought by somebody else...This is something I also
would like to have addressed in some form in a future revision of the
Mozilla CA policy (note for myself).
Answer
-----------
As you have mentioned, this should be discussed outside of this
inclusion request even though I am quite agree with you. But it is an
open question since what a CA will do if someone acquires a 1 year
certificate and expires at the 9th month?
- How are non-latin characters interpreted? There is no provision in
the
Mozilla CA policy, nevertheless this is something which might be
interesting to know how this is handled by this CA (and other CAs in
that situation). Can problems arise if non-latin letters are used and
how would this affect the larger audience of Mozilla (outside of
Turkey)?
Answer
-----------
No problem can occur if the standard defined by X.509 and ASN.1
encodings are carefully carried out and implemented likewise in our
case. UTF8String is a simple ASN.1 string type identified by the
UNIVERSAL TAG number 12 and all the characters in Turkish exist in
UTF8. Hence I think there is no trouble at that point.
Frank Hecker
> C.J. Adams-Collier wrote:
<snip>
>> I am concerned, however, that TÜRKTRUST would even consider using a
>> production CA to issue "test" certificates.
> Using an intermediate CA wouldn't solve this problem (as you call it,
> sibling?), but an unrelated CA root would.
For the record, I am pretty sure that we have CAs already in the root
list that have issued test certs under their hierarchies. IIRC the last
instance of this I saw was a CA that had a subordinate CA used to
testing purposes, under the root CA that we include. (But as you note,
for our purposes a test certificate issued directly from a root CA is
equivalent to a test certificate issued from a subordinate CA under that
root. In both cases the test cert would be recognized as valid if the
root CA cert were recognized as valid.)
I'll ask the TÜRKTRUST representative more about the test certificates.
However as a general matter I'm not sure that a CA issuing test
certificates under a hierarchy is a real matter of concern, as long as
distribution of such certs and the associated private keys are suitably
controlled.
> The CPS provided by this CA as in attachment
> https://bugzilla.mozilla.org/attachment.cgi?id=286696 is in PDF format I
> think....
Please don't use the CPS documents attached to the bug. The English
version of the CPS is now available in PDF format directly from the
TÜRKTRUST site:
http://www.turktrust.com.tr/pdf/cps_third.pdf
Frank Hecker
> I don't feel comfortable with the approval of inclusion based on an
> obsoleted document, though. If the applicant could be requested to publish
> the most recent daft as HTML, PDF or plain text, the public would be able to
> review the document, and I would feel more comfortable.
See my previous message; the English version of the current CPS is at
http://www.turktrust.com.tr/pdf/cps_third.pdf
Eddy Nigg (StartCom Ltd.)
Frank Hecker wrote:
> I'll ask the TÜRKTRUST representative more about the test certificates.
> However as a general matter I'm not sure that a CA issuing test
> certificates under a hierarchy is a real matter of concern, as long as
> distribution of such certs and the associated private keys are suitably
> controlled.
>
>
As I understand from Mert ÖZARAR's response, the so called trial
certificates aren't issued from the same CA root, which is good! However
their CPS doesn't say this clearly and I assume that the CP doesn't
either. However we can't tell, since nobody has seen the CP. But the CP
(and to some extend the CPS) is the legal contract for all involved
parties, being it the CA, its subscribers, relying parties and in this
respect Mozilla (as a super relying party).
In light of this information, I suggest that TURKTRUST updated their CP
and CPS accordingly and perhaps remove the reference to the test
certificates altogether. Perhaps a different CP/CPS for the trial
certificates would be better.
Since efforts are made to get away as much as possible from self-signed
and "untrusted" CA roots, the best solution would be however that *any*
certificate issued by TURKTRUST, including trial and test certificates,
would be at least email/domain validated. Also relying parties wouldn't
get confused as why cert A might be recognized by the browser(s) and
cert B not (having to either click through the errors or importing the
CA root in question, which obviously shouldn't be recommended at all).
Additionally I suggest to wait for an English version of their web site.
The representative of TURKTRUST indicated that it will be due within a
month time. I have visited their site and tried to gain some information
which is almost impossible without knowing Turkish ;-)
(I also intend to reply to posting made by Mert ÖZARAR a.s.a.p)
Eddy Nigg (StartCom Ltd.)
Thank you for your participation here! Please allow me a few notes and
suggestions.
Mert Özarar (TÜRKTRUST) wrote:
> Answer
> -----------
> The audit statement has been taken from the first audit date which was
> on June 2005. The Turkish Telecommunications Authority visits us
> annually. Comment #38 will guide you that this process has been
> completed for 2007. We can supply the official letter for this year's
> audit. Besides we have already agreed on this subject with Gerv.
>
Yes, I've followed the bug entries and have read the relevant comments.
I would suggest to submit the most recent audit statement.
> IMPORTANT Answer
> ------------------------------
> I think there was a misunderstanding at so called "trial
> certificates". Trial certificates are a type of certificates which are
> not valid under Turkish Law. As you suppose, "digital certificate"
> concept is quite a new topic for most of the countries except USA or
> EU. The past of digital certificates entitled by Turkish Government is
> just 2.5 years. We have started to give trial certificates after our
> establishment for educational and promotional purposes. People who
> have gathered trial certificates can use and learn at the same time
> the aim of Public Key Infrastructure. They are NOT in the same
> template with "Qualified Electronic Certificates"(QEC). Besides, the
> root of the qualified certificates is completely DIFFERENT.
As I wrote to the list earlier, I suggest to omit the trial certificates
entirely from the main CP/CPS and publish a dedicated CP/CPS for the CA
root which issues the trial certificate. The CP/CPS is the legal
contract for all involved parties and therefore this is critical.
Alternatively I suggest to update the current CP/CPS to clearly indicate
that the trial certificates operate under a completely different CA root
which should not be imported into browsers except for testing purpose.
Even better would be to perform minimal validations even for the test
certificates, but obviously this is entirely your decision.
> Unfortunately, we are converting out web site to English and it will
> end in a month time.
I think this will be extremely helpful!
> Answer
> -----------
> As you have mentioned, this should be discussed outside of this
> inclusion request even though I am quite agree with you. But it is an
> open question since what a CA will do if someone acquires a 1 year
> certificate and expires at the 9th month?
>
Yes, I'm aware of this obviously, but there is still a difference
between a few month and a few years. Most of the times, registrars keep
previous domain names protected for a certain time in order to give the
original owner the chance to renew the contract with the registrar.
Additionally time plays a role when a potential attacker has the chance
to carefully plan and implement the attack (I'm speaking about
potentially 2 years in this case). A possible solution could be to have
the owner of the domain buy the domain for the respective period in
which case only a transfer of domain ownership would be possible (as
opposed to expiration).
> Answer
> -----------
> No problem can occur if the standard defined by X.509 and ASN.1
> encodings are carefully carried out and implemented likewise in our
> case. UTF8String is a simple ASN.1 string type identified by the
> UNIVERSAL TAG number 12 and all the characters in Turkish exist in
> UTF8. Hence I think there is no trouble at that point.
That's correct, however most of the potential users of Mozilla software
don't know Turkish nor the Turkish letters and the question really is,
how this should be handled from the point of view of Mozilla. What if
tomorrow a CA from -Insert Country Here- issues certificates in Russian,
Arabic, Hebrew, Chinese, Japanese etc letters...? Frank, this one is for
you...
Frank Hecker
> don't know Turkish nor the Turkish letters and the question really is,
> how this should be handled from the point of view of Mozilla. What if
> tomorrow a CA from -Insert Country Here- issues certificates in Russian,
> Arabic, Hebrew, Chinese, Japanese etc letters...? Frank, this one is for
> you...
Since you asked me to comment...
First, is this question about names included in end entity certificates?
(For example, a CA issuing an SSL server certificate to an organization,
and having the organization's name within the certificate being in
Turkish, or Hebrew, or Chinese, or whatever.)
If so, this issue seems (at least to me) to be related to the issue of
internationalized domain names (IDN). IIRC we already support display
and entry of domain names in, e.g., Chinese, Hebrew, etc.
Given that, why should we object to CAs putting Chinese, etc., names in
end entity certificates, as long as there is an appropriate technical
mechanism to make this work? A lot of the CAs we deal with now are
country-specific CAs whose businesses is very focused on the country in
which they're located. They will probably issue most if not all of their
certificates to organizations and individuals in their home country, and
those certificates will probably be seen primarily by users in those
countries. Since most of those users won't speak English, it makes sense
for domain names, names in certificates, and so on, to be in their
native language and the associated character set.
Eddy Nigg (StartCom Ltd.)
>
> Since you asked me to comment...
>
> First, is this question about names included in end entity certificates?
> (For example, a CA issuing an SSL server certificate to an organization,
> and having the organization's name within the certificate being in
> Turkish, or Hebrew, or Chinese, or whatever.)
>
> If so, this issue seems (at least to me) to be related to the issue of
> internationalized domain names (IDN). IIRC we already support display
> and entry of domain names in, e.g., Chinese, Hebrew, etc.
>
> http://developer.mozilla.org/en/docs/Internationalized_Domain_Names_(IDN)_Support_in_Mozilla_Browsers
>
knows to handle. Obviously the relying party might be interested more in
the other details than the domain name (except the initial verification
that this is the right email address or domain name).
> Given that, why should we object to CAs putting Chinese, etc., names in
> end entity certificates, as long as there is an appropriate technical
> mechanism to make this work? A lot of the CAs we deal with now are
> country-specific CAs whose businesses is very focused on the country in
> which they're located. They will probably issue most if not all of their
> certificates to organizations and individuals in their home country, and
> those certificates will probably be seen primarily by users in those
> countries. Since most of those users won't speak English, it makes sense
> for domain names, names in certificates, and so on, to be in their
> native language and the associated character set.
>
argument of course. Nevertheless, I think CAs which do operate in such
countries, most notably Verisign actually "translate" the names to
English (Latin) letters. Also passports have English interpretation of
the native names. Organizations have usually an internationalized name
associated with their native one. I haven't come across a passport (of
the affected countries of course) which doesn't have a secondary line
for each entry in Latin letters. As you understand by now, I'm in favor
of having Latin letters as a must and I guess I'll have to bring up some
good arguments in favor for it ;-)
BTW, do you remember from memory how the EV guidelines handles this?
Else I'll look it up later...it just would be interesting to know what
their decision was on this subject.
Jean-Marc Desperrier
> Given that, why should we object to CAs putting Chinese, etc., names in
> end entity certificates, as long as there is an appropriate technical
> [...] Since most of those users won't speak English, it makes sense
> native language and the associated character set.
Maybe it would be adequate to require that the CA applies a policy that
lowers the risk of homograph spoofing attacks. Nameprep and the IDN
language-specific registration policy applicable to the language(s) the
CA wishes to include in it's certificate might be adequate references.
Though I feel it's an important point that nothing has been required
until now for the CA already included in the list, and that, as far I
know, nothing restricts them from including non US-ASCII content in the
certificates they issue.
Frank Hecker
certificates:
> Maybe it would be adequate to require that the CA applies a policy that
> lowers the risk of homograph spoofing attacks. Nameprep and the IDN
> language-specific registration policy applicable to the language(s) the
> CA wishes to include in it's certificate might be adequate references.
Gerv is well-versed in this topic from his work with IDN and domain name
registrars. In fact, as I understand it, we implemented restrictions to
prevent use of IDN for particular top-level domains until the registrars
for those domains had appropriate controls in place. In theory at least
we could do a similar thing with CAs, with a metadata flag stored with
their root certs to control this.
> Though I feel it's an important point that nothing has been required
> until now for the CA already included in the list, and that, as far I
> know, nothing restricts them from including non US-ASCII content in the
> certificates they issue.
I honestly don't know what the current status is, either with regard to
support for non US-ASCII strings within certs, or use of such strings by
CAs. I've made a note of this on the "CA recommended practices" wiki
page, as a reminder.
Eddy Nigg (StartCom Ltd.)
> I honestly don't know what the current status is, either with regard to
> support for non US-ASCII strings within certs, or use of such strings by
> CAs. I've made a note of this on the "CA recommended practices" wiki
> page, as a reminder.
>
Perhaps this would be the appropriate place for it and of course you can
have a look there what I'm suggesting as well. Once there is agreement
on something it can be moved to the front page...what do you think?
Gervase Markham
> Maybe it would be adequate to require that the CA applies a policy that
> lowers the risk of homograph spoofing attacks.
I've actually opposed this in the past. Homograph spoofing avoidance
policies are the domain of registries, not CAs. These checks should be
done well, and they should be done in only one place - the registry. Any
other system would lead to buck-passing.
Gerv
Eddy Nigg (StartCom Ltd.)
Nice seeing you around.... ;-)
I think what Jean-Marc (and me previously) meant, is not related to the
domain name or email address but about the other details in the subject
line. Obviously the CN (or emailAddress) field is to be verified
accordingly...
Nelson B Bolyard
> For the record, I am pretty sure that we have CAs already in the root
> list that have issued test certs under their hierarchies. IIRC the last
> instance of this I saw was a CA that had a subordinate CA used to
> testing purposes, under the root CA that we include. (But as you note,
> for our purposes a test certificate issued directly from a root CA is
> equivalent to a test certificate issued from a subordinate CA under that
> root. In both cases the test cert would be recognized as valid if the
> root CA cert were recognized as valid.)
Please elaborate. What CA did that?
Is the subordinate CA that did so still valid (unexpired)?
I know of one CA that did so at one time, but the subordinate CA has
expired and the CA that issued it refused to renew it, because it had
been misused in this way.
IMO, this is a serious enough breach that it warrants calling for the
removal of the CA that did it. If the subordinate CA is still valid
and is not revoked, this calls for drastic action.
Frank Hecker
> Frank Hecker wrote:
>> For the record, I am pretty sure that we have CAs already in the root
>> list that have issued test certs under their hierarchies. IIRC the last
>> instance of this I saw was a CA that had a subordinate CA used to
>> testing purposes, under the root CA that we include.
> Please elaborate. What CA did that?
> Is the subordinate CA that did so still valid (unexpired)?
I have no idea. This is just a vague remembrance on my part, and I can't
vouch for its accuracy.
> IMO, this is a serious enough breach that it warrants calling for the
> removal of the CA that did it. If the subordinate CA is still valid
> and is not revoked, this calls for drastic action.
Let's ignore for a moment the question of whether a CA did this or not
(because as I noted above, my recollection may be faulty). I'm still
unclear on why issuing issuing one or more test certs from a CA
hierarchy is in and of itself a problem, *irrespective of the
circumstances under which they were issued*. I'm not referring to
issuing test certs to people outside the CA, in a way that bypasses
normal controls; that's clearly out of bounds. I'm talking about
internal testing by the CA's operations staff.
If I'm running a CA, and I want to test my procedures for issuing certs,
then what's the problem with having my internal staff issue a test cert
under a given hierarchy, in order to verify technical details,
compatibility with applications, etc., and then destroying the private
key for the cert to ensure it can't be further used? You're telling me
that no one at a CA has ever done this, and should never do it?
Michael Ströder
> Frank Hecker wrote:
>
>> For the record, I am pretty sure that we have CAs already in the root
>> list that have issued test certs under their hierarchies. IIRC the last
>> instance of this I saw was a CA that had a subordinate CA used to
>> testing purposes, under the root CA that we include.
>
> Is the subordinate CA that did so still valid (unexpired)?
> IMO, this is a serious enough breach that it warrants calling for the
> removal of the CA that did it. If the subordinate CA is still valid
> and is not revoked, this calls for drastic action.
+1 for the drastic action if that's really the case for any
pre-installed root CA or one of their subordinate CAs.
Ciao, Michael.
Gervase Markham
> domain name or email address but about the other details in the subject
> line. Obviously the CN (or emailAddress) field is to be verified
> accordingly...
Oh, I see. Yes, it's definitely worth them doing something like that.
But I don't know if we can require it, because then we need specs for
what to require.
Gerv
Nelson Bolyard
> Nelson B Bolyard wrote:
>> Frank Hecker wrote:
>>> For the record, I am pretty sure that we have CAs already in the >>>
root list that have issued test certs under their hierarchies.
>>> IIRC the last instance of this I saw was a CA that had a
>>> subordinate CA used to testing purposes, under the root CA that
>>> we include.
> <snip>
>> Please elaborate. What CA did that?
>> Is the subordinate CA that did so still valid (unexpired)?
>
> I have no idea. This is just a vague remembrance on my part, and I
> can't vouch for its accuracy.
>
>> IMO, this is a serious enough breach that it warrants calling for the
>> removal of the CA that did it. If the subordinate CA is still valid
>> and is not revoked, this calls for drastic action.
>
> Let's ignore for a moment the question of whether a CA did this or
> not (because as I noted above, my recollection may be faulty). I'm
> still unclear on why issuing issuing one or more test certs from a
> CA hierarchy is in and of itself a problem, *irrespective of the
> circumstances under which they were issued*. I'm not referring to
> issuing test certs to people outside the CA, in a way that bypasses
> normal controls; that's clearly out of bounds.
And, That's the scenario of concern, the one that's "out of bounds".
> I'm talking about internal testing by the CA's operations staff.
As long as there are sufficient controls on such internal CA testing,
that's fine.
> If I'm running a CA, and I want to test my procedures for issuing
> certs, then what's the problem with having my internal staff issue
> a test cert under a given hierarchy, in order to verify technical
> details, compatibility with applications, etc., and then destroying
> the private key for the cert to ensure it can't be further used?
> You're telling me that no one at a CA has ever done this, and should
> never do it?
No, I'm not talking about controlled CA testing.
The case of which I had previously heard was of a corporate CA that was
subordinate to a public root CA that was trusted in Mozilla, but expired
a few years ago. The corporate CA issued two subordinate CA certs to
subordinate internal corporate CAs. One of those internal CAs was
intended to issue official SSL server certs for use by official company
internal SSL servers, and applications for certs from that CA were
verified for authenticity and required management approval for issuance
(or so I was told).
The other of those two internal subordinate CAs was a "Test CA". It
was available to all company employees and no authentication whatsoever
of any information in the cert was performed. Employees could instantly
get SSL server certs for any DNS name of their choosing within the
company's own domains and subdomains. Certs from the test CA locked
the browser's lock icon just as well as certs from the official CA, in
nearly any browser on earth, and had normal validity periods, so they
didn't expire soon after issuance.
(The description given of TurkTrust's test CA reminded me of that,
except that I'm not sure TurkTrust's test CA limits the DNS domain in
which the cert can be issued.)
The certs from this "test CA" contained a string in the subject name
that disclaimed that the subject name was unverified (or some similar
disclaimer), and the people who ran the test CA naively thought that
was sufficient to prevent the test CA certs from being abused.
But of course, no browser user ever looks at the actual SSL server certs
unless the server cert fails to validate and causes a browser warning.
If the browser shows the lock, then browser users are satisfied that the
CA has done its job of authenticating the cert's subject.
(TurkTrust's repeated insistence that its test certs are not recognized
as valid under Turkish law reminded me of that, as if users are capable
of distinguishing valid-but-not-legally-recognized certs from valid and
legally recognized ones.)
I suspect you can guess what happened. Fortunately, the root CA cert
itself expired soon thereafter, and all the certs subordinate to that
root are no longer valid. But if this ever happens again, we need to
take swift action against any CA that allows that to happen, IMO.
Regarding TurkTrust, if (as they say) the test certs come from a CA
that chains up a separate, untrusted root, then all is well. But
perhaps you could ask for a test cert and its chain, just to make sure
it doesn't chain up to a to-be-trusted root?
Eddy Nigg (StartCom Ltd.)
Eddy Nigg (StartCom Ltd.)
> Regarding TurkTrust, if (as they say) the test certs come from a CA
> that chains up a separate, untrusted root, then all is well. But
> perhaps you could ask for a test cert and its chain, just to make sure
> it doesn't chain up to a to-be-trusted root?
policy and practice statements must be very clear in that respect.
Nobody else is to blame afterwards if it remains as is, because it's in
the CPS. Even if today the unvalidated certificates are issued from a
different root, it can be issued in the future from the root in the NSS
store, because that's what their CPS says today.
Nelson B Bolyard
>> Regarding TurkTrust, if (as they say) the test certs come from a CA
>> that chains up a separate, untrusted root, then all is well. But
>> perhaps you could ask for a test cert and its chain, just to make sure
>> it doesn't chain up to a to-be-trusted root?
> policy and practice statements must be very clear in that respect.
> Nobody else is to blame afterwards if it remains as is, because it's in
> the CPS. Even if today the unvalidated certificates are issued from a
> different root, it can be issued in the future from the root in the NSS
> store, because that's what their CPS says today.
Thank you for that clarification, Eddy!
I appreciate your thoroughness!
David E. Ross
> Gervase Markham wrote:
>> Eddy Nigg (StartCom Ltd.) wrote:
>>
>>> I think what Jean-Marc (and me previously) meant, is not related to the
>>> domain name or email address but about the other details in the subject
>>> line. Obviously the CN (or emailAddress) field is to be verified
>>> accordingly...
>>>
>> Oh, I see. Yes, it's definitely worth them doing something like that.
>> But I don't know if we can require it, because then we need specs for
>> what to require.
>>
>>
> Pure ASCII / Latin characters would do...do we need a spec for that?
>
Remember, ASCII stands for American Standard Code for Information
Interchange. Unless the X.509 specifications require it, we should
avoid ethnocenterism.
If a root certificate is used to issue site certificates that will
generally be used for Turkish language Web sites, I don't understand why
the contents of the root certificate can't also be in Turkish. The few
who actually look inside a certificate should, in this case, be literate
in Turkish but might not be literate in English or any other language
that is expressed solely in ASCII characters.
--
David E. Ross
<http://www.rossde.com/>
Go to Mozdev at <http://www.mozdev.org/> for quick access to
extensions for Firefox, Thunderbird, SeaMonkey, and other
Mozilla-related applications. You can access Mozdev much
more quickly than you can Mozilla Add-Ons.
Eddy Nigg (StartCom Ltd.)
>
> Remember, ASCII stands for American Standard Code for Information
> Interchange. Unless the X.509 specifications require it, we should
> avoid ethnocenterism.
>
this case about how to print something in the certificate. X.509 and not
about policies and its eventual implications. We could use "Latin"
instead of ASCII if this should be the concern.
> If a root certificate is used to issue site certificates that will
> generally be used for Turkish language Web sites, I don't understand why
> the contents of the root certificate can't also be in Turkish.
"generally"....but about what should be done policy wise. The
assumptions by anyone here about who, when and how uses a certificate
issued by whomever is out of place....otherwise why verify anything at
all? Or does this subject line say anything to you?
C=ישראל/ST=דרום/L=אילת/O=סטארטקום בע"מ/CN=ניק אדי
David E. Ross
> David E. Ross wrote:
>> Remember, ASCII stands for American Standard Code for Information
>> Interchange. Unless the X.509 specifications require it, we should
>> avoid ethnocenterism.
>>
> I understand what you mean here, but X.509 is a technical standard, in
> this case about how to print something in the certificate. X.509 and not
> about policies and its eventual implications. We could use "Latin"
> instead of ASCII if this should be the concern.
>> If a root certificate is used to issue site certificates that will
>> generally be used for Turkish language Web sites, I don't understand why
>> the contents of the root certificate can't also be in Turkish.
> Let me raise a point here...this isn't about "maybe", "might" and
> "generally"....but about what should be done policy wise. The
> assumptions by anyone here about who, when and how uses a certificate
> issued by whomever is out of place....otherwise why verify anything at
> all? Or does this subject line say anything to you?
>
> C=ישראל/ST=דרום/L=אילת/O=סטארטקום בע"מ/CN=ניק אדי
C is Israel. O appears to end (reading right-to-left) with a number,
perhaps 72 40. (This is without referring to a template of the X.509
subject line.) Without the vowels, I can't read the rest.
The point is that a large effort is made to internationalize Mozilla
products. I see Firefox has versions in 46 different languages,
including languages that don't use Latin characters. It would seem
strange if such languages could then not be used in certificates.
Perhaps, we might restrict certificates to only those 46 languages.
Then, we could tap the internationalization teams to perform
translations during the review of CA requests.
Eddy Nigg (StartCom Ltd.)
>
> C is Israel. O appears to end (reading right-to-left) with a number,
> perhaps 72 40. (This is without referring to a template of the X.509
> subject line.) Without the vowels, I can't read the rest.
>
to X.509 it's impossible to read it even...at least for normal human
beings such as you and me ;-)
> The point is that a large effort is made to internationalize Mozilla
> products. I see Firefox has versions in 46 different languages,
> including languages that don't use Latin characters. It would seem
> strange if such languages could then not be used in certificates.
>
is very important for software and I'm not arguing against. I know that
there is a dilemma in this case...I'm arguing that in this specific case
you can't please everybody. Also passports and international driving
licenses have English (Latin characters) translations. I view
certificates as an *international* document - exactly like the documents
I mentioned above. It wouldn't make sense if my passport couldn't be
read by anybody (except in my own country). I've got an international
driving license which is in English only...which gives...?
> Perhaps, we might restrict certificates to only those 46 languages.
> Then, we could tap the internationalization teams to perform
> translations during the review of CA requests.
>
>
--
Hasse
> I'm arguing that in this specific case
> you can't please everybody. Also passports and international driving
> licenses have English (Latin characters) translations. I view
> certificates as an *international* document - exactly like the documents
> I mentioned above.
What about pages on the World Wide Web? Should they as *international*
documents be restricted to English also?
--
Hasse
sv-SE l10n team
C.J. Adams-Collier
> On 11/30/2007 5:54 PM, Eddy Nigg (StartCom Ltd.) wrote:
> > Gervase Markham wrote:
> >> Eddy Nigg (StartCom Ltd.) wrote:
> >>
> >>> I think what Jean-Marc (and me previously) meant, is not related to
> the
> >>> domain name or email address but about the other details in the
> subject
> >>> line. Obviously the CN (or emailAddress) field is to be verified
> >>> accordingly...
> >>>
> >> Oh, I see. Yes, it's definitely worth them doing something like that.
> >> But I don't know if we can require it, because then we need specs for
> >> what to require.
> >>
> >>
> > Pure ASCII / Latin characters would do...do we need a spec for that?
> >
>
> Remember, ASCII stands for American Standard Code for Information
> Interchange. Unless the X.509 specifications require it, we should
> avoid ethnocenterism.
Even then, we should submit alterations to the RFC requesting that
non-discriminatory methods be used.
In this case, however, the x.509 definition specifies utf8.
> --
>
> David E. Ross
> <http://www.rossde.com/>
>
Cheers,
C.J.
--
moo.
Eddy Nigg (StartCom Ltd.)
>> I'm arguing that in this specific case
>> you can't please everybody. Also passports and international driving
>> licenses have English (Latin characters) translations. I view
>> certificates as an *international* document - exactly like the documents
>> I mentioned above.
>>
>
> What about pages on the World Wide Web? Should they as *international*
> documents be restricted to English also?
>
identification paper. In real life, nobody tells you what to wear
either....well, actually even that isn't completely true, there are
countries where one has to follow certain codes. Or by a different
comparison, the web site represents either a natural person (personal
web site, blog, photo gallery etc) or an organization (business,
foundation, charity, government agency), whereas the certificate
represents the identity card/passport or business registration/license
(or the confirmation thereof).
In short, a digital certificate is (usually) an international document
identifying certain aspects. If it's supposed to be of any value to a
relying party, well...it should be readable by that party. But if this
is not convincing, not going to force my view onto anybody ;-)
BTW, there is still a difference between German Umlaute or the Hebrew
Aleph-Bet....but something like that would be much harder to define than
just Latin letters.
Michael Ströder
I'd also argue that the language of the CPS, the certificates' content
and all related web pages of a PKI MUST suit the whole set of
subscribers and relying participants. Subscribers and relying
participants have certain obligations, e.g. checking CRLs, reading the
CPS and sometimes the certs' subject/issuer DNs. So they MUST have a
chance to do so.
In the case of a CA issuing SSL certs the relying participants are
protentially spread all over the world (unless a CA states that their
subscribers MUST limit use the certs very strictly)
=> CPS, certificates and web pages MUST be understandable not only for
some parts of the world. One might also argue that not every relying
party understands english though...
Ciao, Michael.
--
Michael Ströder
E-Mail: mic...@stroeder.com
http://www.stroeder.com
Mert Özarar (TÜRKTRUST)
Once again thank you very much for your ideas, efforts and support for
our case. We are quite delighted with the overall performance of this
group and decided to follow up other topics in the group as well to
increase our knowledge and experience on the target subjects to add
value on our services.
Our English website (beta version) is ready and have been uploaded
under domain. http://www.turktrust.com.tr/e/ is the current URL and it
can be reached from http://www.turktrust.com.tr by pressing "English"
button in the upper menu. You can analyze it in parallel but let me
remark some crucial points there regarding the fuzzy concepts.
"http://www.turktrust.com.tr/e/en51.jsp" gives the current trust
hierarchies, roots and subroots. I have mentioned why we have two
roots (former is not currently used) in the Bugzilla discussion page.
As you can notice, "Trial certificates" have a different trust
hierarchy, different root and no subroot(s). You can investigate the
details from the root of trial certificates. Besides, some other CAs
(some of them exist in the IMO trusted CA store) issue same kind of
certificates in the name of [trial/free/demo] certificates. The key
point here is that there is no living connection between them and the
target roots that we want to be recognized by IMO. They are not
subject to any law including Turkish Digital Signature Law. They are
free, dummy, intuitive and "trial" ceritificates just for promotion
and advertisement.
All the related material on trial certificates are detailly explained
in CPS (v3) [which can be reached directly from
http://www.turktrust.com.tr/e/pdf/cps_third.pdf]. As an employee of a
company working on PKI, I personally disagree on modifying the CP and
CPS to dispel the doubts on trial certificates as long as it is
obligatory. We have skimmed similar CP's and CPS's of some elite CAs
around the world and even some of them have not mentioned trial
certificates in details. Moreover, I feel really comfortable as long
as trial certificates are issued from a completely isolated hierarchy
as a security officer.
I understand the doubts on Latin character sets but it is a global
problem, of course. Since we are definitely agree on standards defined
by ASN.1 structures, PKCSs and related RFCs, UTF8 character set does
not cause any trouble in common applications. Unfortunately, we have
over 10.000 customers in Turkey and approxiamately 80% of their names
include a non-latin character. The solution provided to this situation
should be backward compatible , should not aggrieve CAs like us who
have non-Latin national alphabet and definitely will not affect our
acceptance to IMO store.
Please remark the URLs as well:
http://www.turktrust.com.tr/e/en52.jsp (Official document declared by
TTA) shows that the security specialists of TTA authorize us which
proves that there is no security leakage in our hierarchies, root and
subroots.
Best regards,
Mert ÖZARAR
TÜRKTRUST Representative
Gervase Markham
> Pure ASCII / Latin characters would do...do we need a spec for that?
How did a discussion about avoiding homograph spoofing turn into a
suggestion that we only allow Latin characters?
That's entirely unreasonable. We've spent years working on things like
IDN to internationalise the web; why reverse all that for fields in
certificates? There are established methods of checking for homographs -
e.g. the Unicode Consortium TR#36's list of confusables.
Gerv
Eddy Nigg (StartCom Ltd.)
Mert Özarar (TÜRKTRUST) wrote:
> Our English website (beta version) is ready and have been uploaded
> under domain. http://www.turktrust.com.tr/e/ is the current URL...
Very nice, congratulations on that!
> "http://www.turktrust.com.tr/e/en51.jsp" gives the current trust
> hierarchies, roots and subroots. I have mentioned why we have two
> roots (former is not currently used) in the Bugzilla discussion page.
> As you can notice, "Trial certificates" have a different trust
> hierarchy, different root and no subroot(s). You can investigate the
> details from the root of trial certificates.
I tried to found out more about the trial and other certificates at your
site (now that it's in English), however couldn't make the distinction
between any of them...perhaps you can guide me?
> Besides, some other CAs
> (some of them exist in the IMO trusted CA store) issue same kind of
> certificates in the name of [trial/free/demo] certificates.
Well, the discussion is about your CA which is currently considered to
be included in NSS! Any shortcoming by another CA can be discussed in an
unrelated thread on this mailing list. If you know about CAs which issue
unvalidated certificates and its root is currently in NSS please post it
here.
> The key
> point here is that there is no living connection between them and the
> target roots that we want to be recognized by IMO. They are not
> subject to any law including Turkish Digital Signature Law. They are
> free, dummy, intuitive and "trial" ceritificates just for promotion
> and advertisement.
>
Right, however your CPS doesn't make a distinction between different roots!
> We have skimmed similar CP's and CPS's of some elite CAs
> around the world and even some of them have not mentioned trial
> certificates in details.
It doesn't makes it OK. Maybe the CA you refer to has a separate CP/CPS
which regulate such certificates? But again, the only relevant authority
what Mozilla concerns is the Mozilla CA policy which must be satisfied.
> I understand the doubts on Latin character sets but it is a global
> problem, of course.
Absolutely and as I mentioned, the discussion about this issues doesn't
affect your application directly since the Mozilla CA policy doesn't
have any requirements in that respect. Sorry that this was so
extensively discussed in this thread.
>
> Please remark the URLs as well:
> http://www.turktrust.com.tr/e/en52.jsp (Official document declared by
> TTA)
This is the same statement from June 2005 which is already at the bug
report.
Eddy Nigg (StartCom Ltd.)
Gervase Markham wrote:
> How did a discussion about avoiding homograph spoofing turn into a
> suggestion that we only allow Latin characters?
>
Did you follow the thread actually? But I'd suggest we move this
discussion to a new thread since it's not related to this inclusion request.
> That's entirely unreasonable. We've spent years working on things like
> IDN to internationalise the web;
That's for domain names, yes. So it's questionable for digital
certificates IMO...
> why reverse all that for fields in
> certificates?
I explained it before. Because YOU can't read the subject line
/C=ישראל/ST=דרום/O=סטארטקום בע"מ/CN=אדי ניק
It's completely useless to you. A passport or international driving
license entirely in Hebrew, Arabic, Chinese, Japanese, Russian etc.
would be useless as well. However all international ID documents issued
by the affected countries have at least an English (Latin) translation
included (in addition to the natural language and character set). I view
digital certificates as such an international ID document. It should be
readable by the majority (as in passports).
> There are established methods of checking for homographs -
> e.g. the Unicode Consortium TR#36's list of confusables.
It's not about confusion or spoofing in relation to domain names, but
about the other content of the certificate.
Gervase Markham
> /C=ישראל/ST=דרום/O=סטארטקום בע"מ/CN=אדי ניק
> It's completely useless to you.
Absolutely. So I would seriously consider not trusting a site with such
a subject line.
> A passport or international driving
> license entirely in Hebrew, Arabic, Chinese, Japanese, Russian etc.
> would be useless as well. However all international ID documents issued
> by the affected countries have at least an English (Latin) translation
> included (in addition to the natural language and character set).
Really? I'd be interested in evidence of this.
Persuading all the CAs to adopt a scheme where you have both foreign and
Latin letters would be extremely difficult - not least because of the 64
character limit on field length.
Gerv
Eddy Nigg (StartCom Ltd.)
> Eddy Nigg (StartCom Ltd.) wrote:
>
>> I explained it before. Because YOU can't read the subject line
>> /C=ישראל/ST=דרום/O=סטארטקום בע"מ/CN=אדי ניק
>> It's completely useless to you.
>>
>
> Absolutely. So I would seriously consider not trusting a site with such
> a subject line.
>
subject, neither should Mozilla (policy wise)! However nothing prevents
that currently. And just for the record, I guess that EV doesn't allow
it either (so we don't have to mimic EV in the Mozilla CA policy, there
are certain basic patters which should be defined - as with minimal
validation, audit criterion etc).
>> A passport or international driving
>> license entirely in Hebrew, Arabic, Chinese, Japanese, Russian etc.
>> would be useless as well. However all international ID documents issued
>> by the affected countries have at least an English (Latin) translation
>> included (in addition to the natural language and character set).
>>
>
> Really? I'd be interested in evidence of this.
>
passports and driving licenses than you....in addition to that, one of
my two passports in my possession is exactly as described. I'm not sure
how I can provide evidence , but if I would be allowed to disclose the
information I have I could prove it.
> Persuading all the CAs to adopt a scheme where you have both foreign and
> Latin letters would be extremely difficult - not least because of the 64
> character limit on field length.
case do already. Stick to Latin characters...use the content of the
passport or driving license for example. This is what Verisign and other
CAs do in Japan for example. Most likely also in other countries.
Gervase Markham
> Gervase Markham wrote:
>> Eddy Nigg (StartCom Ltd.) wrote:
>>
>>> I explained it before. Because YOU can't read the subject line
>>> /C=ישראל/ST=דרום/O=סטארטקום בע"מ/CN=אדי ניק
>>> It's completely useless to you.
>>
>> Absolutely. So I would seriously consider not trusting a site with
>> such a subject line.
>>
> Exactly! And if the majority shouldn't trust a certificate with such a
> subject, neither should Mozilla (policy wise)!
That doesn't follow. If we include a certificate from a Turkish CA which
has a Turkish subject line, that's fine for Turkish people.
The letters they include here say nothing about their _trustworthiness_,
merely about my ability to evaluate it.
> No, that's not what I suggested, rather to stick what most CAs in any
> case do already. Stick to Latin characters...use the content of the
> passport or driving license for example. This is what Verisign and other
> CAs do in Japan for example. Most likely also in other countries.
EV is going to have Japanese letters, I know that for a fact because
there was a big discussion about it. I don't know what decision they
came to on also including a Romanisation. (Problems can arise because
some scripts have no official Romanisation, so there are several ways of
doing it.)
I don't think it's right for us to put restrictions in this area.
Gerv
Eddy Nigg (StartCom Ltd.)
> Eddy Nigg (StartCom Ltd.) wrote:
>> Exactly! And if the majority shouldn't trust a certificate with such a
>> subject, neither should Mozilla (policy wise)!
>>
>
> That doesn't follow. If we include a certificate from a Turkish CA which
> has a Turkish subject line, that's fine for Turkish people.
>
not related to the evaluation of TURKTRUST but in the broader context.
Just want to make sure that this is understood! Since it isn't regulated
in the Mozilla CA policy, it isn't an objection!
Now, you are right that this is certainly fine for people in the
knowledge of the respective language and character set. But what about
the rest? How can somebody make a judgment on the basis of the
certificate details if the vast majority can't read it? Shouldn't this
be handled as with other international legal documents such as
passports, international driving licenses, Red Cross employee cards etc?
> The letters they include here say nothing about their _trustworthiness_,
> merely about my ability to evaluate it.
>
Who said trustworthiness? I want to be able to read the content of the
certificate, know the name of the organization perhaps (matching that of
their web site or other information), perhaps the locality, country
etc...Which content should be in the C field for example? It's common to
use international two letter codes for country, but can this be actually
just anything? Like /C=לא רוצה להגיד
>> No, that's not what I suggested, rather to stick what most CAs in any
>> case do already. Stick to Latin characters...use the content of the
>> passport or driving license for example. This is what Verisign and other
>> CAs do in Japan for example. Most likely also in other countries.
>>
>
> EV is going to have Japanese letters, I know that for a fact because
> there was a big discussion about it.
Interesting!
> I don't know what decision they
> came to on also including a Romanisation. (Problems can arise because
> some scripts have no official Romanisation, so there are several ways of
> doing it.)
>
> I don't think it's right for us to put restrictions in this area.
>
Apparently it also has been widely discussed at the EV forum and not
surprisingly. Guess this subject might be the source for some more
discussions and concerns. Obviously certificates were issued in the past
generally in Latin characters and I haven't come across many which made
use of anything else. If this behavior is going to be changed with the
strife for localization, than perhaps the picture will look much
different in the future than today.
Oh...and btw, if EV indeed allows to use all kinds of character sets
than I view this as a serious devaluation of this standard. That's not
the way I expect businesses on the world-wide-web to identify
themselves. What is Larry going to say? Issued to "לא ידוע"? Mmmmhh ;-)
Michael Ströder
>
> Now, you are right that this is certainly fine for people in the
> knowledge of the respective language and character set. But what about
> the rest? How can somebody make a judgment on the basis of the
> certificate details if the vast majority can't read it? Shouldn't this
> be handled as with other international legal documents such as
> passports, international driving licenses, Red Cross employee cards etc?
I agree with Eddy on this. When defining cert profiles for CAs I always
take into consideration the set of relying participants. If the certs
are to be used globally they SHOULD be readable to the international
public like other international legal documents. This is not a technial
issue.
> Which content should be in the C field for example? It's common to
> use international two letter codes for country, but can this be actually
> just anything? Like /C=לא רוצה להגיד
For this particular attribute one should stick to the two-letter country
code (ISO 3166) as defined in X.520 section 5.3.1. Note that RFC 3280
also refers to X.520 (1993) in this regard.
Ciao, Michael.
Eddy Nigg (StartCom Ltd.)
> I agree with Eddy on this. When defining cert profiles for CAs I always
> take into consideration the set of relying participants. If the certs
> are to be used globally they SHOULD be readable to the international
> public like other international legal documents. This is not a technial
> issue.
>
>
than me. For me left to add, that localized certificates are probably
fine for a limited set of users issued by a locally operating CA but not
for a product used internationally on the world-wide-web used to
authenticate and identify. (I'm explicitly using the WWW word, even if
it sounds so much from the 90's, because that's what it still is). And
obviously the relying party is what it's all about and Mozilla software
is a product used globally!!!
> For this particular attribute one should stick to the two-letter country
> code (ISO 3166) as defined in X.520 section 5.3.1. Note that RFC 3280
> also refers to X.520 (1993) in this regard.
Mozilla CA policy and/or recommended practices for CAs.
This will be for the benefit of all sides, being it the relying party
(Mozilla, its users), the CAs and at last but not least it will improve
the standing of digital certificates generally. I think that also in
this respect Mozilla can improve the overall experience of the Internet
(see slogans of Mitch etc.) and take a lead in this respect and revert
the devaluation of said certification.
Michael Ströder
>> I agree with Eddy on this. When defining cert profiles for CAs I always
>> take into consideration the set of relying participants. If the certs
>> are to be used globally they SHOULD be readable to the international
>> public like other international legal documents. This is not a technial
>> issue.
>
> fine for a limited set of users issued by a locally operating CA but not
> for a product used internationally on the world-wide-web
Well, I think if the CA clearly states in its CP/CPS that the users
(subscribers and relying participants) of the issued certificates SHALL
be solely "local" users it does not matter whether Mozilla is a product
used globally. But for most CAs issuing SSL/TLS certs this assertion can
simply not be made.
=> The cert's content MUST be readable to the international public.
>> For this particular attribute one should stick to the two-letter country
>> code (ISO 3166) as defined in X.520 section 5.3.1. Note that RFC 3280
>> also refers to X.520 (1993) in this regard.
>
> Agreed! And I think that also in this regard we have to improve the
> Mozilla CA policy and/or recommended practices for CAs.
> This will be for the benefit of all sides, being it the relying party
> (Mozilla, its users), the CAs and at last but not least it will
> improve the standing of digital certificates generally.
I agree here. When writing a cert profile / CPS I'm often grateful for
any advice I can get from other clearly defined standards or policies.
Ciao, Michael.
Eddy Nigg (StartCom Ltd.)
> Well, I think if the CA clearly states in its CP/CPS that the users
> (subscribers and relying participants) of the issued certificates SHALL
> be solely "local" users it does not matter whether Mozilla is a product
> used globally. But for most CAs issuing SSL/TLS certs this assertion can
> simply not be made.
> => The cert's content MUST be readable to the international public.
>
international audience, *even* if the CAs intentions were meant for
"local use" (a term which hardly exists on the Internet - as opposed to
Intranet). Can NSS or other components limit certificates to a certain
region, language or characters set? Guess not and it isn't meant to be
that way anyway...
Therefore the Mozilla CA policy should be defined in that global,
international world-wide context. Additionally (this is for Gerv),
section 6 already states today: "provide some service relevant to
*typical users* of our software products". CAs which operate in a very
limited scope, issues certificates which the majority (the typical user)
can't read and hence the potential relying parties are a group limited
to a certain region/language, *do not comply* to this basic condition.
Defining aspects such as the issue I brought up is a natural extension
of this which in my opinion requires definition. And lets face it,
English is the de-facto international language used almost anywhere,
including the Internet. US-ASCII is the most widely used standard too.
And I'm not even speaking natively English, nor does Michael I think.... ;-)
Frank Hecker
> TÜRKTRUST has applied to add two root CA certificates to the Mozilla
> root store, as documented in the following bug:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=380635
>
> and in the pending certificates list here:
>
> http://www.mozilla.org/projects/security/certs/pending/#T%C3%9CRKTRUST
>
> I have evaluated TÜRKTRUST's request, as per the mozilla.org CA
> certificate policy:
>
> http://www.mozilla.org/projects/security/certs/policy/
> https://bugzilla.mozilla.org/show_bug.cgi?id=380635#c39
>
> and propose to approve this request in two weeks time after a public
> discussion period. If you have any objections, or know of facts which
> might influence this decision, please make them known before then.
The public comment period ended a while ago (my apologies for not
following up immediately after its conclusion). To repeat what I wrote
in comment #43 of bug 380635:
https://bugzilla.mozilla.org/show_bug.cgi?id=380635#c43
after considering the available information I've concluded that the two
final issues raised (non-Latin characters and trial certificates) have
been resolved to my satisfaction, and are not impediments to TÜRKTRUST's
application being approved. I've therefore signaled my approval of this
application in bug 380635, and will proceed to file an NSS bug for
inclusion of the actual root CA certs.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Frank Hecker
> I've therefore signaled my approval of this
> application in bug 380635, and will proceed to file an NSS bug for
> inclusion of the actual root CA certs.
Filed bug 410821 for inclusion of the TURKTRUST certs into NSS:
https://bugzilla.mozilla.org/show_bug.cgi?id=410821