headers
Stephen Wilson | 1 Apr 2009 04:41
Picon
Gravatar

Renew/Rekey/Modification


Colleagues,

There are a few things about certificate "renewal" and "re-key" that 
have long confounded me.  Things only seem to have got more convoluted 
in RFC 3647 and -- no offence! -- in newer Certificate Policies like the 
US FPKI Policy Authority document.   Can anyone help me understand the 
rationale for the some of the following scenarios?  Thanks in advance!

Re-key is said (in the FPKI CP) to be a good idea because the older a 
key gets, the more susceptible it is to loss and compromise.  Fair 
enough, but why wouldn't that consideration be factored into the chosen 
certificate validity period?

Is there ever a real world scenario when a Subject would of their own 
accord request re-key because they feel the key is getting old?  If so, 
why wouldn't they revoke as well?  The FPKI CA says that after re-key 
"The old certificate may or may not be revoked".  Why would you not 
revoke, given the possibility that the key has got too old?  I don't 
think it would ever be sensible to keep using an old original key and a 
fresh key.  And if I were a Relying Party, I might like to know about 
this possible quality difference, yet there would be nothing in a CRL or 
anywhere else to mark the fact that the Subscriber has re-keyed.

The FPKI CA goes on to say that after re-key "The old certificate ... 
must not be further re-keyed, renewed, or modified".  This seems almost 
oxymoronic.  Consider that I have certificate A and then I re-key A to 
create certificate B.  And then I re-key B to create certificate C.  I 
would say that C is indistinguishable from a re-keyed A since A, B and C 
will only differ by key value.  So how is it meaningful to forbid
(Continue reading)

Permalink | Reply | 6 comments |
headers
Johannes Merkle | 1 Apr 2009 14:49
Favicon

Re: Renew/Rekey/Modification


Stephen,

I do not know the FPKI documents but I think your questions generally refer to RFC 3647.

> Re-key is said (in the FPKI CP) to be a good idea because the older a
> key gets, the more susceptible it is to loss and compromise.  Fair
> enough, but why wouldn't that consideration be factored into the chosen
> certificate validity period?
> 
Typically, a certificate is re-keyed when or right before it expires. In this case, the maximum key
lifetime is factored
into the certificate.

> 
> Is there ever a real world scenario when a Subject would of their own
> accord request re-key because they feel the key is getting old?  If so,
Yes, right before the old certificate expires. An alternative scenario would be after revocation due to
suspected key
compromise, but in this case the application for the new cert can not be secured by the old one.

> why wouldn't they revoke as well?  The FPKI CA says that after re-key
> "The old certificate may or may not be revoked".  Why would you not
> revoke, given the possibility that the key has got too old?  I don't
> think it would ever be sensible to keep using an old original key and a
> fresh key.  And if I were a Relying Party, I might like to know about
> this possible quality difference, yet there would be nothing in a CRL or
> anywhere else to mark the fact that the Subscriber has re-keyed.
If the old certificate is going to expire very soon, revocation might not be necessary. However, it is
considered good
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kemp, David P. | 1 Apr 2009 15:45

RE: Renew/Rekey/Modification


You may be over-analyzing the terms.  A certificate can be issued
ab-initio, or it can be related to an existing certificate.  If related,
various things can be held constant while others are changed:
* if only validity (and serial number, of course) changes, it's called
renewal
* if other information excluding the key changes, it's called an update
or modification
* if the key changes, it's called a rekey

If a certificate is replaced because of a known key compromise, the cert
is rekeyed and the old cert is revoked.  If a cert is replaced because
it is getting old (nearing the end of its validity) then the old cert
may either be revoked or be allowed to expire.  Key age is one factor in
determining validity period, but so is other information - it may be
useful to renew short-lived certificates many times without rekeying in
order to avoid or minimize the burden of revocation.

You are correct that if cert A is rekeyed twice, there isn't much
difference between saying cert C is a rekey of B or of A.  But there is
a difference for renew and update - it is a management best practice not
to renew or update A to produce C after rekeying A to produce B - once
A's key has been replaced, no new certificates should be created with
that key.  It may also be good practice to say that if cert A has been
rekeyed to produce B, then only B (and not A, even if still valid)
should be used to authenticate the subject when rekeying to produce C.

Dave

-----Original Message-----
(Continue reading)

Permalink | Reply | 0 comments |
headers
Santosh Chokhani | 1 Apr 2009 16:05
Favicon

RE: OCSP RFC (RFC 2560) Dependence on SHA-1


My resident ASN.1 expert apprised me of the fact that adding a choice
will break backward compatibility.  Thus, extension is a fifth option
(probably third in the priority).

Based on what I know of OCSP implementations, not changing anything in
terms of bits on the wire and aligning the Key ID with SKID in 5280 is
the best approach.  I do not think it will hurt backward compatibility.

OCSP Responder and OCSP client vendors should speak up if I am wrong.

> -----Original Message-----
> From: Santosh Chokhani 
> Sent: Tuesday, March 31, 2009 12:51 PM
> To: 'Massimiliano Pala'; IETF-pkix
> Subject: RE: OCSP RFC (RFC 2560) Dependence on SHA-1
> 
> Max,
> 
> I do not see where and what extension we need to add for 
> other digest algorithm.
> 
> For key id, we need to enhance or broaden the options. 
> 
> > -----Original Message-----
> > From: owner-ietf-pkix <at> mail.imc.org
> > [mailto:owner-ietf-pkix <at> mail.imc.org] On Behalf Of Massimiliano Pala
> > Sent: Tuesday, March 31, 2009 1:37 PM
> > To: IETF-pkix
> > Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1
(Continue reading)

Permalink | Reply | 13 comments |
headers
David A. Cooper | 1 Apr 2009 16:53
Favicon

Re: Renew/Rekey/Modification


Stephen Wilson wrote:
> The FPKI CA goes on to say that after re-key "The old certificate ... 
> must not be further re-keyed, renewed, or modified".  This seems 
> almost oxymoronic.  Consider that I have certificate A and then I 
> re-key A to create certificate B.  And then I re-key B to create 
> certificate C.  I would say that C is indistinguishable from a 
> re-keyed A since A, B and C will only differ by key value.  So how is 
> it meaningful to forbid re-keying A more than once?

Consider a scenario in which the private key corresponding to 
certificate A has been compromised (e.g., an attacker, without my 
knowledge, infects my computer with a virus, obtains a copy of the file 
containing the private key, and guesses the password used to encrypt the 
private key file).  When certificate A is about to expire, if I wish to 
continue to have a certificate from this CA, then one of two scenarios 
may happen:

1) I perform re-key, authenticating myself using certificate A, and 
obtain certificate B.  The attacker is now prevented from performing an 
on-line re-key to obtain a new certificate in my name, since the system 
will not permit any further re-key based on certificate A.  Thus, the 
attacker's ability to impersonate me ends either immediately (if 
certificate A is revoked) or when certificate A expires.

2) The attacker performs a re-key, authenticating himself using the 
stolen private key, and obtains certificate B.  Later, I attempt to 
perform a re-key and am unsuccessful, since the system will not permit 
any further re-key based on certificate A.  I call the help desk and 
complain, which will (hopefully) result in certificate B being revoked.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Santesson | 1 Apr 2009 20:34
Favicon

Re: OCSP RFC (RFC 2560) Dependence on SHA-1


Santosh,

If you are talking about adding other options to calculate the KeyHash value
in ResponderID then I strongly disagree.

If you add unspecified options you change the properties of the field from
deterministic to a completely unknown value. It does not matter if RFC2560
isn't explicit in its description of the use of the field. The fact is that
OCSP explicitly defines this value and as such will allow a client to
deterministically compare this value with the certificate selected to
validate the response signature. If you allow other ways to calculate the
value but do not provide any means to signal what method that was used, then
this feature is lost.

In worst case we will cause current implementation to fail.

I really don't think its worth the effort to change this field. We have a
very large base of implementations that we really don't want to mess up
unless its absolutely necessary.

As the only property of this field is to provide a convenient identifier, it
is far from absolutely necessary to change it. Remember that there is a
second choice to to identify responder by name. For names we have accepted
the possibility of collisions. In that comparison, upgrading from SHA-1 is
really redundant.

/Stefan

On 4/1/09 4:05 PM, "Santosh Chokhani" <SChokhani <at> cygnacom.com> wrote:
(Continue reading)

Permalink | Reply | 12 comments |
headers
Anders Rundgren | 1 Apr 2009 21:48
Picon

WG Advice on Reviving a multikey certificate I-D


Quite some time ago the following I-D was written and then left to
expire (probably due to lack of interest):
http://www.potaroo.net/ietf/all-ids/draft-lin-mpk-app-00.txt

It seems that there is a class of applications that could use this scheme
as an alternative to multiple certificates and that are devices that are
to be pre-configured with device certificates.  Such devices include
mobile phones and routers (work is currently performed by IEEE).

The router people are currently thinking in terms of hosting a single
authentication certificate which in SOHO configurations would be
used "as-is" as an easier alternative to shared secrets.  However,
for enterprise use, it is likely that corporate IT would like to unify
the equipment to an in-house PKI.  Although you could use the
authentication certificate for credential bootstrapping, a better
solution is making in-device key-generation with attested public
keys.  This calls for device attestation keys which in some way
must be distinguishable from authentication keys.

To avoid that devices get "split personalities" it would be nice to
put the attestation key in the same certificate as normally used for
authentications.  Since attestations is something very specific not
associated with standard applications, there is no impediment
having to dig out the public key from a certificate in a slightly
unusual way, it is just 20 lines extra to 2000 you already got :-)

TrustedComputingGroup have addressed this topic using a virtual
orgy of keys and certificates.  I prefer simpler solutions.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Santosh Chokhani | 1 Apr 2009 22:31
Favicon

RE: OCSP RFC (RFC 2560) Dependence on SHA-1


Stefan,

See responses in-line.

> -----Original Message-----
> From: Stefan Santesson [mailto:stefan <at> aaa-sec.com] 
> Sent: Wednesday, April 01, 2009 2:34 PM
> To: Santosh Chokhani; Massimiliano Pala; IETF-pkix
> Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1
> 
> Santosh,
> 
> If you are talking about adding other options to calculate 
> the KeyHash value in ResponderID then I strongly disagree.
> 
> If you add unspecified options you change the properties of 
> the field from deterministic to a completely unknown value. 
> It does not matter if RFC2560 isn't explicit in its 
> description of the use of the field. The fact is that OCSP 
> explicitly defines this value and as such will allow a client 
> to deterministically compare this value with the certificate 
> selected to validate the response signature.

I hope no one is doing the matching of Responder ID with hash of a key
in place of responder signature verification.  That would be real bad.

> If you allow 
> other ways to calculate the value but do not provide any 
> means to signal what method that was used, then this feature is lost.
(Continue reading)

Permalink | Reply | 11 comments |
headers
Santosh Chokhani | 1 Apr 2009 23:00
Favicon

RE: Renew/Rekey/Modification


Stephen,

See responses in-line. 

> -----Original Message-----
> From: owner-ietf-pkix <at> mail.imc.org 
> [mailto:owner-ietf-pkix <at> mail.imc.org] On Behalf Of Stephen Wilson
> Sent: Tuesday, March 31, 2009 10:42 PM
> To: ietf-pkix <at> imc.org
> Subject: Renew/Rekey/Modification
> 
> 
> 
> Colleagues,
> 
> There are a few things about certificate "renewal" and 
> "re-key" that have long confounded me.  Things only seem to 
> have got more convoluted in RFC 3647 and -- no offence! -- in 
> newer Certificate Policies like the 
> US FPKI Policy Authority document.   Can anyone help me 
> understand the 
> rationale for the some of the following scenarios?  Thanks in advance!
> 
> 
> 
> Re-key is said (in the FPKI CP) to be a good idea because the 
> older a key gets, the more susceptible it is to loss and 
> compromise.  Fair enough, but why wouldn't that consideration 
> be factored into the chosen certificate validity period?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Internet-Drafts | 2 Apr 2009 00:00
Picon
Favicon

I-D ACTION:draft-ietf-pkix-tac-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Traceable Anonymous Certificate
	Author(s)	: S. Park, H. Park, Y. Won, J. Lee, S. Kent
	Filename	: draft-ietf-pkix-tac-03.txt
	Pages		: 32
	Date		: 2009-3-31
	
Public Key Infrastructure (PKI) provides a powerful means of 
   authenticating individuals, organizations, and computers(e.g.,  
   web servers). However, when individuals use certificates to  
   access resources on the public Internet, there are legitimate 
   concerns about personal privacy, and thus there are increasing 
   demands for privacy enhancing techniques on the Internet. 

   In a PKI, an authorized entity such as a certification Authority 
   (CA) or a Registration Authority (RA) may be perceived, from a 
   privacy perspective, as a "big brother," even when a CA issues a 
   certificate containing a Subject name that is a pseudonym. This  
   is because such entities can always map a pseudonym in a  
   certificate they issued to the name of the real user to whom it  
   was issued. This document defines a practical architecture and 
   protocols for offering privacy for a user who requests and uses  
   an X.509 certificate containing a pseudonym, while still retaining 
   the ability to map such a certificate to the real user who  
   requested it. The architecture is compatible with IETF certificate 
   request formats such as PKCS10 [3]and CMC[4]. The architecture 
   separates the authorities involved in issuing a certificate: one
(Continue reading)

Permalink | Reply | 0 comments |

Gmane