Subject: Open Issues on <draft-ietf-mmusic-sap-sec-01.txt>

From: Edmund Whelan <[email-masked]>
Date: Mon, 16 Jun 1997 14:54:53 +0100

We are in the process of preparing the new draft of the above document, and
wish to solicit concerns.

 The minutes show the following:

Colin Perkins presented an overview of and open issues for the I-D 
"Specification of Security in SAP Using Public Key Algorithms" aka "SAP 
Security."  See the accompanying slides sap_security.ps.  SAP itself provides 
authentication hooks; this document attempts to define mechanisms that can be 
put on those hooks.  Open issues included whether the key id field in the SAP 
header was required: it was felt that this could move into a specific 
authentication block as both PGP and PKCS#7 have key id fields.  Discussion of
the need to define a standard privacy header, and whether the simple public key
format defined in the document (simplified form of PKCS#7) or full PKCS#7 (or 
both) should be used was deferred to discussion on the mailing list.

We propose a number of changes:

 - There should be a section explaining asymmetric encryption systems

 - There should be substantially more explaining the use of Session Encryption
   Keys with symmetric encryption for all the key exchange mechanisms

 - More rationale should be given about use of Session Encryption Keys and
   their distribution

 - There should be a Privacy Header - but only if strong encryption is used -
   with the Session Encryption Key encrypted with a strong algorithm, either
   symmetric (eg Triple DES) or asymmetric (PGP or PKCS#7).

 - We use the full PKCS#7 - even though it requires ASN.1 encoding. This
   means that S-MIME and PGP code can be used directly.

 - We plan to re-introduce complete certificates for Public Keys; there is no
   agreed Standard on using anything but full certificates to circulate such
   keys.

 - There is a better discussion of PKCS#7.

 - There is discussion of a Privacy Header, which is needed only if strong
   encryption is used to distribute the Session Encryption Key.

 - Better details are given on the Privacy Header.

 - We have removed any need to have the Privacy Header impact preceeding ones
   This Header determines whether PGP, PKCS#7 or strong encryption are used 
   for privacy.

We will be circulating the draft shortly; are there any generic points that
we have missed?

               Peter Kirstein and Edmund Whelan

---

From: Mark Handley <[email-masked]>
Date: Mon, 16 Jun 1997 11:33:08 -0400

>wish to solicit concerns.
...
>We propose a number of changes:

In principle these sound OK, but there isn't really enough detail to
be sure.

>   symmetric (eg Triple DES) or asymmetric (PGP or PKCS#7).

The SAP encryption model is that key distribution occurs out of band
along with information about *precisely* which encryption scheme is
used.  

So I wonder what your privacy header does.  If it is to identify which
encryption scheme is in use, then this does not seem a good idea.  If
it attempts to define a "standard" way of carrying a symmetric
encryption key encrypted with a public key scheme, then this seems OK.
Clearly the latter is not required with Triple-DES, so I fear you mean
the former.

Please elaborate...

>   agreed Standard on using anything but full certificates to circulate such

I didn't understand the context of this - presumably you're not
talking about encryption here but authentication.  What is the
overhead imposed?  We abandoned the idea of using complete
certificates in the SAP packet for authentication originally because
we couldn't afford the space for an arbitrary length certificate.

Mark

---

From: Peter KIRSTEIN <[email-masked]>
Date: Mon, 16 Jun 1997 23:23:55 +0100

>along with information about *precisely* which encryption scheme is
No, that is the model of the symmetric encryption, for which you and
Van  do not want to see any information about the encryption used. In
our modification af the previous draft, we have included versions of
hybrid information, in which there is no reason not to give some
information about the aynchronous key in the SAP announcement. I would
be interested to your reading both the reasons for our use of hybrid
encryption, and that it deals with your objections.

>Clearly the latter is not required with Triple-DES, so I fear you mean

This is dealt with in the paper, so again, I welcom comments.
>we couldn't afford the space for an arbitrary length certificate.
I had always worried about this aspect in the authentication header.
Ed tod me that no objection had been raised to this aspect of the
authentication section of the paprevious draft of the papser. I am
writing this on a slow terminal, so please excuse erros.  We have
dealt with the need to have short cerrtifications paths to keep
certificates short. If you do not like that, we canalways use
certificate identifiers in the authentication header - though that is
not standard for PGP - but I do not care..

I think after you have read the current version, we should discuss it
either by a video conference or telephpne. I may find this difficult
while in the US. Iam back in Lonodn ony at the beginning of July - but
will read mail later this week.

On another matter, I hope that it will be possible to organise a day
meeting with you and Steve McCanne around the ACM meeting in NICER. It
woudl be ideal if that meeting was in London, but we could maek it
Cannes if you really wanted.

Peter