Subject: RE: Associating symmetric algorithms with a public key

From: "Trevor Freeman (Exchange)" <[email-masked]>
Date: Tue, 16 Nov 1999 09:57:47 -0800

The set of application I see using this are not email clients. 
Do you have a specific objection for including this in son of 2459?
Trevor

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Tuesday, November 16, 1999 3:13 AM
To: Trevor Freeman (Exchange)
Cc: Pkix List (E-mail)
Subject: Re: Associating symmetric algorithms with a public key

Trevor,

I seem to recall an objection to doing this which was raised
by Jim Schaad in the SMIME wg, can't recall exactly what it
was though, or whether it applies in general, or just to
SMIME messaging.

Regards,
Stephen.

> "Trevor Freeman (Exchange)" wrote:
> 
> There are a number of applications which need a hint as to the set of
symmetric algorithms which
> can be used with a public key from a certificate for encrypting data with
asynchronous
> applications. There is a directory attribute defined in X.509 for defining
supported algorithms
> which can list a set of algorithms and parameters, but is not associated
with any particular
> key. Using this directory attribute in a certificate would seem to solve
the problem of binding a
> set of algorithms to a specific key.
> Any objections for this to be added to son of 2459? (apart from giving Tim
yet more work - sorry
> Tim)
> Trevor

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Stephen Kent <[email-masked]>
Date: Tue, 16 Nov 1999 19:14:26 -0500

Trevor,

I hate to see extra attributes added to certs. I appreciate the 
desire to give hints to a user re what symmetric algorithms that user 
might employ when communicating with a target user, identified by the 
certificate in question.  However, I'd rather see the LDAP & X.500 
folks provide better data structures for this in the directory, 
rather than adding a field that has only heuristic value to a cert. 
If these are only hints, not proscriptive, then we don't seem to be 
making a string security statement about them anyway.

Even if we agree that Steve's Rule of Revocation is closer to linear 
or log than quadratic, the principle still applies ...

Steve

---

From: Paul Koning <[email-masked]>
Date: Wed, 17 Nov 1999 09:41:47 -0500

>>>>> "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.

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.

	paul