On Mon, Jan 5, 2009 at 8:14 PM, Paul Hoffman 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 Information Acce
On Mon, Jan 5, 2009 at 1:16 PM, Nelson B Bolyard wrote:
> 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 designe
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
On 01/06/2009 04:51 AM, Julien R Pierre - Sun Microsystems:
It seems to me also that a self-signed certificate marked as a trust
anchor, ie. a root, probably shouldn't have an AIA extension. At least
it wouldn't make much sense for it to point to any OCSP responder, since
the root cannot revoke i
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 not
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.
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 convi
Kyle,
Kyle Hamilton wrote:
On Wed, Dec 24, 2008 at 2:46 PM, Eddy Nigg 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 one. by. one. by. one.
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 du
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
Ian G wrote, On 2009-01-05 06:09:
> The recent MD5 collision attack has also demonstrated a "brittle" side
> of OCSP [1]:
I wouldn't call it an attribute of OCSP any more than it is an attribute
of revocation in general. The same thing is true for CRLs that is true
for OCSP. The relying party l
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.
__
At 1:35 PM -0800 1/5/09, Wan-Teh Chang wrote:
>On Sun, Jan 4, 2009 at 12:32 PM, Paul Hoffman 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
* 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
On Sun, Jan 4, 2009 at 12:32 PM, Paul Hoffman 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 Mozilla trust ancho
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 i
Hi,
I'm sure such a flexible system would have its uses.
Glad to hear I am not the only one...
I have already entered it into bugzilla (forgot to put the link here),
please see https://bugzilla.mozilla.org/show_bug.cgi?id=472038
Should the discussion be moved there?
Coordinate with the NS
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
https://lists.moz
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 a
On 3/1/09 23:05, Gervase Markham wrote:
Eddy Nigg wrote:
For example?
Anything out of this list: https://www.startssl.com/?app=30#requirements
You want us to make a IV certificate which can be issued to businesses
without "verifiable physical existence and business presence"?
You mean that
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 bug
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 certi
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
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
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
a
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 scal
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 MUS
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
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
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
30 matches
Mail list logo
