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:
https://wiki
Ian,
Ian G wrote:
Also, add the caveat that this guesstimate only applies Mozilla
product, and not these:
- software that uses NSS but isn't a product of Mozilla
- other libraries
They have to sort themselves out.
Whether we can do much about the other vendors is an open question.
From
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 a
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 exten
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 proj
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 wit
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 k
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
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
Robert Relyea wrote:
>>>
>>> Can we eliminate the whole CA notion by just using a single sig over
>>> the list from a "root" ... and just deliver signed updates?
> We could use PKIX to authorize the roots by setting up a mozilla root,
> then cross signing each of the approved roots. In that case m
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 (w
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 usage
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 automatical
Ian G wrote, On 2008-10-22 16:25 PDT:
> Is there any reason why the message cannot be delivered by the
> current channels? CRL, OCSP? Leaving aside the standards question,
> that is...
NSS is not a playground. Today, NSS is all about interoperability based
on standards. (That wasn't true 13 y
On 10/24/2008 12:54 AM, Julien R Pierre - Sun Microsystems:
If a root ended up being compromised and we heard about it, I can assure
you that we would produce a new NSS release with an update root cert
module with all due haste - meaning probably within a couple of business
days.
Under certain
Kyle,
Kyle Hamilton wrote:
RFC3280 has been obsoleted by RFC5280.
True - sorry but I'm still working with the old RFC. NSS is not current
on the standards yet.
Aside from that, though...
...did the people who created PKIX just not realize that if a non-root
certificate needs the ability
Eddy,
Eddy Nigg wrote:
On 10/23/2008 12:34 AM, Julien R Pierre - Sun Microsystems:
However, in this particular case, for all NSS-based software - a manual
solution exists for older applications : simply mark the root as
untrusted.
If they happen to hear about it. Or if they happen to use an
Ian,
Ian G wrote:
The part means that the new CRL could de-include the root, thus
un-revoking it. So we would need:
* a root revocation is to be cached and not replaced.
Which is something completely foreign to any PKIX standards today. There
is no persistence of any revocation informati
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?
-Kyle H
On Thu, Oct 23, 2008 at 3:39 PM, Julien R Pierre - Sun Microsystems
<[EMAI
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
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, incl
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 co
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.
>
>
>
Julien R Pierre - Sun Microsystems wrote:
> Paul Hoffman wrote:
>> 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, a
On 10/23/2008 12:34 AM, Julien R Pierre - Sun Microsystems:
However, in this particular case, for all NSS-based software - a manual
solution exists for older applications : simply mark the root as untrusted.
If they happen to hear about it. Or if they happen to use an updated NSS
library. How
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 general
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".
Tru
On 10/22/2008 09:46 PM, Julien R Pierre - Sun Microsystems:
Yes, they should ... But the big question is how do they actually do
that and get software to take notice of that suicide note ?
I don't think that can really be done without standards.
I think that's the key to solve the problem of
On 10/22/2008 10:14 PM, Paul Hoffman:
Yes, they should ... But the big question is how do they actually do that and
get software to take notice of that suicide note ?
I don't think that can really be done without standards.
Of course. I'm not saying we don't need a standard, just that the lack
>Yes, they should ... But the big question is how do they actually do that and
>get software to take notice of that suicide note ?
>I don't think that can really be done without standards.
Of course. I'm not saying we don't need a standard, just that the lack of a
standard *today* should not pre
Paul Hoffman wrote:
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 ro
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
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 - whethe
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 th
Paul,
Paul Hoffman wrote:
I disagree with Julien on two items in this thread.
At 5:31 PM -0700 10/20/08, 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 si
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 f
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
>
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 that root CA - wheth
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
http://www.ietf.org/internet-drafts/draft-ietf-pkix-t
I disagree with Julien on two items in this thread.
At 5:31 PM -0700 10/20/08, 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
OK, extracting the meat from all these replies from Pierre, I wrote
this:
===
https://wiki.mozilla.org/CA:Recommendations_for_Roots#SubRoots
Revocation of the Root [edit]
* For a root listed in Mozilla's root list, file a bug to
request the root be marked "untrusted". Once di
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 L
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
Eddy,
Eddy Nigg wrote:
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
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 general-purpo
Eddy,
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 the certification path of the
Ian,
Ian G wrote:
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?
By means of marking that cert as untrusted , or deleting that
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 general-purpose software like NSS/Mozilla.
__
revocation 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
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
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 ex
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
able
> I.e., unless bugs 205436 or 92923 are worked on soon, using https OCSP
> URIs will quite effectively prevent Mozilla clients from connecting to
> this responder :-) [1] István, maybe you can confirm that in all the
> certs issued so far you've only used https OCSP URIs?
Yes, they all contain htt
How come that S/MIME-signed messages are unreadable using Microsoft Mail and
Outlook Express?
Anders
- Original Message -
From: "Ian G" <[EMAIL PROTECTED]>
To: "mozilla's crypto code discussion list"
Sent: Saturday, October 18, 2008 12:49
S
Frank Hecker wrote:
> 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 theor
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
ion 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 to be
> filed & fixed?
A root that
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
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
floating around for some
time in various places, but never 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
69 matches
Mail list logo
