RE: More examples-05 issues

["Pawling, John" <John.Pawling@xxxxxxxxxxxxxxxx>]

Magnus,

Thank you for your feedback.  I agree that the section 6.2 sample message
should not include OriginatorInfo or unprotected attributes.  I agree that
it is useful to have a sample message using RSA for key management and
TripleDES for content encryption that minimizes the inclusion of optional
fields.  We will re-generate the 6.2 sample message and provide to the list.

===========================================
John Pawling, John.Pawling@xxxxxxxxxxxxxxxx
Getronics Government Solutions, LLC
===========================================


-----Original Message-----
From: Magnus Svensson [mailto:magnus@xxxxxxxxxxxx]
Sent: Thursday, January 18, 2001 8:48 AM
To: 'Pawling, John'; ietf-smime-examples@xxxxxxx
Subject: RE: More examples-05 issues


John,

After investigating your new 6.2 example I found that it has an
OriginatorInfo structure, and thus contradicting the draft description of
the example. The draft description is included below for reference:

----
6.2 Basic encrypted content, TripleDES and RSA

Same as 6.1, except with RSA for key management. An EnvelopedData from
Alice to Bob of ExContent using TripleDES for encrypting and RSA for
key management. Does not have a OriginatorInfo, and has unprotected
attributes."
----

Furthermore the OriginatorInfo contains DSS certificates & CRLs for Alice
and Carl. This is obvously of not much use since the example uses RSA for
key management.

In my opinion the 6.1 and 6.2 examples should not contain any optional
information fields since they are basic examples. They should just stick to
the basic requirements. If the unprotected attributes are also removed from
the example it would actually also be backwards compatible to the PKCS#7
spec. Do you agree with me John? This is just my personal opinion, but the
inconsistency with the OriginatorInfo field needs to be solved anyway.

Regards,
Magnus