David Stutzman wrote, On 2009-02-23 08:00:
> Using NSS 3.12.2 RTM or NSS 3.11.4 RTM, I get:
> org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed:
> (-12286) Cannot communicate securely with peer: no common encryption
> algorithm(s).
> Stepping back and eliminating JSS, I get simi
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
On 02/25/2009 08:31 PM, Gervase Markham:
On 23/02/09 23:54, Eddy Nigg wrote:
How to prove? Does Mozilla buy domain names (or purchase certificates)
from time to time in order to govern its policies?
We rely on good citizens like you to let us know when there's a problem
:-) We don't regularly
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
Brown, Chris wrote, On 2009-02-24 06:22:
> I am trying to make a certificate request using a multi valued attribute
> relative distinguished name using the certutil tool. However I keep
> getting an error message saying that the DN is invalid. Is this not
> supported in certutil? Here’s the comm
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
On 23/02/09 23:54, Eddy Nigg wrote:
How to prove? Does Mozilla buy domain names (or purchase certificates)
from time to time in order to govern its policies?
We rely on good citizens like you to let us know when there's a problem
:-) We don't regularly attempt to break the security of CA cert
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
20 matches
Mail list logo
