Subject: RE: RecipientInfo vs SignerInfo key identification

From: "Jim Schaad (Exchange)" <[email-masked]>
Date: Mon, 23 Nov 1998 10:12:09 -0800

I would not be againist the addition of SKI in CMS, but if that was done
then I believe that the S/MIME message draft would be required to add a MUST
NOT on its use.  The addition of SKI would make sense for other groups
without the history of PKCS#7 already deployed to use.

jim

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Monday, November 23, 1998 8:16 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: RecipientInfo vs SignerInfo key identification

Peter:

The addition of SubjectKeyIdentifier to SignerInfo was considered.  Many
developers felt that backward compatibility with PKCS#7 v1.5 and S/MIME v2
was more important that the shorter certificate reference.

It woulf be very easy to add SubjectKeyIdentifier to SignerInfo if the
group concensus has changed.

Russ

At 03:10 AM 11/23/98 +0000, Peter Gutmann wrote:
>I've noticed that RecipientInfo identifies a key with a CHOICE between 
>IssuerAndSerialNumber and SubjectKeyIdentifier, but SignerInfo only allows 
>IssuerAndSerialNumber.  Presumably whatever reason requires the SKI in the 
>RecipientInfo should also require it in the SignerInfo, could these be
merged 
>to create a unified identifier type (ie they both use a RecipientInfo-style

>CHOICE)?
>Peter.

---

From: "Blake Ramsdell" <[email-masked]>
Date: Mon, 23 Nov 1998 13:31:52 -0800

> was more important that the shorter certificate reference.

When was this considered?  I can't find a discussion about it in the past
(of course, that refers more to my blindness than anything else.)

> group concensus has changed.

It seems that you can tick the version number as we do if ACs or
encapsulated content other than id-data is present.

I really don't recall discussing this, and it seems that certificate
references should be the same across the board.  I do agree that backward
compatibility is paramount, and we can accomplish that by using the version
number tick that we are already using for other non-backward-compatible
things.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

---

From: "Blake Ramsdell" <[email-masked]>
Date: Mon, 23 Nov 1998 14:56:03 -0800

> From: Jim Schaad (Exchange) [mailto:[email-masked]]
> Sent: Monday, November 23, 1998 2:47 PM
> To: Blake Ramsdell; 'Russ Housley'; [email-masked]
> Cc: [email-masked]
> Subject: RE: RecipientInfo vs SignerInfo key identification
> 
> These discussions occured when we were still meeting in San 
> Fransico.  If we
> allow for this to occur in the S/MIME world we immeadiately 
> hit the demon of
> backwards compatability.  I don't know about your product, 
> but ours does not
> look at capabilites of recipients when sending signed mail.  
> Thus we MUST
> use the Issuer/Serial Number identification as we have no idea if the
> receiving client has the ability to understand anything new.

Isn't this a problem if you have attribute certificates or secure return
receipts also?  These features will not be supported by v2 clients either
(and will cause a similar interoperability problem).

Likewise, the RecipientInfo changes for this same purpose seem to have
exactly the same problem (and we got around this by ticking the version
number), so the demon is still with us.

I personally don't want this changed, but I wanted to make sure I understood
the arguments against it.

Blake

---

From: "Jim Schaad (Exchange)" <[email-masked]>
Date: Mon, 23 Nov 1998 14:47:19 -0800

Blake,

These discussions occured when we were still meeting in San Fransico.  If we
allow for this to occur in the S/MIME world we immeadiately hit the demon of
backwards compatability.  I don't know about your product, but ours does not
look at capabilites of recipients when sending signed mail.  Thus we MUST
use the Issuer/Serial Number identification as we have no idea if the
receiving client has the ability to understand anything new.

This is a fine change for CMS but verboten for S/MIME

jim

-----Original Message-----
From: Blake Ramsdell [mailto:[email-masked]]
Sent: Monday, November 23, 1998 1:32 PM
To: 'Russ Housley'; [email-masked]
Cc: [email-masked]
Subject: RE: RecipientInfo vs SignerInfo key identification

Blake

---

From: "Jim Schaad (Exchange)" <[email-masked]>
Date: Mon, 23 Nov 1998 15:08:12 -0800

While it is true that the inclusion of attribute certificates will cause
this problem, that is going to be a rare item in the current world.  This is
going to generally be in closed (or semi-closed) rollouts and not hit the
internet in general.

Existing clients will be able to read messages which include secure receipt
requests, they would not generate a return receipt.  There may also be some
issues about current clients reading an acutal receipt, but that is the
unexpected not expected case.

jim

-----Original Message-----
From: Blake Ramsdell [mailto:[email-masked]]
Sent: Monday, November 23, 1998 2:56 PM
To: Jim Schaad (Exchange); 'Russ Housley'; [email-masked]
Cc: [email-masked]
Subject: RE: RecipientInfo vs SignerInfo key identification

Blake