Thank you for your diligence, Eddy!
-Kyle H
On Thu, Mar 26, 2009 at 11:26 AM, Eddy Nigg wrote:
> On 03/26/2009 03:53 PM, Eddy Nigg:
>>
>> During the last two weeks I tried to contact the relevant person at the
>> registry for the Israeli Signature Law. Unfortunately I wasn't able to reach
>> any
On 03/26/2009 03:53 PM, Eddy Nigg:
During the last two weeks I tried to contact the relevant person at
the registry for the Israeli Signature Law. Unfortunately I wasn't
able to reach anybody neither by email nor phone.
Luckily I was however able to have an interesting conversation with
Ere
On 03/11/2009 05:51 PM, michal...@gmail.com:
In Addition Comsign is being criticize by accountant that specialize
in Information Security.
And operate according the European Telecommunications Standards
Institute (ETSI).
Since I have the intention to deal with the Israel signature law
myself
Since Eddy's in Israel and thus most likely knows Hebrew (and if not,
he knows someone who can translate it well enough for him -- and he
has both a vested interest in ensuring he gets it right and a good
track record with his contributions to the Mozilla CA vetting
process), I propose holding acti
On 03/11/2009 05:51 PM, michal...@gmail.com:
Hi
Regarding you questions
Comsign operate under the Israeli Electronic Signature Law.
Here is link for all the regulation that derivative from the law.
Unfortunately this link is in Hebrew (I hope you can translate it)
http://www.justice.gov.il/MOJHeb
Hi
Regarding you questions
Comsign operate under the Israeli Electronic Signature Law.
Here is link for all the regulation that derivative from the law.
Unfortunately this link is in Hebrew (I hope you can translate it)
http://www.justice.gov.il/MOJHeb/RashamGormimMashrim/HokVetakanot
Comsign is
The summary of the action items resulting from this first public
discussion is as follows.
The criteria by which the CA was audited needs to be clarified.
ComSign is requested to provide information about the audit criteria
or the CA certificate practice requirements as published by the
Ministry o
On 03/04/2009 06:17 PM, michal...@gmail.com:
On Feb 28, 12:47 pm, Eddy Nigg wrote:
Having studied the Israeli Electronic Signature Law on previous
occasions, the law resembles in many aspects similar legislation's of
the EC. We've seen at different opportunities the lack of its usefulness
i
Original Message
Subject:Re: ComSign Root Inclusion Request
Date: Wed, 4 Mar 2009 08:17:18 -0800 (PST)
From: michal...@gmail.com
To: Eddy Nigg
I'm forwarding on behalf of Michal this email to the mailing list since
she apparently replied to me directl
On Feb 26, 5:49 pm, Kyle Hamilton wrote:
> 2009/2/26 Eddy Nigg :
>
> > On 02/26/2009 04:18 PM, stefan.claes...@gmail.com:
>
> >> The CRL that you have problems with are generated manually trough
> >> our offline CA. (RSA Certificate Manager) When generating manually you
> >> just copy
> >> the crl
On 02/24/2009 10:21 PM, Kathleen Wilson:
This begins the one-week discussion period. After that week, I will
provide a summary of issues noted and action items. If there are no
outstanding issues, then this request can be approved for inclusion.
If there are outstanding issues or action items, th
Nelson B Bolyard wrote re hexadecimal error codes in Firefox/PSM:
Can MoFo or MoCo PLEASE contribute some man-hours to fixing this?
This requires no crypto expertise. It's a trivial GUI issue.
NSS supplies all the error strings. There's no excuse left for FF
displaying error codes in unsigned h
On Thu, Feb 26, 2009 at 7:04 PM, Nelson B Bolyard wrote:
> PEM's only real value is that it allows data to be copied and pasted
> into and out of text documents. The base64 content is no more
> enlightening, and IMO is significantly less informative, than the
> binary DER. PEM encoding adds a MI
After quoting a passage from ITU document X.690, whose title is:
ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)
on 2009-02-26 01:40 PST, Kyle Hamilton wrote,
> I have not received a specific a
ugh. I have to rely on external utilities to form a pipeline into an
NSS utility that it'll actually use -- and then, not be able to use
the metadata discarded by grep -v to verify that what was decoded was
what was actually expected?
-Kyle H
2009/2/26 Nelson B Bolyard :
> Kyle Hamilton wrote, O
Kyle Hamilton wrote, On 2009-02-26 07:49:
> I am not sure how NSS's crlutil handles PEM,
It doesn't. It requires DER.
> or which tool would be used to de-PEM the target.
grep -v "X509 CRL" crl.pem | atob -o crl.der
Uses the "atob" utility which is one of NSS's utilities.
--
dev-tech-crypt
> There's a potential problematic practice here, which is "long time
> period between CRL issuance".
My understanding is that the update frequency of the CRLs is important
in regards to the end-entity certificates, not necessarily at the CA
level.
These URLs are the CRLs at the CA level, and thei
On 2/26/2009 1:48 AM, Kyle Hamilton wrote [in part]:
> There's a potential problematic practice here, which is "long time
> period between CRL issuance". I'm seeing issuance dates of October 6,
> 2008, with the next updates to be expected at April 4, 2009. I expect
> this is 180 days, though I d
2009/2/26 Eddy Nigg :
> On 02/26/2009 04:18 PM, stefan.claes...@gmail.com:
>>
>> The CRL that you have problems with are generated manually trough
>> our offline CA. (RSA Certificate Manager) When generating manually you
>> just copy
>> the crl into notepad and save it as crl.
>>
>
> It's very easy
On 02/26/2009 04:18 PM, stefan.claes...@gmail.com:
The CRL that you have problems with are generated manually trough
our offline CA. (RSA Certificate Manager) When generating manually you
just copy
the crl into notepad and save it as crl.
It's very easy to convert them to DER afterward. You ca
On Feb 26, 3:55 pm, Eddy Nigg wrote:
> On 02/26/2009 06:18 AM, Eddy Nigg:
>
>
>
>
>
> > On 02/26/2009 05:24 AM, David E. Ross:
>
> >> In the case of secure browsing at authenticated Web sites, I want to be
> >> conservative in what I accept. If a CA is generating certificates that
> >> do not comp
On 02/26/2009 06:18 AM, Eddy Nigg:
On 02/26/2009 05:24 AM, David E. Ross:
In the case of secure browsing at authenticated Web sites, I want to be
conservative in what I accept. If a CA is generating certificates that
do not comply with accepted RFCs, what else is that CA doing wrong? In
other w
On 25/2/09 23:28, Nelson B Bolyard wrote:
Kyle Hamilton wrote, On 2009-02-25 14:04:
Postel's first rule of interoperability: be liberal in what you
accept, be conservative in what you send.
Yeah. Lots of nasty Internet vulnerabilities have results from applying
that to crypto protocols and fo
Jean-Marc Desperrier wrote:
[...]
With FF 3.2a1pre latest nightly the result of dropping the URL
http://fedir.comsign.co.il/crl/ComSignSecuredCA.crl on a browser window
is :
"The application cannot import the Certificate Revocation List (CRL).
Error Importing CRL to local Database. Error Code:ff
Nelson B Bolyard wrote:
Kathleen Wilson wrote, On 2009-02-24 12:21:
* CRL issue: Current CRLs result in the e009 error code when
downloading into Firefox. ComSign has removed the critical flag from
the CRL, and the new CRLs will be generated in April.
Was that with FF 2? FF 3 should not
Kyle Hamilton wrote:
[...] this CA in question is not generating improper
certificates. It is generating proper CRLs, and it is simply encoding
and transmitting them as PEM-encoded DER-encoded CRL structures when
RFC5280 (which, by the way, I've been repeatedly told that NSS does
*NOT* comply w
2009/2/25 Eddy Nigg :
>
> Or in other words - and lets put it a bit more mildly - they certainly never
> tested their CRLs, at least not with the software this group cares about.
>
> But didn't Kyle say the CRLs are empty anyway (no revocations)? I couldn't
> find any records either. This doesn't
This is mostly off-topic, and relates primarily to one of my pet
peeves regarding everything cryptography-oriented on the Internet
today. I also know that this is not the correct venue to try to make
any reforms. However, since Mr. Ross has stated his view on the
topic, I feel that I must state m
On 02/26/2009 05:24 AM, David E. Ross:
In the case of secure browsing at authenticated Web sites, I want to be
conservative in what I accept. If a CA is generating certificates that
do not comply with accepted RFCs, what else is that CA doing wrong? In
other words, if a CA sends CRLs that are
On 2/25/2009 2:04 PM, Kyle Hamilton wrote:
> Postel's first rule of interoperability: be liberal in what you
> accept, be conservative in what you send.
>
> Which RFC requires which? (I had read somewhere, for example, that
> wildcard certificates must be handled by HTTP over TLS servers in a
> p
Theoretically, x- types are only to be used until an official MIME
type assignment has been made.
Realistically, older clients don't have any idea what the new MIME
type assignment will be.
What do you get in the Accept: header for the requests for your CRLs?
(I'm actually curious, since I've nev
On 02/26/2009 12:28 AM, Nelson B Bolyard:
[RFC2585]. HTTP server implementations accessed via the URI SHOULD
specify the media type application/pkix-crl in the content-type
header field of the response.
Would the header application/x-pkcs7-crl be potentially wrong? It's what
we've
Kyle Hamilton wrote, On 2009-02-25 14:04:
> Postel's first rule of interoperability: be liberal in what you
> accept, be conservative in what you send.
Yeah. Lots of nasty Internet vulnerabilities have results from applying
that to crypto protocols and formats. I know, I've had to fix 'em!
> Wh
Kyle Hamilton wrote, On 2009-02-25 13:51:
> It is, indeed, showing me the e009 error code (with hexadecimal
> numbers) when I go to those CRL distribution points in FF 3.0.6. (At
> least the text is selectable and copiable:)
>
> The application cannot import the Certificate Revocation List (C
Postel's first rule of interoperability: be liberal in what you
accept, be conservative in what you send.
Which RFC requires which? (I had read somewhere, for example, that
wildcard certificates must be handled by HTTP over TLS servers in a
particular way -- it turns out that it wasn't part of PK
Kyle Hamilton wrote, On 2009-02-25 13:56:
> This is going to sound rather stupid of me, but I'm going to ask this anyway:
> Why is Firefox insisting on a specific encoding of the data, rather
> than being flexible to alternate, unconfusable, common encodings?
The RFCs require conforming CAs to se
kathleen95...@yahoo.com wrote, On 2009-02-25 10:39:
> In regards to the CRLS
> http://fedir.comsign.co.il/crl/ComSignCA.crl
> http://fedir.comsign.co.il/crl/ComSignSecuredCA.crl
>
> I have just tried the two CRL’s again, and see that the error is
> indeed e009 which corresponds to error code
This is going to sound rather stupid of me, but I'm going to ask this anyway:
is there any possible potential DER-encoded message which will begin
with the string "-BEGIN X509 CRL-"? If there isn't, might I
possibly suggest that requiring DER in this location and manner will
do absolutely
It is, indeed, showing me the e009 error code (with hexadecimal
numbers) when I go to those CRL distribution points in FF 3.0.6. (At
least the text is selectable and copiable:)
The application cannot import the Certificate Revocation List (CRL).
Error Importing CRL to local Database. Error Co
Kathleen Wilson wrote, On 2009-02-24 12:21:
> * CRL issue: Current CRLs result in the e009 error code when
> downloading into Firefox. ComSign has removed the critical flag from
> the CRL, and the new CRLs will be generated in April.
Was that with FF 2? FF 3 should not be showing hexadecima
I apologize for the confusion. I was mentally mistaking the error code
e009 for fffe095.
In regards to the CRLS
http://fedir.comsign.co.il/crl/ComSignCA.crl
http://fedir.comsign.co.il/crl/ComSignSecuredCA.crl
I have just tried the two CRL’s again, and see that the error is
indeed e009 whi
stefan.claes...@gmail.com wrote:
Is CIDP required to use in a crl?
No. In fact, the issue with Hongkong Post was that its CDP CRL had the
CIDP extension marked as critical, and that was why Firefox had an error
when loading it.
The NSS cryptographic library used by Firefox, Thunderbird, and
There are no certificates revoked in either the ComsignCA.crl or
ComsignSecuredCA.crl. I do not know if this would be the cause of the
e009 error.
-Kyle H
On Wed, Feb 25, 2009 at 2:56 AM, wrote:
> On Feb 24, 10:42 pm, Frank Hecker
> wrote:
>> Kathleen Wilson wrote:
>> > As per the CA Sche
On Feb 24, 10:42 pm, Frank Hecker
wrote:
> Kathleen Wilson wrote:
> > As per the CA Schedule athttps://wiki.mozilla.org/CA:ScheduleComSign
> > is the next request in the queue for public discussion.
>
> Thanks for preparing this for public discussion!
>
> > * CRL issue: Current CRLs result in the
Kathleen Wilson wrote:
As per the CA Schedule at https://wiki.mozilla.org/CA:Schedule ComSign
is the next request in the queue for public discussion.
Thanks for preparing this for public discussion!
* CRL issue: Current CRLs result in the e009 error code when
downloading into Firefox. Com
As per the CA Schedule at https://wiki.mozilla.org/CA:Schedule ComSign
is the next request in the queue for public discussion.
ComSign (a private company owned by Comda, Ltd. in Israel) has applied
to add two new root CA certificates to the Mozilla root store, as
documented in the following bug:
46 matches
Mail list logo
