Re: Combo DSS/ElGamal keys

[Douglas Stell-P27604 <Douglas_Stell-P27604@xxxxxxxxxxxxx@[160.12.2.1]@austx.tandem.com>]

>To force every STS-like terminal to validate 2 chains of
>cert controls, and revocation status, whereas one will do, and
>no vulnerabilities in conforming systems are introduced by enabling
>double-key key distribution via a single certificate
>mechanism, seems an unreasonable engineering assumption.

This is a little close to a red herring argument. One seldom has need to 
validate the signature and encryption certificates of the same subject. The 
recipient usually validates the signer's signature certificate for 
authentication and possibly his own encryption certificate for inbound 
access control, if access control is an issue. The originator usually 
validates the recipient's and possibly his own encryption certificate for 
outbound access control.

Even if both certificates of a subject need to be validated they would be 
issued by the CA and the application would not have to validate 2 chains of 
certificates or CRLs. Seperate certificates then requires validating only 
one additional certificate and looking for it in the CA's CRL.

>This practice is already documented in MISSI-based Fortezza and MSP
>[3.0] certificate-concept design documents where the "signing DSA key"
>from a MISSI [V1] cert is used for solemn signing acts by real humans,
>whereas a multi-purpose single public value (potentially and likely
>to be escrowed by DoD CA software) is available for use for KEA
>key agreement for confidentiality service establishment and, in such
>as SSL enviornments  a Fortezza-based *signed*-challenge response
>handshake for various classes of anonymous and accountable shared
>secret and data origin authentication service establisment

MISSI is abandoning this the two-key certificate. So, I wouldn't hold this 
up as a model to follow. MISSI is going to separate certificates as it 
transitions to Version 3 certificates and MSP 4.0. The reasons are the same 
ones stated earlier in this thread and repeated below, most notably proper 
revocation. (MISSI V1 certs have a single key identifier for both encryption 
and signature keys. Well, actually, they didn't foresee the need to revoke 
signature keys.)

>> It is not generally a good idea to have two public keys in the same
>> certificate, even if it appears that it might be useful in some
>> circumstances.  This is especially true for signature keys and
>> encryption/key-transfer keys, since these are likely to have quite
>> different life cycle characteristics.  Typically, for example, you will
>> want the validity periods to be different (perhaps significantly so).
>> Furthermore, the whole area of revocation becomes much more painful
>> do you really want all your signatures to become invalid simply because
>> your key-transfer key was compromised (or, worse yet, was only
>> *suspected* to have been compromised)?

This is good advice and Warwick strongly advised the MISSI working group to 
abandon the two-key model and go with separate certificates with standard 
subjectPublicKeyInfo fields. Being heavily involved in that working group 
and its revocation, renewal, rekey and operatonial aspects, I can attest 
that this is good advice. Do what MISSI and everyone else is doing, not what 
MISSI did.

doug stell