ietf-smime
[Top] [All Lists]

Re[5]: 2nd S/MIME BOF meeting minutes

1997-04-16 05:28:06
     Why do we need to put all the mail capabilities in the certificate ?
     Why not separate the fact that I have RSA and put that somewhere in 
     the message header for the recipient (and everybody, I do not care) to 
     see ???
     
     David Gaon


______________________________ Reply Separator _________________________________
Subject: RE: RE: Re[2]: 2nd S/MIME BOF meeting minutes
Author:  Blake Ramsdell <BlakeR(_at_)deming(_dot_)com> at smtp
Date:    4/16/97 6:42 AM


I think the problem here is if you put information about your mail 
capabilities in your certificate, then when your mail capabilities 
change, your certificate changes.
     
Blake
     
-----Original Message-----
From: Geoff Klein [SMTP:geoff(_at_)commtouch(_dot_)co(_dot_)il] 
Sent: Tuesday, April 15, 1997 3:45 PM
To: spock(_at_)RSA(_dot_)COM; ietf-smime(_at_)imc(_dot_)org; 
gaond(_at_)ncr(_dot_)disa(_dot_)mil 
Subject: Re: RE: Re[2]: 2nd S/MIME BOF meeting minutes

-----BEGIN PGP SIGNED MESSAGE-----

Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

To: spock(_at_)RSA(_dot_)COM, ietf-smime(_at_)imc(_dot_)org, 
gaond(_at_)ncr(_dot_)disa(_dot_)mil 
Date: Tue Apr 15 22:44:56 1997


In the world of peer-to-peer store-and-forward communications (e.g. 
email) there really is no negotiation possible at "start of
communications".  This is especially evident in the case of a multicast 
message, i.e. sending a message to a bunch of recipients.

In such an environment, negotiation can be done either out of band 
beforehand (e.g. by looking up some entries in a directory) or via
exchange of email by the end users who are not always savvy enough to 
effectively negotiate encryption algorithms and key sizes.  It was our 
intent when creating S/MIME to provide some base level of
interoperability possible among all S/MIME-enabled user agents (i.e. 
the "MUSTS") and an easy path to negotiating the use of the strongest 
possible encryption where both ends are capable (i.e. the "SHOULDS"). 

-steve

Since certificates are in any case a prerequisit, supported/prefered 
algorithms could be published as extended properties of an X509.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQCVAwUBM1PozULv5OMYFK1FAQH6nQP+OQf1E2yJ0JgfRGkLBvbh4zAzTgd23le6 
FMj4HHQPNV8zHbHFTpby8QVzrb/i4Ufx0IVQpQyKRfeaXrzcF4D3lKuQ/sqfWYUZ 
miYKo/M64iO8Y8Dgcc5JQmOPiV1U+GlYje39S4iOjJ4yjDr+WODS1kuL6h4FPl2y 
iM80oZ0XvHE=
=VD0l
-----END PGP SIGNATURE-----