Eddy Nigg (StartCom Ltd.) wrote, On 2008-02-10 17:33:
> Network Solutions has a server certificate issued by "Network Solutions
> EV SSL CA". Ever heard of this CA? Well, it's chained like this:
>
> "AddTrust External CA Root" from Sweden and belongs to Comodo from the
> United Kingdom ->
> "UT
Eddy Nigg (StartCom Ltd.) wrote:
> Thanks for this information. However from our (Mozilla) point of view,
> the root can sign X CA certificates able to sign EV certificates
> (directly and indirectly). The OID requirement is just cosmetically in
> respect of the capabilities once a root is marke
Eddy Nigg (StartCom Ltd.) wrote:
> Kyle Hamilton wrote:
>> I have not. I must point out, though, that Frank has essentially
>> stated that it's impossible to remove an already-vetted CA.
> Did Frank say that? I don't think so...
I didn't quite say that, but I can understand why Kyle interpreted
Frank Hecker wrote:
> So the bottom line is that if a root CA is approved for EV, its
> subordinate CAs do *not* automatically gain the ability to issue EV
> certificates. Instead the root CA has to specifically enable a given
> subordinate to be "EV-capable", by issuing it a CA certificate with
Eddy Nigg (StartCom Ltd.) wrote:
> Now, I have no clue how this is going to work and perhaps Nelson can
> give us some more informationexample: If AddTrust is going to be
> upgraded to an EV root, is any sub ordinated CA potentially an EV CA?
I haven't yet looked in detail at the Network So
Frank Hecker wrote:
> Eddy Nigg (StartCom Ltd.) wrote:
>
>
>> ... _I'm requesting
>> hereby and now to have thorough review of this situation and
>> reassessment_ of the Mozilla CA policy concerning everything related to
>> sub-ordinated CAs.
>>
>
> This is a good discussion to have, an
On 2/10/2008 7:00 AM, Kyle Hamilton wrote:
> On Feb 10, 2008 3:28 AM, Eddy Nigg (StartCom Ltd.)
> <[EMAIL PROTECTED]> wrote:
>> Kyle, even so part of your argument might be correct, you are doing a great
>> injustice to some of us here, specially to the ones which bother to review
>> the CAs. Also
Kyle Hamilton wrote:
> However, the process itself is broken. The set of requirements are
> broken. The only weapon which can be used -- decertification -- is
> never (and will never, based on the Foundation's view of user
> convenience as trumping user security) used. This puts Frank into a
> p
Frank Hecker wrote:
> Eddy Nigg (StartCom Ltd.) wrote:
>
>
>> ... _I'm requesting
>> hereby and now to have thorough review of this situation and
>> reassessment_ of the Mozilla CA policy concerning everything related to
>> sub-ordinated CAs.
>>
>
> This is a good discussion to have, an
On Feb 10, 2008 3:28 AM, Eddy Nigg (StartCom Ltd.)
<[EMAIL PROTECTED]> wrote:
>
> Kyle, even so part of your argument might be correct, you are doing a great
> injustice to some of us here, specially to the ones which bother to review
> the CAs. Also Frank and Gerv invest quite some time into gett
Eddy Nigg (StartCom Ltd.) wrote:
> ... _I'm requesting
> hereby and now to have thorough review of this situation and
> reassessment_ of the Mozilla CA policy concerning everything related to
> sub-ordinated CAs.
This is a good discussion to have, and I agree that it's a timely issue.
I'd onl
Kyle Hamilton wrote:
> The end result is that anyone who chooses to spend a hundred thousand
> bucks or so on a single audit can then go around selling the benefit
> of their inclusion in the trust list to the highest bidder without
> fear of repercussion. Which is what they've been doing. And no
During the last few month many issues concerning sub-ordinated CA
certificates of CAs, considered for inclusion and CAs already included
in NSS, have come up at this forum. Today exists a situation where the
Mozilla CA policy doesn't provide enough guiding and definition, because
the policy was
Kyle Hamilton wrote:
> Without fear of delisting and decertification, CAs are running
> roughshod (not just 'are going to run roughshod', but 'ARE RUNNING
> roughshod'), making a farce of the process and the 'trust' in place.
> Without a clear view of user security held by a majority of the
> Mozil
14 matches
Mail list logo
