Michael Sierchio wrote:
> I'm not suggesting that this isn't useful, just that it is not
> a defect that it isn't part of the key format itself.
That may or may not be true, but none of your arguments support this point.
I'm learning towards a belief that it is a defect, but I am not thoroughly
On Tue, Mar 18, 2008 at 5:01 PM, Michael Sierchio <[EMAIL PROTECTED]> wrote:
> Kyle Hamilton wrote:
>
> > Certificate issuance is a statement of identity binding for a given
> > key at a given assurance. No more, no less.
>
> No, it isn't. It's often more.
Such as...?
> > A CA does not and
On Wed, Mar 19, 2008 at 10:45 AM, Michael Sierchio <[EMAIL PROTECTED]> wrote:
> Steffen DETTMER wrote:
>
> > For operational, administrative and forensic concerns I think it
> > is important to know the key generation time as well as who
> > generated it in exactly which way, who gave the key to
Steffen DETTMER wrote:
For operational, administrative and forensic concerns I think it
is important to know the key generation time as well as who
generated it in exactly which way, who gave the key to whom when
and why and so on - maybe even including a transactional log of
every key usage eve
* Michael Sierchio wrote on Tue, Mar 18, 2008 at 17:01 -0700:
> > ... It specifies things that third parties can know and rely
> > on. Only the principal itself can know what it's actually
> > going to use the key for.
>
> No, key usage restrictions are certainly within the realm of
> what a CA wi
> David Schwartz wrote:
> > Michael Sierchio:
> >> If it's your policy not to reuse keys, or allow their use beyond
> >> the lifespan of the certificate, then the enforcement mechanism
> >> for this MUST be in the CA.
> I completely disagree. If this were true, CA's would generate
> the priva
Kyle Hamilton wrote:
Certificate issuance is a statement of identity binding for a given
key at a given assurance. No more, no less.
No, it isn't. It's often more.
A CA does not and cannot specify the value of the data which can be
encrypted or protected by any given key.
Irrelevant to
On Tue, Mar 18, 2008 at 1:58 PM, Michael Sierchio <[EMAIL PROTECTED]> wrote:
> David Schwartz wrote:
> > Michael Sierchio:
> >
> >> If it's your policy not to reuse keys, or allow their use beyond
> >> the lifespan of the certificate, then the enforcement mechanism
> >> for this MUST be in the
David Schwartz wrote:
Michael Sierchio:
If it's your policy not to reuse keys, or allow their use beyond
the lifespan of the certificate, then the enforcement mechanism
for this MUST be in the CA.
I completely disagree. If this were true, CA's would generate the private key
as part of the ce
Michael Sierchio:
> If it's your policy not to reuse keys, or allow their use beyond
> the lifespan of the certificate, then the enforcement mechanism
> for this MUST be in the CA.
I completely disagree. If this were true, CA's would generate the private key
as part of the certificate issuing p
David Schwartz wrote:
What I think Michael Sierchio was saying, though, was something different.
He's not saying to treat a certificate as revoked, he's saying not to issue
a certificate. Basically, he's saying a CA could refuse to issue a
certificate for any key that it had ever seen before in
Kyle Hamilton wrote:
On Sun, Mar 16, 2008 at
Since it's infeasable to store all of the possible keypairs in the
number of atoms in the universe, your assertion holds no water.
Did you do the calculation? The number of primes less than or equal
to 512 bits in length number around 10**150,
On Mon, Mar 17, 2008 at 12:14 AM, Michael Sierchio <[EMAIL PROTECTED]> wrote:
> Kyle Hamilton wrote:
>
> > A key's lifetime is, cryptographically speaking, the amount of time
> > for which it can be expected to provide a sane level of security in
> > relation to the value of the data which it pr
Steffen Dettmer wrote:
> > > You may argue, and get me to agree, that cert
> > > reissue/resigning with the same SubjectPubkeyData is a bad
> > > idea. Make 'em generate keypairs. Keep a list forever of
> > > pubkeys seen in certs and reject any that appear in CSRs.
> (CSR? Is this like a CRL
Hi,
interesting thread.
I also think that secret and shared keys have attributes as
creation or validation date. One very important attribute I would
like to mention is the "is revoked" attribute. Of course
certificates also can be revoked, but this is something
different. Revoked certificates ca
David Schwartz wrote:
> ... An attacker can start trying to break your key as soon he has your public
key.
Issuance date of the cert suffices. It's still not an attribute of
the private key.
In any case, you may of course need to validate an old signature, and the
mechanics for that have been
Michael Sierchio wrote:
> Anyway, in the case of RSA keypairs we don't manufacture them, we
> discover them. They're already there, we just search for our p's and q's
> in the appropriate range and rely on chance starting conditions to find
> some not in use. I suggested, but not entirely in je
Kyle Hamilton wrote:
A key's lifetime is, cryptographically speaking, the amount of time
for which it can be expected to provide a sane level of security in
relation to the value of the data which it protects.
Right, which is a matter of consensus best practice, we hope...
Of course, cryptog
On Sun, Mar 16, 2008 at 11:27 PM, Michael Sierchio <[EMAIL PROTECTED]> wrote:
> David Schwartz wrote:
>
> > You have to have absolute trust in any entity that will generate or store
> your private key. Thus you can trust any information in it -- anyone who
> could put in bogus information could
David Schwartz wrote:
You have to have absolute trust in any entity that will generate or store your
private key. Thus you can trust any information in it -- anyone who could put
in bogus information could give away your key to strangers. (By absolute trust,
I mean with respect to anything yo
> David's apparent statement is "the person trusting the time is the
> person generating the key."
> Michael's apparent idea is "if you're generating it and including it
> in the key format, then you're making an assertion which must
> trustable by people other than the person generating the key."
Kyle Hamilton wrote:
On Sun, Mar 16, 2008 at 10:44 PM, David Schwartz <[EMAIL PROTECTED]> wrote:
If you can't trust the system that generates and stores your private key,
you're screwed anyway. So I don't see that this argument has any validity.
The issue is 'who is trusting what?'
David's
On Sun, Mar 16, 2008 at 10:57 PM, Michael Sierchio <[EMAIL PROTECTED]> wrote:
> David Schwartz wrote:
>
> > If you can't trust the system that generates and stores your private key,
> you're screwed anyway. So I don't see that this argument has any validity.
>
> A timestamp is not an attribute o
On Sun, Mar 16, 2008 at 10:44 PM, David Schwartz <[EMAIL PROTECTED]> wrote:
>
> If you can't trust the system that generates and stores your private key,
> you're screwed anyway. So I don't see that this argument has any validity.
The issue is 'who is trusting what?'
David's apparent statement
David Schwartz wrote:
If you can't trust the system that generates and stores your private key,
you're screwed anyway. So I don't see that this argument has any validity.
A timestamp is not an attribute of a private key. It's utterly
irrelevant. If your purpose is to require that new certif
> > I have argued many times that not including the creation date
> in every private key data format was a *huge* mistake.
> Furthermore --
> How do you know what time it is? How do I know you know what time
> it is? Do I trust you to put the correct time, or even a monotically
> increasing
David Schwartz wrote:
Arguably, you shouldn't do it even once, because it's extremely easy
to fall into the pattern of "one key and one key only" in the systems
design or implementation. I can't remember who coined the phrase, but
it's not "good crypto hygeine".
I have argued many times that n
David Schwartz wrote:
Arguably, you shouldn't do it even once, because it's extremely easy
to fall into the pattern of "one key and one key only" in the systems
design or implementation. I can't remember who coined the phrase, but
it's not "good crypto hygeine".
I have argued many times that n
Patrick Patterson wrote:
Actually, what you care about are the keys associated with the certificate.
For encryption, you've got content that is encrypted with the public key, and
decryptable only with the private key. Since the certificate is your public
key signed by some Certificate Authorit
> Arguably, you shouldn't do it even once, because it's extremely easy
> to fall into the pattern of "one key and one key only" in the systems
> design or implementation. I can't remember who coined the phrase, but
> it's not "good crypto hygeine".
I have argued many times that not including the
On Sunday 16 March 2008, David Schwartz wrote:
> > Doesn't what you suggest create a headache? Every time I want to
> > decrypt an
> > old message I sent or I received, or a file, I will need to
> > change the mail
> > client configuration and point it to another private key.
>
> One would hope yo
On Sat, Mar 15, 2008 at 11:36 PM, David Schwartz <[EMAIL PROTECTED]> wrote:
> For example, suppose I create a public/private keypair that I don't think
> anyone can break for 50 years. If I make the certificate valid for 30 years
> because of this, it would obviously be a bad idea to keep the sa
Hello Mick:
Mick wrote:
> Yes it does. Keeping the same private key and generating new public key with
> it seems to be a sensible thing to do from a practical point of view.
>
Be careful - first of all - you can't "generate a new public key" - you
can generate a new certificate request, but
> Doesn't what you suggest create a headache? Every time I want to
> decrypt an
> old message I sent or I received, or a file, I will need to
> change the mail
> client configuration and point it to another private key.
One would hope your mail client will allow you to keep any number of k
On Sat, Mar 15, 2008 at 12:12 PM, Mick <[EMAIL PROTECTED]> wrote:
> On Saturday 15 March 2008, Kyle Hamilton wrote:
> > It's rather infeasable to keep the same private key and generate a new
> > public key. If you keep the private key after the expiration of the
> > certificate, you can still d
On Saturday 15 March 2008, Kyle Hamilton wrote:
> It's rather infeasable to keep the same private key and generate a new
> public key. If you keep the private key after the expiration of the
> certificate, you can still decrypt messages encrypted to it; thus, if
> you generate a new pub/priv pair,
It's rather infeasable to keep the same private key and generate a new
public key. If you keep the private key after the expiration of the
certificate, you can still decrypt messages encrypted to it; thus, if
you generate a new pub/priv pair, you just need to keep the old key,
and use all the keys
On Friday 14 March 2008, Patrick Patterson wrote:
> Hi Mick:
>
> On Friday 14 March 2008 16:43:28 Mick wrote:
> > Hi All,
> >
> > I am not sure what happens under the following scenario. I use an SSL
> > certificate (e.g. from CaCert.org) to encrypt and sign a file and or an
> > email message. La
Hi Mick:
On Friday 14 March 2008 16:43:28 Mick wrote:
> Hi All,
>
> I am not sure what happens under the following scenario. I use an SSL
> certificate (e.g. from CaCert.org) to encrypt and sign a file and or an
> email message. Later on the certificate expires. I renew the certificate,
> load
39 matches
Mail list logo
