DSV/S-TRUST root inclusion request

1 view
Skip to first unread message

Frank Hecker

unread,
Dec 16, 2008, 12:43:57 PM12/16/08
to
I've decided to make S-TRUST the next CA to enter the public discussion
period. (I need to do a little more work for KISA, T-Systems, and
Microsec, the other CAs near the top of the list.) S-TRUST is operated
by Deutscher Sparkassenverlag (DSV), which has applied to add four new
root CA certificates to the Mozilla root store, as documented in the
following bug:

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

and in the pending certificates list here:

http://www.mozilla.org/projects/security/certs/pending/#S-TRUST

Some quick comments regarding noteworthy points:

* S-TRUST issues certificates to individuals for use in SSL client
authentication and email. Since they don't issue certificates to SSL
servers, right now I've got them marked as requesting that only the
email "trust bit" be enabled.

However, does the SSL trust bit need to be enabled for S-TRUST client
certificates to be properly recognized at either the client or server
end? I can't remember the answer for this, and would appreciate advice.

* Per German law S-TRUST issues one new root CA certificate for every
year, with each root cert having a 5-year lifetime. Thus they are
currently requesting inclusion of four root certificates, for 2005
through 2008. Starting in 2010 the older root certs will begin to expire
and we can remove them.

* The CPS documents are in German (sorry Eddy!), but as far as I know we
have English translations of the relevant sections, and can do further
translations as needed.

* S-TRUST has undergone audits per the ETSI TS 101 456 and 102 042
criteria. The relevant audit certificates are still current.

I suggest reading Kathleen's summary document to get an overview of this
request; thanks again to Kathleen for preparing these!

As we did with SECOM Trust, I'm planning to have a single one-week
discussion period. After that week, if there are no outstanding issues
relating to the request then I am going to go ahead and officially
approve it. (Otherwise we'll postpone further discussion until the
issues are resolved.)

Frank

--
Frank Hecker
hec...@mozillafoundation.org

Eddy Nigg

unread,
Dec 16, 2008, 2:10:48 PM12/16/08
to
On 12/16/2008 07:43 PM, Frank Hecker:

> However, does the SSL trust bit need to be enabled for S-TRUST client
> certificates to be properly recognized at either the client or server
> end?

Absolutely not. Email is sufficient for S/MIME and authentication.

>
> * Per German law S-TRUST issues one new root CA certificate for every
> year, with each root cert having a 5-year lifetime. Thus they are
> currently requesting inclusion of four root certificates, for 2005
> through 2008. Starting in 2010 the older root certs will begin to expire
> and we can remove them.

This is unfortunate and seems to me problematic. I'd suggest that they
create a root from which they'd issue those as intermediate. I'm almost
certain that other vendors will not include them for the same reason (so
it's not an argument in itself, it just shows the limits of reason for
inclusion - some vendors do have specific requirements in this regard
which we don't). However I want to think more about it (if it's reasonable).

>
> * The CPS documents are in German (sorry Eddy!),

Why sorry? I speak fluently German....going to have a look at it if the
above isn't an issue.

>
> I suggest reading Kathleen's summary document to get an overview of this
> request; thanks again to Kathleen for preparing these!

Yes, they are always excellent! I really love the work Kathleen
performs, it speeds everything so much up!

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org

Frank Hecker

unread,
Dec 16, 2008, 5:04:05 PM12/16/08
to
Eddy Nigg wrote re S-TRUST issuing new root certificates annually:

> This is unfortunate and seems to me problematic. I'd suggest that they
> create a root from which they'd issue those as intermediate. I'm almost
> certain that other vendors will not include them for the same reason (so
> it's not an argument in itself, it just shows the limits of reason for
> inclusion - some vendors do have specific requirements in this regard
> which we don't). However I want to think more about it (if it's
> reasonable).

Please feel free to mention this issue in the bug. However I suspect
that S-TRUST is constrained in its practices by the relevant German laws
and/or EU directives. Unfortunately I couldn't find any references that
address this particular issue.

(Incidentally, when I was trying to find out more information about this
issue, one of my Google searches returned this as one of the top results:

http://www.springerlink.com/content/b586573164k873p4/

I'm sure many of you will find the title of this book quite apropos.)

> Why sorry? I speak fluently German....going to have a look at it if the
> above isn't an issue.

Excellent. I'm glad that after a diet of Hungarian and Japanese we have
something more to your taste :-)

Eddy Nigg

unread,
Dec 16, 2008, 5:33:31 PM12/16/08
to
On 12/17/2008 12:04 AM, Frank Hecker:

>
> Please feel free to mention this issue in the bug. However I suspect
> that S-TRUST is constrained in its practices by the relevant German laws
> and/or EU directives.

I'm not aware of such an EU directive (and we would have known by now
from other inclusion requests). It might be some specific German law and
if proved correct would just show, that they haven't thought it through.
How can the law makers expect to have software vendors update and add
and remove roots in that manner. That's fine for one CA, but there are
potentially tens if not hundreds.

Incidentally I think it unreasonable to include a root which will have
to be removed in less than a year or two. Anyway, I'll ask for more
information on this subject.


>
> (Incidentally, when I was trying to find out more information about this
> issue, one of my Google searches returned this as one of the top results:
>
> http://www.springerlink.com/content/b586573164k873p4/

Ha, just don't let them to make it one :-)


>> Why sorry? I speak fluently German....going to have a look at it if
>> the above isn't an issue.
>
> Excellent. I'm glad that after a diet of Hungarian and Japanese we have
> something more to your taste :-)
>

Well, they are all very nice people, but in the end of the day I can't
read it :S

Considering the various issues I found so far during the last two years?
or so...I don't feel really comfortable with those. Somehow it's
expected that such documents are (also) published in English, specially
since other will have to rely on the issued certificates without having
a chance to understand what they are about. I think you just mentioned
about the same somewhere else...

Ian G

unread,
Dec 16, 2008, 6:17:56 PM12/16/08
to mozilla's crypto code discussion list
On 16/12/08 23:04, Frank Hecker wrote:
> Eddy Nigg wrote re S-TRUST issuing new root certificates annually:

> Please feel free to mention this issue in the bug. However I suspect


> that S-TRUST is constrained in its practices by the relevant German laws
> and/or EU directives. Unfortunately I couldn't find any references that
> address this particular issue.


I don't see it in Annex II of DIRECTIVE 1999/93/EC, which would be the
technical place if it was in the Directive. It is also not in the SigG
which is the German implementation of the directive.

(The way it works is that the EU directive binds the governments, which
have to pass laws to bind the people. So the directive does not bind
the people, or in this case the CA.)

It is most likely in the regulations that are created by the regulating
agency; that is the way these things work. I think that is the
telecommunications regulator. Likely, these things are not translated
into English. (The simplification of "law" is often meant to include
these things.) If you really wanted to do see it, the thing to do would
be to ask for the specific regulations, and get them translated.

Just some thoughts!

iang

Frank Hecker

unread,
Dec 16, 2008, 6:26:04 PM12/16/08
to
Ian G wrote re creating new root certificates annually for CAs issuing
qualified certificates:

> It is most likely in the regulations that are created by the regulating
> agency; that is the way these things work. I think that is the
> telecommunications regulator. Likely, these things are not translated
> into English. (The simplification of "law" is often meant to include
> these things.)

I suspect you are right about this. (I couldn't find anything about this
practice in EU documents I found.)

> If you really wanted to do see it, the thing to do would
> be to ask for the specific regulations, and get them translated.

That's a good idea, I'll do that. I'd like to get a definitive answer on
this question, since I know I've seen this practice with other CAs,
including I think at least one not in Germany.

Eddy Nigg

unread,
Dec 16, 2008, 6:29:01 PM12/16/08
to
On 12/17/2008 01:26 AM, Frank Hecker:

>
> That's a good idea, I'll do that. I'd like to get a definitive answer on
> this question, since I know I've seen this practice with other CAs,
> including I think at least one not in Germany.
>

Frank, I asked about it at the bug already earlier. Once I get the
information I'll be glad to provide information about it, including
translation about the important parts (if this suits us).

Nelson B Bolyard

unread,
Dec 16, 2008, 8:42:32 PM12/16/08
to mozilla's crypto code discussion list
Frank Hecker wrote:
> I've decided to make S-TRUST the next CA to enter the public discussion
> period. (I need to do a little more work for KISA, T-Systems, and
> Microsec, the other CAs near the top of the list.) S-TRUST is operated
> by Deutscher Sparkassenverlag (DSV), which has applied to add four new
> root CA certificates to the Mozilla root store, as documented in the
> following bug:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=370627
>
> and in the pending certificates list here:
>
> http://www.mozilla.org/projects/security/certs/pending/#S-TRUST
>
> Some quick comments regarding noteworthy points:
>
> * S-TRUST issues certificates to individuals for use in SSL client
> authentication and email. Since they don't issue certificates to SSL
> servers, right now I've got them marked as requesting that only the
> email "trust bit" be enabled.
>
> However, does the SSL trust bit need to be enabled for S-TRUST client
> certificates to be properly recognized at either the client or server
> end? I can't remember the answer for this, and would appreciate advice.

In the presently released versions of Firefox, (or other NSS SSL clients)
no trust flag is necessary for a cert to be used for client authentication.
This is because the server tells the client which CAs are trusted by the
server, and the client picks a cert that is issued by one of the CAs named
by the server.

In an NSS server, the list of CA names sent out to remote clients when asking
them for client authentication is determined from the set of certs that have
the special SSL client auth CA trust flag. By default NO CA certs ever have
that flag set. Server admins must set that flag explicitly.

> * Per German law S-TRUST issues one new root CA certificate for every
> year, with each root cert having a 5-year lifetime.

Have they legislated that pi is 3 again?

New ROOT CA certificate? really? Root?
Is the requirement for a new cert? or for a new key?
That is, can each of the certs issued one year apart have the same key?

> Thus they are currently requesting inclusion of four root certificates, for
> 2005 through 2008. Starting in 2010 the older root certs will begin to
> expire and we can remove them.

Do the new certs for S-TRUST have the same key, or do they have different
keys? If they have different keys, do they also have different subject names?
Do they have different Subject Key ID (SKID) extension values?
Do the certs they issue have Authority Key ID (AKID) extensions?

This whole thing makes little sense, and is a pretty big concern.
Remember that unlike SSL server and client authentication, signatures on
emails and other types of files should be long lasting, and should be
verifiable for a long time. You don't want all the encrypted emails in your
mail folders to suddenly become unreadable because the signatures on those
messages can no longer be verified, because a CA cert has expired and has not
been renewed.

Eddy Nigg

unread,
Dec 16, 2008, 9:20:28 PM12/16/08
to
On 12/17/2008 03:42 AM, Nelson B Bolyard:

> Do the new certs for S-TRUST have the same key, or do they have
> different keys? If they have different keys, do they also have different
> subject names?
> Do they have different Subject Key ID (SKID) extension values?
> Do the certs they issue have Authority Key ID (AKID) extensions?
>

Nelson, see this attachment from Kathleen:
https://bugzilla.mozilla.org/attachment.cgi?id=337729 scroll to page two
and come to your own conclusions.

Frank Hecker

unread,
Dec 16, 2008, 9:45:56 PM12/16/08
to
Eddy Nigg wrote:
> Frank, I asked about it at the bug already earlier. Once I get the
> information I'll be glad to provide information about it, including
> translation about the important parts (if this suits us).

Thank you. I also sent an email message to the representatives of DSV,
alerting them to the start of the public discussion period and asking
them to respond to this question.

Nelson B Bolyard

unread,
Dec 17, 2008, 1:54:16 AM12/17/08
to mozilla's crypto code discussion list
Eddy Nigg wrote, On 2008-12-16 18:20:
> On 12/17/2008 03:42 AM, Nelson B Bolyard:
>> Do the new certs for S-TRUST have the same key, or do they have
>> different keys? If they have different keys, do they also have different
>> subject names?
>> Do they have different Subject Key ID (SKID) extension values?
>> Do the certs they issue have Authority Key ID (AKID) extensions?
>
> Nelson, see this attachment from Kathleen:
> https://bugzilla.mozilla.org/attachment.cgi?id=337729 scroll to page two
> and come to your own conclusions.

One of the reasons I asked the question is that MS Word files present a
problem for me.

But I did dig up the URLs for the 4 CA certs, and examined those certs.
Each of them has a separate subject name, public key, subject key ID,
authority key ID, and of course validity period.

To be honest, I think this is a burden that Mozilla ought not to bear.
Mozilla should not put itself into a position of needing to add a new
root CA cert for this CA every year, and then keep them for a long time
thereafter.

Further, if (as the bug suggests) the REAL PRIMARY purpose of this CA
is to provide German citizens with SSL client certificates, and it is
not used to issue SSL server certs, then it is (or should be) unnecessary
for their browsers to have this CA cert AT ALL. For SSL client auth
purposes, it's quite sufficient for the browser to just have the user's
cert and private key and no CA cert at all. The server sends down a
message saying "if you have a cert issued by this CA, send it". The
browser examines the certs it possesses to find ones that have the
desired string in the issuer name, and for which the browser has the
private key. Having the CA cert is unnecessary.

While some German law or regulation may require them to issue new roots
annually, I doubt that it prevents them from also issuing intermediate
CA certs with the same subject name, key, subject key ID, etc, but issued
by some single common root that changes infrequently (these are so-called
cross signed CA certs). With such a scheme, that root that issues the
cross signed certs can be the one to get put into Mozilla with email trust.

So, My advice is: just say no. Don't take on the burden of adding a
new root CA cert every year when there is no good need. Please consider
this an objection to including those roots in the root CA list.

Eddy Nigg

unread,
Dec 17, 2008, 5:31:57 AM12/17/08
to
On 12/17/2008 08:54 AM, Nelson B Bolyard:

>
> One of the reasons I asked the question is that MS Word files present a
> problem for me.
>

I use OpenOffice, and you?

Kathleen could have published those files as ODT, but I suspect that for
the benefit of all users, she preferred to publish DOC files so
everybody could read them, also those which DO use MS software for this
purpose. Perhaps she should publish them as PDF in the future.


> But I did dig up the URLs for the 4 CA certs, and examined those certs.
> Each of them has a separate subject name, public key, subject key ID,
> authority key ID, and of course validity period.

As suspected and indicated in the document.

> So, My advice is: just say no. Don't take on the burden of adding a
> new root CA cert every year when there is no good need. Please consider
> this an objection to including those roots in the root CA list.

As indicated earlier, I think it unreasonable as well. And this is
really unfortunate, since it could have done a lot of good for S/MIME,
specially when considering the high usage/market share of Mozilla
products in Germany and the chance to have some 40 million potential
users encrypting mail.

I will wait for their response at the bug and examine the regulation of
the law they referred to. But most likely it won't change anything in
the end. It's hard to serve two masters in this case...

Anders Rundgren

unread,
Dec 17, 2008, 6:03:00 AM12/17/08
to mozilla's crypto code discussion list, Eddy Nigg (StartCom Ltd.)
<snip>

Eddy Nigg wrote:
>> So, My advice is: just say no. Don't take on the burden of adding a
>> new root CA cert every year when there is no good need. Please consider
>> this an objection to including those roots in the root CA list.

>As indicated earlier, I think it unreasonable as well. And this is
>really unfortunate, since it could have done a lot of good for S/MIME,
>specially when considering the high usage/market share of Mozilla
>products in Germany and the chance to have some 40 million potential
>users encrypting mail.

Although Swedish authorities have done a lot of strange things in PKI,
I am happy that their broken scheme doesn't allow verification by
clients [*], since that could have caused major help-desk issues if people
believed that encrypted mail actually is a working application :-)

Anders

*] Root is secret and OCSP calls require a contract + requester certificate

Kyle Hamilton

unread,
Dec 17, 2008, 6:29:14 AM12/17/08
to mozilla's crypto code discussion list
I would request PDF. (Then again, I'd also request a signed PDF;
maybe Kathleen can get a PDF signing cert from StartCom? ;))

-Kyle H

> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>

Ian G

unread,
Dec 17, 2008, 6:40:14 AM12/17/08
to mozilla's crypto code discussion list
On 17/12/08 11:31, Eddy Nigg wrote:
> On 12/17/2008 08:54 AM, Nelson B Bolyard:
>>
>> One of the reasons I asked the question is that MS Word files present a
>> problem for me.
>>
>
> I use OpenOffice, and you?

Me too on both. MS Word or ODT files are a pain. I just want read the
stuff, not have to fire up NeoOffice and fight my way through the
million editing options.

> .... Perhaps she should publish them as PDF in the future.

Agreed! Wordprocessing formats in all their guises are for preparation
and editing, not for publication. The documents posted on the wiki are
published, there isn't a sense where I download the documents and then
patch them up a bit and send them back.

PDF seems to be a reasonably common form for publication. Perhaps add a
comment in the Checklist that PDF is preferred rather than word
processing formats (e.g., Word).

iang

Kyle Hamilton

unread,
Dec 17, 2008, 6:42:11 AM12/17/08
to mozilla's crypto code discussion list
I would very much like to see the implementing regulations that they
think causes them to need a new root rekey every year. A new CA
issued by a root, sure... but a new root? That's outlandish and a
substantial burden on the browser vendors.

I agree with the cross-certification aspect of Nelson's suggestion.

If it's to enable TLS client authentication (and not S/MIME), there's
absolutely no reason for the client to have this, since the client's
PKCS#12 file will include the issuing root anyway.

If it is for S/MIME, email-bit is appropriate on the client side, and
the root should be present.

But... expecting browser vendors to update their certificate lists
every year for a single organization would mean that the browser
vendors would have to expect to update the certificate list every year
for ALL organizations, and would also violate the archival principle
(that signatures of archived documents can be verified via the
presence of a timestamp from a reputable timestamping authority and a
trust anchor which still needs to be available).

Until the regulations are produced, I am STRONGLY AGAINST these roots'
inclusion. Even after the regulations are produced, I'm still very
likely going to be against it, though I am not stating absolutely "no"
at this time. (They may actually have a reason that I'll accept. I
doubt it, but I'll hold out hope... if for no other reason than to
point and laugh at the German government when they express a
completely unfounded fear.)

If I were able to commit Mozilla to any future action, what I'd do:
Refuse their request and inform them to tell their regulatory agency
to get in touch with Mozilla and other browser vendors to understand
why it's an unacceptable burden. Those regulatory agencies need to
get input on "best current practices", and help to figure out how to
rewrite the regulations so that they don't impose such a burden on the
browsers.

-Kyle H

On Tue, Dec 16, 2008 at 10:54 PM, Nelson B Bolyard <nel...@bolyard.me> wrote:
> Eddy Nigg wrote, On 2008-12-16 18:20:

>> On 12/17/2008 03:42 AM, Nelson B Bolyard:
>>> Do the new certs for S-TRUST have the same key, or do they have
>>> different keys? If they have different keys, do they also have different
>>> subject names?
>>> Do they have different Subject Key ID (SKID) extension values?
>>> Do the certs they issue have Authority Key ID (AKID) extensions?
>>
>> Nelson, see this attachment from Kathleen:
>> https://bugzilla.mozilla.org/attachment.cgi?id=337729 scroll to page two
>> and come to your own conclusions.
>

> One of the reasons I asked the question is that MS Word files present a
> problem for me.
>

> But I did dig up the URLs for the 4 CA certs, and examined those certs.
> Each of them has a separate subject name, public key, subject key ID,
> authority key ID, and of course validity period.
>

> To be honest, I think this is a burden that Mozilla ought not to bear.
> Mozilla should not put itself into a position of needing to add a new
> root CA cert for this CA every year, and then keep them for a long time
> thereafter.
>
> Further, if (as the bug suggests) the REAL PRIMARY purpose of this CA
> is to provide German citizens with SSL client certificates, and it is
> not used to issue SSL server certs, then it is (or should be) unnecessary
> for their browsers to have this CA cert AT ALL. For SSL client auth
> purposes, it's quite sufficient for the browser to just have the user's
> cert and private key and no CA cert at all. The server sends down a
> message saying "if you have a cert issued by this CA, send it". The
> browser examines the certs it possesses to find ones that have the
> desired string in the issuer name, and for which the browser has the
> private key. Having the CA cert is unnecessary.
>
> While some German law or regulation may require them to issue new roots
> annually, I doubt that it prevents them from also issuing intermediate
> CA certs with the same subject name, key, subject key ID, etc, but issued
> by some single common root that changes infrequently (these are so-called
> cross signed CA certs). With such a scheme, that root that issues the
> cross signed certs can be the one to get put into Mozilla with email trust.
>

> So, My advice is: just say no. Don't take on the burden of adding a
> new root CA cert every year when there is no good need. Please consider
> this an objection to including those roots in the root CA list.

Ian G

unread,
Dec 17, 2008, 6:45:02 AM12/17/08
to mozilla's crypto code discussion list
On 17/12/08 12:29, Kyle Hamilton wrote:
> ... (Then again, I'd also request a signed PDF;

> maybe Kathleen can get a PDF signing cert from StartCom? ;))


LOL... what happens when a CA puts up a signed document? Well, you
can't trust it because the CA isn't yet in the root list.

In general, it is good to eat ones own dogfood.

However this should not be mixed up with *the production* of the same.
Here, we are producing the dogfood, so we must not also consume it. If
we also consume it, we are entering into the mad cow production chain.

iang


PS: American expression to mean, use ones own product.

Ian G

unread,
Dec 17, 2008, 7:11:01 AM12/17/08
to mozilla's crypto code discussion list
On 17/12/08 02:42, Nelson B Bolyard wrote:
> Frank Hecker wrote:

>> * Per German law S-TRUST issues one new root CA certificate for every
>> year, with each root cert having a 5-year lifetime.
>

> Have they legislated that pi is 3 again?

Welcome to Europe, we hope you enjoyed your flight, and will travel on
pi airlines around the globe again :)


> Do the new certs for S-TRUST have the same key, or do they have
> different keys? If they have different keys, do they also have different
> subject names?
> Do they have different Subject Key ID (SKID) extension values?
> Do the certs they issue have Authority Key ID (AKID) extensions?


Certainly, these questions I would like answered too, and I wonder if we
can get them, and the answers onto the wiki?

> This whole thing makes little sense, and is a pretty big concern.


This is partly a cultural thing, and partly a case of "be careful what
you wished for."

In Germany, the politicians and bureaucrats bought into the PKI thing in
a big way, and proceeded to make it part of their business. Now, in
Germany, unlike in other places, they tend to do things only when there
is a law to back them up. In (say) America, they tend to do things when
there is no law saying you can't. It's a cultural thing.

The law was created in typical European style: EU directive => enacting
local law => regulator and regulations => "private market" controls,
that last step being somewhat familiar as audits, etc.

Now, as we know, a lot of the stuff that PKI people said was hopeful,
written down in advance of any large scale real world implementation.
There are many gaps. When the Germans (or anyone else) came along and
tried to regulate it, they had to fill in the gaps, because in their
view, there should be no gaps, there should a law plus regulation. The
obvious happened: they filled in some gaps, but their solution was
different to anyone else's.

Consider above, that the EU directive is 6 pages long. That means there
are substantial gaps in how to do things, and therefore there are
differences in the interpretations of the national perspectives.

One final gotcha to make it all the more delicious: in the EU directive
(and therefore in the national laws) it says that all qualified
implementations from other countries have to be accepted without
question in your local country. Which means that which is explicitly
banned in one country can be acquired from neighbouring country, and
must be accepted, even if banned in national law. Yes, this has cause
wonderful clashes.

Now, what do you do about it? Mozo is in a difficult position. As we
have discussed in this group before, Mozo's principle is to pass these
questions across to the standards committee. For sake of argument, this
would be the PKIX committee.

However, national law trumps standards committees.

I wish it were different. But, it isn't.

iang

Ian G

unread,
Dec 17, 2008, 7:20:50 AM12/17/08
to mozilla's crypto code discussion list
On 17/12/08 12:42, Kyle Hamilton wrote:
> I would very much like to see the implementing regulations that they
> think causes them to need a new root rekey every year.

Yes, worthwhile to ask for that, because it will prepare the ground for
the other German CAs.

> But... ....... and would also violate the archival principle


> (that signatures of archived documents can be verified via the
> presence of a timestamp from a reputable timestamping authority and a
> trust anchor which still needs to be available).


Yes, to recall an unpopular claim of mine: digital signing where it
attempts to mimic human signing should be deprecated in poorly
architectured applications like S/MIME. For reasons just like these.

(BTW, where is this "archival principle" documented?)

To make matters worse, even if you wanted to follow my unpopular advice
there, the European experiment is designed precisely for this market:
digital human signing by "qualified certificates".

Hence, if you enter this area, you should do things *their way*; the
signatures will be contested in European courts by European lawyers
under European laws. If Mozilla doesn't work within the framework, then
there could be problems...

And to recall another unpopular suggestion: Mozilla should clarify the
agreement it has with end-users, and with CAs, so as to set the
liabilities in advance, in preparation for these cases.


> Until the regulations are produced, I am STRONGLY AGAINST these roots'
> inclusion. Even after the regulations are produced, I'm still very
> likely going to be against it, though I am not stating absolutely "no"
> at this time. (They may actually have a reason that I'll accept. I
> doubt it, but I'll hold out hope... if for no other reason than to
> point and laugh at the German government when they express a
> completely unfounded fear.)


It is perhaps fun to laugh about the silly Germans ... but consider:
their digital signature project is very serious, it is strongly
supported by the tax authorities and they fully intend for tax
submissions to be signed. They have already passed or attempted to pass
the legislation to make this so.

Also, Germany is heartland for Mozilla. There are more supporters there
than other places, in general.


> If I were able to commit Mozilla to any future action, what I'd do:
> Refuse their request and inform them to tell their regulatory agency
> to get in touch with Mozilla and other browser vendors to understand
> why it's an unacceptable burden. Those regulatory agencies need to
> get input on "best current practices", and help to figure out how to
> rewrite the regulations so that they don't impose such a burden on the
> browsers.


Law trumps standards committees, best current practices, help from
browser vendors, etc.

Also, bear in mind that Mozilla has expressely and deliberately
outsourced this question to their standards committees. It is in the
mission statement. Mozilla has already declined a role at this table.

This is why I say "be careful what you wish for..."

iang

Eddy Nigg

unread,
Dec 17, 2008, 8:13:52 AM12/17/08
to
On 12/17/2008 01:45 PM, Ian G:

> On 17/12/08 12:29, Kyle Hamilton wrote:
>> ... (Then again, I'd also request a signed PDF;
>> maybe Kathleen can get a PDF signing cert from StartCom? ;))
>
>
> LOL... what happens when a CA puts up a signed document? Well, you can't
> trust it because the CA isn't yet in the root list.
>

Interestingly in my reader there was only one CA, that of Adobe. Maybe
they cross-sign others to make them trusted, not sure. But it's rather
easy to add other CA certificates under Document -> Manage Trusted
Identities -> Certificates.

Frank Hecker

unread,
Dec 17, 2008, 11:18:10 AM12/17/08
to
Nelson B Bolyard wrote:
> Further, if (as the bug suggests) the REAL PRIMARY purpose of this CA
> is to provide German citizens with SSL client certificates, and it is
> not used to issue SSL server certs, then it is (or should be) unnecessary
> for their browsers to have this CA cert AT ALL. For SSL client auth
> purposes, it's quite sufficient for the browser to just have the user's
> cert and private key and no CA cert at all.

Understood, but these certificates are also usable for email, even if
it's a secondary use, and hence having the root embedded is relevant for
Thunderbird, SeaMonkey, et.al. (And of course, just because email is a
secondary use now doesn't mean it will always be so.)

Nelson B Bolyard

unread,
Dec 17, 2008, 12:35:14 PM12/17/08
to mozilla's crypto code discussion list
Eddy Nigg wrote, On 2008-12-17 02:31:
> On 12/17/2008 08:54 AM, Nelson B Bolyard:

>> But I did dig up the URLs for the 4 CA certs, and examined those certs.


>> Each of them has a separate subject name, public key, subject key ID,
>> authority key ID, and of course validity period.
>
> As suspected and indicated in the document.

I didn't see anything about public keys or key IDs in the document.
Did I overlook something?

Nelson B Bolyard

unread,
Dec 18, 2008, 9:45:33 PM12/18/08
to mozilla's crypto code discussion list
According to my mail client, Ian G wrote on 2008-12-17 04:11 PST:

[paraphrasing liberally:
Europeans let their legislatures do their engineering.]

Lot of countries have created their own legislation or regulation for
security software, and then sat back and waited for others to implement
their designs ... and waited ... and waited ... and waited ...

This may well be just another case.

> Now, what do you do about it? Mozo is in a difficult position.

No, not a bit. The governments in most countries are accustomed to being
obeyed unquestioningly. They act astonished when NONE of the popular
browsers implement the requirements they try to impose. Tsk tsk.

Mozilla (indeed, all browsers) have successfully ignored lots of silly
regulations from individual countries. A good example of that is
regulation that requires the CAs in one country to put into their certs a
monetary limit on the financial value of the transactions done that use
those certs, a limit using the nation's own monetary units, and to require
any software that uses those certs to dishonor those certs until they are
prepared to enfore those limits. Mozilla software happily dishonors all
those certs. There are other examples as well.

> As we have discussed in this group before, Mozo's principle is to pass
> these questions across to the standards committee.
> For sake of argument, this would be the PKIX committee.

Wrong, but nice try.

> However, national law trumps standards committees.

LOL.

> I wish it were different. But, it isn't.

So, some country says "our citizens must use browsers that do this",
and no browsers do this, and eventually the country realizes that they
must relent or else have their citizens live in the dark ages. Eventually
they relent. That's what happened to the requirement about the monetary
limits in certs. The monetary limits are still there, but are now marked
as saying that the software that uses those certs is now free to honor those
certs even if it ignores those limits, and browsers all do so.

Ian G

unread,
Dec 19, 2008, 8:09:12 AM12/19/08
to mozilla's crypto code discussion list
On 19/12/08 03:45, Nelson B Bolyard wrote:
> According to my mail client, Ian G wrote on 2008-12-17 04:11 PST:
>
> [paraphrasing liberally:
> Europeans let their legislatures do their engineering.]


A fair comment, but it isn't as one sided as all that.


> Lot of countries have created their own legislation or regulation for
> security software, and then sat back and waited for others to implement
> their designs ... and waited ... and waited ... and waited ...


Governments indeed have discovered that they are just players in the
market when it comes to Internet. Sometimes weak, sometimes powerful.

> This may well be just another case.


It may well be, granted. The point I would make is that if QC is going
to succeed, then the place to watch is Germany. Just an opinion. They
are the ones who care the most *and* have the most weight.

(It is actually further along in some other places, like Estonia, but
they have no weight.)

But, I agree with you that it is still an "if" not a when.


>> Now, what do you do about it? Mozo is in a difficult position.
>
> No, not a bit. The governments in most countries are accustomed to being
> obeyed unquestioningly. They act astonished when NONE of the popular
> browsers implement the requirements they try to impose. Tsk tsk.


It isn't about being obeyed, so much as getting changes and bug fixes
done at the architectural level and above.

If you go to the CAs there, they will likely not appreciate your
perspective on the problem. Their perspective on the problem for them
comes from their regulations. They've spent the last N years building
up to get that done. They only come to the browsers as a last step.


> Mozilla (indeed, all browsers) have successfully ignored lots of silly
> regulations from individual countries. A good example of that is
> regulation that requires the CAs in one country to put into their certs a
> monetary limit on the financial value of the transactions done that use
> those certs, a limit using the nation's own monetary units, and to require
> any software that uses those certs to dishonor those certs until they are
> prepared to enfore those limits. Mozilla software happily dishonors all
> those certs. There are other examples as well.


Sure. Easy one. Were they marked as critical extentions?

>> As we have discussed in this group before, Mozo's principle is to pass
>> these questions across to the standards committee.
>> For sake of argument, this would be the PKIX committee.
>
> Wrong, but nice try.


If we agree to disagree that could be as far as it goes.

On the other hand, you could state what it is that you feel that is
wrong in the above description ... and we could explore and learn.

I'll go first: when we had a debate about revocation of the root, you
finalised that debate by accepting that there was a problem, and that
PKIX was the place for it to be fixed. It wasn't up to Mozo. Hence, I
mention it above.

In the mission of Mozilla, it states that we follow the standards
process. And, this includes security.

With respect, which part do you believe is wrong?


>> However, national law trumps standards committees.
>
> LOL.


You may laugh, but the CA in question is not enjoying the joke.


>> I wish it were different. But, it isn't.
>
> So, some country says "our citizens must use browsers that do this",
> and no browsers do this, and eventually the country realizes that they
> must relent or else have their citizens live in the dark ages.


Yes, that is what happens. In China, Skype has to ship a special
version with some secret MITM in it (speculation, I don't know what it
is). Likewise in ebay and yahoo, they both had to make global changes
because of the French. If you look at Paypal and SL there are similar
problems, caused by governments. Probably you recall the old days where
Netscape had to ship in two different versions because of the USA
government.

Please don't interpret my words personally, I play the other side to
explain things, not to start arguments. I also don't like the fact that
Skype has to breach the security of users. I also don't like qualified
certificates, and have written elsewhere much against them.

What to do about these things is a much more complex problem.


> Eventually
> they relent. That's what happened to the requirement about the monetary
> limits in certs. The monetary limits are still there, but are now marked
> as saying that the software that uses those certs is now free to honor those
> certs even if it ignores those limits, and browsers all do so.


Yes, that was an easy one, the design was borked from the start, like
that RFC that Anders posted.

Mozilla doesn't seem to have had to deal with the hard choices here, but
the CAs in question do.

Getting back to the only issue I can recall, from Frank's original mail:


> * Per German law S-TRUST issues one new root
> CA certificate for every year, with each root
> cert having a 5-year lifetime. Thus they are
> currently requesting inclusion of four root
> certificates, for 2005 through 2008. Starting
> in 2010 the older root certs will begin to
> expire and we can remove them.

If this is it, I would wonder whether it is worth fighting. What's the
problem for Mozo?


iang

Eddy Nigg

unread,
Jan 22, 2009, 1:35:56 PM1/22/09
to
On 12/17/2008 01:29 AM, Eddy Nigg:

> On 12/17/2008 01:26 AM, Frank Hecker:
>>
>> That's a good idea, I'll do that. I'd like to get a definitive answer on
>> this question, since I know I've seen this practice with other CAs,
>> including I think at least one not in Germany.
>>
>
> Frank, I asked about it at the bug already earlier. Once I get the
> information I'll be glad to provide information about it, including
> translation about the important parts (if this suits us).
>

I've received answers from the representative of S-Trust at the bug. As
suspect right from the beginning, there is no such law or requirement as
claimed initially that justifies the issuing of new roots every year for
a life-time of only five years. For further reference see bug 370627
from comment 47 onwards:
https://bugzilla.mozilla.org/show_bug.cgi?id=370627#c47

According to comments made by Nelson and others, I suggest to refrain
from including this CA at this time. Their model is hardly sustainable,
unnecessary complicated for no apparent benefit. Some of the documents I
reviewed from the "Bundesnetzagentur" even explicitly discourages their
implementation.

Kyle Hamilton

unread,
Jan 22, 2009, 2:53:29 PM1/22/09
to mozilla's crypto code discussion list
(sorry for the late response.)

On Wed, Dec 17, 2008 at 4:20 AM, Ian G <ia...@iang.org> wrote:
> On 17/12/08 12:42, Kyle Hamilton wrote:
>> But... ....... and would also violate the archival principle
>> (that signatures of archived documents can be verified via the
>> presence of a timestamp from a reputable timestamping authority and a
>> trust anchor which still needs to be available).
>
> Yes, to recall an unpopular claim of mine: digital signing where it
> attempts to mimic human signing should be deprecated in poorly architectured
> applications like S/MIME. For reasons just like these.
>
> (BTW, where is this "archival principle" documented?)

Aside from audits, it's also basically required by US Federal Court
Rules of Civil Procedure 26 and 34, as effective 12/2006. Any court
may require that any evidence submitted be authenticated. Without the
root available to authenticate...

Remember that it's not 'mimicing human signing'. It's preventing
modification of what was originally sent. (It's rather like the
process of committing logs -- if the logs need to be verifiable that
nothing has been retroactively added or removed or changed, they need
to have some means of chaining the IV from the prior log entry.)

> It is perhaps fun to laugh about the silly Germans ... but consider: their
> digital signature project is very serious, it is strongly supported by the
> tax authorities and they fully intend for tax submissions to be signed.
> They have already passed or attempted to pass the legislation to make this
> so.
>
> Also, Germany is heartland for Mozilla. There are more supporters there
> than other places, in general.

That's because in the US, Firefox is coming to be viewed as an evil
lesser than but akin to IE.

-Kyle H

Ian G

unread,
Jan 26, 2009, 7:23:40 AM1/26/09
to mozilla's crypto code discussion list
On 22/1/09 20:53, Kyle Hamilton wrote:
> (sorry for the late response.)
>
> On Wed, Dec 17, 2008 at 4:20 AM, Ian G<ia...@iang.org> wrote:
>> On 17/12/08 12:42, Kyle Hamilton wrote:
>>> But... ....... and would also violate the archival principle
>>> (that signatures of archived documents can be verified via the
>>> presence of a timestamp from a reputable timestamping authority and a
>>> trust anchor which still needs to be available).
>> Yes, to recall an unpopular claim of mine: digital signing where it
>> attempts to mimic human signing should be deprecated in poorly architectured
>> applications like S/MIME. For reasons just like these.
>>
>> (BTW, where is this "archival principle" documented?)
>
> Aside from audits,


Thanks for the answer!

As I read it, WebTrust 8,11 requires that documentation cover any
publication. I do not recall any archival *requirement*. There is
however section 2 of the Chokhani et al RFC layout for CPSs which is
basically "document your archives."

It is true that DRC B.2.h says "A list of subscriber certificates is
available to subscribers and the general public including..." however
this is somewhat troubling, from both business perspectives and privacy
perspectives, and I for one am not pushing this particular criteria.


> it's also basically required by US Federal Court
> Rules of Civil Procedure 26 and 34, as effective 12/2006. Any court
> may require that any evidence submitted be authenticated. Without the
> root available to authenticate...


Well, ok, so this is a general principle of "evidence in court". If one
intended to present evidence, then archiving it properly would be a
mighty fine idea.

However:

* I don't think I've come across any *general expression* of how to
present evidence in the CA world, listed for the benefit of subscribers
or relying parties. It doesn't seem as though one of the selling points
for certificates is that "you can present this as evidence in a court."

* A CA could respond that a certificate is not intended for that
purpose. I would see this as likely, but I guess we would have to ask
CAs what they thought.

* (CAs typically maintain a private repository, but that is for the
benefit of the CA, generally.)

* Not to mention in any depth the jurisdiction issues here.


iang

Eddy Nigg

unread,
Jan 27, 2009, 3:03:10 PM1/27/09
to
On 01/22/2009 08:35 PM, Eddy Nigg:

> I've received answers from the representative of S-Trust at the bug. As
> suspect right from the beginning, there is no such law or requirement as
> claimed initially that justifies the issuing of new roots every year for
> a life-time of only five years. For further reference see bug 370627
> from comment 47 onwards:
> https://bugzilla.mozilla.org/show_bug.cgi?id=370627#c47
>
> According to comments made by Nelson and others, I suggest to refrain
> from including this CA at this time. Their model is hardly sustainable,
> unnecessary complicated for no apparent benefit. Some of the documents I
> reviewed from the "Bundesnetzagentur" even explicitly discourages their
> implementation.
>

Update: One of the CA roots requested for inclusion is valid until 2030:

S-TRUST Authentication and Encryption Root CA 2005:PN
Valid until: 06/22/2030 02:59:59

The above mentioned issue does not apply to this root. Incidentally this
root was also included at Microsoft, the others not. There is no
objection to include the "Authentication and Encryption" root from
S-Trust as far as I can see.

Ben Bucksch

unread,
Jan 27, 2009, 3:33:24 PM1/27/09
to Frank Hecker
On 16.12.2008 18:43, Frank Hecker wrote:
> S-TRUST is operated by Deutscher Sparkassenverlag (DSV)

Just a little background on this:

Sparkasse is a "mutual savings bank".
They are fairly popular in Germany: Every region has its own (and their
geographical coverage usually does not overlap much), and combined they
have a decent market share (40% +/-10 % I'd guess).
They are non-profit.
They have a shared company which does some of the IT for them.

Given that banks have to authenticate their customers by identity card,
by money laundering laws, the verification is about as strong as it gets
in practice. (Some of them have Internet banks, though, which may
authenticate using the post office using a special scheme called
PostIdent - but even that requires the ID card and an in-person signature).

A weakness may be that the customer keys are stored on a chip on the
bank debit card (like credit card, just without credit), and the cards
may be sent by normal postal mail, normal letters, so there's a way to
intercept them. The PIN code (to use ATM machines, not sure if needed to
access the PKI keys) is sent as normal postal mail as well, but in a
separate letter on a different day, in a special envelope protecting
against shine through.

Of course, people wear these cards in their purse all the time, so that
may be stolen.

All of what I wrote is from memory, so there might be slight
incorrectness. I have only glanced over their CPS, not read it.
HTH anyways.

Ben

Ben Bucksch

unread,
Jan 27, 2009, 3:36:17 PM1/27/09
to Frank Hecker
On 16.12.2008 23:04, Frank Hecker wrote:
> However I suspect that S-TRUST is constrained in its practices by the
> relevant German laws and/or EU directives. Unfortunately I couldn't
> find any references that address this particular issue.

Even if so, such a law wouldn't preclude a root *specifically for us*
that just signs all the others. Given that only browsers trust that
root, the law wouldn't care about it.

Eddy Nigg

unread,
Jan 27, 2009, 3:46:44 PM1/27/09
to
On 01/27/2009 10:36 PM, Ben Bucksch:

First of all there is no such law as claimed in the CP/CPS of S/Trust.
Please see the bug entries and conclusive reporting here in relation to
that. Second, I've proposed to them to issue such a root and sign their
short-living CAs from that root. This would most likely allow them to
have this root included here and other vendors as well. Of course this
requires some changes at their side including CP/CPS and auditing, but
it should be entirely possible to achieve it within less than a year. In
the meantime I propose to have their long-living root included in NSS
(if no other concerns should be raised).

Ben Bucksch

unread,
Jan 27, 2009, 4:09:52 PM1/27/09
to mozilla's crypto code discussion list

(OT: Just culture)

On 17.12.2008 13:11, Ian G wrote:
>> Have they legislated that pi is 3 again?
> Welcome to Europe, we hope you enjoyed your flight, and will travel on
> pi airlines around the globe again :)

For the record, it was the US - Indiana specifically - which legislated
pi, see a quick "google legislating pi".


> In Germany, the politicians and bureaucrats bought into the PKI thing
> in a big way, and proceeded to make it part of their business.

True.

> Now, in Germany, unlike in other places, they tend to do things only
> when there is a law to back them up.

Also true, when it comes to bureaucracy, because said bureaucracy is
heavily determined by the most complex tax laws in the world, and other
regulations. In general, things are more regulated, and yes, that's
cultural - which has good and bad parts. For example, the windows
actually keep the warm in, because the house builder is *forced* to use
good isolation.

But, as the later posts said, there is *no such law* or regulation which
forced a new root each year. You see a lot of hot air about laws,
regulations and courts, both in US and Germany.

Ben Bucksch

unread,
Jan 27, 2009, 4:09:52 PM1/27/09
to mozilla's crypto code discussion list

(OT: Just culture)

On 17.12.2008 13:11, Ian G wrote:

>> Have they legislated that pi is 3 again?
> Welcome to Europe, we hope you enjoyed your flight, and will travel on
> pi airlines around the globe again :)

For the record, it was the US - Indiana specifically - which legislated

pi, see a quick "google legislating pi".

> In Germany, the politicians and bureaucrats bought into the PKI thing
> in a big way, and proceeded to make it part of their business.

True.

> Now, in Germany, unlike in other places, they tend to do things only
> when there is a law to back them up.

Also true, when it comes to bureaucracy, because said bureaucracy is

Frank Hecker

unread,
Feb 4, 2009, 10:20:18 AM2/4/09
to
Eddy Nigg wrote:
> Update: One of the CA roots requested for inclusion is valid until 2030:
>
> S-TRUST Authentication and Encryption Root CA 2005:PN
> Valid until: 06/22/2030 02:59:59
>
> The above mentioned issue does not apply to this root. Incidentally this
> root was also included at Microsoft, the others not. There is no
> objection to include the "Authentication and Encryption" root from
> S-Trust as far as I can see.

I agree on the inclusion of "S-TRUST Authentication and Encryption Root
CA 2005:PN", and so I'm going to go ahead and formally approve that.

On the inclusion of the other roots, there is nothing in our policy that
addresses the issue of short-lived roots. However the consensus seems
to be that this practice is not actually legally-required, and it does
pose a burden on us. I'm therefore OK with not including the other roots
for now, and encouraging S-TRUST to move to a scheme where they use a
longer-lived root for these certs.

Kathleen, could you post a summary to bug 370627, and then ping me for
final approval?

Reply all
Reply to author
Forward
0 new messages