ietf-smime
[Top] [All Lists]

RE: Issues with Enhanced Security Services for S/MIME (ESS-01)

1998-01-14 21:05:59
I had a conversation with John Pawling and we have agreed on the
following changes to my original proposal.



-----Original Message-----
From: Jim Schaad (Exchange) 

5.  Section 1.3.4. - Last paragraph :  Change the last sentence to
"These attributes are required and must be in the authenticated
attribute section if a receiptRequest attribute is present."

5.  Section 1.3.4 Last paragraph:  Delete the last sentence in the
paragraph.  The original purpose of the sentence was to justify the
inclusion of the rest of the paragraph and probably should not have been
included.  The same material is actually in the receipt request so they
do not need to be authenticated.


6.  Section 2.2.1 - Some issues regarding the existence of multiple
SignerInfo's with receipt requests.
      A.  Add the following text to paragraph 3. "If ReceiptRequest
are present which conflict, no receipt is to be returned."
      B. If there are multiple signerInfos, and I can understand but
cannot verify all of the signatures.  Do I send a receipt.  My
assumption is "New Paragraph(?)  A receipt must be returned if any
signature containing a receipt request can be validated, even if other
signatures containing the same receipt request cannot be validated."

6.  These modifications (or equal text) should actually be applied to
Section 2.3 not section 2.2.1.  Paul, if you want words I'll get them to
you next week when I have the document in front of me again.


7.  Section 2.5  -- Who does a receipt get sent to?  It dawned on me
that I was assuming that a receipt is returned to the RFC-822 
From field
(reply-to?) in the message.  I don't know that is true any more with
multiple signerInfos.  Is the receipt mailed to the 
transport's idea of
who sent the message, or according to the 
subject/subjectAltName in the
certificate which was used to create the signature?

7.  After talking with John, and in light of some of the other
converstions we have been in recently, I propose the following changes:

A.  The ASN for ReceiptRequest is modified so that receiptsTo is no
longer optional.
B.  Text describing receiptsTo should be modified so that the receipt
requestor is required to place their address in the field so that the
return location of the receipt is always known and authenticated.
C.  Section 2.5 step 1 would be modified so that the list of receipts is
always initialized from the receiptsTo field since it is always present.


8.  Section 2.7 -- It is nice to know that I should not use 0 or 1 for
BuildinContentType.  The problem is that I don't know  what I 
SHOULD put
in to this field.  perhaps I'll always leave it blank from 
fear of being
wrong.  Can we get some type of description or verify specific pointer
to what does go into this field.  So far the best I have is from John
where he said "Oh -- if you were using this in X400 it make 
more sense."

Add the following paragraph to section 2.7

Unless the data to be placed in the encapsulatedContentType field has
been profiled to be different in your operating environment, the
internal content type should be placed in the ExternalContentType choice
of EncapsulatedContentType.

New item:

Insert a new pargraph 3 in section 4.2

When the MLA creates the new attribute list for its signature, the MLA
MUST propigate forward all attributes in the old signature unless it
explicitly replaces the attribute with a new value.  MLA will frequently
encounter attributes, or protions of attributes which it does not
understand.  Attributes should as security labels cannot be removed from
the new signature being created without compromising the security of the
system.  As it is impossible to enumerate the future list of attributes
which have security implicitions, MLA must propigate forward all
attributes which it does not explicity replace (such as the message
digest attribute).

jim

<Prev in Thread] Current Thread [Next in Thread>