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
2009/2/25 Eddy Nigg eddy_n...@startcom.org:
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
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
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
Eddy Nigg wrote:
On 02/25/2009 08:31 PM, Gervase Markham:
On 23/02/09 23:54, Eddy Nigg wrote:
[...]
Only CAs are relevant if at all. You don't expect that 200 domain names
were registered by going through anti-spoofing checking and measures, do
you?!
[...]
Outsh, sorry! That should have
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
Paul Hoffman wrote:
At 7:09 AM +0100 2/24/09, Kaspar Brand wrote:
Kyle Hamilton wrote:
Removal of support for wildcards can't be done without PKIX action, if
one wants to claim conformance to RFC 3280/5280.
Huh? Both these RFCs completely step out of the way when it comes to
wildcard
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
On Feb 26, 3:55 pm, Eddy Nigg eddy_n...@startcom.org 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
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
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
On 26/02/09 11:05, Jean-Marc Desperrier wrote:
Eddy Nigg wrote:
On 02/25/2009 08:31 PM, Gervase Markham:
On 23/02/09 23:54, Eddy Nigg wrote:
[...]
Only CAs are relevant if at all. You don't expect that 200 domain names
were registered by going through anti-spoofing checking and
measures, do
2009/2/26 Eddy Nigg eddy_n...@startcom.org:
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
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 don't
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 their
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-crypto
At 12:49 PM +0100 2/26/09, Jean-Marc Desperrier wrote:
Just one thing : The use of a wildcard certificate was a misleading red
herring in the implementation of the attack.
What's truly broken is that the current i18n attack protection relies on the
checking done by the registrar/IDN, and that
On Wed, Jan 21, 2009 at 6:50 AM, Johnathan Nightingale
john...@mozilla.com wrote:
Hi folks,
I just posted a blog entry here about a side project I've had running for a
little while:
http://blog.johnath.com/2009/01/21/ssl-information-wants-to-be-free/
The very short version is that I
Here are the MD5 certificate numbers we measured using Google Chrome's
usage statistics collection service:
http://dev.chromium.org/developers/md5-certificate-statistics
I don't see any way to edit that page, so I'll have to correct it here. The
first sentence is deceptively wrong, as we have
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
20 matches
Mail list logo
