Subject: RE: Associating symmetric algorithms with a public key

From: Peter Williams <[email-masked]>
Date: Wed, 17 Nov 1999 09:26:34 -0800

> -----Original Message-----
> From: Paul Koning [mailto:[email-masked]]
> Sent: Wednesday, November 17, 1999 6:42 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: Associating symmetric algorithms with a public key
> 
> 
> >>>>> "Stephen" == Stephen Kent <[email-masked]> writes:
> 
>  Stephen> Trevor, I hate to see extra attributes added to certs....
>  Stephen> ....  However, I'd rather see the LDAP &
>  Stephen> X.500 folks provide better data structures for this in the
>  Stephen> directory, rather than adding a field that has only
>  Stephen> heuristic value to a cert.  If these are only hints, not
>  Stephen> proscriptive, then we don't seem to be making a string
>  Stephen> security statement about them anyway.
> 
> I agree with that.  I also don't go along with the underlying notion
> of an association between a public key and a set of symmetric
> algorithms.  There is no such association, cryptographically speaking.

This is a fun topic.

(a) There is a natural association between a public key and a security
mechanism such that dual/triple/multi cert regimes are required per se in 
the PKI, apparently.

(b) There is no natural association between a public and those security
mechanisms that require both public and symmetric algorithm support, from
the claim.

What is an example of (b)?

PEM had a security mechanism, which required that the output of
a private-key operation be ciphered in the DEK of the session to
ensure that only the intended recipient was authorized to rely on 
the signature and/or learn the signature ciphertext/plaintext pair.

(There was nothing artificial about the design of this security
mechanism; straight forward crypto-countermeasures engineering...)

> 
> It's conceivable that there exists an artificial association, in some
> applications, or some users, or some environments.  If so, does it
> make sense to burden certificates with this sort of
> application-specific baggage?  I don't think so.

if the word certificate include PMI certs (which in PKIX it
does) then there is no reason why the PMI cert cannot hold
such a directoryattribute which is used as an authenticated
control signal to control the multi-algorithm mechanism. That is 
what the PMI is for, after all, including using CRLs/OCSP etc to 
withdraw the privilege.

If the PMI cert can do this legitimately, nominally so can the 
id cert, given it now contains such enourmous amounts of other 
usage/purpose control signals now. 

Microsoft could invent a new IETF extension syntax, if there
is pro forma objection to the nice reusable one from ISO.  This 
would break the association with directory management, but enable
the (1 mechanism : multiple facility) control to be 
expressed via id/pmi certs.

> 	paul

---

From: Paul Koning <[email-masked]>
Date: Wed, 17 Nov 1999 12:49:24 -0500

>>>>> "Peter" == Peter Williams <[email-masked]> writes:

 >> -----Original Message----- From: Paul Koning

 >>  I agree with that.  I also don't go along with the underlying
 >> notion of an association between a public key and a set of
 >> symmetric algorithms.  There is no such association,
 >> cryptographically speaking.

 Peter> This is a fun topic.

 Peter> (a) There is a natural association between a public key and a
 Peter> security mechanism such that dual/triple/multi cert regimes
 Peter> are required per se in the PKI, apparently.

 Peter> (b) There is no natural association between a public and those
 Peter> security mechanisms that require both public and symmetric
 Peter> algorithm support, from the claim.

That's not what I said.

 Peter> What is an example of (b)?

 Peter> PEM had a security mechanism, which required that the output
 Peter> of a private-key operation be ciphered in the DEK of the
 Peter> session to ensure that only the intended recipient was
 Peter> authorized to rely on the signature and/or learn the signature
 Peter> ciphertext/plaintext pair.

Fine.  But that's not what I was talking about.  You're talking about
the details of a particular key estabilishment protocol.  Clearly,
there you want to establish a binding between the possession of a
asymmetric system private key, and a newly established symmetric
session key.  What you described is one way to do that.  (IKE is an
example of a different protocol, one that doesn't do it in that way.)

What I meant: there is no cryptographic property of public keys that
associates them with symmetric ciphers.  The bits, or the mathematical 
definition, of an RSA key are entirely independent of any symmetric
cipher.  Indeed, if symmetric ciphers didn't exist at all, the public
key and certificates that talk about it would remain meaningful.

How far should PKIX go in adding application specific things to certs?
I find certs to be too big already, and would rather not see them
fatten even more.

	paul