Frank Hecker wrote:
So personally I'd consider a 5-day timeframe reasonable, and based on
past conversations with people doing update releases, I think it might
be pushed down as low as 3 days.
OK, seeing as 5-days this hasn't raised too many eyebrows, I've
fixed up this page:
Julien R Pierre - Sun Microsystems wrote:
Eddy,
Eddy Nigg wrote:
On 10/23/2008 12:34 AM, Julien R Pierre - Sun Microsystems:
... However reality shows that it takes quite some time until
a new version of NSS seeps to the application level, including with
Mozilla's own products (which would
Kyle Hamilton wrote:
RFC3280 has been obsoleted by RFC5280. Aside from that, though...
...did the people who created PKIX just not realize that if a non-root
certificate needs the ability to be revoked, a root certificate would
also?
Hi Kyle,
Of course it was realised, but what they did
At 3:25 PM +0200 10/24/08, Ian G wrote:
Robert Relyea wrote:
The problem with this idea is that mozilla probably does not want to be
in the CA business. The overhead of creating a mozilla root key in a
safe and secure manner is quite involved (and more than doing a key gen
on a smart card).
Paul Hoffman wrote:
At 3:25 PM +0200 10/24/08, Ian G wrote:
Robert Relyea wrote:
The problem with this idea is that mozilla probably does not want to be
in the CA business. The overhead of creating a mozilla root key in a
safe and secure manner is quite involved (and more than doing a
Ian G wrote:
OK, could we speculate that Mozo apps also could turn out a security
update for their products in ... say 2 business days? Or, what number?
And then, we could suggest that the whole process is likely to take
a week (5 business days)?
The Firefox team has done security updates
Frank Hecker wrote:
So personally I'd consider a 5-day timeframe reasonable, and based on
past conversations with people doing update releases, I think it might
be pushed down as low as 3 days.
I should clarify that this timeframe doesn't include any CA-related
time prior to the Mozilla
On 10/24/2008 05:07 PM, Paul Hoffman:
Robert: you are already in that business by distributing trust anchors that you
have (sometimes) vetted. You are a CA without signing anything, just by
distributing a trust anchor repository.
Kind ofMozilla doesn't certify really anything, but
At 9:42 AM -0700 10/24/08, Robert Relyea wrote:
Paul Hoffman wrote:
Robert: you are already in that business by distributing trust anchors that
you have (sometimes) vetted. You are a CA without signing anything, just by
distributing a trust anchor repository.
Yes, but by doing so we aren't in
Ian,
Ian G wrote:
Is there any reason why the message cannot be delivered by the
current channels? CRL, OCSP?
Yes, there is one : the fact that trust anchors are specifically
excluded from CRL and OCSP revocation checking in PKIX standards.
In other words, no PKIX-compliant software,
Kyle,
Kyle Hamilton wrote:
I think we all understand that the basic concept of a root-signed
self-revocation is workable, in principle, at the information level.
There may be substantial implementation questions...
There are those who don't think so, since the operations defined at
the Root
Eddy,
Eddy Nigg wrote:
- software that uses NSS but isn't a product of Mozilla
Those products have to figure out where they pick up NSS.
Various vendors have come up with different solutions.
Both Sun and Red Hat have integrated NSS into the OS, and you can get
the NSS libraries
Julien R Pierre - Sun Microsystems wrote:
How do we revoke Mozilla's root?
By updating mozilla software :)
Certainly not by issuing a CRL. Mozilla doesn't have the keys needed to
issue a CRL to revoke any root. (CRL's must be signed by the issuer, or
by an agent with the appropriate key
Julien R Pierre - Sun Microsystems wrote:
If the root could revoke itself, in the case of root cert key
compromise, ie. the root cert's private key becoming public, anybody
could then sign revocation information for that root CA - whether to
mark it revoked or unrevoked.
Leaving aside the
At 4:39 PM +0100 10/22/08, Gervase Markham wrote:
Julien R Pierre - Sun Microsystems wrote:
If the root could revoke itself, in the case of root cert key
compromise, ie. the root cert's private key becoming public, anybody
could then sign revocation information for that root CA - whether to
Gervase,
Gervase Markham wrote:
Julien R Pierre - Sun Microsystems wrote:
If the root could revoke itself, in the case of root cert key
compromise, ie. the root cert's private key becoming public, anybody
could then sign revocation information for that root CA - whether to
mark it revoked or
Paul,
Paul Hoffman wrote:
Updating software with a new root module is a lot simpler. Of course that
process has its own set of security issues as well.
It also doesn't work for users who are using a different root module. Barely traceable
management action != open message protocol.
True.
Eddy,
Eddy Nigg wrote:
Updating software with a new root module is a lot simpler. Of course
that process has its own set of security issues as well.
Besides that, one of the problems is, how to reach each and every
software (including older or non-updated or smaller ones).
I think
making use of NNS it might take month, even years.
I've mentioned initially at this thread, that revocation of CA roots has
its problems, but I haven't been able to define something better with
current tools. Apparently there is a shortcoming which needs to be
addressed at some point
2008/10/22 Ian G [EMAIL PROTECTED]:
Quite right. The flip side of this is that if *anyone* other than the
person who generated the key pair has they public key, they *should*
sign the suicide note and distribute it because if they have it, a bad
actor could have it as well.
I think we all
Kyle Hamilton wrote:
2008/10/22 Ian G [EMAIL PROTECTED]:
Quite right. The flip side of this is that if *anyone* other than the
person who generated the key pair has they public key, they *should*
sign the suicide note and distribute it because if they have it, a bad
actor could have it as
Paul Hoffman wrote:
If you want to to be able to revoke roots, please consider instead
getting active in the current work on TAMP (trust anchor management
protocol) being discussed in the PKIX WG.
Thanks for the suggestion; I presume that
At 2:02 PM + 10/21/08, Frank Hecker wrote:
Paul Hoffman wrote:
If you want to to be able to revoke roots, please consider instead
getting active in the current work on TAMP (trust anchor management
protocol) being discussed in the PKIX WG.
Thanks for the suggestion; I presume that
Kyle,
Kyle Hamilton wrote:
On Mon, Oct 20, 2008 at 5:31 PM, Julien R Pierre - Sun Microsystems
[EMAIL PROTECTED] wrote:
If the root could revoke itself, in the case of root cert key compromise,
ie. the root cert's private key becoming public, anybody could then sign
revocation information for
Eddy,
Eddy Nigg wrote:
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
protocols.
(Therefore they can only really be replaced by an adjustment to the
root list?)
Correct.
And -- broader question for the policy wonks as well as the coders
-- are we actually happy that this is a good thing: revocation of
roots is not a CRL/OCSP possibility? Should we write
Julien R Pierre - Sun Microsystems:
Eddy,
Eddy Nigg wrote:
That's entirely and implementation issue and design approach.
No. It is also an issue of PKIX standards as well. CAs should not
implement revocation mechanisms that are not standard, and expect them
to be supported by
Julien R Pierre - Sun Microsystems:
Eddy Nigg wrote:
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.
Remember that CRLs don't expire. The application can consider them
either valid or invalid based on
Julien R Pierre - Sun Microsystems:
Or until next update. It's still valid but not updated anymore.
It still remains valid for the application to use an old CRL if it is
unable to obtain newer one, whatever the reason.
I think that's what I said :-)
--
Regards
Signer: Eddy Nigg, StartCom
: revocation of roots
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https
István Zsolt BERTA:
On the long run, we plan to introduce an OCSP service that is usable
for the general public, i.e. that does not require authentication and
works using the 'authorized responder' concept. This week we had a
discussion with the National Communications Authority, we shall be
At 2:45 AM + 10/18/08, Frank Hecker wrote:
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
with the hard facts of whether it
is possible.
And -- broader question for the policy wonks as well as the coders
-- are we actually happy that this is a good thing: revocation of
roots is not a CRL/OCSP possibility? Should we write this up as a
policy statement somewhere? Or should we treat it as a bug
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.
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
actually happy that this is a good thing: revocation of
roots is not a CRL/OCSP possibility? Should we write this up as a
policy statement somewhere? Or should we treat it as a bug to be
filed fixed?
A root that revokes itself invokes the liar's paradox.
NSS wishes to avoid the fate
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
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 the
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 notethat what it really is :-)
Having a trusted service that manages trust anchors for users can be very
helpful.
NSS itself is a trust anchor,
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
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
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
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
43 matches
Mail list logo
