Hi,
is it normal that, during the SSL handshake,
the disabled removable token is asked for the authentication
certificate/key, please?
We are developing a xulrunner extension that acts as the client of
'SmartCard Manager' .
In some modes this application uses two tokens: operator's and the
On 01/05/2009 06:44 PM, Paul Hoffman:
At 6:08 PM +0200 1/5/09, Eddy Nigg wrote:
Therefor we can't lump just all failures together and as you correctly stated,
there is no clear line between one and the other. This is what I was saying.
What you said was As I see it, our case indeed was a
At 6:08 PM +0200 1/5/09, Eddy Nigg wrote:
Therefor we can't lump just all failures together and as you correctly stated,
there is no clear line between one and the other. This is what I was saying.
What you said was As I see it, our case indeed was a bug, the Comodo case was
negligence. That
Florian Weimer wrote:
Section 18 does not require that the domain holder is aware of the
application.
Section 18 requires that the domain holder _be_ the applicant.
To verify Applicant's registration, or exclusive control, of the domain
name(s) to be listed in the EV certificate, the CA MUST
On 01/05/2009 04:56 PM, Gervase Markham:
I am not saying the two incidents were the same - I think every incident
has to be assessed individually. I am just saying that you cannot make
such a division so quickly and easily.
Not quickly and easily - agree on that. And every incident needs to
At 3:09 PM +0100 1/5/09, Ian G wrote:
The recent MD5 collision attack has also demonstrated a brittle side of OCSP
[1]:
http://blogs.technet.com/swi/archive/2008/12/30/information-regarding-md5-collisions-problem.aspx
It seems that, assuming we can create an intermediate or subroot certificate,
Is there anybody to answer to my/Kaspar Band's statement below, as to get a
final clarification ?:
1. Is there a dev-tech-crypto / Firefox developer/programmer who wants to
confirm Kaspar Band's idea that running Firefox in Safe
Mode when generating the key as well as requesting the Certificate
The recent MD5 collision attack has also demonstrated a brittle side
of OCSP [1]:
http://blogs.technet.com/swi/archive/2008/12/30/information-regarding-md5-collisions-problem.aspx
It seems that, assuming we can create an intermediate or subroot
certificate, then we can also redirect the OCSP
Jan Schejbal wrote:
I suggest an universal mechanism (integrated or as an extension) than
can be fed rules about certificates, CAs and sites and showing warnings
or interrupting connections where necessary.
I'm sure such a flexible system would have its uses. Coordinate with the
NSS and PSM
On 05.01.2009 01:35, Nelson B Bolyard wrote:
There's no mozilla.policy hierarchy.
It can be created.
There's already a mozilla.governance, which would fit there, too.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
On 05.01.2009 01:00, Eddy Nigg wrote:
A dev.security...yes, the forgotten step child of crypto. At times
we used to post there (and cross post to crypto) and don't know why
crypto became the de-facto list for all CA/SSL/Policy related issues.
Because crypto (including CA) is just a small
Eddy Nigg wrote:
As I see it, our case indeed was a bug, the Comodo case was negligence.
There is no clear line between one and the other. You are saying the
Comodo case was negligence because the bug was so obvious that they
should have spotted it. But the obviousness of bugs is a gradated
Ian G wrote, On 2009-01-05 11:28:
We know as a more or less accepted fact that the design of secure
browsing was for Credit Cards,
I believe that you've accepted that as fact. But PR and marketing is not
design. It was designed for MUCH more than mere credit cards.
and the benefit there is
On Sun, Jan 4, 2009 at 12:32 PM, Paul Hoffman phoff...@proper.com wrote:
I propose that Mozilla form a new mailing list, dev-policy-trustanchors. The
topics for that list would include:
- All new trust anchors being added to the Mozilla trust anchor pile
- Proposals for changes to the
* Gervase Markham:
Florian Weimer wrote:
Section 18 does not require that the domain holder is aware of the
application.
Section 18 requires that the domain holder _be_ the applicant.
Some CAs disagree with this interpretation. Here's an example:
Domain: seb-bank.de
Domain-Ace:
At 1:35 PM -0800 1/5/09, Wan-Teh Chang wrote:
On Sun, Jan 4, 2009 at 12:32 PM, Paul Hoffman phoff...@proper.com wrote:
I propose that Mozilla form a new mailing list, dev-policy-trustanchors. The
topics for that list would include:
- All new trust anchors being added to the Mozilla trust
Paul Hoffman wrote:
You are missing the parts where there are actual technical questions
or assertions in the middle of threads that started as trust anchor
rants.
Requesting actual details in the middle of a long ranty thread is a good
way to get missed no matter what newsgroup or topic.
Paul Hoffman wrote, On 2009-01-05 08:54:
At 3:09 PM +0100 1/5/09, Ian G wrote:
[...] Hence, once we rogue-players have created a certificate like this,
the CA cannot revoke it using its own control mechanisms. [...]
I am not convinced the article is correct. If it is correct, it is a
Viktor TARASOV wrote, On 2009-01-05 08:53:
is it normal that, during the SSL handshake, the disabled removable
token is asked for the authentication certificate/key, please?
The feature that allows slots to be disabled is intended to be a
configuration feature, not intended for dynamic use
Kyle,
Kyle Hamilton wrote:
On Wed, Dec 24, 2008 at 2:46 PM, Eddy Nigg eddy_n...@startcom.org wrote:
On 12/25/2008 12:36 AM, Kyle Hamilton:
To be honest, Mozilla doesn't distribute keytool with Firefox, which
means that I have to try to go into the (unbatchable) interface and
remove the flags
At 4:01 PM -0800 1/5/09, Nelson B Bolyard wrote:
Paul Hoffman wrote, On 2009-01-05 08:54:
At 3:09 PM +0100 1/5/09, Ian G wrote:
[...] Hence, once we rogue-players have created a certificate like this,
the CA cannot revoke it using its own control mechanisms. [...]
I am not convinced the
Kyle,
Kyle Hamilton wrote:
I am minded of the CRL entry reason remove from CRL. Does NSS
properly handle that reason-code?
The reason code remove from CRL is only applicable to delta CRLs. In
addition, this is only allowed if the certificate had the status of on
hold in the base CRL. You
Paul,
Paul Hoffman wrote:
3) A corollary of (2): Even when parent == grandparent, and hence parent
is also a sibling, it's not generally true that you can use the OCSP URL
from the parent to check the OCSP status of a child.
All of that is true (and is true for CRLs, I believe), but it is
At 6:51 PM -0800 1/5/09, Julien R Pierre - Sun Microsystems wrote:
Paul,
Paul Hoffman wrote:
3) A corollary of (2): Even when parent == grandparent, and hence parent
is also a sibling, it's not generally true that you can use the OCSP URL
from the parent to check the OCSP status of a child.
All
On Mon, Jan 5, 2009 at 8:14 PM, Paul Hoffman phoff...@proper.com wrote:
As far as I know, the AIA only applies to the end entity certificate, and not
to any children certificates. Do you have any evidence in any standard that
this is not the case ?
From RFC3280 :
4.2.2.1 Authority
25 matches
Mail list logo
