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 oth
(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
On 01/27/2009 10:36 PM, Ben Bucksch:
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
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 *specifical
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)
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
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 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
(sorry for the late response.)
On Wed, Dec 17, 2008 at 4:20 AM, Ian G 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 tim
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
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 le
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
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 suspecte
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 cl
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 vi
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 tra
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
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'
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
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
On Wed, Dec 17, 2008 at 2:31 AM, 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
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
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
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) extensio
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 the
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 K
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
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
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 tran
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
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
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
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 ro
31 matches
Mail list logo
