Frank Hecker:
Yes, but as I understand it what is being discussed here is a more
elaborate scheme whereby, for example, we (Mozilla) might run an actual
CA just for the purpose of cross certifying the roots that we accept.
Like Nelson, I can't remember who exactly was advocating this and what
My understanding is that when one revokes a certificate, it breaks the
binding of the information in the certificate from the public key
contained in the certificate.
The trust of the public key as a trust anchor is a separate concept
from the binding of the information in the certificate. Even i
Eddy Nigg wrote:
Paul Hoffman:
Having a trusted service that manages trust anchors for users can be
very helpful.
NSS itself is a trust anchor, the CA certificates are signed into
certdata.txt upon the request of Frank.
Yes, but as I understand it what is being discussed here is a more
e
Frank Hecker:
Eddy Nigg wrote:
b. Is there a way in the root list (code) to signal that a root is
revoked (other than by a self-signed CRL of self)? E.g., by a flag
or something?
Not that I'm aware of.
I don't know if this is what Ian was referring to, but in theory we can
leave the root
Eddy Nigg wrote:
b. Is there a way in the root list (code) to signal that a root is
revoked (other than by a self-signed CRL of self)? E.g., by a flag
or something?
Not that I'm aware of.
I don't know if this is what Ian was referring to, but in theory we can
leave the root certificate in
Paul Hoffman:
At 11:13 AM -0700 10
I can speak up for it, but I am loathe to say it is "better" than suicide notes.
I like the phrase "suicide note"that what it really is :-)
Having a trusted service that manages trust anchors for users can be very
helpful.
NSS itself is a trust anch
Ian G:
b. Once so revoked, are all following CRLs also "revoked"?
The CRL would have to be valid until the expiration time of the root.
c. Or, are all certificates revoked?
They are revoked due to the fact that the root is revokedRevoking
recursive could also be an option.
a.
At 11:13 AM -0700 10/17/08, Nelson B Bolyard wrote:
>A root that revokes itself invokes the liar's paradox.
>NSS wishes to avoid the fate of the android Norman. :)
Sorry, but that's a bit too glib. A "suicide note" is one valid method of trust
anchor management. It does not invoke t
Having read and mused on this "chicken and egg" problem, I see a
bunch of questions here. I doubt they will all be answered, but
food for thought:
1. If a root is compromised, how is it revoked and/or replaced?
2. If it is done by signing a revocation over self in CRL form, then:
a. Is NSS
Ian G wrote, On 2008-10-17 03:28:
> Nelson Bolyard wrote:
>> NSS will never check a self-issued cert for OCSP revocation.
To clarify, the PRESENT RELEASE of NSS will never check a self-issued
cert for OCSP revocation. Future releases may do different things.
> Ah, ok, excellent, that helps with
Frank Hecker:
I'm not sure what you mean by "repeating the process". How would such
revocation work in practice (assuming a PKI library that did CRL
checking for roots)? Would the root just sign a CRL with its own
certificate's serial number on it? Presumably at that point any
application re
Nelson B Bolyard wrote:
One final question: Does anyone know what Thunderbird 3 will be doing in
terms of OCSP checks? Will this problem affect end entity certificates
issued by Microsec for S/MIME use?
I would expect it to be identical to FF3. They use the same PSM and NSS.
Thanks for the
[EMAIL PROTECTED] wrote, On 2008-10-16 23:09:
> Hi Again,
> I've still been working on getting all the PKI functionality working
> inside my XulRunner 1.8 based browser in Eclipse. I came across the
> Chrome url: chrome://pippki/content/certManager.xul which is exactly
> what I wanted to manage the
Nuno Ponte wrote, On 2008-10-15 04:20 PDT:
> We are running a CA that has thousands of revoked certificates
> which leads to CRLs of several MBytes.
>
> On the next nenewal of the CA, we are thinking of partitioning the
> CRLs at each X number of issued certificates. The issued certificat
Frank Hecker wrote, On 2008-10-17 06:57:
> Please refresh my memory here: As I understand it, the basic problem was
> that if the Microsec root were included in Firefox (or other products)
> and a user surfed to an SSL/TLS-enabled site with an end entity
> certificate issued by Microsec (a cert
Nelson Bolyard wrote:
Frank Hecker wrote:
* OCSP. My understanding is that the Microsec practice of having a
separate root for OCSP is very problematic, particularly given the
inclusion of AIA extensions with OCSP URLs in end entity certificates.
As I understand it, Microsec is removing AIA exte
Eddy Nigg wrote:
Now IMO as the root certificate signs itself, with the same authority it
should be able to revoke itself. This would result obviously in
repeating the process until the root is removed and not used anymore,
but it would mark the root and all certificates signed by it revoked.
Ian G:
Ah, ok, excellent, that helps with the big question: Can we
conclude from this that roots cannot be revoked by means of the
OCSP/CRL channel?
No, because it depends on the application and library implementing it I
think. Apparently it's correct for NSS.
Now IMO as the root certifica
On 081014 at 23:45, Ian G wrote:
> > No. There are no plans to include any PSK cipher suites in NSS.
> > Because of the enormous potential for PSK cipher suites to be misused by
> > application developers, there is strong resistance to incorporating them
> > into NSS.
>
> Nelson, I'm fascinated b
Nelson Bolyard wrote:
> Frank Hecker wrote:
>> However there still appears to be an open question as to whether having an
>> AIA extension with OCSP URL in the Microsec root certificate will cause a
>> problem with NSS. (Nelson wrote that he was going to investigate this, but I
>> don't recall seei
On Wednesday 15 October 2008 15:14:10 István Zsolt BERTA wrote:
> > Just a thought...
> > If Nelson's investigation does find that the OCSP AIA extension in your
> > Root Certificate is a problem for NSS, is there really anything to stop
> > you from issuing a new Root Certificate? This new Root C
21 matches
Mail list logo
