On 10/24/2008 05:34 PM, Frank Hecker:
Eddy Nigg wrote:
I'd like to pick this discussion up once again and evaluate what the
goals of Mozilla and the Mozilla CA policy really are. Certainly the
above is not the defined goal, but rather provide some reasonable
assurance about the CAs included in N
Eddy Nigg wrote:
I'd like to pick this discussion up once again and evaluate what the
goals of Mozilla and the Mozilla CA policy really are. Certainly the
above is not the defined goal, but rather provide some reasonable
assurance about the CAs included in NSS and Mozilla products and allow
us
Frank Hecker wrote:
> Ian G wrote:
>> The goals of Mozo are written somewhere else, and they only speak
>> softly to the issue of security from memory. I think it is worth
>> revisiting them, perhaps someone has them to hand?
>
> Are you referring to the high-level goals of the Mozilla Foundation
Frank Hecker wrote:
> [I'm trying to catch up on these threads, my apologies for the delay. I
> don't have time to respond to every message, unfortunately.]
(I understand, I also feel the pressure.)
> Ian G wrote:
>> If that was true, there would likely be an agreement between Mozilla
>> and Ver
Ian G wrote:
The goals of Mozo are written somewhere else, and they only speak
softly to the issue of security from memory. I think it is worth
revisiting them, perhaps someone has them to hand?
Are you referring to the high-level goals of the Mozilla Foundation (not
necessarily security-rela
[I'm trying to catch up on these threads, my apologies for the delay. I
don't have time to respond to every message, unfortunately.]
Ian G wrote:
If that was true, there would likely be an agreement between Mozilla
and Verisign (following the above RPA tradition) explicitly giving
Mozilla permi
Ian G:
One good way to achieve certainty is for Mozilla to require the
documents to be declared in the process.
That might be a good idea...actually that's what I assume when a CA
makes a request for inclusion (but on the other hand, no CA has yet
confirmed or signed an agreement in this resp
Eddy Nigg wrote:
> On 10/10/2008 01:45 PM, Ian G:
>> Finally, if it ever did get to court, I don't see any good reasons
>> why it would not stand up?
>
>
> Well, I prefer to refrain from commenting on this, but the fact that I
> mentioned it could give you some hint ;-)
Sounds a bit like the RI
On 10/10/2008 01:45 PM, Ian G:
Finally, if it ever did get to court, I don't see any good reasons
why it would not stand up?
Well, I prefer to refrain from commenting on this, but the fact that I
mentioned it could give you some hint ;-)
( I should clarify things here: there is certainly
Eddy Nigg wrote:
> On 10/10/2008 01:48 AM, Ian G:
>
>> IN CONSIDERATION OF YOUR AGREEMENT TO THESE TERMS, YOU ARE ENTITLED
>> TO USE VERISIGN INFORMATION AS SET FORTH HEREIN.
>>
>> https://www.verisign.com/repository/rpa.html
>>
>> Now, curiously, unless we agree to that text, we can't even rely on
On 10/10/2008 01:48 AM, Ian G:
>
> Wl whatever it is, you'd like it; read on.
>
Actually I did :-)
>
> IN CONSIDERATION OF YOUR AGREEMENT TO THESE TERMS, YOU ARE ENTITLED
> TO USE VERISIGN INFORMATION AS SET FORTH HEREIN.
>
> https://www.verisign.com/repository/rpa.html
>
> Now, curi
Eddy Nigg wrote:
> On 10/09/2008 05:33 PM, Ian G:
>> The goals of Mozo are written somewhere else, and they only speak
>> softly to the issue of security from memory
>
> I obviously meant the goals of the Mozilla CA Policy and NSS, which
> isn't used only by Mozilla (Firefox) but lots of differen
On 10/09/2008 05:33 PM, Ian G:
>
> The goals of Mozo are written somewhere else, and they only speak
> softly to the issue of security from memory
I obviously meant the goals of the Mozilla CA Policy and NSS, which
isn't used only by Mozilla (Firefox) but lots of different software. NSS
is a cry
Eddy Nigg wrote:
> On 10/02/2008 10:23 PM, Frank Hecker:
> >
> > Our goal here is to avoid having to evaluate lots and lots of
> > subordinate CAs, and instead have the roots take care of their own
> > subordinates and ensure they're compliant to policy.
> >
>
> I'd like to pick this discussi
On 10/02/2008 10:23 PM, Frank Hecker:
>
> Our goal here is to avoid having to evaluate lots and lots of
> subordinate CAs, and instead have the roots take care of their own
> subordinates and ensure they're compliant to policy.
>
I'd like to pick this discussion up once again and evaluate wha
On 10/03/2008 05:37 PM, Iang:
>
> I am not entirely convinced that it is as easy as that. The audit is a
> far more nuanced thing than "auditor checks, it's ok." If you think
> that, then, I've got a subprime to sell you.
>
The WebTrust audit is pretty clear in this respect, not sure what you
mea
On 10/03/2008 06:58 PM, Paul Hoffman:
> At 3:02 PM +0300 10/3/08, Eddy Nigg wrote:
>> Here I wanted to add something...it's not that we should prevent
>> intermediate third-party CAs or cross-signing, but we need to apply the
>> same requirements on all CAs.
>
> But we don't. All the legacy CAs hav
At 3:02 PM +0300 10/3/08, Eddy Nigg wrote:
>Here I wanted to add something...it's not that we should prevent
>intermediate third-party CAs or cross-signing, but we need to apply the
>same requirements on all CAs.
But we don't. All the legacy CAs have different requirements put on them. To
me, thi
Hi All,
being the devil's advocate here, personal opinions if any...
Eddy Nigg wrote:
> On 10/03/2008 04:29 AM, Frank Hecker:
>> Well, it does matter how difficult it is to implement a policy, and I
>> think we have to exercise some judgment here. At one end of the spectrum
>> we have situation
On 10/03/2008 05:43 AM, Eddy Nigg:
> On 10/03/2008 04:29 AM, Frank Hecker:
>> Even beyond the
>> WISeKey model (the "CA in a box" appliance device), I suspect that a
>> number of other CAs serving the enterprise market have enough
>> subordinates that it would be unrealistic to require actual audit
On 10/03/2008 04:29 AM, Frank Hecker:
>
I turned your reply somewhat upside-down, because I want to comment
first in general terms...
>
> Well, it does matter how difficult it is to implement a policy, and I
> think we have to exercise some judgment here. At one end of the spectrum
> we have sit
Eddy Nigg wrote:
> The principal guiding us should be the audit requirements mentioned
> above and there shall be no CA included which hasn't undergone such an
> audit, being it as part of a root or in its own rights. A root shall not
> be included in case sub-ordinate CAs exist which haven't se
On 10/03/2008 03:38 AM, Frank Hecker:
> Remember that a lot of CAs working with enterprises outsource the
> Registration Authority function to those enterprises. In other words,
> the enterprise is ultimately responsible for doing verification of
> subscribers (e.g. when issuing certificates to emp
On 10/03/2008 03:04 AM, Justin Dolske:
> Out of curiousity... How many (if any) such CAs are currently included
> in NSS? It seems a little scary to be providing a way for these 3rd
> party CAs to become operational in Mozilla products without going
> through the Mozilla approval process. It seems
On 10/02/2008 10:23 PM, Frank Hecker:
>
> Kathleen thinks, and I agree, that the best way to approach this both
> with T-Systems and with other CAs in general is to ask the CA to update
> the CP/CPS for the root to include language addressing the following:
>
> * Clear requirements for subordinate
Justin Dolske wrote:
> Out of curiousity... How many (if any) such CAs are currently included
> in NSS?
It's not clear, since we've never gone back and looked at all the legacy
CAs. There are certainly a number of root CAs that authorize third
parties to run subordinate CAs and issue end entity
Frank Hecker wrote:
> Kathleen Wilson and I have been discussing how to re-start the
> evaluation process for T-Systems. If you recall, that request (bug
> 378882) got bogged down in a discussion of how to deal with situations
> where the root CA doesn't actually issue end entity certificates and t
27 matches
Mail list logo
