Nelson Bolyard wrote:
I think mozilla will turn OCSP back on by default in some forthcoming
release. Maybe soon, who knows?
There has been discussions else where on this issue, basically at
present it would be very difficult to stop any maliciously signed code
from propagating unless things
Julien Pierre wrote:
You can however implement what you want without NSS changes, by wrapping
the NSS certificate verification function.
By effectively reimplementing a certificate chain build algorithm.
Your algorithm is simple, because it handles only simple cases, but full
implementation of
Jean-Marc,
Jean-Marc Desperrier wrote:
Julien Pierre wrote:
You can however implement what you want without NSS changes, by
wrapping the NSS certificate verification function.
By effectively reimplementing a certificate chain build algorithm.
Extending it is more like it, since you reuse
Jean-Marc,
Jean-Marc Desperrier wrote:
Julien Pierre wrote:
First, let me point out that the RFC only recommends an algorithm to
verify certificates and signatures on the current date, but not at
dates in the past.
I don't want to strech the whole discussion any longer, but if you are
Julien Pierre wrote:
First, let me point out that the RFC only recommends an algorithm to
verify certificates and signatures on the current date, but not at dates
in the past.
I don't want to strech the whole discussion any longer, but if you are
actually interested in that sort of things, then
John Gardiner Myers wrote:
For reasons you mention, even checking against the latest currently
available CRL is at most best effort.
I fully concur this is only best effort.
This is BTW exactly what I wrote in my message.
But it's the level of best effort that *can* be achieved.
I don't get why
Jean-Marc Desperrier wrote:
Currently the defined maximum for NSS is *infinite*.
If there's any crl available for checking, however old, the check will
*never* return crl outdated. This is not configurable.
This in my opinion makes the CRL checking in NSS ineffective.
When the NSS chech says
Julien Pierre wrote:
Second, a certificate may be retroactively revoked, such as in the
case where a private key was compromised, but the fact wasn't noticed
until a week later.
There are also potential delays between the time it is noticed and the
time it is reported to the CA, and between
Nelson B wrote:
Jean-Marc, There's a verb missing from this next sentence you wrote,
and understanding that sentence depends entirely on the missing verb.
Please fill in the missing verb, here |
v
As a general rule, it's a bad idea to something that was
Jean-Marc,
Jean-Marc Desperrier wrote:
So if you do CRL checking at all, there are good reasons to report this
check as failed if you only have access to a CRL whose nextUpdate is in
the past. Except of course if you have an date argument in the check
that says Check validity for *this* date
Deacon, Alex wrote:
VeriSign has spent a lot of time and effort recently ensuring that not only
do our OCSP services work, but that they will continue to work as the load
increases. Clearly there is no excuse for any CA, especially VeriSign, to
have a faulty OCSP implementation...especially if
If an OCSP response has both a thisUpdate and a nextUpdate value then yes,
it is a good idea.
Alex
-Original Message-
From: Rahul Aggarwal [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 11, 2004 10:00 PM
To: [EMAIL PROTECTED]
Subject: RE: On turning CRL and OCSP checking
Deacon, Alex wrote:
If an OCSP response has both a thisUpdate and a nextUpdate value then yes,
it is a good idea.
The new, enhanced, internally based on CRL, Verisign OCSP responder uses
that ?
The old one had no nextUpdate, and a thisUpdate generated for each
request, so locally caching it
Hi,
-Original Message-
From: Jean-Marc Desperrier [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 12, 2004 9:16 AM
To: [EMAIL PROTECTED]
Subject: Re: On turning CRL and OCSP checking on by default.
Deacon, Alex wrote:
If an OCSP response has both a thisUpdate and a
Jean-Marc Desperrier wrote:
Julien Pierre wrote:
Technically, the revocation information from CRLs does not expire.
nextUpdate only means the CA should have more recent information
available, not that the CRL is expired. So I don't see it as wrong to
still do the OCSP check.
There is no
Julien Pierre wrote:
[...] A lot of OCSP servers have been incorrectly
(and that includes Verisign's). [...]
A significatn problem with Verisign is that some time ago, they were
including the OCSP extension for some people who had not paid for OCSP,
so the responder would refuse to tell the
As I mentioned in a pervious email...this has been fixed.
Alex
-Original Message-
From: Jean-Marc Desperrier [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 11, 2004 10:24 AM
To: [EMAIL PROTECTED]
Subject: Re: On turning CRL and OCSP checking on by default.
Julien Pierre
Hi Julien,
-Original Message-
From: Julien Pierre [mailto:[EMAIL PROTECTED]
Sent: Monday, February 09, 2004 6:02 PM
To: [EMAIL PROTECTED]
Subject: Re: On turning CRL and OCSP checking on by default.
Alex,
Deacon, Alex wrote:
1) Although the option to perform cert
Hi Duane,
Agreed. If a CA indicates via an AIA that OCSP services are available then
it better ensure things are working correctly.
Alex
-Original Message-
From: Duane [mailto:[EMAIL PROTECTED]
Sent: Monday, February 09, 2004 7:41 PM
To: [EMAIL PROTECTED]
Subject: Re: On
Hi,
Deacon, Alex wrote:
VeriSign has spent a lot of time and effort recently ensuring that not only
do our OCSP services work, but that they will continue to work as the load
increases. Clearly there is no excuse for any CA, especially VeriSign, to
have a faulty OCSP implementation...especially
Turning on OCSP by default is bug 110161.
The lack of an OCSP cache is one issue. A harder issue is that NSPR's
nonblocking model is not capable of passing the information needed to do
nonblocking OCSP queries during an SSL handshake.
When I last tried turning OCSP on, Verisign had screwed up
OCSP is turned off by default in mozilla, because frankly, a lot of
home-grown CAs put out certs that claimed they did OCSP, when they
didn't. So, mozilla would get one of their certs (e.g. from an https
server), try to contact the OCSP server (and fail), and then claim the
cert is revoked (the
Duane wrote:
OCSP is turned off by default in mozilla, because frankly, a lot of
home-grown CAs put out certs that claimed they did OCSP, when they
didn't. So, mozilla would get one of their certs (e.g. from an https
server), try to contact the OCSP server (and fail), and then claim the
cert is
Hi Nelson,
Here are my thoughts on how this should work.
1) Although the option to perform cert validation (either via OCSP or CRL)
should be a user configurable option, I believe that the application should
ship with this option turned ON by default.
2) The decision as to what mechanism the
Alex,
Deacon, Alex wrote:
1) Although the option to perform cert validation (either via OCSP or CRL)
should be a user configurable option, I believe that the application should
ship with this option turned ON by default.
It would be nice, but I wonder how many users would complain about all
It would be nice, but I wonder how many users would complain about all
the sites not working ... A lot of OCSP servers have been incorrectly
(and that includes Verisign's). I think the option should be off by
default for clients, certainly for CRLs, which get very large and are
not suitable
26 matches
Mail list logo
