Subject: RE: Associating symmetric algorithms with a public key

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

Now I get it even less, I think.

So if a cert said "DES" you could still use Blowfish to encrypt my
files?  I could still use CAST to protect my IPSEC sessions?

>>If the cert says DES, and you choose not to use DES, that is your
decision, its a big world, and you get to make you own choices, just don't
be surprised if only DES works.

If it's a "hint" that sounds like a user preference or application
interface default item.  You can put those things in your application
registry or in configuration files or user set-up scripts or stuff like 
that, but it definitely doesn't belong in a cert.

>>Putting it in the registry, local configuration file or set-up script does
not help me know what your preferences are, so it needs to be published. The
defined X.509 directory attribute, does not associate a public key with a
set of algorithms. 

Trevor

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 17 Nov 1999 09:14:16 -0500 (EST)

I recognize: 1) that specific implementations may have different supported
combinations of public and symmetric keys, 2) that there does not
appear to be a suitable directory attribute currently defined for expressing
public-symmetric capabilities, and 3) that putting a list of symmetric
algorithms in a PK cert would express the desired result.

However, I agree with Steve and Paul that this is a configuration option
which does not belong in a cert.

The supported algorithm combinations could change as soon as the user
changes to a different version of the application, changes to a different
crypto module, or even clicks on some check boxes.  As soon as the
user takes one of these actions, he would have to communicate the change
to his correspondents.  The easiest way is to push a notification, or to
post an update to a directory attribute.  The hardest way is to get a
new cert, because the new cert would still have to be pushed or posted.

The IETF way of ensuring interoperability is to designate a
mandatory-to-implement algorithm suite.  The sender can guarantee
that the receiver can decode the message by using that suite, without
needing any new capability negotiation mechanism.  To express additional
capabilities, you may need to just define a new directory attribute if
existing S/MIME or other attributes cannot do the trick.  I'm curious
why S/MIME hasn't needed to solve this problem yet, so that an attribute
defined there could be used to support other asynchronous protocols.

Dave Kemp

> From: "Trevor Freeman (Exchange)" <[email-masked]>
> To: "'Stephen Kent'" <[email-masked]>
> Cc: "Pkix List (E-mail)" <[email-masked]>
> Subject: RE: Associating symmetric algorithms with a public key
> Date: Tue, 16 Nov 1999 17:19:46 -0800
> 
> Hi Steve,
> 
> I am sympathetic to being careful as to what is in a certificate. 
> The main reason for saying they are a hint is that in the final analysis,
> this kind of thing can never be more than a hint with asynchronous
> protocols, so it really is a reality check. I am equally hesitant to yet
> again build a dependency on the directory, and I am equally unconvinced that
> it makes sense in this case to duplicate this information. This defined
> mechanism also give a clean package  of self contained data - wherever the
> certificate goes, so does the information regarding the associated symmetric
> algorithms. RFC2459 supports the use of directory attributes, this is a
> directory attribute so all we are doing in reality is clarifying and
> highlighting a potential application of this specific attribute. Adding it
> to the certificate also simplifies the semantics because key usage and
> policy are now inherited from the certificate so are not needed in the
> extension.
> 
> Trevor

---

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 16 Nov 1999 08:52:31 -0700

Trevor,

S/MIME defines and SMIMECapabilites parameter which is normally
sent in-line along with the certificates, and they are now proposing to 
put it in the directory as well.

Are these applications independent of S/MIME?  Should this capability 
be added to CMS instead of being S/MIME specific?

To what extent, and why, are these symmetric keys tied to a particulat public key?
Isn't this more likely to be a general client restriction?

I would understand, however, if you didn't want to use a 40-bit  RC2 key 
to respond to a triple-DES encrypted message using a 2048 bit RSA encryption 
key, as Outlook Express currently does.

Bob

>>> "Trevor Freeman (Exchange)" <[email-masked]> 11/15/99 05:03PM >>>
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

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 17 Nov 1999 13:19:55 -0500

Would n't the application protocol be the appropriate place to carry this
information.  For example, SIGNED MACRO carry the Algorithm OID.  Couldn't
application protocol carry the symmetric algorithm OID.  This also gives the
flexibility that the public key certificate can be used for key transfer (or
agreement) with a variety of symmetric algorithms.

-----Original Message-----
From: David P. Kemp [mailto:[email-masked]]
Sent: Wednesday, November 17, 1999 9:14 AM
To: [email-masked]
Subject: RE: Associating symmetric algorithms with a public key

Dave Kemp

---

From: Peter Williams <[email-masked]>
Date: Wed, 17 Nov 1999 10:25:32 -0800

This is my last, hopefully useful, contribution on the topic:

The discussion seemed to be begging the question: how
can a certificate-borne control signal be used
to limit the application of a given public key to
mechanisms/protocols which are built
from a combination of more basic cryptographic primitive
operations. Alternatively, how can an authority control that
one algorithm is used only in combination with
other prescribed algorithms, for a given public key.

We know that such a quite-proper (keyUsage) signal exists to 
limit the usage of public keys to particular public-key using 
security mechanisms.

Why should not a similar control signal exist to limit
the use of a public key for combination mechanisms each
faciliated by distinct, named algorithms?

Just as the constraint (a) exists mainly to engender a world 
of  strong and weak key management for signature vs encryption 
keys, so the control (b) would exist to allow CAs to prevent
you the user using RSA except with weak symmetric algorithms,
say, or require that AES is used only in combination with DSS, etc.

I dont thing raw math properties come into this: it seems to be
about the desire and flexibility to assert control over the 
combination of algorithms  - presumably to engender assurance, 
or enable the imposition of national or cultural policies
for combined crypto-use. PKIX authors were complicit in 
the imposition of (a) on the Internet, why not (b)?

Remember, PKI is no longer an authentication framework. Its
primarily a framework for imposing centralized control, so
as to effect policy-based crypto management, and enable
authorities to assert their power to limit what users
can do with interoperable cryptography - once such
easy interoperability is faciliated by the use of PKI. 

Controlling the "appropriate/legitimate" combination of multiple 
algorithms could be seen as an important, missing element of 
infrastructure assurance.

> From: Paul Koning [mailto:[email-masked]]
> Sent: Wednesday, November 17, 1999 9:49 AM
> To: [email-masked]
> Cc: [email-masked]
> >>>>> "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
>

---

From: "Trevor Freeman (Exchange)" <[email-masked]>
Date: Wed, 17 Nov 1999 10:42:08 -0800

Bob,
This is not directly related to CMS, but it still begs the question of
distribution of information. I am also thinking of other application, not
just CMS. 

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Tuesday, November 16, 1999 7:53 AM
To: Trevor Freeman (Exchange); [email-masked]
Subject: Re: Associating symmetric algorithms with a public key

Trevor,

To what extent, and why, are these symmetric keys tied to a particulat
public key?
Isn't this more likely to be a general client restriction?

Bob

---

From: "Trevor Freeman (Exchange)" <[email-masked]>
Date: Wed, 17 Nov 1999 10:51:56 -0800

I have seen no solutions to this issue for applications who are not LDAP
aware, and many may hold LDAP support as being a good idea, is not
mandatory. 
I accept that directory publication is more flexible, however there does
seem to be agreement that the current attribute in X.509 does not express
the necessary relationship.
If different applications all can use the same certificate, while having
different sets of symmetric algorithms, how is such a requirement to be met
in the LDAP case without introducing a management issue, and unnecessary
duplication?