At 5:09 PM + 2/4/09, Frank Hecker wrote:
1. To what extent do typical CPSs and CPs address this issue? In other words,
if we were to read the average CPS/CP, would it have language that would
unambiguously tell us whether our policy requirement were met or not? Or is
this something that's
At 6:23 PM -0800 2/4/09, Kyle Hamilton wrote:
There are two states in the NIST key state transition diagram that are
appropriate to this entire concept... compromised (state entered
when the private information associated with it -- i.e., the private
key and its passphrase, and has only one
On 11/2/09 17:20, Paul Hoffman wrote:
At 5:09 PM + 2/4/09, Frank Hecker wrote:
1. To what extent do typical CPSs and CPs address this issue? In other words,
if we were to read the average CPS/CP, would it have language that would
unambiguously tell us whether our policy requirement were
On 02/11/2009 06:33 PM, Ian G:
Whether or not the average CPS/CP has it is irrelevant. Let's look at
the standards that all CAs are supposed to be using, in this case RFC
5280:
Where in the policy does it mention RFC 5280?
I guess Mozilla strives to follow standards.
The CA is not
On 02/04/2009 07:39 PM, Frank Hecker:
Re resellers, I think it is a fruitless task for us to try to move the
entire CA industry to change the way it operates as a business. Our main
interest is in having CAs maintain effective controls over their
authorized agents, whether these be actual
Eddy Nigg wrote:
On 02/05/2009 04:23 AM, Kyle Hamilton:
Once a key is in compromised state, it can never become uncompromised
again. Enforcing this is part of the trust that I have in the
certification authorities -- and why I don't currently trust any of
them to tell me who anyone happens to
Eddy Nigg wrote:
On 02/05/2009 04:05 AM, Frank Hecker:
* In the near term I think we should make it a recommended practice that
CAs should revoke certificates whose private keys are known to be
compromised, as well as certificates for which subscriber verification
is known to be invalid.
On 02/05/2009 04:03 PM, Frank Hecker:
I agree that it would be unusual for a CPS to state that certificate
revocation could be done only at the request of the subscriber. However
I *can* imagine a CPS where this would be ambiguous. For example, your
StartCom CPS is very slightly ambiguous,
On 02/05/2009 04:13 PM, Frank Hecker:
I agree. I think this is a case where it definitely makes sense to have
this be a requirement. I also think the case of revocation on key
compromise is relatively clear, and I don't anticipate any major
problems finding policy language to deal with it.
Michael Ströder wrote:
Julien R Pierre - Sun Microsystems wrote:
Paul Hoffman wrote:
At 3:45 PM -0800 1/21/09, Nelson B Bolyard wrote:
Perhaps Mozilla should change its policy to require CAs to revoke certs
when the private key is known to be compromised, whether or not an
attack
is in
On 4/2/09 18:09, Frank Hecker wrote:
Now, with regard to making this a formal policy requirement, I have the
following questions:
1. To what extent do typical CPSs and CPs address this issue? In other
words, if we were to read the average CPS/CP, would it have language
that would unambiguously
On 02/04/2009 07:09 PM, Frank Hecker:
1. To what extent do typical CPSs and CPs address this issue? In other
words, if we were to read the average CPS/CP, would it have language
that would unambiguously tell us whether our policy requirement were met
or not? Or is this something that's typically
Ian G wrote re revocation on compromise:
I happen to be in that area at the moment as I am reading CAcert against
the criteria, so I will pass on their CPS [2]:
Thanks for this info!
Certificates may be revoked under the following circumstances:
1. As initiated by the Subscriber
Eddy Nigg wrote re revocation on compromise:
Generally CAs can act upon mere knowledge about certain circumstances
for revoking certificates.
snip
I believe that the StartCom CPS isn't unique in regards to revocation
which states:
Circumstances for Revocation
Revocation of a certificate is
There are two states in the NIST key state transition diagram that are
appropriate to this entire concept... compromised (state entered
when the private information associated with it -- i.e., the private
key and its passphrase, and has only one possible state transition
from it) and compromised
On 02/05/2009 04:05 AM, Frank Hecker:
* In the near term I think we should make it a recommended practice that
CAs should revoke certificates whose private keys are known to be
compromised, as well as certificates for which subscriber verification
is known to be invalid.
Well, a recommendation
On 02/05/2009 04:23 AM, Kyle Hamilton:
Once a key is in compromised state, it can never become uncompromised
again. Enforcing this is part of the trust that I have in the
certification authorities -- and why I don't currently trust any of
them to tell me who anyone happens to be, since any CPS
Ian G wrote:
There have been a lot of calls to change the policy ... has someone
thought to keep a record of all these? Here's what I recall so far:
* MD5 should be dropped [1]
* publication of private key is considered to be compromise
+ compromise should cause revocation
* no
David,
David Stutzman wrote:
Jean-Marc Desperrier wrote:
You *obviously* never had to handle this CRL :
http://onsitecrl.certplus.com/DIRECTIONGENERALEDESIMPOTSDIRECTIONGENERALEDESIMPOTSUSAGER/LatestCRL
Java programs just can't take it up. And J2EE is by far the most
popular application
Ian,
Ian G wrote:
On 31/1/09 03:56, Kyle Hamilton wrote:
The PKIX standard can deal with problems of this extent.
If an implementation of the standard cannot, then the implementation
is nonconforming, and cannot be expected to interoperate.
Do you mean, an implementation should be able to
On 31/1/09 17:08, Paul Hoffman wrote:
On 31/1/09 03:56, Kyle Hamilton wrote:
The PKIX standard can deal with problems of this extent.
If an implementation of the standard cannot, then the implementation
is nonconforming, and cannot be expected to interoperate.
Do you mean, an implementation
At 12:29 PM +0100 2/1/09, Ian G wrote:
On 31/1/09 17:08, Paul Hoffman wrote:
If a trust anchor has a CRL that is too large for for the implementation to
handle, the implementation MUST remove that trust anchor from its pile.
Wouldn't it be better to mark those certificates in the same way as
On 31/1/09 03:56, Kyle Hamilton wrote:
The PKIX standard can deal with problems of this extent.
If an implementation of the standard cannot, then the implementation
is nonconforming, and cannot be expected to interoperate.
Do you mean, an implementation should be able to deal with a CRL of
On 31/1/09 03:56, Kyle Hamilton wrote:
The PKIX standard can deal with problems of this extent.
If an implementation of the standard cannot, then the implementation
is nonconforming, and cannot be expected to interoperate.
Do you mean, an implementation should be able to deal with a CRL of any
On 01/31/2009 06:08 PM, Paul Hoffman:
On 31/1/09 03:56, Kyle Hamilton wrote:
The PKIX standard can deal with problems of this extent.
If an implementation of the standard cannot, then the implementation
is nonconforming, and cannot be expected to interoperate.
Do you mean, an implementation
An implementation should be able to deal with a CRL of any size, that
is indeed what I'm saying. CRLs are also the ONLY revocation
mechanism specified by X.509. (As well, they're also still specified
in RFC 5280, which means that a fully-conforming implementation of the
Internet PKI must handle
Paul Hoffman wrote:
[...]
That feels insufficient to me. I also disagree that there are
practical problems of revoking a very large number of certificates.
The worst problem is that the CRL will grow; that's no big deal, it
is supposed to grow.
You *obviously* never had to handle this CRL :
Jean-Marc Desperrier wrote:
You *obviously* never had to handle this CRL :
http://onsitecrl.certplus.com/DIRECTIONGENERALEDESIMPOTSDIRECTIONGENERALEDESIMPOTSUSAGER/LatestCRL
Java programs just can't take it up. And J2EE is by far the most popular
application server architecture nowadays. 64
On 01/30/2009 01:25 PM, Jean-Marc Desperrier:
Paul Hoffman wrote:
[...]
That feels insufficient to me. I also disagree that there are
practical problems of revoking a very large number of certificates.
The worst problem is that the CRL will grow; that's no big deal, it
is supposed to grow.
Florian Weimer wrote:
* Michael Ströder:
Florian Weimer wrote:
What about requiring that all certificates must be published by the CA
(including sub-CAs)?
No, this might lead to also revealing internal DNS names never meant to
be public.
Huh? Typical CA policies
Whatever a typical CA
It is kind of sad that this discussion has become CAs should not revoke
certificates when the private keys are exposed because Java cannot handle CRLs
reliably. That says more about the failures of Java than it does failures in
PKIX.
--Paul Hoffman
--
dev-tech-crypto mailing list
The PKIX standard can deal with problems of this extent.
If an implementation of the standard cannot, then the implementation
is nonconforming, and cannot be expected to interoperate.
in other words, it's the implementation's fault, not the standard's.
(Yes, a standard has the responsibility to
Jean-Marc Desperrier wrote, On 2009-01-30 03:25:
Paul Hoffman wrote:
[...]
That feels insufficient to me. I also disagree that there are
practical problems of revoking a very large number of certificates.
The worst problem is that the CRL will grow; that's no big deal, it
is supposed to
Eddy Nigg wrote:
[...]
Well, this thread started out with the request that Mozilla should
change it's policy to require CAs revoke certificate when the private
key is known to be compromised.
Given the practical problems of revoking a very large number of
certificates, I'd consider it
At 1:21 PM +0100 1/29/09, Jean-Marc Desperrier wrote:
Eddy Nigg wrote:
[...]
Well, this thread started out with the request that Mozilla should
change it's policy to require CAs revoke certificate when the private
key is known to be compromised.
Given the practical problems of revoking a very
On 01/29/2009 02:21 PM, Jean-Marc Desperrier:
Eddy Nigg wrote:
[...]
Well, this thread started out with the request that Mozilla should
change it's policy to require CAs revoke certificate when the private
key is known to be compromised.
Given the practical problems of revoking a very large
On 22/1/09 02:17, lots of people wrote:
At 3:45 PM -0800 1/21/09, Nelson B Bolyard wrote:
Perhaps Mozilla should change its policy to require CAs to revoke certs
when the private key is known to be compromised, whether or not an attack
is in evidence, as a condition of having trust bits in
On 25/1/09 22:06, Florian Weimer wrote:
* Ian G.:
What I know of, not exclusive or reliable:
...
2. while certificates by their nature and name are often public
(public key), that doesn't mean that anyone else can use
them. Indeed, some CAs go to the extent of making their certificates
* Eddy Nigg:
On 01/22/2009 11:59 AM, Florian Weimer:
http://lxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt
The list doesn't include sub-CAs, which are equivalent to listed CAs
for all practical purposes.
Well, if you ping a web site then you'll most likely also
* Ian G.:
Huh? Typical CA policies explicitly state that subscriber
certificates are not confidential, and are not treated as such by the
CA (so that they can be used by marketing, for instance).
What I know of, not exclusive or reliable:
1. privacy, as Eddy has pointed out. The reason
On 01/25/2009 11:02 PM, Florian Weimer:
The Mozilla-listed CA does not know which certificates have been
issued if there's an intermediate CA. Mozilla does not know which
intermediate CAs exist. So there's not much room for proactive
action. You can only run after individual certificates.
* Eddy Nigg:
As a matter of fact, most CAs have policies in place which require
them upon knowledge of potential or *suspected* compromise to revoke
ANY certificate. I'm certain those policies exist for the top CAs
covering the majority of certificates. The keys are compromised, not
only
On 01/22/2009 11:04 AM, Florian Weimer:
* Eddy Nigg:
As a matter of fact, most CAs have policies in place which require
them upon knowledge of potential or *suspected* compromise to revoke
ANY certificate. I'm certain those policies exist for the top CAs
covering the majority of certificates.
* Eddy Nigg:
On 01/22/2009 11:04 AM, Florian Weimer:
* Eddy Nigg:
As a matter of fact, most CAs have policies in place which require
them upon knowledge of potential or *suspected* compromise to revoke
ANY certificate. I'm certain those policies exist for the top CAs
covering the majority
On Thu, Jan 22, 2009 at 1:59 AM, Florian Weimer f...@deneb.enyo.de wrote:
* Eddy Nigg:
but I guess that sub CAs could be published, end-user certificates
most likely not.
Why not?
Among other things:
- The ability for other entities to mine that data for improper contact
- The ability for
On 01/22/2009 11:59 AM, Florian Weimer:
http://lxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt
The list doesn't include sub-CAs, which are equivalent to listed CAs
for all practical purposes.
Well, if you ping a web site then you'll most likely also know the
On 01/22/2009 12:17 PM, Kyle Hamilton:
- The ability for other entities to mine that data for improper contact
- The ability for the information in the certificates to be otherwise misused
- Not every certificate user wants to identify as being a part of a
given PKI system
- Requiring full
Julien R Pierre - Sun Microsystems wrote:
Paul Hoffman wrote:
At 3:45 PM -0800 1/21/09, Nelson B Bolyard wrote:
Perhaps Mozilla should change its policy to require CAs to revoke certs
when the private key is known to be compromised, whether or not an
attack
is in evidence, as a condition of
Florian Weimer wrote:
What about requiring that all certificates must be published by the CA
(including sub-CAs)?
No, this might lead to also revealing internal DNS names never meant to
be public.
Ciao, Michael.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
At 3:45 PM -0800 1/21/09, Nelson B Bolyard wrote:
Perhaps Mozilla should change its policy to require CAs to revoke certs
when the private key is known to be compromised, whether or not an attack
is in evidence, as a condition of having trust bits in Firefox.
Fully agree.
--Paul Hoffman
--
Paul Hoffman wrote:
At 3:45 PM -0800 1/21/09, Nelson B Bolyard wrote:
Perhaps Mozilla should change its policy to require CAs to revoke certs
when the private key is known to be compromised, whether or not an attack
is in evidence, as a condition of having trust bits in Firefox.
Fully agree.
On Wed, Jan 21, 2009 at 5:50 PM, Julien R Pierre - Sun Microsystems
julien.pierre.nos...@nospam.sun.com wrote:
Paul Hoffman wrote:
At 3:45 PM -0800 1/21/09, Nelson B Bolyard wrote:
Perhaps Mozilla should change its policy to require CAs to revoke certs
when the private key is known to be
52 matches
Mail list logo
