Re: Authentication vs. binding signature, and ephemeral vs. permanent key usage

[Eric Murray <ericm@xxxxxxx>]

Peter Gutmann writes:
> 
> >In summary, I would suggest the following new key usage bits:
> >
> >1.  Authentication -- a service
> >
> >2.  Binding signature -- a service
> >
> >3.  Enduring -- an indication of the validity of the authentication or 
> >binding signature after the certificate validity interval. This should 
> >replace the current "nonrepudiation" bit, which should be deprecated.
> >
> >4.  Accessible by a third party -- i.e., subject to key escrow, key recovery, 
> >etc., whether by one's employer, a trusted third party, and/or the government 
> >directly.
> >
> >5.  Ideally, the "digital signature" mechanism bit must be exclusive of any 
> >other usage.  But if it is used in combination with other bits, it will may 
> >mean that the key will NOT be exempt from key escrow or weakened cryptography 
> >requirements that may be imposed by various regimes.
>  
>I mostly agree with this, but I'm wondering whether the plethora of extra bits 
> isn't going to cause confusion in the future (look at the existing example of 
> keyAgreement vs encipherOnly/decipherOnly - the latter two make the former 
> redundant).

There'a already a huge plethora of extensions, a few more key
usage bits that are unambiguous wouldn't hurt anything.

I also agree, for the most part, with Bob's recommentations.

>  How about just clarifying the digitalSignature definition to 
>mean "binding signatures only" and adding a new authentication bit, instead of 
> adding two new bits with a somewhat vague relationship to the existing one?
>  
> I'm also not so sure about the enduring and GAK bits.  GAK isn't really a key 
> usage, is a lot more complicated than just a simple "yes/no", and is already 
> covered in a few standards (eg the draft GAK FIPS which devotes an entire 
> certificate extension to it).  The enduring bit may also be something which 
> can't be expressed as a simple yes or no - how long does it endure?  Is it 
> affected by cert renewals?  Is there a reliance limit attached to it?  It 
> sounds like this would also require its own extension, and may not even be 
>useful because it's really up to the relying party as to whether they're going 
> to trust an expired cert, and what they'd trust it for -

The enduring 'bit' would indeed need to have at least a time period
attached to it, in fact that's how I read it the first time.

The enduring bit is one way of solving something that's broken in X.509-
the key associated with a cert can be used to sign right up until the
key, and it's cert, expire.  But a signature on a document one second
before the cert expires is essentially worthless.  What's needed is a
way to indicate that at time X the private key will no longer be used to
sign, and at time X+Y the cert expires and the public key should no
longer be used to verify signatures.

This isn't a new idea by any means.  It's solved in SET by an extension
which specifies the time period which the private key can be used for
signing, and the Validity remains with the traditional meaning- that the
cert's public key should no longer be used after it has expired.

Changing Bob's Enduring bit to an extension (presumeably with a Validity
or at least a time at which it expires) would invert the meaning- the
X.509 Validity would become the time which the private key can be used
for signing, and the Enduring extension would indicate how long the
cert's public key can be used.  The problem with this is that it changes
the meaning of the Validity.  I'd think that for compatability the
Validity should indicate the public key's useage period, and an
extension (like SET's privateKeyUsagePeriod, which is probably not
unique to SET) be used to indicate the private key useage period.


> I have 5-year-old 
> keys from people which I still trust for signatures even though they're well 
> past their use-by date because they're not used for high-value signatures and 
> because I know they're careful with the keys.  I wouldn't trust them for 
> high-value signing, and the presence or abscence of an enduring bit wouldn't 
> change this.

I think that a lot of people do this, especially with PGP 'certificates'.
People will always use their personal knowledge about other people to
modify their trust relationships.    In general, PKIs need to transmit
enough human-understandable information to make it possible to
perform that kind of off-the-cuff trust  calculation, while also
carrying enough information to allow non-AI software to reliably
calculate trust chains for the majority of cases where the humans
involved do not know each other.



-- 
Eric Murray  Chief Security Scientist  N*Able Technologies  www.nabletech.com
(email:  ericm  at  lne.com   or   nabletech.com)          PGP keyid:E03F65E5