Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
From: "Bonatti, Chris" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 31 Mar 1998 18:21:45 -0500

Tim Dean wrote:

> 2. I am somewhat doubtful that access control in the recipient's user agent is going to add a jot of Real
> Security in practice.  It would surely be extremely unwise to place any kind of reliance on it.  Any
> Computer Scientist worth his salt is quickly going to figure how to by-pass this check and read
> everything which arrives in his computer.  (And he is probably the kind of person you didn't want to
> unintentionally send a message to anyway!)
>

This is certainly true.  I too wonder about the value of rules-based access control in a off-the-shelf product.  I suspect that the realities of commercial implementations would make it difficult to establish any trust in recipient RBAC processing.

Chris

Date: Tue, 31 Mar 1998 00:35:09 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: DH mechanism?
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

This part of the specification is still being written. 

Russ

At 08:01 PM 3/30/98 +0000, Dr Stephen Henson wrote:
>Is the way in which DH is used for v3 S/MIME enveloped modes documented
>anywhere? I've read PKCS#3 and the S/MIME specs but this leaves some
>questions unanswered.
>
>Do the sender and recipient use two fixed keys (presumably as part of
>certificates) with a common set of parameters or does the sender
>generate a random one-time session key pair for the recipients
>parameters?
>
>Steve.
>-- 
>************************************************
>* Dr Stephen N. Henson.                        *
>* Freelance Cryptographic Consultant.          *
>* Email: [email-masked]                   * 
>************************************************
> 

From: Tim Dean <[email-masked]>
To: John Ross <[email-masked]>, "'Russ Housley'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Signed Label (was RE: 'Signature Purpose' attribute?)
Date: Tue, 31 Mar 1998 10:28:11 +0100
Sender: [email-masked]

Russ,
>>What happens if a recipient receives a forwarded message that include a
>>security policy in the eSSSecurityLabel  that he/she in does not understand,
>>is that still an error?

>Absolutely.  The security label must be marked critical, so the inability
>to process the critical attribute must cause an error to be reported to the
>user.

>>I think the proposed text will mislead implementations to always discarding
>>the message if a security policy is unknown.  I do not think that is right.

>We disagree.  Rule-based access control cannot be enforced if the recipient
>is allowed to ignore the security label.

Two thoughts:

1.  Insisting that the UA software parse and understand the label before showing the message to the user 
raises serious denial-of-service issues.  There are many circumstances when operational necessity 
demands label-based access control is over-ridden - certainly on reception in a distributed system.  
There are likely to be many, many label formats floating around out there, and systems should not stop 
working just because they don't recognise all of them. 

2. I am somewhat doubtful that access control in the recipient's user agent is going to add a jot of Real 
Security in practice.  It would surely be extremely unwise to place any kind of reliance on it.  Any 
Computer Scientist worth his salt is quickly going to figure how to by-pass this check and read 
everything which arrives in his computer.  (And he is probably the kind of person you didn't want to 
unintentionally send a message to anyway!)

Therefore I think I must agree with John R's suggestion on this: or at least make the it a configurable 
option dependent on security policy.  Also, ESS should probably contain a health warning about relying 
on recipient side access control processing.  By all means check message labels on transmission and at 
points along the path: for example just before the message is about to exit your organisation.  Hopefully 
the label semantics are understood at least that far.  After that I suspect it may be too late.

Tim

-----------------------------------------------
Tim Dean
Defence Evaluation & Research Agency
Malvern
United Kingdom
telephone:      +44-1684-894239
facsimile:      +44-1684-896113
e-mail:         [email-masked]
----------------------------------------------------

John Ross wrote:
>What happens if a recipient receives a forwarded message that include a
>security policy in the eSSSecurityLabel  that he/she in does not understand,
>is that still an error?

Absolutely.  The security label must be marked critical, so the inability
to process the critical attribute must cause an error to be reported to the
user.

>I think the proposed text will mislead implementations to always discarding
>the message if a security policy is unknown.  I do not think that is right.

We disagree.  Rule-based access control cannot be enforced if the recipient
is allowed to ignore the security label.

>All I think needs to be done is to leave such decisions to local policy;
>Thus reword your text as..
>
>"Receiving agents SHOULD have a local policy which specifies
>what action is taken when an eSSSecurityLabel is received which
>includes a security-policy-identifier that the processing software
>does not recognize."
>
>
>If think there is a need to specify default handling, then It should be to
>ignore security labels when the policy is not understood.

Completely disagree!

>Also, I still think that the security policy should not be optional.

Wow.  We agree on this one.  The syntax that we are using comes from X.411.
 In X.411, this field is optional, and we are trying to maintain
compatibility.  I suggest that we use english text to state that the
security policy must be present.

-- Russ

Date: Tue, 31 Mar 1998 00:02:57 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Triple-DES Key Wrapping
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

Dr Henson:

Thanks for looking at the 3DES key wrap proposal.

I looked at PKCS#5.  It seems to me that the password-based-encryption
defined in PKCS#5 is not suitable.

I do not think that the parity bits in the key bytes do not provide
sufficeint integrity.  There is no information to ensure that the bytes are
in the correct order.

Additionally, I defined a key wrap algorithm that is smaller that the
alternative you proposed.  It seems to me that we should not make the
wrapped key any bigger than necessary.

I did not invent the sum-of-sums checksum proposed.  This integrity
function has had quite a bit of analysis, and the result is very small when
compared to a hash function.

Russ

Dr Stephen Henson wrote:
>The obvious method (to me at least) is to use triple DES CBC with PKCS#5
>padding. On the face of it the parity checks over 24 bytes and padding
>gives a better than 1 in 2^32 chance of random data failing the test.
>
>I suppose the only issue is where the inner IV comes from. Any reason
>why the outer IV (from the AlgorithmIdentifier) can't be used twice?
>
>Failing that the inner key could be the DER encoding of something
>analagous to a DigestInfo structure containing the encryption algorithm,
>IV and key. If you do things that way you automatically get something
>that should work with all algorithms and doesn't require that the inner
>and outer encryption algorithms be the same. You also get a kind of
>inbuilt integrity check because any corruption/tampering is likely to
>result in an invalid encoding.
>
>In any case why does another checksum need to be devised? We already
>have some pretty good checksums and ways of presenting them with digest
>algorithms and DigestInfo structures.
>
>Steve.
>-- 
>************************************************
>* Dr Stephen N. Henson.                        *
>* Freelance Cryptographic Consultant.          *
>* Email: [email-masked]                   * 
>************************************************
> 

Date: Mon, 30 Mar 1998 11:17:26 -0500
To: John Ross <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Cc: [email-masked]
Sender: [email-masked]

John Ross wrote:
>What happens if a recipient receives a forwarded message that include a
>security policy in the eSSSecurityLabel  that he/she in does not understand,
>is that still an error?

Absolutely.  The security label must be marked critical, so the inability
to process the critical attribute must cause an error to be reported to the
user.

>I think the proposed text will mislead implementations to always discarding
>the message if a security policy is unknown.  I do not think that is right.

We disagree.  Rule-based access control cannot be enforced if the recipient
is allowed to ignore the security label.

>All I think needs to be done is to leave such decisions to local policy;
>Thus reword your text as..
>
>"Receiving agents SHOULD have a local policy which specifies
>what action is taken when an eSSSecurityLabel is received which
>includes a security-policy-identifier that the processing software
>does not recognize."
>
>
>If think there is a need to specify default handling, then It should be to
>ignore security labels when the policy is not understood.

Completely disagree!

>Also, I still think that the security policy should not be optional.

Wow.  We agree on this one.  The syntax that we are using comes from X.411.
 In X.411, this field is optional, and we are trying to maintain
compatibility.  I suggest that we use english text to state that the
security policy must be present.

-- Russ

Date: Mon, 30 Mar 1998 15:01:22 -0500 (EST)
From: Bancroft Scott <[email-masked]>
To: Scott Hollenbeck <[email-masked]>
Cc: "'IETF S/MIME'" <[email-masked]>
Subject: Re: ESS-04 ESSSecurityLabel Tags
Sender: [email-masked]

On Mon, 30 Mar 1998, Scott Hollenbeck wrote:

> The ESSSecurityLabel structure includes two INTEGER types:
> 
>   version Version DEFAULT v1
> 
> and
>   security-classification SecurityClassification OPTIONAL
> 
> when an optional security classification is present, don't we have
> a tagging problem within the ESSSecurityLabel SET?  Shouldn't one of
> these INTEGER types include a context specific tag, such as
> 
>   security-classification [0] SecurityClassification OPTIONAL
> 
> I believe we do have an ambiguous tag situation, and would propose
> that the security-classification definition be changed to include
> a context specific tag as defined above.

Correct, the ASN.1 is ambiguous without the tag being present.
A change of the sort that you recommend is required.

--------------------------------------------------------------------------
Bancroft Scott                                Toll Free    :1-888-OSS-ASN1
Open Systems Solutions, Inc.                  International:1-609-987-9073
[email-masked]                                  Tech Support :1-732-249-5107
http://www.oss.com                            Fax          :1-732-249-4636

Date: Mon, 30 Mar 1998 20:01:42 +0000
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: DH mechanism?
Sender: [email-masked]

Is the way in which DH is used for v3 S/MIME enveloped modes documented
anywhere? I've read PKCS#3 and the S/MIME specs but this leaves some
questions unanswered.

Do the sender and recipient use two fixed keys (presumably as part of
certificates) with a common set of parameters or does the sender
generate a random one-time session key pair for the recipients
parameters?

Steve.
-- 
************************************************
* Dr Stephen N. Henson.                        *
* Freelance Cryptographic Consultant.          *
* Email: [email-masked]                   * 
************************************************

From: Scott Hollenbeck <[email-masked]>
To: "'IETF S/MIME'" <[email-masked]>
Subject: ESS-04 ESSSecurityLabel Tags
Date: Mon, 30 Mar 1998 10:27:46 PST
Sender: [email-masked]

The ESSSecurityLabel structure includes two INTEGER types:

  version Version DEFAULT v1

and
  security-classification SecurityClassification OPTIONAL

when an optional security classification is present, don't we have
a tagging problem within the ESSSecurityLabel SET?  Shouldn't one of
these INTEGER types include a context specific tag, such as

  security-classification [0] SecurityClassification OPTIONAL

I believe we do have an ambiguous tag situation, and would propose
that the security-classification definition be changed to include
a context specific tag as defined above.

----->
Scott Hollenbeck (mailto:[email-masked])
Xerox Special Information Systems
Arlington, Virginia, USA

From: "John Ross" <[email-masked]>
To: "Sean Turner" <[email-masked]>, "John Pawling" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: ESSSecurityLabel Comments
Date: Mon, 30 Mar 1998 15:59:23 -0800
Sender: [email-masked]

I can agree to that.

-----Original Message-----
From: Sean Turner <[email-masked]>
To: John Pawling <[email-masked]>
Cc: [email-masked] <[email-masked]>; John Ross <[email-masked]>
Date: Monday, March 30, 1998 6:49 AM
Subject: Re: ESSSecurityLabel Comments

>John
>
>Instead of actually changing the syntax you could just as easily put in the
text to indicate that the security policy oid is always required.  One less
change to the existing syntax.
>
>spt
>
>John Pawling wrote:
>>
>> All,
>>
>> We need to add a context-specific tag to the ESSSecurityLabel version
field
>> because there are two INTEGERs in the SET.  In order to keep the tags in
>> numerical order, recommend that ESSPrivacyMark utf8String should be
changed
>> to "[1]" and then "[0]" can be used for ESSSecurityLabel version.  This
>> results in the following:
>>
>> ESSSecurityLabel ::= SET {
>>   version                    [0] Version DEFAULT v1,
>>   security-policy-identifier     SecurityPolicyIdentifier OPTIONAL,
>>   security-classification        SecurityClassification OPTIONAL,
>>   privacy-mark                   ESSPrivacyMark OPTIONAL,
>>   security-categories            SecurityCategories OPTIONAL }
>>
>> ESSPrivacyMark ::= CHOICE {
>>     pString                      PrintableString (SIZE
>> (1..ub-privacy-mark-length)),
>>     -- If pString is used, the ESSSecurityLabel version is set to v1
>>     utf8String               [1] IMPLICIT OCTET STRING SIZE (1..MAX)
>>     -- If utf8String is used, its contents MUST be in UTF8 format, and
>>     -- the ESSSecurityLabel version is set to v2
>> }
>>
>> ================================
>> John Pawling, [email-masked]
>> J.G. Van Dyke & Associates, Inc.
>> www.jgvandyke.com
>> ================================
>

Date: Mon, 30 Mar 1998 09:44:53 -0500
To: "Bonatti, Chris" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Chris:

The intent is not that the inner and outer labels will be identical.  The
outer label specifies the handling of the ciphertext.  In some
environments, the sensitivity of the data may warrant handling restrictions
of ciphertext.  On the other hand, the inner label specifies the handling
of the plaintext.  I expect this label will be present more often than the
outer label.  The inner label should not be transmitted in the clear, that
is why it is covered by EnvelopedData.  If the inner label is transmitted
in the clear, it tells a passive wiretapper which messages contain "the
good stuff."  In other words, it allows an attacker to focus their
cryptoanalytic attack.

Russ

Bonatti, Chris wrote:
>John Pawling wrote:
>
>> Chris,
>>
>> I respectfully disagree with your proposal.  The two different labels that
>> you require can be implemented by including each label in a separate
>> signedData layer of the message.  The original signer could include the
>> "information label" in the original, inner signedData layer.  The "system
>> label" could be included in an outer signedData layer that encapsulates the
>> original, inner signedData layer.  This is the optimal strategy because the
>> recipient MUST make a separate access control decision for each of the
>> signedData layers.
>
>John,
>
>    This is a GROSSLY inefficient means of addressing this requirement.
In the common case where both labels are applied by the originating user,
this means double signature generation operations, double signature
verification operations, plus a bunch of extra attribute and ASN.1
overhead.  All that is required to address this is either:
>
>        a)    An identical label attribute, with a distinct OID.
>               Said attribute to be ignored for the purpose of
>               access control.
>
>        b)    A more complex structure WITHIN the existing
>                label attribute that would allow the information
>                label to be conveyed (and ignored).
>
>What I proposed in my original submission was (b) above, but I really
don't have a strong preference.
>
>    Also, applying an access control check for the information label is
not required or even useful.  In the system-high scenario to which this
applies, the information security label will always be dominated by the
system security label.
>
>
>> The recipient MUST process the eSSSecurityLabel in each
>> signedData object that it verifies.  Because the recipient will verify both
>> the outer and inner signedData objects, then it MUST process the
>> eSSSecurityLabel attribute in each of the signedData objects.  Therefore,
>> both the "system" and "information" eSSSecurityLabels are processed by the
>> recipient.  An important point to note is that the recipient software makes
>> a separate access control decision for each signedData object.  IMHO, that
>> is the primary difference between processing
>> eSSSecurityLabels included in layered signedData objects versus those
>> included in multiple signerInfos included in the same signedData object.
>
>    I am not even convinced that you need to have the two labels in
different signerInfo elements.  Provided that they are both applied by the
originator, then there is no need for a second signature.
>
>> In the latter case, all eSSSecurityLabels included in the various
signerInfos
>> (that are verified) are checked as part of the same cumulative access
>> control decision process applied to the individual signedData object.  If
>> multiple eSSSecurityLabels were allowed in the same signerInfo or same
>> signedData, then there would be mass confusion and room for contradiction
>> when different labels are processed by the recipient as part of the same
>> cumulative access control decision applied to the individual signedData
>> object.

>
>    Again, you are assuming that the information label would be part of
the ACDF.  I'm not convinced that this is necessary.
>
>> I believe that it is impractical to try to force the S/MIME
>> community into accepting a complicated access control decision strategy
such
>> as would be required to define the rules to process multiple
>> eSSSecurityLabels included in the same signerInfo or same signedData.
>>
>> IMHO, the cost in efficiency of requiring nested signedData objects to
>> convey multiple, different eSSSecurityLabels is well worth the clarity
gained.
>>
>> In summary, I believe that the ESSSecurityLabel should remain as is.
>
>Chris sends...
> 

Date: Mon, 30 Mar 1998 08:39:59 -0500
From: Sean Turner <[email-masked]>
Organization: IECA, Inc.
To: John Pawling <[email-masked]>
CC: [email-masked], John Ross <[email-masked]>
Subject: Re: ESSSecurityLabel Comments
Sender: [email-masked]

John

Instead of actually changing the syntax you could just as easily put in the text to indicate that the security policy oid is always required.  One less change to the existing syntax.

spt

John Pawling wrote:
> 
> All,
> 
> We need to add a context-specific tag to the ESSSecurityLabel version field
> because there are two INTEGERs in the SET.  In order to keep the tags in
> numerical order, recommend that ESSPrivacyMark utf8String should be changed
> to "[1]" and then "[0]" can be used for ESSSecurityLabel version.  This
> results in the following:
> 
> ESSSecurityLabel ::= SET {
>   version                    [0] Version DEFAULT v1,
>   security-policy-identifier     SecurityPolicyIdentifier OPTIONAL,
>   security-classification        SecurityClassification OPTIONAL,
>   privacy-mark                   ESSPrivacyMark OPTIONAL,
>   security-categories            SecurityCategories OPTIONAL }
> 
> ESSPrivacyMark ::= CHOICE {
>     pString                      PrintableString (SIZE
> (1..ub-privacy-mark-length)),
>     -- If pString is used, the ESSSecurityLabel version is set to v1
>     utf8String               [1] IMPLICIT OCTET STRING SIZE (1..MAX)
>     -- If utf8String is used, its contents MUST be in UTF8 format, and
>     -- the ESSSecurityLabel version is set to v2
> }
> 
> ================================
> John Pawling, [email-masked]
> J.G. Van Dyke & Associates, Inc.
> www.jgvandyke.com
> ================================

Date: Mon, 30 Mar 1998 13:39:51 +0000
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Re: Triple-DES Key Wrapping
Sender: [email-masked]

The obvious method (to me at least) is to use triple DES CBC with PKCS#5
padding. On the face of it the parity checks over 24 bytes and padding
gives a better than 1 in 2^32 chance of random data failing the test.

I suppose the only issue is where the inner IV comes from. Any reason
why the outer IV (from the AlgorithmIdentifier) can't be used twice?

Failing that the inner key could be the DER encoding of something
analagous to a DigestInfo structure containing the encryption algorithm,
IV and key. If you do things that way you automatically get something
that should work with all algorithms and doesn't require that the inner
and outer encryption algorithms be the same. You also get a kind of
inbuilt integrity check because any corruption/tampering is likely to
result in an invalid encoding.

In any case why does another checksum need to be devised? We already
have some pretty good checksums and ways of presenting them with digest
algorithms and DigestInfo structures.

Steve.
-- 
************************************************
* Dr Stephen N. Henson.                        *
* Freelance Cryptographic Consultant.          *
* Email: [email-masked]                   * 
************************************************

Date: Sun, 29 Mar 1998 21:33:39 -0800
To: Russ Housley <[email-masked]>
From: Tim Dierks <[email-masked]>
Subject: Re: Triple-DES Key Wrapping
Cc: [email-masked]
Sender: [email-masked]

At 8:02 PM -0500 3/29/98, Russ Housley wrote:
>All:
>
>S/MIME 3 requires a function to encrypt one Triple-DES key in another.
>Below, I propose such a function, and I am writing to request review of
>that function.
>
>Here is how S/MIME 3 will use the function.  S/MIME 3 locally generate a
>random content-encryption Triple-DES key.  As the name implies, this key
>will be used to encrypt the message content.  Then, Diffie-Hellman will be
>used to generate a pairwise Triple-DES key with each message recipient, and
>the content-encryption key will be encrypted under the pairwise key.  I was
>unable to find a standard for the encryption of one Triple-DES key in
>another Triple-DES key.  The obvious encryption of the three DES keys in
>ECB mode does not seem sufficient to me.  This method would allow an
>attacker to rearrange the three blocks and the recipient could not detect
>the problem until  the entire message we decrypted.  So, I have proposed a
>technique that provides confidentiality and integrity.

1) I know this is a stupid question because this has been accepted as a
given by the WG for quite a bit of time, but why is S/MIME using the
Diffie-Hellman algorithm, which requires a bit of wedging to work as a
store-and-forward key transport algorithm, rather than ElGamal? Note that
this proposal is basically identical to ElGamal, only it uses 3DES and a
checksum instead of modular multiplication and PKCS#1-style padding.

2) Unless S/MIME is only going to support 3DES, it seems that there must be
a method capable of wrapping keys other than 3DES keys. Is that the intent?
Why not just create a single wrapping mechanism for all kinds of keys?
(Note that this comment has nothing to do with the selection of 3DES as a
wrapping mechanism, just the fact that it wraps only 3DES keys.)

3) Is 16 bits the appropriate place to trade off the work factor for
causing a checksum collision with the overhead per recipient? Why not 8, or
24? (I don't have a problem with 16, I was just interested in why that
value precisely.) (Note that the work factor is actually 2^19, thanks to
the requirement that the resultant keys must have odd parity.)

4) You may want to clarify step 3a of the key checksum algorithm to "Create
a 16 bit integer, called temp, by setting the high 8 bits to zero and the
low 8 bits to the key octet." to avoid (probably unreasonable) endian-ness
confusion.

 - Tim

Tim Dierks - Software Haruspex - [email-masked]
 "Well, cyberterrorists may be difficult to capture in the act, but from what I
  know about people who are highly skilled with computers, they should be easy
  to beat up." - Ernest Cey, quoted in The Onion, <http://www.theonion.com>

Date: Sun, 29 Mar 1998 20:02:09 -0500
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
From: Russ Housley <[email-masked]>
Subject: Triple-DES Key Wrapping
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

--=====================_891237729==_
Content-Type: text/plain; charset="us-ascii"

All:

S/MIME 3 requires a function to encrypt one Triple-DES key in another.
Below, I propose such a function, and I am writing to request review of
that function.

Here is how S/MIME 3 will use the function.  S/MIME 3 locally generate a
random content-encryption Triple-DES key.  As the name implies, this key
will be used to encrypt the message content.  Then, Diffie-Hellman will be
used to generate a pairwise Triple-DES key with each message recipient, and
the content-encryption key will be encrypted under the pairwise key.  I was
unable to find a standard for the encryption of one Triple-DES key in
another Triple-DES key.  The obvious encryption of the three DES keys in
ECB mode does not seem sufficient to me.  This method would allow an
attacker to rearrange the three blocks and the recipient could not detect
the problem until  the entire message we decrypted.  So, I have proposed a
technique that provides confidentiality and integrity.

Please do not propose improvements that are covered by any issued or
pending patents.

Thanks for your assistance,
  Russ

- - - - - - - - - - 

--=====================_891237729==_
Content-Type: text/plain; charset="us-ascii"

Mechanism:                  Triple-DES with Checksum
Wrapping Key Type:          Triple-DES (3 keys)
Type of key to be wrapped:  Triple-DES (3 keys)

KEY CHECKSUM ALGORITHM:

1.  Initialize two 16 bit integers, sum1 and sum2, to zero.
2.  Arrange the Triple-DES key into a string of 24 octets as follows:
    2a.  Key 1 followed by Key 2 followed by Key 3.
    2b.  Order the octets of each key most to least significant.
3.  Loop through the 24 octets of the Triple-DES key.
    3a.  Create a 16 bit integer, called temp, by concatenating 8 zero bits and
         the key octet.
    3b.  sum1 = sum1 + temp.
    3c.  sum2 = sum2 + sum1.
4.  Use sum2 as the checksum value.

KEY WRAP ALGORITHM:

1.  Adjust the parity bits on the three DES keys as necessary to give each octet
    odd parity: Key 1, Key 2, and Key 3.
2.  Compute a 16-bit check word on the key as described above.
3.  Using ECB mode, encrypt Key 1, Key 2, and Key 3 in the wrapping key.
4.  Create a temporary block from the concatenation of the low order six
    octets of the encrypted Key 3 and the two octets of the check word.
5.  Using ECB mode, encrypt the temporary block in the wrapping key.
6.  Concatenate the encrypted Key 1, Key 2, and Key 3 with the low order two
    octets of the encrypted temporary block to form the 26 octet (208 bits)
    wrapped key.

KEY UNWRAP ALGORITHM:

1.  Break the high order 24 octets into three 8 octet blocks, and decrypt
    each using the wrapping key with ECB mode.  The result will be the
    original key, Key 1, Key 2, and Key 3, if no errors are encountered
    in the following steps.
2.  Check the parity of Key 1, Key 2, and Key 3.  If any is incorrect then
    there is an error.
3.  Compute 16-bit check word on the decrypted key as described above.
4.  Create a temporary block from the concatenation of the low order six
    octets of the encrypted Key 3 value and the check word.
5.  Using DES ECB, encrypt the temporary block in the wrapping key.
6.  If the low order two octets of the wrapped key do not match the low 
    order two octets of the encrypted temporary block then there is an error.

--=====================_891237729==_--

From: John Ross <[email-masked]>
To: [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at post.mail.demon.net
Subject: security label
Date: Sun, 29 Mar 1998 10:32:32 +0100
Sender: [email-masked]

As per pevious comments on compatiblity between X.411 security label and the
eSSScecurityLable, I think the following would offer more compatibility and
allow for the extended character set:

eSSSecurityLable::= Choice{
    x411-security-label  Security label,
    version2-security-label Version2Securitylabel}

SecurityLabel ::= SET {
 security-policy-identifier SecurityPolicyIdentifier OPTIONAL,
 security-classification SecurityClassification OPTIONAL,
 privacy-mark PrivacyMark OPTIONAL,
 security-categories SecurityCategories OPTIONAL }

Version2SecurityLabel ::= SET {
 security-policy-identifier SecurityPolicyIdentifier,
 security-classification SecurityClassification OPTIONAL,
 privacy-mark  ExtendedPrivacyMark OPTIONAL,
 security-categories SecurityCategories OPTIONAL }

ExtendedPrivacyMark ::= UTC-8 STRING.

Then rules can be specified, that mandate the X.411 label is generated
unless the extended character set is required, then version 2 security label
shall be generated.

The above should mean that any signature that signs over the x.411 label
will operate end to end even if it has to cross a gateway between  a domian
that only suppports the X.411 securty label and a domain that supportes both
the X.411 and version2 labels.

I also think that maintains structual compatibility between the X.411 and
version2 signatures.

Any comments?

John Ross

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Questions about PKCS #10 and cert extensions
Reply-To: [email-masked]
Date: Sun, 29 Mar 1998 20:02:27 (NZST)
Sender: [email-masked]

While making some long-overdue updates to the X.509 style guide, I saw that the
section on PKCS #10 use might need some corrections.  This currently says:
 
  According to the PKCS #10 spec, the attributes field is mandatory, so if it's
  empty it's encoded as a zero-length field.  The example however assumes that
  if there are no attributes, the field shouldn't be present, treating it like
  an OPTIONAL field.  A number of vendors conform to the example rather than
  the specification, but just to confuse the issue RSADSI, who produced PKCS
  #10, regard things the other way around, with the spec being right and the
  example being wrong.  The most obvious effect of this is that TIPEM (which
  was the only available toolkit for PKCS#10 for a long time) follows the spec
  and does it "wrong (sense #2)", whereas more recent independant
  implementations follow the example and do it "wrong (sense #1)".
 
  PKCS #10 also dates from the days of X.509v1 and includes references to
  obsolete and deprecated objects and data formats.  PKCS #6 extended
  certificates are a workaround for the abscence of certificate extensions in
  X.509v1 and shouldn't be used at all, and it's probably a good idea to avoid
  the use of PKCS #9 extended attributes as well (some certification request
  protocols bypass the use of PKCS #9 by wrapping extra protocol layers
  containing PKCS #9 elements around the outside of PKCS #10).  Unfortunately
  since PKCS #10 doesn't mention X.509v3 at all, there's no clear indication of
  what is and isn't valid as an attribute for X.509v3 (for example a
  GeneralName should be treated as a valid attribute, a BasicConstraint may or
  may not be treated as valid depending on the CA's certification policy, and
  an AuthorityKeyIdentifier would definitely be an invalid attribute).
 
  To add to the confusion, the S/MIME certificate request draft states that
  X.509v3 extensions used as attributes in a certification request should be
  encoded as a SEQUENCE OF extensions wrapped up in a PKCS #9 attribute
  identified by the OID { pkcs-9 14 }.
 
Unfortunately I haven't been able to find anything which clears up the
confusion over either the encoding of the attributes field, or the use of
X.509v3 extensions.  Is anyone aware of implementations which still encode the
attributes as if they were declared 'Attributes OPTIONAL'?  Everything I've
seen recently always encodes the attributes as a zero-length field, however
being outside the US I can't check what most of the commonly-available
implementations do.  Should I recommend that they always be encoded as per the
spec and drop the section on encoding as per the example entirely?  (NB: I know
what the official position on this is, what I'd like to know is what it's like
in practice).
 
The other area of confusion is what's in the attributes.  PKCS #10 still refers
to the deprecated PKCS #6 extended certificates, as well as PKCS #9 extended
attributes, but not X.509v3 attributes/extensions which would probably be more
useful.  If I could get some indication of usage of X.509v3 attributes in a
certification request I'd like to add some comments on it to the guide -
because PKCS #10 predates the various v3 attributes you often have to resort to
guesswork to find out what is and isn't acceptable.  Are the comments in the
text above appropriate?  How should X.509v3 attributes be specified, as per the
S/MIME draft or directly as attributes (without the PKCS #9 wrapping)?  What
attributes are valid?  What ones are used in practice?
 
On the subject of extensions, the guide currently makes some rather vague
comments about handling extensions.  Looking through the X.509v3, S/MIME, and
PKIX cert-related drafts, I've noticed that the recommendations in there about
handling the critical flag are even more vague, since if the critical flag
isn't set most of the extensions are meant to be of an advisory nature only.
This means that an implementation could conceivably handle them with:
 
 1. If extension is critical and unrecognised, cert = invalid.
 2. If extension is noncritical, ignore it.
 
which relegates all noncritical extensions to communicating the message "I'm
only including this to bloat up the cert" (very few of the certs I've got have
their extensions marked as critical, in playing with MSIE and Netscape I've
found that doing this renders some certs unusable by both browsers).  For
instance consider the <anonymous CA> root cert, which is marked, via a keyUsage
extension, as being for cert and CRL signing only.  Since it's non-critical,
I'm free to ignore this and use it for key exchange, encryption, and whatever
else I please.
 
The problem lies in the nature of the critical flag (and I know this has been
debated before, but it was never really resolved).  At the moment it's used as:
 
 Critical = you must process this extension
 Non-critical = you don't have to process this extension
 
However "you don't have to process this extension" leaves implementors free to
either process it anyway or ignore it.  What complicates this issue is that
various standards leave the question of criticality up to implementors ("it
would be cool if you made this critical, but don't like, feel any pressure to
do so", or words to that effect).  Since including certain extensions like
basicConstraints, keyUsage, certificatePolicies, and a few others is pointless
unless they're marked critical, I'm thinking of recommending that if used,
these extensions must be marked critical.  What do people think about this?
 
Peter.

Date: Sat, 28 Mar 1998 20:35:10 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Comment on ESS and Privacy Marks
Sender: [email-masked]

>    My proposal offers these same benefits.

No, your proposal offered these benefits *as long as* every single security
policy made a special allowance for a UTF8 privacyMark security-category
using the identical OID. That's quite a requirement, and one that I think
is too onerous for this spec, given that the only benefit of doing it would
be so that people using X.411 would not have to convert.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Sat, 28 Mar 1998 21:21:52 -0500
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: Paul Hoffman / IMC <[email-masked]>
CC: [email-masked]
Subject: Re: Comment on ESS and Privacy Marks
Sender: [email-masked]

Paul,

    My proposal offers these same benefits.  I guess I should have said UNIQUE benefits.

Chris

__________________

Paul Hoffman / IMC wrote:

> At 11:15 PM 3/27/98 -0500, Bonatti, Chris wrote:
> >What exactly are the benefits to the current approach that make it so
> >desireable?
>
> Let me repeat myself. The benefits include:
> - being able to include an Internet mail address
> - being able to use charsets used by most of the world's population
>
> If you don't find these beneficial, I'm not sure we can ever come to
> agreement. In the IETF, they are both requirements.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, [email-masked]
Subject: RE: Comment on ESS and Privacy Marks
Date: Fri, 27 Mar 1998 21:28:30 -0800
Sender: [email-masked]

Actually let me be a bit stronger on this:

If privacy marks are GOOD then they are good for everybody and need to be
treated in a global manner by ALL clients.  If they are not GOOD then they
should be "removed" from the specification.  

I have seen a number of suggestions that are along the lines of -- oh, just
define an extension which has the new privacy mark syntax.  I will make the
same objection now that I made to the original statment of this (which John
Pawling originally made).  It is not a standard way.  The extensions are BY
DEFINTION dependent on the policy of the label.  A normal client now has
three different things to worry about:

1.  What is the character set of the privacy mark, or does one exist,
2.  What is this other extensions I need to start looking for (which will
not be done by legacy clients anyway),
3.  What do I do if both the extension exists and the privacy mark exist.

This is assuming that we are going to make some type of statement along the
lines of EVERY policy now has this possible extension/qualification to it.  

THIS IS BAD NEWS for client writers.  I like things really simple.  About
the hardest thing I can handle is one question -- which character set.  I
don't want to deal with the rest of the issues as well and maybe get
non-standard answers.

jim

Date: Fri, 27 Mar 1998 20:40:45 -0800
To: <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Comments on MSG-03
Sender: [email-masked]

At 07:52 PM 3/27/98 -0800, Paul Hoffman / IMC wrote:
>At 11:44 AM 3/26/98 -0800, Jim Schaad (Exchange) wrote:
>>1.  Section 2.6.2.3 and 2.6.2.4.  The wording no longer works for these two
>>sections now that 3DES is a must and RC2/40 is an optional.
>
>I disagree. The wording works fine.

OK, I now see what Jim was saying. I still disagree with his solution, but
I see where the wording needs to be changed. Instead of his suggested
changes for steps 3 and 4, I propose collapsing them into one:

2.6.1.3 Rule 3: Unknown Capabilities, Unknown Version of S/MIME

If:
 - the sending agent has no knowledge of the encryption capabilities
   of the recipient,
 - and the sending agent has no knowledge of the version of S/MIME
   of the recipient,
then the sending agent SHOULD use tripleDES because it is
stronger encryption and is required by S/MIME v3. If the sending
agent choses not to use tripleDES in this step, it SHOULD use
RC2/40.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 27 Mar 1998 20:32:52 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Comment on ESS and Privacy Marks
Sender: [email-masked]

At 11:15 PM 3/27/98 -0500, Bonatti, Chris wrote:
>What exactly are the benefits to the current approach that make it so
>desireable?

Let me repeat myself. The benefits include:
- being able to include an Internet mail address
- being able to use charsets used by most of the world's population

If you don't find these beneficial, I'm not sure we can ever come to
agreement. In the IETF, they are both requirements.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 27 Mar 1998 19:52:55 -0800
To: <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Comments on MSG-03
Sender: [email-masked]

At 11:44 AM 3/26/98 -0800, Jim Schaad (Exchange) wrote:
>1.  Section 2.6.2.3 and 2.6.2.4.  The wording no longer works for these two
>sections now that 3DES is a must and RC2/40 is an optional.

I disagree. The wording works fine. It was heavily debated about a year
ago. The first rule that comes after "you know what the user wants" MUST
prefer tripleDES. Prefering RC2/40 over tripleDES is wrong and will keep
S/MIME v3 from becoming a standard in the IETF.

>  I have switched
>the order of the rules as tripleDES is now a MUST algorithm and is therefore
>by definition supported, but we know that not everyone does support it.  I
>suggest that these sections be re-written as follows:
>
>"2.6.1.3 Rule 3: Low Encryption interopt mode
>
>If:
> - the sending agent has no knowledge of the encryption capabilities of the
>recipient,
> - and the sending agent is has reason to believe that the recipient does
>not support high level encryption,
>then the sending agent SHOULD use RC2/40.

Over my dead body. Whoops, maybe I stated that too forcefully. :-)

The phrase "has reason to believe" has no place in a specification like
this. That's based on such vague out-of-band guesses that it will lead to
rampant confusion on developer's part. Worse yet, it will cause some
sending agents to default to weak encryption. We have to say how they might
know this, and we already did that in 2.6.1.1 and 2.6.1.2. If you think
there is some other way for the sender to know something about the
recipient, please let me know, since we should add a step between the first
two and the second two.

The logic for the current 2.6.1.3 and 2.6.1.4 is that if you have no idea
what the recipient wants, the only thing you can base your decision on is
your aversion to risk of failed decryption. Because the latter choice is
based on a non-protocol decision, 2.6.1.3 and 2.6.1.4 must be SHOULDs, not
MUSTs.

>2.  Insert a new section 2.6.4 with the following text.
>"Section 2.6.4  Selecting a receipients Encryption Certificate

This looks pretty good. I might want to wordsmith it a bit, but I think
this is a valuable addition.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 27 Mar 1998 23:16:16 -0500
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: John Ross <[email-masked]>
CC: Ietf distribution list <[email-masked]>, John Pawling <[email-masked]>
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Sender: [email-masked]

John (Pawling),

    I agree with the sentiment of John Ross's remarks here.  I think that there will be cases (due to the widespread variation likely in security policies) where there will be a mix of policies reflected in the various labels in the message.  Forwarding is the most obvious case of this.

Chris

_______________

John Ross wrote:

> What happens if a recipient receives a forwarded message that include a
> security policy in the eSSSecurityLabel  that he/she in does not understand,
> is that still an error?
>
> I think the proposed text will mislead implementations to always discarding
> the message if a security policy is unknown.  I do not think that is right.
>
> All I think needs to be done is to leave such decisions to local policy;
> Thus reword your text as..
>
> "Receiving agents SHOULD have a local policy which specifies
> what action is taken when an eSSSecurityLabel is received which
> includes a security-policy-identifier that the processing software
> does not recognize."
>
> If think there is a need to specify default handling, then It should be to
> ignore
> security labels when the policy is not understood.
>
> Also, I still think that the security policy should not be optional.
>
> -----Original Message-----
> From: John Pawling <[email-masked]>
> To: John Ross <[email-masked]>; Bonatti, Chris <[email-masked]>;
> [email-masked] <[email-masked]>
> Date: Friday, March 27, 1998 5:56 AM
> Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
>
> >John,
> >
> >I included the following text in my comments to ESS-04 (which was
> originally
> >submitted by Jim Schaad).  I stand by this comment :
> >
> >9) Sec 3.1.2, Please add as 3rd para:  (This text was included in ESS-03,
> >but was mistakenly deleted from ESS-04.)
> >
> >"Receiving agents SHOULD have a local policy regarding whether or not to
> >show the inner content of a signedData object that includes an
> >eSSSecurityLabel security-policy-identifier that the processing software
> >does not recognize.  If the receiving agent does not recognize the
> >eSSSecurityLabel security-policy-identifier value, then it SHOULD stop
> >processing the message and indicate an error."
> >
> >Please note that this says SHOULD, not MUST.
> >
> >================================
> >John Pawling, [email-masked]
> >J.G. Van Dyke & Associates, Inc.
> >www.jgvandyke.com
> >================================
> >
> >
> >At 09:08 AM 3/27/98 -0800, John Ross wrote:
> >>John Pawling wrote:
> >>...........an important point to note is that the recipient software makes
> >>>a separate access control decision for each signedData object..........
> >>
> >>Question:
> >>In your view, does this mean that if the recipinet does not understand the
> >>policy id in the eSSSecuriltylabel that he may ignore the label in the
> >>access control decision, even though he has verified the signature of the
> >>signedData object to which it relateds?
> >>
> >

Date: Fri, 27 Mar 1998 23:16:03 -0500
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: John Pawling <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Sender: [email-masked]

John Pawling wrote:

> Chris,
>
> I respectfully disagree with your proposal.  The two different labels that
> you require can be implemented by including each label in a separate
> signedData layer of the message.  The original signer could include the
> "information label" in the original, inner signedData layer.  The "system
> label" could be included in an outer signedData layer that encapsulates the
> original, inner signedData layer.  This is the optimal strategy because the
> recipient MUST make a separate access control decision for each of the
> signedData layers.

John,

    This is a GROSSLY inefficient means of addressing this requirement.  In the common case where both labels are applied by the originating user, this means double signature generation operations, double signature verification operations, plus a bunch of extra attribute and ASN.1 overhead.  All that is required to address this is either:

        a)    An identical label attribute, with a distinct OID.
               Said attribute to be ignored for the purpose of
               access control.

        b)    A more complex structure WITHIN the existing
                label attribute that would allow the information
                label to be conveyed (and ignored).

What I proposed in my original submission was (b) above, but I really don't have a strong preference.

    Also, applying an access control check for the information label is not required or even useful.  In the system-high scenario to which this applies, the information security label will always be dominated by the system security label.

> The recipient MUST process the eSSSecurityLabel in each
> signedData object that it verifies.  Because the recipient will verify both
> the outer and inner signedData objects, then it MUST process the
> eSSSecurityLabel attribute in each of the signedData objects.  Therefore,
> both the "system" and "information" eSSSecurityLabels are processed by the
> recipient.  An important point to note is that the recipient software makes
> a separate access control decision for each signedData object.  IMHO, that
> is the primary difference between processing
> eSSSecurityLabels included in layered signedData objects versus those
> included in multiple signerInfos included in the same signedData object.

    I am not even convinced that you need to have the two labels in different signerInfo elements.  Provided that they are both applied by the originator, then there is no need for a second signature.

> In the latter case, all eSSSecurityLabels included in the various signerInfos
> (that are verified) are checked as part of the same cumulative access
> control decision process applied to the individual signedData object.  If
> multiple eSSSecurityLabels were allowed in the same signerInfo or same
> signedData, then there would be mass confusion and room for contradiction
> when different labels are processed by the recipient as part of the same
> cumulative access control decision applied to the individual signedData
> object.

    Again, you are assuming that the information label would be part of the ACDF.  I'm not convinced that this is necessary.

> I believe that it is impractical to try to force the S/MIME
> community into accepting a complicated access control decision strategy such
> as would be required to define the rules to process multiple
> eSSSecurityLabels included in the same signerInfo or same signedData.
>
> IMHO, the cost in efficiency of requiring nested signedData objects to
> convey multiple, different eSSSecurityLabels is well worth the clarity gained.
>
> In summary, I believe that the ESSSecurityLabel should remain as is.

Chris sends...

Date: Fri, 27 Mar 1998 23:15:38 -0500
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: John Ross <[email-masked]>
CC: Ietf distribution list <[email-masked]>, Paul Hoffman / IMC <[email-masked]>, John Pawling <[email-masked]>
Subject: Re: Comment on ESS and Privacy Marks
Sender: [email-masked]

John Ross wrote:

> But I disagree when you imply that a signed security label can be changed
> when passes through a gateway,  the aim is for as much interoperability as
> possible, so the signatures of data objects which are not translated by
> gateways can be applied end to end.  In that case the security label cannot
> be translated.

    I agree with this observation.  John Pawling's comments (too many John's :-) seem to assume that any outside system would necessarily strip off the CMS signature.  At least one design that I know of preserves the CMS signature value, and embeds it in their native protocols.  Since the CMS signature is used later, modifying the security label at the gateway is not an option.  However, components that are not CMS-aware will still be looking for the legacy label.

    If we expect that S/MIME will be a common exchange standard for digital signatures, we have to expect that our structures are going to be pulled into other systems.

Chris

Date: Fri, 27 Mar 1998 23:15:33 -0500
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: Paul Hoffman / IMC <[email-masked]>
CC: [email-masked]
Subject: Re: Comment on ESS and Privacy Marks
Sender: [email-masked]

Paul Hoffman / IMC wrote:

> This is the crux of the design decision. ESS is designed to standardize the
> inclusion of advanced new features in S/MIME, not to be bits-on-the-wire
> compatible with non-Internet formats which no longer make sense. I think
> you'll have to agree: a privacy mark that cannont include an Internet mail
> address (due to the lack of '@' in PrintableString) makes no sense in an
> Internet protocol.

Paul,

    I do not dispute this point.  I merely point out that, all other factors being equal, it is better to select a non-disruptive design than a disruptive one.  If there were clear counterarguments saying that the existing approach were somehow "better", I would relent.  However, what I have heard so far sounds like basic defense of the status quo -- on a solution that is about a month old.

> Where we can, we make it easy for software to create messages that are
> easily processable into older protocols. This has always been an important
> part of all the S/MIME work, and particularly the ESS work. Thus, we offer
> a choice for ESSPrivacyMark. If we didn't care about making life easier for
> those transitioning from older protocols, there would be no choice, just a
> UTF8 string.

    This is all that I propose is to, as you say, "make it easier".  As things stand now, it's half way there.  Either we should say that we don't care (in which case it should just be UTF-8 without a choice), or that we do (in which case what I'm saying is quite relevant).

Best Regards,
Chris B.

> --Paul Hoffman, Director
> --Internet Mail Consortium

Date: Fri, 27 Mar 1998 23:15:25 -0500
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: John Pawling <[email-masked]>
CC: Paul Hoffman / IMC <[email-masked]>, [email-masked]
Subject: Re: Comment on ESS and Privacy Marks
Sender: [email-masked]

John Pawling wrote:

> Chris,
>
> I agree with Paul that the ESSSecuritylabel is completely compatible with
> the X.411 SecurityLabel when the privacyMark choice is PrintableString. In
> fact, I would encourage you to propose to the ITU that the X.411
> securityLabel should be similarly enhanced.

John,

    With all due respect, you guy must have a unique view of backward compatibility.  Yeah, sure the definition has a printable string mode, but if you actually USE the enhancement.  Existing ACDFs will choke.  Any time you elect for "sender's choice" this issue arises.

    Modifying X.411 is a nice idea for the long term, but it also doesn't address the concern for backward compatibility with existing ACDFs.

> Furthermore, I respectfully disagree with your counter-proposal of defining
> a standard securityCategory syntax to hold the privacyMark UTF8String.  The
> X.411 spec states that the security policy in force (identified by the
> securityLabel security-policy-identifier) is used to indicate the syntaxes
> that are allowed to be present in the securityLabel security-categories.
> This implies that every organization's security policy (that uses the
> ESSSecurityLabel) would have to include the standard definition of the
> privacyMark security-category using the identical OID.  IMHO, there is no
> way that all of the organizations are going to agree on any standard
> security-categories or using an identical OID.  Security-categories are
> considered to be a matter of local policy and the various organizations are
> not going to accept a standard security category forced on them.

    This just doesn't make any sense.  If the various security policies won't support an additional category, then why should we expect them to support the new syntax at all?  Surely any organization whose policy specifies use of a privacy mark with extended characters would require support of a pre-defined category defined for that purpose.  On reception, supporting the category is certainly no more of a stretch than support policy mapping for every organization's policy.  They would all have to implement the new syntax for the privacy-mark field anyway, so getting them to implement reception of the new category should be no harder.  Plus, with the category approach, you have the additional benefit that you get graceful degradation for systems that don't process the new syntax.

    What exactly are the benefits to the current approach that make it so desireable?  This is, after all, a new attribute so there shouldn't be a lot of inertia to overcome.

Chris B.

> In summary, I believe that the ESSPrivacyMark should not be changed.
>
> ================================
> John Pawling, [email-masked]
> J.G. Van Dyke & Associates, Inc.
> www.jgvandyke.com
> ================================
>
> At 02:54 PM 3/26/98 -0500, Bonatti, Chris wrote:
> >    Let's be clear, however, that conveying the UTF-8 string as a security
> category allows the result to be compatible regardless of whether UTF-8 is
> used.  There is already a perfectly good extension mechanism included in the
> X.411 label.  Can somebody spell out for me the reason for NOT using it to
> address the UTF-8 requirement?  The way I see it, the current solution is
> creating a problem that does not need to be created.
> >
> >Chris
> >

Date: Fri, 27 Mar 1998 13:54:13 -0800
To: <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Comment on ESS and Privacy Marks
Sender: [email-masked]

At 07:43 PM 3/27/98 -0800, John Ross wrote:
>I think you have some valid arguments, I also agree that the current X.411
>printable string syntax has its limitations in an international scenario.

Two things here. One, calling it the "international scenario" is kind of
insulting: the native languages for more than three quarters of the world's
population needs non-PrintableString characters. Two, you have to remember
the "Internet scenario": you can't use Internet mail addresses in
PrintableString because of the lack of "@" in the charset.

>But I disagree when you imply that a signed security label can be changed
>when passes through a gateway,  the aim is for as much interoperability as
>possible, so the signatures of data objects which are not translated by
>gateways can be applied end to end.  In that case the security label cannot
>be translated.

I think you misunderstand what a gateway does. It converts from one
protocol to another. If the conversion cannot be done cleanly, it does the
best job possible. If bits of a signed message need to be changed across
the gateway, the gateway should:
1) validate the signature on the incoming message
2) convert as little as needed
3) create a message signed by the gateway that includes the incoming
validation status and the new, converted message

I think the gateway issue, particularly to a non-IETF protocol, is well
outside the charter of this group.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 27 Mar 1998 16:06:46 -0500
To: "Darren Harter" <[email-masked]>, "Darren Harter" <[email-masked]>, <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: ESSSecurityLabel Comments -Reply
Sender: [email-masked]

Darren,

The CMS signedData signerInfo signature value is calculated based on a
digest of the authenticatedAttributes included in the signerInfo (assuming
that authenticatedAttributes are present, which they will be in your example
because of the presence of an eSSSecurityLabel authenticatedAttribute).  The
only way that the original signer's signature value will be preserved
through a gateway translation is if the recipient end-user software can
calaulate the digest of the identical data that was digested by the signer.
In other words, the end user software would need to be able to hash the
identical authenticatedAttributes SEQUENCE included in the original CMS
signedData signerInfo.  It would be a significant modification to your
legacy software to support this requirement.  Instead, you may want to
consider converting your applications to use CMS:)

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

At 06:08 PM 3/27/98 -0000, Darren Harter wrote:
>John,
>
>I understand and respect your point.
>
>My memory could be failing me here, but I believe that the consensus of
>opinion following Tim Dean's
>interoperability presentation (I think Jim Schaad expressed it quite well)
>in the WG meeting in December was that the issue of allowing Signatures to
>remain intact when going through gateways to other security protocols was
>important - though not directly under the charter for the group.
>
>As you are aware there are implementations out there that employ signatures
>over X.411 labels - primarily using MSP (and soon PCT).  To allow signatures
>over labels to pass through such gateways does require a bits-on-the-wire
>compatibility, and I believe that anything that ESS does to prevent this
>will delay acceptance of the protocol for my customers.  For my customers,
>interoperability with other security protocols through gateways is a primary
>requirement.
>
>I appreciate that some of this is outside the scope of this group.
>
>See you all in LA - perhaps we can discuss further then.
>
>Darren
>
>
>
>
>

From: John Ross <[email-masked]>
To: Ietf distribution list <[email-masked]>, Paul Hoffman / IMC <[email-masked]>, John Pawling <[email-masked]>
Subject: Re: Comment on ESS and Privacy Marks
Date: Fri, 27 Mar 1998 19:43:00 -0800
Sender: [email-masked]

I think you have some valid arguments, I also agree that the current X.411
printable string syntax has its limitations in an international scenario.
But I still think we should try and maintain compatibity between the two
label where possible.

I also agree that we can propose some ehancements to the X.411 label which
may help to keep alignment in the future.

But I disagree when you imply that a signed security label can be changed
when passes through a gateway,  the aim is for as much interoperability as
possible, so the signatures of data objects which are not translated by
gateways can be applied end to end.  In that case the security label cannot
be translated.

-----Original Message-----
From: John Pawling <[email-masked]>
To: John Ross <[email-masked]>; [email-masked]
<[email-masked]>; Paul Hoffman / IMC <[email-masked]>
Date: Friday, March 27, 1998 5:33 AM
Subject: Re: Comment on ESS and Privacy Marks

>John,
>
>I respectfully disagree with your comments.  The X.411 securityLabel syntax
>was included in ESS to maximize the re-use of existing software.  It was
not
>included in ESS to provide direct bits-on-the-wire compatibility with
>existing non-CMS security protocols.  You state "An implementation which
>understands the X.411 label...", but there are not any commmercially
>deployed S/MIME user agents (that I know of) currently using the X.411
>securityLabel syntax as an authenticatedAttribute.  Therefore, direct
>backwards compatibility between eSSSecurityLabels and S/MIME v2 agents
using
>X.411 securityLabels is not an issue.
>
>Any security heading that is currently using the X.411 securityLabel is not
>implementing CMS, so a translation step will be required between CMS and
the
>non-CMS security heading.  When a CMS signedData object is received by an
>organization implementing a non-CMS legacy security protocol, then software
>that recognizes the CMS signedData format will be required to initially
>decode and verify the original CMS signer's signature.  That software will
>then need to translate the received CMS signedData format into the format
of
>the legacy, non-CMS security heading that includes the X.411 securityLabel.
>In other words, there will need to be a gateway that tranlates the CMS
>signedData object into the legacy format.
>
>Therefore, any interoperability between eSSSecurityLabels and X.411
>securityLabels will occur as part of the process of translating the CMS
>signedData format to the non-CMS format that uses X.411 securityLabels (and
>vice versa).  During that translation process, the eSSecurityLabel can be
>translated to an X.411 securityLabel.  The received eSSSecurityLabel will
be
>bits-on-the-wire identical to the X.411 SecurityLabel when the privacyMark
>choice is PrintableString.  If the eSSSecurityLabel privacyMark choice is
>not PrintableString then the non-CMS translating software will need to map
>the UTF8String to another representation such as a security-category
defined
>by the recipient local organization's security policy.
>
>IMHO, changing the original signer's eSSSecurityLabel privacyMark during
the
>CMS-to-non-CMS translation process is acceptable because the originator's
>CMS signature can't be verified by the end-user recipient anyway because
>that user's legacy software won't have the capability of verifying CMS
>signatures.  In other words, the end-user's legacy software will not be
>prepared to hash the original signer's signedData signerInfo
>authenticatedAttributes in order to directly validate the original signer's
>signature.  The gateway will not be able to preserve the original signer's
>signature during the translation process.
>
>The X.411 SecurityLabel privacyMark syntax is woefully inadequate.  I
>encourage you to propose to the ITU that the X.411
>securityLabel should be enhanced to be identical to the eSSSecurityLabel.
>
>Please see my reponse to Chris Bonatti's messsage for my explanation of why
>the "globally defined" security-category will not work.
>
>In summary, I believe that the ESSPrivacyMark should not be changed.
>
>================================
>John Pawling, [email-masked]
>J.G. Van Dyke & Associates, Inc.
>www.jgvandyke.com
>================================
>
>
>
>At 08:28 AM 3/27/98 -0800, John Ross wrote:
>>The problem with the current proposal is not only on origination, but on
>>reception. An implementation which understands the X.411 label will expect
>>printable string and not expect UTF-8, so what does it do if the UTF-8
>>string contains extended characters, it may try to display them as
printable
>>characters, it may not?
>>
>>I agree with Chris that a more elegant solution to this problem would be
to
>>define a security category to convey the enhanced string value?  this
offers
>>a fully flexible solution which uses the valid extension mechanism
provided
>>by the X.411 label .
>>
>>John Ross
>>
>

From: John Ross <[email-masked]>
To: "Bonatti, Chris" <[email-masked]>, Ietf distribution list <[email-masked]>, John Pawling <[email-masked]>
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Date: Fri, 27 Mar 1998 19:42:21 -0800
Sender: [email-masked]

What happens if a recipient receives a forwarded message that include a
security policy in the eSSSecurityLabel  that he/she in does not understand,
is that still an error?

I think the proposed text will mislead implementations to always discarding
the message if a security policy is unknown.  I do not think that is right.

All I think needs to be done is to leave such decisions to local policy;
Thus reword your text as..

"Receiving agents SHOULD have a local policy which specifies
what action is taken when an eSSSecurityLabel is received which
includes a security-policy-identifier that the processing software
does not recognize."

If think there is a need to specify default handling, then It should be to
ignore
security labels when the policy is not understood.

Also, I still think that the security policy should not be optional.

-----Original Message-----
From: John Pawling <[email-masked]>
To: John Ross <[email-masked]>; Bonatti, Chris <[email-masked]>;
[email-masked] <[email-masked]>
Date: Friday, March 27, 1998 5:56 AM
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)

>John,
>
>I included the following text in my comments to ESS-04 (which was
originally
>submitted by Jim Schaad).  I stand by this comment :
>
>9) Sec 3.1.2, Please add as 3rd para:  (This text was included in ESS-03,
>but was mistakenly deleted from ESS-04.)
>
>"Receiving agents SHOULD have a local policy regarding whether or not to
>show the inner content of a signedData object that includes an
>eSSSecurityLabel security-policy-identifier that the processing software
>does not recognize.  If the receiving agent does not recognize the
>eSSSecurityLabel security-policy-identifier value, then it SHOULD stop
>processing the message and indicate an error."
>
>Please note that this says SHOULD, not MUST.
>
>================================
>John Pawling, [email-masked]
>J.G. Van Dyke & Associates, Inc.
>www.jgvandyke.com
>================================
>
>
>At 09:08 AM 3/27/98 -0800, John Ross wrote:
>>John Pawling wrote:
>>...........an important point to note is that the recipient software makes
>>>a separate access control decision for each signedData object..........
>>
>>Question:
>>In your view, does this mean that if the recipinet does not understand the
>>policy id in the eSSSecuriltylabel that he may ignore the label in the
>>access control decision, even though he has verified the signature of the
>>signedData object to which it relateds?
>>
>

From: John Ross <[email-masked]>
To: Ietf distribution list <[email-masked]>, John Pawling <[email-masked]>
Subject: Re: protected content
Date: Fri, 27 Mar 1998 19:43:13 -0800
Sender: [email-masked]

Thanks for that clarification,  that helps as far as understanding how CMS
and ESS can be used with repect to X.400.  But you should at least change
the name of ContentHints to someting more meaningfull.

-----Original Message-----
From: John Pawling <[email-masked]>
To: John Ross <[email-masked]>; Ietf distribution list
<[email-masked]>
Date: Friday, March 27, 1998 6:14 AM
Subject: Re: protected content

>John,
>
>The CMS spec does not limit the value of signedData encapContentInfo
>eContentType or envelopedData encryptedContentInfo contentType to be
>id-data.  The S/MIME message spec does make that limitation because it
>specifies how to use CMS with MIME.  In fact, there have already been
>discussions of using CMS to protect X.400 messages.  In that case, the
>signedData encapContentInfo eContentType or envelopedData
>encryptedContentInfo contentType could be the P2, P22 or  P772 OID (or
>other).  A separate document needs to be written specifying how CMS and ESS
>will be used with X.400.  IMHO, this is out of scope for the S/MIME WG
since
>the charter states "MIME encapsulation".
>
>I respectfully disagree with your proposal for
>ProtectedInformationTypeAttribute.  I believe that the signedData
>encapContentInfo eContentType and envelopedData encryptedContentInfo
>contentType OBJECT IDENTIFIER fields provides sufficient information to
>identify the content.  There is no need to specify a complicated ASN.1
>syntax to define the various flavors of message.  Organizations can define
>OIDs to provide the desired level of granularity.
>
>In summary, I beleive that contentHints should be left as is.
>
>================================
>John Pawling, [email-masked]
>J.G. Van Dyke & Associates, Inc.
>www.jgvandyke.com
>================================
>

From: John Ross <[email-masked]>
To: Ietf distribution list <[email-masked]>, John Pawling <[email-masked]>
Subject: Re: protected content
Date: Fri, 27 Mar 1998 19:43:23 -0800
Sender: [email-masked]

Thanks for that clarification,  that helps as far as understanding how CMS
and ESS can be used with repect to X.400.  But you should at least change
the name of ContentHints to someting more meaningfull.

-----Original Message-----
From: John Pawling <[email-masked]>
To: John Ross <[email-masked]>; Ietf distribution list
<[email-masked]>
Date: Friday, March 27, 1998 6:14 AM
Subject: Re: protected content

>John,
>
>The CMS spec does not limit the value of signedData encapContentInfo
>eContentType or envelopedData encryptedContentInfo contentType to be
>id-data.  The S/MIME message spec does make that limitation because it
>specifies how to use CMS with MIME.  In fact, there have already been
>discussions of using CMS to protect X.400 messages.  In that case, the
>signedData encapContentInfo eContentType or envelopedData
>encryptedContentInfo contentType could be the P2, P22 or  P772 OID (or
>other).  A separate document needs to be written specifying how CMS and ESS
>will be used with X.400.  IMHO, this is out of scope for the S/MIME WG
since
>the charter states "MIME encapsulation".
>
>I respectfully disagree with your proposal for
>ProtectedInformationTypeAttribute.  I believe that the signedData
>encapContentInfo eContentType and envelopedData encryptedContentInfo
>contentType OBJECT IDENTIFIER fields provides sufficient information to
>identify the content.  There is no need to specify a complicated ASN.1
>syntax to define the various flavors of message.  Organizations can define
>OIDs to provide the desired level of granularity.
>
>In summary, I beleive that contentHints should be left as is.
>
>================================
>John Pawling, [email-masked]
>J.G. Van Dyke & Associates, Inc.
>www.jgvandyke.com
>================================
>

From: "Flanigan, Bill" <[email-masked]>
To: IETF-SMIME WG <[email-masked]>
Subject: More on Cert-03.txt and Msg-03.txt
Date: Fri, 27 Mar 1998 13:18:40 -0500
Sender: [email-masked]

Hello Blake,

	Some additional nits:

		1.  Cert-03.txt:

			i.  Section 2.3, paragraph 2.  Delete sentence # 2
and # 3 
or relocate into an appendix or footnote.  Rationale:  verbiage 
seems to be editorial/expository/informational, but not technical 
per se.
		
			j.  Section 2.3, paragraph 5, sentences 3-5.
Relocate 
into first paragraph.  Rationale:  information is too important 
to be hidden back there.

			k.  Section 3.1, paragraphs 1-4.  Delete or relocate

into an appendix.  Rationale:  verbiage seems to be editorial 
and/or expository in nature, but not technical per se.

			l.  Section 3.2.  Relocate paragraph # 2 into the
last 
paragraph of this section.  Replace "emailAddress" with "Email 
Address" in last line of last paragraph.

			m.  Section 4.0.  

				(1)  Relocate paragraph # 1 into an appendix
and 
delete the word "that" from the penultimate line of this same 
paragraph.  Rationale:  verbiage seems mostly expository 
in nature, but not technical per se.

				(2)  Insert new lead-off paragraph that sets
forth 
the "MUST" language items.

				(3)  Relocate all but the first sentence in
existing 
paragraph # 2 into an appendix.  Rationale:  verbiage seems to be
editorial/expository/informational, but not technical per se.

			n.  Section 4.2.

				(1)  In line # 1, what does the "and" mean?
And...what?

				(2)  Sentence # 1 and # 2 should be
reordered.  
Rationale: current sentence #2 contains a "MUST statement and is 
more important.

			o.  Section 4.4.

				(1)  Paragraph 1.  Except for the last two
sentences, 
relocate rest of paragraph into an appendix.  Rationale:  verbiage 
seems mostly expository in nature, but not technical per se.

				(2)  Paragraph 1, line 10.  Change "minimum
required" 
to "maximum allowable".  Rationale:  to promote interoperability 
despite the v3 extensions "curse," and so that verbiage agrees 
with the first sentence in paragraph # 3.

				(3)  Paragraph 3, line 2.  Define the term
"critical."

				(4)  Paragraph 3.  This paragraph is too
confusing 
(what with "non-critical unless"..."deemed critical"..."SHOULD 
NOT be marked as critical", etc.  Recommend complete rewrite or 
delete.

			p.  Section 4.4.1.  

				(1)  Paragraph 2, line 3.  Define "end-user 
subscriber" vis-a-vis "clients" , "users", "receiving agent", 
and "sending agents".

				(2)  Final line.  One-line paragraphs =
improper 
grammar.  Combine line with paragraph #1 or # 2.  How should the 
"basicConstraints extension be marked?  "Critical" or...?

			q.  Section 4.4.3.  How should the "subject
alternative 
name extension" be marked?

			r.  Section 5.0  Is a "failure" always a security 
consideration?  Are there security considerations that are not 
failures?
 
		2.  Msg-03.txt.  Later   

Also hope this helps.

Bill

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
William F. Flanigan, Jr., Ph.D.       Voice:           (703) 735-3305
Defense Information Systems Agency      DSN:                      653
Strategic Planning Office (JEBA)        Fax:            (703)735-3255
10701 Parkridge Boulevard        Voice Mail:            (703)735-3305 
Reston, VA 20191-4357              Internet:  <[email-masked]>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

From: "Darren Harter" <[email-masked]>
To: "Darren Harter" <[email-masked]>, <[email-masked]>, "John Pawling" <[email-masked]>
Subject: Re: ESSSecurityLabel Comments -Reply
Date: Fri, 27 Mar 1998 18:08:14 -0000
Sender: [email-masked]

John,

I understand and respect your point.

My memory could be failing me here, but I believe that the consensus of
opinion following Tim Dean's
interoperability presentation (I think Jim Schaad expressed it quite well)
in the WG meeting in December was that the issue of allowing Signatures to
remain intact when going through gateways to other security protocols was
important - though not directly under the charter for the group.

As you are aware there are implementations out there that employ signatures
over X.411 labels - primarily using MSP (and soon PCT).  To allow signatures
over labels to pass through such gateways does require a bits-on-the-wire
compatibility, and I believe that anything that ESS does to prevent this
will delay acceptance of the protocol for my customers.  For my customers,
interoperability with other security protocols through gateways is a primary
requirement.

I appreciate that some of this is outside the scope of this group.

See you all in LA - perhaps we can discuss further then.

Darren

Date: Fri, 27 Mar 1998 11:27:27 -0500
To: Darren Harter <[email-masked]>, [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: ESSSecurityLabel Comments -Reply
Sender: [email-masked]

Darren,

I respectfully disagree with your comments and with your proposed changes to
the ESSSecurityLabel syntax.  The X.411 securityLabel syntax was included in
ESS to maximize the re-use of existing software.  It was not included in ESS
to provide direct bits-on-the-wire compatibility with existing non-CMS
security protocols.  There are not any commmercially deployed S/MIME user
agents (that I know of) currently using the X.411 securityLabel syntax as an
authenticatedAttribute.  Therefore, direct backwards compatibility between
eSSSecurityLabels and S/MIME v2 agents using X.411 securityLabels is not a
requirement.  

Any interoperability between eSSSecurityLabels and X.411 securityLabels will
occur as part of the process of translating the CMS signedData format to the
non-CMS format that uses X.411 securityLabels (and vice versa).  During that
translation process, the eSSecurityLabel can be translated to an X.411
securityLabel (and vice versa). 

Your proposal adds significant complexity to the ESSSecurityLabel format
which I believe is not required because the translating software can
accommodate any differences between the ESSSecurityLabel and X.411 security
label representations.

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

Date: Fri, 27 Mar 1998 07:46:46 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Comment on ESS and Privacy Marks
Sender: [email-masked]

At 08:34 AM 3/27/98 -0500, John Pawling wrote:
>I respectfully disagree with your comments.  The X.411 securityLabel syntax
>was included in ESS to maximize the re-use of existing software.  It was not
>included in ESS to provide direct bits-on-the-wire compatibility with
>existing non-CMS security protocols.

This is the crux of the design decision. ESS is designed to standardize the
inclusion of advanced new features in S/MIME, not to be bits-on-the-wire
compatible with non-Internet formats which no longer make sense. I think
you'll have to agree: a privacy mark that cannont include an Internet mail
address (due to the lack of '@' in PrintableString) makes no sense in an
Internet protocol.

Where we can, we make it easy for software to create messages that are
easily processable into older protocols. This has always been an important
part of all the S/MIME work, and particularly the ESS work. Thus, we offer
a choice for ESSPrivacyMark. If we didn't care about making life easier for
those transitioning from older protocols, there would be no choice, just a
UTF8 string.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 27 Mar 1998 07:52:38 -0800
To: <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: protected content
Sender: [email-masked]

At 09:15 AM 3/27/98 -0500, John Pawling wrote:
>A separate document needs to be written specifying how CMS and ESS
>will be used with X.400.  IMHO, this is out of scope for the S/MIME WG since
>the charter states "MIME encapsulation".

Quite right. Further, I would object to trying to shoe-horn this into our
charter. The MIXER WG is a great example of why asking IETF people to work
on X.400-related specs is a Really Bad Idea. One might argue the same thing
about X.500 specs...

However, there seems to be interest in this. If someone creates such a
draft, IMC would be happy to create a mailing list for discussing it so
that it can be done well with lots of input from the appropriate
communities. I'm absolutely not volunteering to do such a draft, since I
take the "I" in IMC seriously, but am willing to run a mailing list for the
work.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 27 Mar 1998 09:38:02 -0500
To: "JOHN ROSS" <[email-masked]>, <[email-masked]>
From: [email-masked] (John Pawling)
Subject: ESSSecurityLabel Change
Sender: [email-masked]

John,

You are probably not going to believe this, but I agree with your proposal
to make the eSSSecurityLabel security-policy-identifier a mandatory field.
The security-policy-identifier identifes the syntax and semantics of the
remaining fields, so I agree that it must always be present.  I agree that
the syntax should force the security-policy-identifier to always be present.
This reults in the following new ESSSecurityLabel syntax:

ESSSecurityLabel ::= SET {
  version                    [0] Version DEFAULT v1,
  security-policy-identifier     SecurityPolicyIdentifier,
  security-classification        SecurityClassification OPTIONAL,
  privacy-mark                   ESSPrivacyMark OPTIONAL,
  security-categories            SecurityCategories OPTIONAL }

ESSPrivacyMark ::= CHOICE {
    pString                      PrintableString (SIZE
(1..ub-privacy-mark-length)),
    -- If pString is used, the ESSSecurityLabel version is set to v1
    utf8String               [1] IMPLICIT OCTET STRING SIZE (1..MAX)
    -- If utf8String is used, its contents MUST be in UTF8 format, and
    -- the ESSSecurityLabel version is set to v2
}

I believe that ESS should state: "Receiving agents SHOULD have a local
policy regarding whether or not to show the inner content of a signedData
object that includes an eSSSecurityLabel security-policy-identifier that the
processing software does not recognize.  If the receiving agent does not
recognize the eSSSecurityLabel security-policy-identifier value, then it
SHOULD stop processing the message and indicate an error."

I agree with your statement: "and make the access control processing of the
eSSSecurityLabel depending on supporting the value of the
SecurityPolicyIdentifier."  I beleive that ESS Section 3 already makes that
clear.  I don't believe that ESS should include any further requirements
regarding processing security labels or mandating access control strategies.
Those are issues for local organizations to determine when they define their
security policies and access control strategies.  This is consistent with
your statement that access control is dependent on the
security-policy-identifier value.

You stated: "Your concern about complex access control rules still applies
in the multi-wrapping case.  Whenever multiple labels can exists, complex
access control rules are needed to process them."  I agree that complex
access control rules still apply in the multi-wrapping case, but at least we
can simplify the access control decision applied to each signedData object
by mandating that all essSecurityLabels in the signedData onject MUST be
identical.   That way we avoid the situation, for example, in which one
eSSSecurityLabel in a signedData states "US SECRET" and another states "US
UNCLASSIFIED".  With the separate wrappers, it simplifies the overall access
control decision strategy.  For example, a local organization may have
different strategies for handling access control failures in outer
signedData objects than in inner signedData objects.

In summary, I don't believe that ESS should mandate the access control
stratgies to be used by local organnizations, but I believe that we can make
some simple rules (as are currently included in ESS) to simplify the
decision made for each signedData object.

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

Date: Fri, 27 Mar 1998 09:15:42 -0500
To: John Ross <[email-masked]>, Ietf distribution list <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: protected content
Sender: [email-masked]

John,

The CMS spec does not limit the value of signedData encapContentInfo
eContentType or envelopedData encryptedContentInfo contentType to be
id-data.  The S/MIME message spec does make that limitation because it
specifies how to use CMS with MIME.  In fact, there have already been
discussions of using CMS to protect X.400 messages.  In that case, the
signedData encapContentInfo eContentType or envelopedData
encryptedContentInfo contentType could be the P2, P22 or  P772 OID (or
other).  A separate document needs to be written specifying how CMS and ESS
will be used with X.400.  IMHO, this is out of scope for the S/MIME WG since
the charter states "MIME encapsulation".

I respectfully disagree with your proposal for
ProtectedInformationTypeAttribute.  I believe that the signedData
encapContentInfo eContentType and envelopedData encryptedContentInfo
contentType OBJECT IDENTIFIER fields provides sufficient information to
identify the content.  There is no need to specify a complicated ASN.1
syntax to define the various flavors of message.  Organizations can define
OIDs to provide the desired level of granularity.

In summary, I beleive that contentHints should be left as is.

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

Date: Fri, 27 Mar 1998 08:57:56 -0500
To: John Ross <[email-masked]>, "Bonatti, Chris" <[email-masked]>, [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Sender: [email-masked]

John,

I included the following text in my comments to ESS-04 (which was originally
submitted by Jim Schaad).  I stand by this comment : 

9) Sec 3.1.2, Please add as 3rd para:  (This text was included in ESS-03,
but was mistakenly deleted from ESS-04.)

"Receiving agents SHOULD have a local policy regarding whether or not to
show the inner content of a signedData object that includes an
eSSSecurityLabel security-policy-identifier that the processing software
does not recognize.  If the receiving agent does not recognize the
eSSSecurityLabel security-policy-identifier value, then it SHOULD stop
processing the message and indicate an error."

Please note that this says SHOULD, not MUST.

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

At 09:08 AM 3/27/98 -0800, John Ross wrote:
>John Pawling wrote:
>...........an important point to note is that the recipient software makes
>>a separate access control decision for each signedData object..........
>
>Question:
>In your view, does this mean that if the recipinet does not understand the
>policy id in the eSSSecuriltylabel that he may ignore the label in the
>access control decision, even though he has verified the signature of the
>signedData object to which it relateds?
>

Date: Fri, 27 Mar 1998 08:34:23 -0500
To: John Ross <[email-masked]>, [email-masked], Paul Hoffman / IMC <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Comment on ESS and Privacy Marks
Sender: [email-masked]

John,

I respectfully disagree with your comments.  The X.411 securityLabel syntax
was included in ESS to maximize the re-use of existing software.  It was not
included in ESS to provide direct bits-on-the-wire compatibility with
existing non-CMS security protocols.  You state "An implementation which
understands the X.411 label...", but there are not any commmercially
deployed S/MIME user agents (that I know of) currently using the X.411
securityLabel syntax as an authenticatedAttribute.  Therefore, direct
backwards compatibility between eSSSecurityLabels and S/MIME v2 agents using
X.411 securityLabels is not an issue.  

Any security heading that is currently using the X.411 securityLabel is not
implementing CMS, so a translation step will be required between CMS and the
non-CMS security heading.  When a CMS signedData object is received by an
organization implementing a non-CMS legacy security protocol, then software
that recognizes the CMS signedData format will be required to initially
decode and verify the original CMS signer's signature.  That software will
then need to translate the received CMS signedData format into the format of
the legacy, non-CMS security heading that includes the X.411 securityLabel.
In other words, there will need to be a gateway that tranlates the CMS
signedData object into the legacy format.

Therefore, any interoperability between eSSSecurityLabels and X.411
securityLabels will occur as part of the process of translating the CMS
signedData format to the non-CMS format that uses X.411 securityLabels (and
vice versa).  During that translation process, the eSSecurityLabel can be
translated to an X.411 securityLabel.  The received eSSSecurityLabel will be
bits-on-the-wire identical to the X.411 SecurityLabel when the privacyMark
choice is PrintableString.  If the eSSSecurityLabel privacyMark choice is
not PrintableString then the non-CMS translating software will need to map
the UTF8String to another representation such as a security-category defined
by the recipient local organization's security policy.

IMHO, changing the original signer's eSSSecurityLabel privacyMark during the
CMS-to-non-CMS translation process is acceptable because the originator's
CMS signature can't be verified by the end-user recipient anyway because
that user's legacy software won't have the capability of verifying CMS
signatures.  In other words, the end-user's legacy software will not be
prepared to hash the original signer's signedData signerInfo
authenticatedAttributes in order to directly validate the original signer's
signature.  The gateway will not be able to preserve the original signer's
signature during the translation process. 

The X.411 SecurityLabel privacyMark syntax is woefully inadequate.  I
encourage you to propose to the ITU that the X.411
securityLabel should be enhanced to be identical to the eSSSecurityLabel.

Please see my reponse to Chris Bonatti's messsage for my explanation of why
the "globally defined" security-category will not work.

In summary, I believe that the ESSPrivacyMark should not be changed.

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

At 08:28 AM 3/27/98 -0800, John Ross wrote:
>The problem with the current proposal is not only on origination, but on
>reception. An implementation which understands the X.411 label will expect
>printable string and not expect UTF-8, so what does it do if the UTF-8
>string contains extended characters, it may try to display them as printable
>characters, it may not?
>
>I agree with Chris that a more elegant solution to this problem would be to
>define a security category to convey the enhanced string value?  this offers
>a fully flexible solution which uses the valid extension mechanism provided
>by the X.411 label .
>
>John Ross
>

Date: Fri, 27 Mar 1998 12:47:57 +0000
From: Darren Harter <[email-masked]>
To: [email-masked], [email-masked]
Subject: ESSSecurityLabel Comments -Reply
Sender: [email-masked]

John,

There is a further flaw in the scheme.  Because the ESSSecurityLabel is a
SET, it will be sorted when DER is used.

This means that the set elements will appear in the following order in the DER
encoding:

When Printable String Used - v1

     Classification - tag 0x02
     PolicyId - tag 0x06
     Privacy - tag 0x13
     Categories - tag 0x30

When UTF8 String Used - v2

     Classification - tag 0x02
     PolicyId - tag 0x06
     Categories - tag 0x30
     Version - 0x80
     Privacy - tag 0x81

As you can see from this a v1 application will decode the Classification,
PolicyId and Categories successfully.  When the Version tag is hit, the v1 app
will error.  This is becuase the v1 app will be expecting a 0x13 as the octets in
the SET encoding have not yet been exhausted.  At best the app will log an error,
at worst all hell breaks out.

The only way around this would be to use a tag that would force the Version field
to appear first in the encoding.  Unfortunately that would have to be 0x01
(BOOLEAN's tag) - yuk.

The definition (though I don't like it) would be

ESSSecurityLabel ::= SET {
  version                    [UNIVERSAL 1] IMPLICIT Version DEFAULT v1,
  security-policy-identifier               SecurityPolicyIdentifier OPTIONAL,
  security-classification                  SecurityClassification OPTIONAL,
  privacy-mark                             ESSPrivacyMark OPTIONAL,
  security-categories                      SecurityCategories OPTIONAL }

Personally, I would prefer to see this:

ESSSecurityLabel ::= CHOICE {
  x411Label      SecurityLabel,
  enhancedLabel  EnhancedLabel }

EnhancedLabel ::= SEQUENCE {
  version  Version DEFAULT v2,
  essLabel ESSLabel }

ESSLabel ::= SET {
  security-policy-identifier       SecurityPolicyIdentifier OPTIONAL,
  security-classification          SecurityClassification OPTIONAL,
  privacy-mark                 [1] IMPLICIT OCTET STRING SIZE(1..MAX)OPTIONAL,
  security-categories              SecurityCategories OPTIONAL }

What do you think?

Darren Harter
CASM Programme Office
CESG    

>>> John Pawling <[email-masked]> 03/26 7:58 pm >>>
All,

We need to add a context-specific tag to the ESSSecurityLabel version field
because there are two INTEGERs in the SET.  In order to keep the tags in
numerical order, recommend that ESSPrivacyMark utf8String should be changed
to "[1]" and then "[0]" can be used for ESSSecurityLabel version.  This
results in the following:

ESSSecurityLabel ::= SET {
  version                    [0] Version DEFAULT v1,
  security-policy-identifier     SecurityPolicyIdentifier OPTIONAL,
  security-classification        SecurityClassification OPTIONAL,
  privacy-mark                   ESSPrivacyMark OPTIONAL,
  security-categories            SecurityCategories OPTIONAL }

ESSPrivacyMark ::= CHOICE {
    pString                      PrintableString (SIZE
(1..ub-privacy-mark-length)),
    -- If pString is used, the ESSSecurityLabel version is set to v1
    utf8String               [1] IMPLICIT OCTET STRING SIZE (1..MAX)
    -- If utf8String is used, its contents MUST be in UTF8 format, and
    -- the ESSSecurityLabel version is set to v2
}

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

                                            

From: "JOHN ROSS" <[email-masked]>
To: <[email-masked]>
Subject: Fw: 
Date: Fri, 27 Mar 1998 12:27:20 -0000
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_001E_01BD597B.B0899CE0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_001F_01BD597B.B0899CE0"

------=_NextPart_001_001F_01BD597B.B0899CE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

-----Original Message-----
From: jgross <[email-masked]>
To: [email-masked] <[email-masked]>
Date: 27 March 1998 12:20

------=_NextPart_001_001F_01BD597B.B0899CE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN">
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><B>-----Original =
Message-----</B><BR><B>From:=20
</B>jgross &lt;<A=20
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;<B=
R><B>To:=20
</B><A href=3D"mailto:[email-masked]">[email-masked]</A> &lt;<A=20
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;<BR><B>Date:=
 </B>27=20
March 1998 12:20<BR><BR></DIV></FONT>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_001_001F_01BD597B.B0899CE0--

------=_NextPart_000_001E_01BD597B.B0899CE0
Content-Type: message/rfc822;
	name="Re 'Signature Purpose' attribute.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="Re 'Signature Purpose' attribute.eml"

From: "John Ross" <[email-masked]>
To: "John Pawling" <[email-masked]>,
	"Tim Dean" <[email-masked]>,
	"'Russ Housley'" <[email-masked]>
Cc: "Ietf distribution list" <[email-masked]>
Subject: Re: 'Signature Purpose' attribute?
Date: Fri, 27 Mar 1998 12:13:59 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4

John

I can see some logic in mandating that  there must be a consistent value
eSSSecurityLabel(s)  at each layer of signedData.  Your reasoning being that
it needs complex access control rules on reception if different values are
allowed at the same level. To some extend I concur, specially because the
SecurityPolicyIdentifier is optionally present in eSSSecurityLabel .

The primary issue I am concerned with in the multi-wrapping solution is;
the processing requirement on reception for eSSSecurityLabel(s) which are
not "understood" or can be "miss-understood" in the receiving domain at the
various levels of wrapping.

Your concern about complex access control rules still applies in the
multi-wrapping case.  Whenever multiple labels can exists, complex access
control rules are needed to process them.

When the eSSSecurityLabel is critical, the recipient environment must do
something with it.  What it does, will depend on its understanding of the
semantics of the information in the security label.  In many cases the
semantics and access control requirements can be determined as part of the
SecurityPolicyIdentifier, but that element may be absent from the
eSSSecurityLabel .  The result of this is a recipient may have mandatory
access control rules enforced on him/her based on an invalid
eSSSecurityLabel for his/her domain.

I think, the problem can be solved in several ways, including:
1: Making the SecurityPolicyIdentifier a mandatory part of
eSSSecurityLabel(s), and make the access control processing of the
eSSSecurityLabel depending on supporting the value of the
SecurityPolicyIdentifier.
2: Defining more precisely  the processing rules for handling of the
eSSSecurityLabel(s) on reception at the various levels of nesting(wrapping).

JR

-----Original Message-----
From: John Pawling <[email-masked]>
To: John Ross <[email-masked]>; 'Russ Housley'
<[email-masked]>; Tim Dean <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Thursday, March 26, 1998 7:13 PM
Subject: RE: 'Signature Purpose' attribute?

>John,
>
>Your requirements can be met be including the various differing
>eSSecurityLabels in nested signedData objects. The original signer could
>include her eSSSecurityLabel in the original, inner signedData layer.  The
>international/boundary gateway could include its eSSSecuritylabel in an
>outer signedData layer that encapsulates the original, inner signedData
>layer.  This preserves the originator's signature and eSSSecurityLabel
>end-to-end.  Furthermore, this stratgey allows the gateway to include its
>mapped eSSSecurityLabel in the outer signedData layer without corrupting
the
>original signer's eSSecurityLabel in the inner signedData layer.  It is
>imperative that the original signer's eSSSecurityLabel must not be
>corrupted.  If that is allowed to happen, then the original signer is not
>being provided with the security services that she requested.
>
>I respectfully disagree with your statement that "there is a problem with
>the outer-signature (double wrapping) proposal and the current S/MIME
access
>control rules."  ESS does not dictate how access control is to be
performed.
>ESS does not dictate the application's actions if the access control fails.
>ESS makes statements like "the application SHOULD..."  and "the receiving
>agent MUST warn the user of this condition".  ESS does NOT state "The
>application MUST reject the message if access control fails."  This is a
>matter of local policy.
>
>All that I am trying to state in my series of rebuttals is that we should
>simplify the access control decision process by requiring all
>eSSSecurityLabels included in a single signedData object to be identical.
>If differing eSSSecurityLabels are allowed in the same signerInfo or same
>signedData, then there will be room for confusion and contradiction when
>different labels are processed by the recipient as part of the same
>cumulative access control decision applied to the individual signedData
>object.  I believe that it is impractical to try to force the S/MIME
>community into accepting a complicated access control decision strategy
such
>as would be required to define the rules to process multiple differing
>eSSSecurityLabels included in the same signerInfo or same signedData.
>
>In summary, I believe that the ESSSecurityLabel strategy should remain as
is.
>
>================================
>John Pawling, [email-masked]
>J.G. Van Dyke & Associates, Inc.
>www.jgvandyke.com
>================================
>
>
>
>At 11:13 AM 3/25/98 -0800, John Ross wrote:
>>Russ,
>>
>>The problem with your proposal of removing the originator signature an
>replace it with a new signature, is that many international/boundary
>gateways may want to perform label mapping and still require the
originators
>signatures to go end to end (i.e pass through gateways unaltered).
>>
>>I also I think there is a problem with the outer-signature (double
>wrapping) proposal and the current S/MIME access control rules.  Under the
>double wrapping  proposals, an international/boundary gateway will need to
>generate an outer-signature which would includes the national/domain
>specific eSSSecuritylabel, this may be in addition to (and different from)
>the eSSSecuritylabel in the originators signature. However, if I understand
>the current access control rules of s/mime correctly, it is mandatory that
>both the originators eSSSecuritylabel, and the outer wrapped gateway
>eSSSecuritylabel shall be processed by the recipient. (i.e. local recipient
>access control must be based on all labels).  The problem is that, the
inner
>eSSSecuritylabel may have no semantics in the recipients environment.  So
>the access control decision can only be based on the outer eSSSecuritylabel
>which as generated by the gateway.
>>
>>Thus I think, the access control rules in s/mime need to be made dependant
>on the security policy identifier (which is part of the eSSSecuritylabel).
>This would allow the access control decision to be made based on all
>eSSSecuritylabel were the policy identifier is understood and supported by
>the recipient.  Any eSSSecuritylabel present at any  level (originators,
>wrapped or triple wrapped) may be ignore (as to the enforcement of access
>control rules) if the policy identifier is not understood or supported
>>
>>I think the above rule, must still be subject to the criticality rules.
The
>implementation implications of both rules would be to enforce correctly
>process the policy identifier  and hence determine if the eSSSecuritylabel
>was applicable or not for local access control processing.
>>
>>John Ross
>>
>>-----Original Message-----
>>From: Russ Housley [SMTP:[email-masked]]
>>Sent: Tuesday, March 24, 1998 11:21 AM
>>To: Tim Dean
>>Cc: [email-masked]
>>Subject: RE: 'Signature Purpose' attribute?
>>
>>Tim:
>>
>>If a security authority wants to change the label, then it must remove the
>>originator signature an replace it with a new signature.
>>
>>User agent processing will become overly complex if we allow there to be
>>multiple labels on a content.
>>
>>Russ
>>
>>
>>At 11:48 AM 3/23/98 +0000, Tim Dean wrote:
>>>John,
>>>
>>>>>3) I like the text in ESS as it stands now, but there may be
suggestions
>>>>to modify the syntax and operation of eSSSecurityLabel to accommodate
other
>>>>requirements.  If ESS were changed, the example might apply.
>>>
>>>>[JSP: IMHO, the ESS text must stand.  Your example is a good reason why
it
>>>>must stand.  If the original signer included an eSSSecurityLabel in the
>>>>original signedData object then additional signer's of that original
>>>>signedData object MUST not be allowed to include different security
labels
>>>>in signerInfos within the same signedData object.  If that were to be
>>>>allowed, then there would be mass confusion and room for contradiction
when
>>>>different labels are processed by the recipient as part of the same
>>>>cumulative access control decision applied to the individual signedData
>>>>object.  Furthermore, if the original signer did not include an
>>>>eSSSecurityLabel in the original signedData object, then the original
signer
>>>>made the decision that the content did not need to be labeled and that
>>>>access control is not required to access the content.  In all cases, all
>>>>intermediate entities MUST respect the original signer's wishes
regarding
>>>>the eSSSecurityLabel that she included in the signedData that she
created or
>>>>else she is not receiving the security services that she requested when
she
>>>>originally signed the content.]
>>>
>>>I must respectfully disagree that in all cases, all intermediate entities
>>must respect the original signer's
>>>wishes regarding the label.  In many environments, such as ours, security
>>authorities have the power of
>>>veto over any label created by an originator.  In electronic (S/MIME)
>>terms, my 'environment' will
>>>probably create the label automatically for me.  That 'environment' could
>>be the current enclave/domain
>>>where I am working, or the machine I am currently logged onto, or even
the
>>client software on the
>>>machine, e.g. on a Compartmented Mode Workstation.  In certain cases the
>>labelling authority will be a
>>>human-being acting as a 'release authority'.  This signed label will
>>probably be checked by the Guard
>>>before onward transmission.
>>>
>>>In short, I want to create and sign messages as an originator; some third
>>party will counter-sign and label
>>>them for me.  I am very much hoping that ESS and S/MIME in general will
>>accommodate this model as
>>>well as other security policies.  As a general principle, I believe ESS
>>and S/MIME should be security-
>>>policy neutral wherever possible.  I am very much hoping that with the
>>addition of sig-purpose attribute
>>>'content Reviewer', my particular policy could be supported.  For this
>>reason, I would very much like all
>>>of Dave Kemp's original examples, including security label, to remain.
>>>
>>>Tim
>>>
>>>----------
>>>From:  John Pawling [SMTP:[email-masked]]
>>>Sent:  Thursday, March 19, 1998 10:34 PM
>>>To:  David P. Kemp; [email-masked]
>>>Subject:  Re: 'Signature Purpose' attribute?
>>>
>>>Dave,
>>>
>>>Please see my responses in-line:
>>>
>>>
>>>At 04:30 PM 3/19/98 -0500, David P. Kemp wrote:
>>>>> From: [email-masked] (John Pawling)
>>
>>>>>
>>>>> The contentReviewer is only allowed to
>>>>> include an eSSSecurityLabel authenticated attribute in the signerInfo
that
>>>>> she signs if there was already an eSSSecurityLabel attribute present
in
>>the
>>>>> signerInfo(s) already included in the original signedData object.
>>>>
>>>>
>>>>John,
>>>>
>>>>  It was just an example, but thanks for pointing out the restrictions
on
>>>>eSSSecurityLabel.  I can think of three rebuttals:
>>>>
>>>>1) the above quoted sentence isn't necessarily true in all cases,
because
>>>>a security gateway could take a message (either signed or plain old
email)
>>>>and wrap it in a new signedData.
>>>
>>>[JSP: I agree that an intermediate entity can encapsulate the original
>>>signedData object within a new outer signedData object.  The intermediate
>>>entity can then include the appropriate eSSSecurityLabel attribute, if
>>>required, in the signerInfo within the new outer signedData object.  The
>>>intermediate entity's eSSSecurityLabel attribute may be different than
that
>>>included in the inner signedData object.  IMHO, that is acceptable
because
>>>the recipient MUST make a separate access control decision for each of
the
>>>signedData layers.  The recipient MUST process the eSSSecurityLabel in
each
>>>signedData object that it verifies.  Because the recipient will verify
both
>>>the outer and inner signedData objects, then it MUST process the
>>>eSSSecurityLabel attribute in each of the signedData objects.  Therefore,
>>>both the original signer's and intermediate entity's eSSSecurityLabels
are
>>>processed by the recipient.  An important point to note is that the
>>>recipient software makes a separate access control decision for each
>>>signedData object.  IMHO, that is the primary difference between
processing
>>>eSSSecurityLabels included in layered signedData objects versus those
>>>included in multiple signerInfos included in the same signedData object.
In
>>>the latter case, all eSSSecurityLabels included in the various
signerInfos
>>>(that are verified) are checked as part of the same cumulative access
>>>control decision process applied to the individual signedData object.
>>>
>>>To get back to your original rebuttal, if the intermediate entity adds
the
>>>outer signedData, then IMHO it is not a contentReviewer, it is a
>>>contentOriginator because it is creating a new signedData object.
>>>Therefore, I believe that my comment still stands.]
>>>
>>>
>>>>2) eSSSecurityLabel is defined in the ESS document, whereas
signaturePurpose
>>>>has been proposed for inclusion in CMS.  CMS may be used in non-S/MIME
>>>>applications which have different compliance requirements than S/MIME
and
>>>>which do not refer to ESS at all.
>>>
>>>[JSP: One of the major goals of ESS is to define standard attributes for
use
>>>with CMS.  The CMS spec MUST NOT make statements (such as your example
IMHO)
>>>that are contradictory to the principles of ESS (which CMS currently does
>>>not).  The best strategy would be for CMS not to mention security labels
at
>>>all (which it currently does not).  Therefore, I recommend that you
should
>>>either remove the security label example or move the signaturePurpose
>>>attribute to ESS and discuss eSSSecurityLabels.  Furthermore,
applications
>>
>>>that use eSSSecurityLabels attributes MUST set the attributes to be
critical
>>>so if an application needs to use security labels it would be best if it
>>>were to implement eSSSecurityLabels to avoid interoperability problems
with
>>>those applications that are implementing the standard eSSSecurityLabels.]
>>>
>>>
>>>>3) I like the text in ESS as it stands now, but there may be suggestions
>>>>to modify the syntax and operation of eSSSecurityLabel to accommodate
other
>>>>requirements.  If ESS were changed, the example might apply.
>>>
>>>[JSP: IMHO, the ESS text must stand.  Your example is a good reason why
it
>>>must stand.  If the original signer included an eSSSecurityLabel in the
>>>original signedData object then additional signer's of that original
>>>signedData object MUST not be allowed to include different security
labels
>>>in signerInfos within the same signedData object.  If that were to be
>>>allowed, then there would be mass confusion and room for contradiction
when
>>>different labels are processed by the recipient as part of the same
>>>cumulative access control decision applied to the individual signedData
>>>object.  Furthermore, if the original signer did not include an
>>>eSSSecurityLabel in the original signedData object, then the original
signer
>>>made the decision that the content did not need to be labeled and that
>>>access control is not required to access the content.  In all cases, all
>>>intermediate entities MUST respect the original signer's wishes regarding
>>>the eSSSecurityLabel that she included in the signedData that she created
or
>>>else she is not receiving the security services that she requested when
she
>>>originally signed the content.]
>>>
>>>>
>>>>
>>>>     dpk
>>>>
>>>
>>
>>
>

------=_NextPart_000_001E_01BD597B.B0899CE0--

From: John Ross <[email-masked]>
To: Ietf distribution list <[email-masked]>
Subject: protected content
Date: Fri, 27 Mar 1998 11:27:39 -0800
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0004_01BD5973.597C4770
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

How can the type of protected information be identified in s/mime.

It is the intention of the S/MIME specification to be used to protect =
information which is encoded in any form.  If multi S/MIME wrapping is =
performed, inner most content is identified a "id-data".  This gives no =
clue as to the encoding or type of the information being protected. Does =
anyone agree that it would be useful to identify the type and encoding =
of the protected information? or do you disagree?

In some off-line discussion it was sujested that the contentHints =
attribute as defined in ESS may be used for this purpose. Also , the =
ess-02 draft eluded to an attribute called "encapsulatedContentType" =
which may have been intended to meet this requirement.=20

I think the title of contentHints is wrong if is is used for this =
purpose, second as defined currently it is not up to the job.

If the above is agree, a new type of ttribute is should be defined =
replacing contentHints.
The following is a starter for ten based  based on renaming and =
extendingn the current "contentHints" attribute.

ProtectedInformationTypeAttribute ::=3D SEQUNCE {
contentDescription=20
  =20

------=_NextPart_000_0004_01BD5973.597C4770
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>How can the type of protected =
information be=20
identified in s/mime.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>It is the intention of the S/MIME =
specification=20
to be used to protect information which is encoded in any form.&nbsp; If =
multi=20
S/MIME wrapping is performed,</FONT><FONT color=3D#000000 size=3D2> =
inner most=20
content is identified a &quot;id-data&quot;.&nbsp; This gives no clue as =
to the=20
encoding or type of the information being protected. Does anyone agree =
that it=20
would be useful to identify the type and encoding of the protected =
information?=20
or do you disagree?</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>In some off-line discussion it was =
sujested that=20
the contentHints attribute as defined in ESS may be used for this =
purpose. Also=20
, the ess-02 draft eluded to an attribute called=20
&quot;encapsulatedContentType&quot; which may have been intended to meet =
this=20
requirement.&nbsp;</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>I think the title of contentHints is =
wrong if is=20
is used for this purpose, second as defined currently it is not up to =
the=20
job.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>If the above is agree, a new type of ttribute is =
should be=20
defined replacing contentHints.</FONT></DIV>
<DIV><FONT size=3D2>The following is a starter for ten based&nbsp; based =
on=20
renaming and extendingn the current &quot;contentHints&quot;=20
attribute.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>ProtectedInformationTypeAttribute ::=3D SEQUNCE =
{</FONT></DIV>
<DIV><FONT size=3D2>contentDescription </FONT></DIV>
<DIV><FONT color=3D#000000 =
size=3D2>&nbsp;&nbsp;&nbsp;</FONT></DIV></BODY></HTML>

------=_NextPart_000_0004_01BD5973.597C4770--

From: John Ross <[email-masked]>
To: Ietf distribution list <[email-masked]>
Subject: protected content
Date: Fri, 27 Mar 1998 11:54:51 -0800
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0014_01BD5977.2A5CB160
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

How can the type of protected information be identified in s/mime.
=20
It is the intention of the S/MIME specification to be used to protect =
information which is encoded in any form,  not just using MIME.  If =
believe the convention in CMS is,  when multi S/MIME wrapping is =
performed the inner most content is identified a "id-data" in =
contentType attribute.  This gives no clue as to the encoding or type of =
the information which being protected. Does anyone agree that it would =
be useful to identify the type and encoding of the protected =
information? or do you disagree? or is if you think it is currently =
identified , how is this done?
=20
In some off-line discussion it was proposed that the contentHints =
attribute as defined in ESS may be used for this purpose. Also , the =
ess-02 draft eluded to an attribute called "encapsulatedContentType" =
which may have been intended to meet this requirement.=20
=20
I think the title of contentHints is wrong if is used for this purpose, =
second as defined currently it is not up to the job.
=20
If the above is agree, a new type of attribute is should be defined =
replacing contentHints.
The following is a starter for ten based on renaming and extending the =
current "contentHints"  and using some of the old =
"encapsulatedContentType" syntax.
=20
ProtectedInformationTypeAttribute ::=3D SEQUENCE {
  contentDescription [0] IMPLICIT OCTET STRING SIZE (1..MAX) OPTIONAL,
    -- If contentDescription is used, its contents MUST be in UTF8 =
format
  contentType [1] ContentType OPTIONAL
  protectedContentType [2} ProtectedContentType OPTIONAL }

ContentType is a defined by CMS
ProtectedContentType ::=3D CHOICE {
  built-in BuiltinContentType,
  external ExternalContentType,
  externalWithSubtype ExternalContentWithSubtype }

BuiltinContentType ::=3D [APPLICATION 6] INTEGER {
    -- APPLICATION 6 is used for binary compatibility with X.411
  unidentified (0),
  external (1),
  interpersonal-messaging-1984 (2),
  interpersonal-messaging-1988 (22),
  edi-messaging (35),
  voice-messaging (40)} (0..ub-built-in-content-type)

ub-built-in-content-type INTEGER ::=3D 32767

ExternalContentType ::=3D OBJECT IDENTIFIER

ExternalContentWithSubtype ::=3D SEQUENCE {
  external ExternalContentType,
  subtype OCTET STRING}

Any Comments?

------=_NextPart_000_0014_01BD5977.2A5CB160
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN">
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>How can the type of protected =
information be=20
identified in s/mime.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>It is the intention of the S/MIME =
specification=20
to be used to protect information which is encoded in any form,&nbsp; =
not just=20
using MIME.&nbsp; If believe the convention in CMS is,&nbsp; when multi =
S/MIME=20
wrapping is performed the</FONT><FONT color=3D#000000 size=3D2> inner =
most content=20
is identified a &quot;id-data&quot; in contentType attribute.&nbsp; This =
gives=20
no clue as to the encoding or type of the information which being =
protected.=20
Does anyone agree that it would be useful to identify the type and =
encoding of=20
the protected information? or do you disagree? or is if you think it is=20
currently identified , how is this done?</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>In some off-line discussion it was =
proposed that=20
the contentHints attribute as defined in ESS may be used for this =
purpose. Also=20
, the ess-02 draft eluded to an attribute called=20
&quot;encapsulatedContentType&quot; which may have been intended to meet =
this=20
requirement.&nbsp;</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>I think the title of contentHints is =
wrong if is=20
used for this purpose, second as defined currently it is not up to the=20
job.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>If the above is agree, a new type of attribute is =
should be=20
defined replacing contentHints.</FONT></DIV>
<DIV><FONT size=3D2>The following is a starter for ten based on renaming =
and=20
extending the current &quot;contentHints&quot;&nbsp; and using some of =
the old=20
&quot;encapsulatedContentType&quot; syntax.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>ProtectedInformationTypeAttribute ::=3D SEQUENCE =
{</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp; contentDescription [0] =
IMPLICIT OCTET=20
STRING SIZE (1..MAX) OPTIONAL,<BR>&nbsp;&nbsp;&nbsp; -- If =
contentDescription is=20
used, its contents MUST be in UTF8 format<BR>&nbsp; contentType [1] =
ContentType=20
OPTIONAL</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp; protectedContentType [2}=20
ProtectedContentType OPTIONAL }</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>ContentType is a defined by =
CMS</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>ProtectedContentType ::=3D =
</FONT><FONT=20
color=3D#000000 size=3D2>CHOICE {<BR>&nbsp; built-in =
BuiltinContentType,<BR>&nbsp;=20
external ExternalContentType,<BR>&nbsp; externalWithSubtype=20
ExternalContentWithSubtype }</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>BuiltinContentType ::=3D =
[APPLICATION 6] INTEGER=20
{<BR>&nbsp;&nbsp;&nbsp; -- APPLICATION 6 is used for binary =
compatibility with=20
X.411<BR>&nbsp; unidentified (0),<BR>&nbsp; external (1),<BR>&nbsp;=20
interpersonal-messaging-1984 (2),<BR>&nbsp; interpersonal-messaging-1988 =

(22),<BR>&nbsp; edi-messaging (35),<BR>&nbsp; voice-messaging (40)}=20
(0..ub-built-in-content-type)</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>ub-built-in-content-type INTEGER =
::=3D=20
32767</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>ExternalContentType ::=3D OBJECT=20
IDENTIFIER</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>ExternalContentWithSubtype ::=3D =
SEQUENCE=20
{<BR>&nbsp; external ExternalContentType,<BR>&nbsp; subtype OCTET=20
STRING}</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Any =
Comments?</FONT></DIV></BODY></HTML>

------=_NextPart_000_0014_01BD5977.2A5CB160--

From: John Ross <[email-masked]>
To: "Bonatti, Chris" <[email-masked]>, [email-masked], John Pawling <[email-masked]>
MMDF-Warning:  Parse error in original version of preceding line at post.mail.demon.net
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Date: Fri, 27 Mar 1998 09:08:05 -0800
Sender: [email-masked]

John Pawling wrote:
...........an important point to note is that the recipient software makes
>a separate access control decision for each signedData object..........

Question:
In your view, does this mean that if the recipinet does not understand the
policy id in the eSSSecuriltylabel that he may ignore the label in the
access control decision, even though he has verified the signature of the
signedData object to which it relateds?

-----Original Message-----
From: John Pawling <[email-masked]>
To: Bonatti, Chris <[email-masked]>; [email-masked]
<[email-masked]>
Date: Thursday, March 26, 1998 6:34 PM
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)

>Chris,
>
>I respectfully disagree with your proposal.  The two different labels that
>you require can be implemented by including each label in a separate
>signedData layer of the message.  The original signer could include the
>"information label" in the original, inner signedData layer.  The "system
>label" could be included in an outer signedData layer that encapsulates the
>original, inner signedData layer.  This is the optimal strategy because the
>recipient MUST make a separate access control decision for each of the
>signedData layers.  The recipient MUST process the eSSSecurityLabel in each
>signedData object that it verifies.  Because the recipient will verify both
>the outer and inner signedData objects, then it MUST process the
>eSSSecurityLabel attribute in each of the signedData objects.  Therefore,
>both the "system" and "information" eSSSecurityLabels are processed by the
>recipient.  An important point to note is that the recipient software makes
>a separate access control decision for each signedData object.  IMHO, that
>is the primary difference between processing
>eSSSecurityLabels included in layered signedData objects versus those
>included in multiple signerInfos included in the same signedData object.
In
>the latter case, all eSSSecurityLabels included in the various signerInfos
>(that are verified) are checked as part of the same cumulative access
>control decision process applied to the individual signedData object.  If
>multiple eSSSecurityLabels were allowed in the same signerInfo or same
>signedData, then there would be mass confusion and room for contradiction
>when different labels are processed by the recipient as part of the same
>cumulative access control decision applied to the individual signedData
>object.  I believe that it is impractical to try to force the S/MIME
>community into accepting a complicated access control decision strategy
such
>as would be required to define the rules to process multiple
>eSSSecurityLabels included in the same signerInfo or same signedData.
>
>IMHO, the cost in efficiency of requiring nested signedData objects to
>convey multiple, different eSSSecurityLabels is well worth the clarity
gained.
>
>In summary, I believe that the ESSSecurityLabel should remain as is.
>
>================================
>John Pawling, [email-masked]
>J.G. Van Dyke & Associates, Inc.
>www.jgvandyke.com
>================================
>
>
>
>At 11:08 AM 3/26/98 -0500, Bonatti, Chris wrote:
>>    I have some other concerns with the current restrictions on ESS
>security label.  As long as each instance of the label in the signedData
>element must contain the same value, I think there are very important
>scenarios that cannot be serviced.
>>
>>    It may be necessary to for the signer to include multiple instances of
>the security label using different policy IDs and/or security category
>structures for the purpose of satisfying the requirements of multiple
policy
>domains.  This would require a change to the wording of ESS clause 3.1.1.
>For simplistic labeling, this is probably not a concern.  However, we don't
>have (nor are we likely to soon have) a standard for representing
>categories/compartments in varying security domains.  As long as this is
the
>case, we are going to have variations in the labeling requirements on a
>per-policy basis.  This will essentially require label conversion (as John
>Ross suggests) or multiple signed labels with different values.
>>
>>    There is another circumstance in which it may be necessary to include
>either or both of an "information" or "system" security label.  If both
>labels are present, the information label will convey the "true" label of
>the content from the originator to the recipient.  The system label will
>convey the label of the content to be used for access control purposes.
>This split label may, among other things, be used to convey the actual
>content classification when used in a system-high environment.  Whether
>either or both of these labels is present is a function of security policy.
>The security policy ID may, in fact, be used to discriminate between these
>two.  This scenario likewise requires a change to ESS clause 3.1.1.
>>
>>    It should also noted that in cases where multiple labels are provided
>by the same signer, it would be VERY inefficient to convey each of these in
>a separate signerInfo elements because of the overhead of multiple
signature
>operations.  Therefore, the implied restriction in 3.1.1 on multiple
>instances of the label attribute might not make sense.
>>
>>    I would suggest that a better way to handle this would be to make the
>ESS security label attribute internally multivalued and include a mechanism
>for identifying the purpose of each instance of the label.  For example,
the
>ESS label attribute could be changed to the following:
>>
>>        ESSSecurityLabel ::= SEQUENCE OF LabelItem
>>
>>        LabelItem ::= SEQUENCE {
>>            security-label    SecurityLabel,
>>            label-purpose    LabelPurpose }
>>
>>        LabelPurpose ::= ENUMERATED {
>>             system-label (0),
>>             information-label (1), ... }
>>
>>        SecurityLabel ::= SET {
>>            security-policy-identifier    SecurityPolicyIdentifier
OPTIONAL,
>>            security-classification        SecurityClassification
OPTIONAL,
>>            privacy-mark                    ESSPrivacyMark OPTIONAL,
>>            security-categories            SecurityCategories OPTIONAL }
>>
>>This plus some better wording in secution 3 of ESS could open S/MIME up to
>support a more complex labeling environment.
>>
>>    Thoughts?
>>
>>Chris
>>
>>
>> ---------------------------------------------------------------
>> |  International Electronic Communication Analysts, Inc.      |
>> |  Christopher D. Bonatti                 9010 Edgepark Road  |
>> |  Vice-president                     Vienna, Virginia 22182  |
>> |  [email-masked]   Tel: 301-212-9428   Fax: 703-506-8377  |
>> ---------------------------------------------------------------
>>
>>
>>
>>
>>
>>
>

From: John Ross <[email-masked]>
To: [email-masked], Paul Hoffman / IMC <[email-masked]>
MMDF-Warning:  Parse error in original version of preceding line at post.mail.demon.net
Subject: Re: Comment on ESS and Privacy Marks
Date: Fri, 27 Mar 1998 08:28:59 -0800
Sender: [email-masked]

The problem with the current proposal is not only on origination, but on
reception. An implementation which understands the X.411 label will expect
printable string and not expect UTF-8, so what does it do if the UTF-8
string contains extended characters, it may try to display them as printable
characters, it may not?

I agree with Chris that a more elegant solution to this problem would be to
define a security category to convey the enhanced string value?  this offers
a fully flexible solution which uses the valid extension mechanism provided
by the X.411 label .

John Ross

-----Original Message-----
From: Paul Hoffman / IMC <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Thursday, March 26, 1998 9:51 AM
Subject: Re: Comment on ESS and Privacy Marks

>At 11:09 AM 3/26/98 -0500, Bonatti, Chris wrote:
>>I think that expanded character sets are generally useful, but you need to
>>recognize that you're not necessarily working from a blank slate.  The
label
>>in the previous ESS draft was aligned with the X.411 security label.  This
>>label structure has gained a fair amount of acceptance, and is used in a
>>number of areas including X.500, and non-OSI systems.  I was pleased to
see
>>it appear in ESS.  Changing the privacy-mark field makes the ESS label
>>incompatible with the existing X.411 security label structure.  Using an
>>alternate encoding or character set for the existing field is certain to
>>impact existing implementations that provide and consume security labels.
>
>If the MUA creating the privacy mark wants to be compliant with X.411, it
>can: it chooses the pString value in ESSPrivacyMark. If it wants to have
>their mark use characters outside the PrintableString charset (for
>instance, if the mark needs to include a non-ASCII text character or if the
>sender wants to include an Internet mail address in the privacy mark), it
>uses the utf8String value. The current label is *not* incompatible with
>X.411; one of the two choices is. It is quite easy to create
>X.411-compatible privacy labels if what you want to say in the label
>doesn't need any characters outside the PrintableString charset.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium

Date: Thu, 26 Mar 1998 21:50:54 -0500
To: John Ross <[email-masked]>, "'Russ Housley'" <[email-masked]>, Tim Dean <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: 'Signature Purpose' attribute?
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

John,

Your requirements can be met be including the various differing
eSSecurityLabels in nested signedData objects. The original signer could
include her eSSSecurityLabel in the original, inner signedData layer.  The
international/boundary gateway could include its eSSSecuritylabel in an
outer signedData layer that encapsulates the original, inner signedData
layer.  This preserves the originator's signature and eSSSecurityLabel
end-to-end.  Furthermore, this stratgey allows the gateway to include its
mapped eSSSecurityLabel in the outer signedData layer without corrupting the
original signer's eSSecurityLabel in the inner signedData layer.  It is
imperative that the original signer's eSSSecurityLabel must not be
corrupted.  If that is allowed to happen, then the original signer is not
being provided with the security services that she requested.  

I respectfully disagree with your statement that "there is a problem with
the outer-signature (double wrapping) proposal and the current S/MIME access
control rules."  ESS does not dictate how access control is to be performed.
ESS does not dictate the application's actions if the access control fails.
ESS makes statements like "the application SHOULD..."  and "the receiving
agent MUST warn the user of this condition".  ESS does NOT state "The
application MUST reject the message if access control fails."  This is a
matter of local policy.

All that I am trying to state in my series of rebuttals is that we should
simplify the access control decision process by requiring all
eSSSecurityLabels included in a single signedData object to be identical.
If differing eSSSecurityLabels are allowed in the same signerInfo or same
signedData, then there will be room for confusion and contradiction when
different labels are processed by the recipient as part of the same
cumulative access control decision applied to the individual signedData
object.  I believe that it is impractical to try to force the S/MIME
community into accepting a complicated access control decision strategy such
as would be required to define the rules to process multiple differing
eSSSecurityLabels included in the same signerInfo or same signedData.  

In summary, I believe that the ESSSecurityLabel strategy should remain as is.

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

At 11:13 AM 3/25/98 -0800, John Ross wrote:
>Russ, 
>
>The problem with your proposal of removing the originator signature an
replace it with a new signature, is that many international/boundary
gateways may want to perform label mapping and still require the originators
signatures to go end to end (i.e pass through gateways unaltered). 
>
>I also I think there is a problem with the outer-signature (double
wrapping) proposal and the current S/MIME access control rules.  Under the
double wrapping  proposals, an international/boundary gateway will need to
generate an outer-signature which would includes the national/domain
specific eSSSecuritylabel, this may be in addition to (and different from)
the eSSSecuritylabel in the originators signature. However, if I understand
the current access control rules of s/mime correctly, it is mandatory that
both the originators eSSSecuritylabel, and the outer wrapped gateway
eSSSecuritylabel shall be processed by the recipient. (i.e. local recipient
access control must be based on all labels).  The problem is that, the inner
eSSSecuritylabel may have no semantics in the recipients environment.  So
the access control decision can only be based on the outer eSSSecuritylabel
which as generated by the gateway. 
>
>Thus I think, the access control rules in s/mime need to be made dependant
on the security policy identifier (which is part of the eSSSecuritylabel).
This would allow the access control decision to be made based on all
eSSSecuritylabel were the policy identifier is understood and supported by
the recipient.  Any eSSSecuritylabel present at any  level (originators,
wrapped or triple wrapped) may be ignore (as to the enforcement of access
control rules) if the policy identifier is not understood or supported 
>
>I think the above rule, must still be subject to the criticality rules. The
implementation implications of both rules would be to enforce correctly
process the policy identifier  and hence determine if the eSSSecuritylabel
was applicable or not for local access control processing.
>
>John Ross
>
>-----Original Message-----
>From:	Russ Housley [SMTP:[email-masked]]
>Sent:	Tuesday, March 24, 1998 11:21 AM
>To:	Tim Dean
>Cc:	[email-masked]
>Subject:	RE: 'Signature Purpose' attribute?
>
>Tim:
>
>If a security authority wants to change the label, then it must remove the
>originator signature an replace it with a new signature.
>
>User agent processing will become overly complex if we allow there to be
>multiple labels on a content.
>
>Russ
>
>
>At 11:48 AM 3/23/98 +0000, Tim Dean wrote:
>>John,
>>
>>>>3) I like the text in ESS as it stands now, but there may be suggestions
>>>to modify the syntax and operation of eSSSecurityLabel to accommodate other
>>>requirements.  If ESS were changed, the example might apply.
>>
>>>[JSP: IMHO, the ESS text must stand.  Your example is a good reason why it
>>>must stand.  If the original signer included an eSSSecurityLabel in the
>>>original signedData object then additional signer's of that original
>>>signedData object MUST not be allowed to include different security labels
>>>in signerInfos within the same signedData object.  If that were to be
>>>allowed, then there would be mass confusion and room for contradiction when
>>>different labels are processed by the recipient as part of the same
>>>cumulative access control decision applied to the individual signedData
>>>object.  Furthermore, if the original signer did not include an
>>>eSSSecurityLabel in the original signedData object, then the original signer
>>>made the decision that the content did not need to be labeled and that
>>>access control is not required to access the content.  In all cases, all
>>>intermediate entities MUST respect the original signer's wishes regarding
>>>the eSSSecurityLabel that she included in the signedData that she created or
>>>else she is not receiving the security services that she requested when she
>>>originally signed the content.]
>>
>>I must respectfully disagree that in all cases, all intermediate entities
>must respect the original signer's
>>wishes regarding the label.  In many environments, such as ours, security
>authorities have the power of
>>veto over any label created by an originator.  In electronic (S/MIME)
>terms, my 'environment' will
>>probably create the label automatically for me.  That 'environment' could
>be the current enclave/domain
>>where I am working, or the machine I am currently logged onto, or even the
>client software on the
>>machine, e.g. on a Compartmented Mode Workstation.  In certain cases the
>labelling authority will be a
>>human-being acting as a 'release authority'.  This signed label will
>probably be checked by the Guard
>>before onward transmission.
>>
>>In short, I want to create and sign messages as an originator; some third
>party will counter-sign and label
>>them for me.  I am very much hoping that ESS and S/MIME in general will
>accommodate this model as
>>well as other security policies.  As a general principle, I believe ESS
>and S/MIME should be security-
>>policy neutral wherever possible.  I am very much hoping that with the
>addition of sig-purpose attribute
>>'content Reviewer', my particular policy could be supported.  For this
>reason, I would very much like all
>>of Dave Kemp's original examples, including security label, to remain.
>>
>>Tim 
>>
>>----------
>>From:  John Pawling [SMTP:[email-masked]]
>>Sent:  Thursday, March 19, 1998 10:34 PM
>>To:  David P. Kemp; [email-masked]
>>Subject:  Re: 'Signature Purpose' attribute?
>>
>>Dave,
>>
>>Please see my responses in-line:
>>
>>
>>At 04:30 PM 3/19/98 -0500, David P. Kemp wrote:
>>>> From: [email-masked] (John Pawling)
>
>>>> 
>>>> The contentReviewer is only allowed to
>>>> include an eSSSecurityLabel authenticated attribute in the signerInfo that
>>>> she signs if there was already an eSSSecurityLabel attribute present in
>the
>>>> signerInfo(s) already included in the original signedData object.
>>>
>>>
>>>John,
>>>
>>>  It was just an example, but thanks for pointing out the restrictions on
>>>eSSSecurityLabel.  I can think of three rebuttals:
>>>
>>>1) the above quoted sentence isn't necessarily true in all cases, because
>>>a security gateway could take a message (either signed or plain old email)
>>>and wrap it in a new signedData.
>>
>>[JSP: I agree that an intermediate entity can encapsulate the original
>>signedData object within a new outer signedData object.  The intermediate
>>entity can then include the appropriate eSSSecurityLabel attribute, if
>>required, in the signerInfo within the new outer signedData object.  The
>>intermediate entity's eSSSecurityLabel attribute may be different than that
>>included in the inner signedData object.  IMHO, that is acceptable because
>>the recipient MUST make a separate access control decision for each of the
>>signedData layers.  The recipient MUST process the eSSSecurityLabel in each
>>signedData object that it verifies.  Because the recipient will verify both
>>the outer and inner signedData objects, then it MUST process the
>>eSSSecurityLabel attribute in each of the signedData objects.  Therefore,
>>both the original signer's and intermediate entity's eSSSecurityLabels are
>>processed by the recipient.  An important point to note is that the
>>recipient software makes a separate access control decision for each
>>signedData object.  IMHO, that is the primary difference between processing
>>eSSSecurityLabels included in layered signedData objects versus those
>>included in multiple signerInfos included in the same signedData object.  In
>>the latter case, all eSSSecurityLabels included in the various signerInfos
>>(that are verified) are checked as part of the same cumulative access
>>control decision process applied to the individual signedData object.  
>>
>>To get back to your original rebuttal, if the intermediate entity adds the
>>outer signedData, then IMHO it is not a contentReviewer, it is a
>>contentOriginator because it is creating a new signedData object.
>>Therefore, I believe that my comment still stands.]
>>
>>
>>>2) eSSSecurityLabel is defined in the ESS document, whereas signaturePurpose
>>>has been proposed for inclusion in CMS.  CMS may be used in non-S/MIME
>>>applications which have different compliance requirements than S/MIME and
>>>which do not refer to ESS at all.
>>
>>[JSP: One of the major goals of ESS is to define standard attributes for use
>>with CMS.  The CMS spec MUST NOT make statements (such as your example IMHO)
>>that are contradictory to the principles of ESS (which CMS currently does
>>not).  The best strategy would be for CMS not to mention security labels at
>>all (which it currently does not).  Therefore, I recommend that you should
>>either remove the security label example or move the signaturePurpose
>>attribute to ESS and discuss eSSSecurityLabels.  Furthermore, applications
>
>>that use eSSSecurityLabels attributes MUST set the attributes to be critical
>>so if an application needs to use security labels it would be best if it
>>were to implement eSSSecurityLabels to avoid interoperability problems with
>>those applications that are implementing the standard eSSSecurityLabels.]  
>>
>>
>>>3) I like the text in ESS as it stands now, but there may be suggestions
>>>to modify the syntax and operation of eSSSecurityLabel to accommodate other
>>>requirements.  If ESS were changed, the example might apply.
>>
>>[JSP: IMHO, the ESS text must stand.  Your example is a good reason why it
>>must stand.  If the original signer included an eSSSecurityLabel in the
>>original signedData object then additional signer's of that original
>>signedData object MUST not be allowed to include different security labels
>>in signerInfos within the same signedData object.  If that were to be
>>allowed, then there would be mass confusion and room for contradiction when
>>different labels are processed by the recipient as part of the same
>>cumulative access control decision applied to the individual signedData
>>object.  Furthermore, if the original signer did not include an
>>eSSSecurityLabel in the original signedData object, then the original signer
>>made the decision that the content did not need to be labeled and that
>>access control is not required to access the content.  In all cases, all
>>intermediate entities MUST respect the original signer's wishes regarding
>>the eSSSecurityLabel that she included in the signedData that she created or
>>else she is not receiving the security services that she requested when she
>>originally signed the content.]
>>
>>>
>>>
>>>     dpk
>>>
>> 
>
>

Date: Thu, 26 Mar 1998 21:18:30 -0500
To: "Bonatti, Chris" <[email-masked]>, "[email-masked]" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Sender: [email-masked]

Chris,

I respectfully disagree with your proposal.  The two different labels that
you require can be implemented by including each label in a separate
signedData layer of the message.  The original signer could include the
"information label" in the original, inner signedData layer.  The "system
label" could be included in an outer signedData layer that encapsulates the
original, inner signedData layer.  This is the optimal strategy because the
recipient MUST make a separate access control decision for each of the
signedData layers.  The recipient MUST process the eSSSecurityLabel in each
signedData object that it verifies.  Because the recipient will verify both
the outer and inner signedData objects, then it MUST process the
eSSSecurityLabel attribute in each of the signedData objects.  Therefore,
both the "system" and "information" eSSSecurityLabels are processed by the
recipient.  An important point to note is that the recipient software makes
a separate access control decision for each signedData object.  IMHO, that
is the primary difference between processing
eSSSecurityLabels included in layered signedData objects versus those
included in multiple signerInfos included in the same signedData object.  In
the latter case, all eSSSecurityLabels included in the various signerInfos
(that are verified) are checked as part of the same cumulative access
control decision process applied to the individual signedData object.  If
multiple eSSSecurityLabels were allowed in the same signerInfo or same
signedData, then there would be mass confusion and room for contradiction
when different labels are processed by the recipient as part of the same
cumulative access control decision applied to the individual signedData
object.  I believe that it is impractical to try to force the S/MIME
community into accepting a complicated access control decision strategy such
as would be required to define the rules to process multiple
eSSSecurityLabels included in the same signerInfo or same signedData.  

IMHO, the cost in efficiency of requiring nested signedData objects to
convey multiple, different eSSSecurityLabels is well worth the clarity gained.  

In summary, I believe that the ESSSecurityLabel should remain as is.

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

At 11:08 AM 3/26/98 -0500, Bonatti, Chris wrote:
>    I have some other concerns with the current restrictions on ESS
security label.  As long as each instance of the label in the signedData
element must contain the same value, I think there are very important
scenarios that cannot be serviced.
>
>    It may be necessary to for the signer to include multiple instances of
the security label using different policy IDs and/or security category
structures for the purpose of satisfying the requirements of multiple policy
domains.  This would require a change to the wording of ESS clause 3.1.1.
For simplistic labeling, this is probably not a concern.  However, we don't
have (nor are we likely to soon have) a standard for representing
categories/compartments in varying security domains.  As long as this is the
case, we are going to have variations in the labeling requirements on a
per-policy basis.  This will essentially require label conversion (as John
Ross suggests) or multiple signed labels with different values.
>
>    There is another circumstance in which it may be necessary to include
either or both of an "information" or "system" security label.  If both
labels are present, the information label will convey the "true" label of
the content from the originator to the recipient.  The system label will
convey the label of the content to be used for access control purposes.
This split label may, among other things, be used to convey the actual
content classification when used in a system-high environment.  Whether
either or both of these labels is present is a function of security policy.
The security policy ID may, in fact, be used to discriminate between these
two.  This scenario likewise requires a change to ESS clause 3.1.1.
>
>    It should also noted that in cases where multiple labels are provided
by the same signer, it would be VERY inefficient to convey each of these in
a separate signerInfo elements because of the overhead of multiple signature
operations.  Therefore, the implied restriction in 3.1.1 on multiple
instances of the label attribute might not make sense.
>
>    I would suggest that a better way to handle this would be to make the
ESS security label attribute internally multivalued and include a mechanism
for identifying the purpose of each instance of the label.  For example, the
ESS label attribute could be changed to the following:
>
>        ESSSecurityLabel ::= SEQUENCE OF LabelItem
>
>        LabelItem ::= SEQUENCE {
>            security-label    SecurityLabel,
>            label-purpose    LabelPurpose }
>
>        LabelPurpose ::= ENUMERATED {
>             system-label (0),
>             information-label (1), ... }
>
>        SecurityLabel ::= SET {
>            security-policy-identifier    SecurityPolicyIdentifier OPTIONAL,
>            security-classification        SecurityClassification OPTIONAL,
>            privacy-mark                    ESSPrivacyMark OPTIONAL,
>            security-categories            SecurityCategories OPTIONAL }
>
>This plus some better wording in secution 3 of ESS could open S/MIME up to
support a more complex labeling environment.
>
>    Thoughts?
>
>Chris
>
>
> ---------------------------------------------------------------
> |  International Electronic Communication Analysts, Inc.      |
> |  Christopher D. Bonatti                 9010 Edgepark Road  |
> |  Vice-president                     Vienna, Virginia 22182  |
> |  [email-masked]   Tel: 301-212-9428   Fax: 703-506-8377  |
> ---------------------------------------------------------------
>
>
>
>
>
>

Date: Thu, 26 Mar 1998 21:08:55 -0500
To: "Bonatti, Chris" <[email-masked]>, Paul Hoffman / IMC <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Comment on ESS and Privacy Marks
Cc: [email-masked]
Sender: [email-masked]

Chris,

I agree with Paul that the ESSSecuritylabel is completely compatible with
the X.411 SecurityLabel when the privacyMark choice is PrintableString. In
fact, I would encourage you to propose to the ITU that the X.411
securityLabel should be similarly enhanced.

Furthermore, I respectfully disagree with your counter-proposal of defining
a standard securityCategory syntax to hold the privacyMark UTF8String.  The
X.411 spec states that the security policy in force (identified by the
securityLabel security-policy-identifier) is used to indicate the syntaxes
that are allowed to be present in the securityLabel security-categories.
This implies that every organization's security policy (that uses the
ESSSecurityLabel) would have to include the standard definition of the
privacyMark security-category using the identical OID.  IMHO, there is no
way that all of the organizations are going to agree on any standard
security-categories or using an identical OID.  Security-categories are
considered to be a matter of local policy and the various organizations are
not going to accept a standard security category forced on them.

In summary, I believe that the ESSPrivacyMark should not be changed.

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

At 02:54 PM 3/26/98 -0500, Bonatti, Chris wrote:
>    Let's be clear, however, that conveying the UTF-8 string as a security
category allows the result to be compatible regardless of whether UTF-8 is
used.  There is already a perfectly good extension mechanism included in the
X.411 label.  Can somebody spell out for me the reason for NOT using it to
address the UTF-8 requirement?  The way I see it, the current solution is
creating a problem that does not need to be created.
>
>Chris
>

Date: Thu, 26 Mar 1998 20:49:13 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: RE: ESS-04 Comments
Sender: [email-masked]

All,

I agree with Paul's proposed wording with the following comment:

Please change:

OLD: "If a SignedData object has more than one SignerInfo that has an
mlExpansionHistory attribute, the recipient MUST compare the
mlExpansionHistory attributes in all the SignerInfos, and MUST NOT process
the mlExpansionHistory attribute unless every mlExpansionHistory attribute
in the SignedData block is identical. If the mlExpansionHistory attributes
in the signerInfos are not all identical, then the receiving agent MUST stop
processing the message and SHOULD notify the user or MLA administrator of
this error condition."

NEW: "If a SignedData object has more than one SignerInfo that has an
mlExpansionHistory attribute, the recipient MUST compare the
mlExpansionHistory attributes in all the SignerInfos that it has verified,
and MUST NOT process the mlExpansionHistory attribute unless every verified
mlExpansionHistory attribute in the SignedData block is identical. If the
mlExpansionHistory attributes in the verified signerInfos are not all
identical, then the receiving agent MUST stop processing the message and
SHOULD notify the user or MLA administrator of this error condition."

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

From: "Flanigan, Bill" <[email-masked]>
To: IETF-SMIME WG <[email-masked]>
Subject: Cert-03.txt and Msg-03.txt
Date: Thu, 26 Mar 1998 17:34:37 -0500
Sender: [email-masked]

> -----Original Message-----
> From:	Flanigan, Bill 
> Sent:	Wednesday, March 25, 1998 6:16 PM
> To:	Paul Hoffman / IMC
> Subject:	RE: New versions of the -cert and -msg specs now available
> 
> Hello Paul and Blake,
> 
> 	Some nits--small and (maybe) not small:
> 
> 		1.  Cert-03.txt:
> 
> 			a.  Purpose of document should be stated in new/old
> Section 1.0.  It seems to be hiding now in Section 2.0.
> 
> 			b.  Section 1.1, line 7.  Why a "SEQUENCE"?  Why not
> "one or more"?
> 
> 			c.  Section titles starting with Section 2.1.
> Eliminate the run-on use of words.
> 
> 			d.  Section 2.1.  Delete "for" from line 1.  This
> section seems confusing what with receiving agents, sending agents,
> clients, users, etc.  Recommend that these terms be defined in Section 1.1
> or "harmonized".
> 
> 			f.  Recommend that document be given a "PKI scrub"
> starting with Section 2.1.
> 
> 			g.  Section 4.1, line 6-8.  Keep this sentence, and
> delete the rest of the Section.
> 
> 			h.  Section 5.0, lines 2-3.  It's unclear what the
> relationship is between the "S/MIME agent" and "protecting the user's
> private key."  Shouldn't the user protect his/her/its private key period?
> 
> 			i.  More to come.
> 
> 	2.  Msg-03.txt.  Later.
> 
> Hope this helps.
> 
> Bill
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> William F. Flanigan, Jr., Ph.D.       Voice:           (703) 735-3305
> Defense Information Systems Agency      DSN:                      653
> Strategic Planning Office (JEBA)        Fax:            (703)735-3255
> 10701 Parkridge Boulevard        Voice Mail:            (703)735-3305 
> Reston, VA 20191-4357              Internet:  <[email-masked]>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
> 	
> 
> -----Original Message-----
> From:	Paul Hoffman / IMC [SMTP:[email-masked]]
> Sent:	Tuesday, March 24, 1998 10:19 PM
> To:	[email-masked]
> Subject:	New versions of the -cert and -msg specs now available
> 
> Greetings, y'all. I've just made Blake's latest versions, -03, of the
> -cert
> and -msg drafts available at:
> <http://www.imc.org/draft-ietf-smime-cert>
> <http://www.imc.org/draft-ietf-smime-msg>
> These will be the versions we'll be talking from at the IETF meeting on
> Monday. However, there's no need to wait until then to start commenting
> (the same's true for -cms and -ess).
> 
> (BTW, you shouldn't have to clear your browser cache to get the drafts
> this
> time.)
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium

Date: Thu, 26 Mar 1998 16:31:40 -0500
To: Tim Dean <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

Tim,

I agree with your most recent message.  I didn't agree with the implication
of your earlier messages that differing ESSSecurityLabels attributes could
be included in a single signedData object.

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

At 12:56 PM 3/25/98 -0000, Tim Dean wrote:
>John, 
>
>>Your requirements can be met by nesting signedData layers.  The original
>>signer can include her eSSSecurityLabel in the original, inner signedData
>>layer.  The intermediate entity can include its eSSSecurityLabel in an outer
>>signedData layer that encapsulates the original, inner signedData layer.
>
>What you describe here is exactly what we need.  Some intermediate entity
adds a signed label to an 
>originator's message by encapsulating it in a signedData.  (The label could
be derived from reviewing the 
>text, or based on some parameter in my current environment, or whatever.
It could even encrypt the 
>original and slap an 'unclassified' label on it.)  However, that
intermediate entity doesn't want the recipient 
>or anyone else to be confused into thinking she originated the message.  So
she uses sig purpose 
>'contentReviewer' to indicate this.  Nothing I've read in ESS or in Dave
K's original text seems to conflict 
>with this model.  Where are we not 'synching' here?
>
>Tim
>
>-----------------------------------------------
>Tim Dean
>Defence Evaluation & Research Agency
>Malvern
>United Kingdom
>telephone:      +44-1684-894239
>facsimile:      +44-1684-896113
>e-mail:         [email-masked]
>----------------------------------------------------
>

Date: Thu, 26 Mar 1998 14:58:58 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: ESSSecurityLabel Comments
Sender: [email-masked]

All,

We need to add a context-specific tag to the ESSSecurityLabel version field
because there are two INTEGERs in the SET.  In order to keep the tags in
numerical order, recommend that ESSPrivacyMark utf8String should be changed
to "[1]" and then "[0]" can be used for ESSSecurityLabel version.  This
results in the following:

ESSSecurityLabel ::= SET {
  version                    [0] Version DEFAULT v1,
  security-policy-identifier     SecurityPolicyIdentifier OPTIONAL,
  security-classification        SecurityClassification OPTIONAL,
  privacy-mark                   ESSPrivacyMark OPTIONAL,
  security-categories            SecurityCategories OPTIONAL }

ESSPrivacyMark ::= CHOICE {
    pString                      PrintableString (SIZE
(1..ub-privacy-mark-length)),
    -- If pString is used, the ESSSecurityLabel version is set to v1
    utf8String               [1] IMPLICIT OCTET STRING SIZE (1..MAX)
    -- If utf8String is used, its contents MUST be in UTF8 format, and
    -- the ESSSecurityLabel version is set to v2
}

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

Date: Thu, 26 Mar 1998 14:54:05 -0500
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: Paul Hoffman / IMC <[email-masked]>
CC: [email-masked]
Subject: Re: Comment on ESS and Privacy Marks
Sender: [email-masked]

    Let's be clear, however, that conveying the UTF-8 string as a security category allows the result to be compatible regardless of whether UTF-8 is used.  There is already a perfectly good extension mechanism included in the X.411 label.  Can somebody spell out for me the reason for NOT using it to address the UTF-8 requirement?  The way I see it, the current solution is creating a problem that does not need to be created.

Chris

______________________

Paul Hoffman / IMC wrote:

> At 11:09 AM 3/26/98 -0500, Bonatti, Chris wrote:
> >I think that expanded character sets are generally useful, but you need to
> >recognize that you're not necessarily working from a blank slate.  The label
> >in the previous ESS draft was aligned with the X.411 security label.  This
> >label structure has gained a fair amount of acceptance, and is used in a
> >number of areas including X.500, and non-OSI systems.  I was pleased to see
> >it appear in ESS.  Changing the privacy-mark field makes the ESS label
> >incompatible with the existing X.411 security label structure.  Using an
> >alternate encoding or character set for the existing field is certain to
> >impact existing implementations that provide and consume security labels.
>
> If the MUA creating the privacy mark wants to be compliant with X.411, it
> can: it chooses the pString value in ESSPrivacyMark. If it wants to have
> their mark use characters outside the PrintableString charset (for
> instance, if the mark needs to include a non-ASCII text character or if the
> sender wants to include an Internet mail address in the privacy mark), it
> uses the utf8String value. The current label is *not* incompatible with
> X.411; one of the two choices is. It is quite easy to create
> X.411-compatible privacy labels if what you want to say in the label
> doesn't need any characters outside the PrintableString charset.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "Blake Ramsdell (E-mail)" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: Comments on MSG-03
Date: Thu, 26 Mar 1998 11:44:02 -0800
Sender: [email-masked]

These two are leftovers from the previous mail which did not get
incorperated into the new draft (except as Needed changes in appendix F).

1.  Section 2.6.2.3 and 2.6.2.4.  The wording no longer works for these two
sections now that 3DES is a must and RC2/40 is an optional.  I have switched
the order of the rules as tripleDES is now a MUST algorithm and is therefore
by definition supported, but we know that not everyone does support it.  I
suggest that these sections be re-written as follows:

"2.6.1.3 Rule 3: Low Encryption interopt mode

If:
 - the sending agent has no knowledge of the encryption capabilities of the
recipient,
 - and the sending agent is has reason to believe that the recipient does
not support high level encryption,
then the sending agent SHOULD use RC2/40.

2.6.1.4  Rule 4: Unknown Capabilities

If:
 - the sending agent has no knowledge of the encryption capabilities of the
recipient,
then the sending agent MUST use tripleDES."

2.  Insert a new section 2.6.4 with the following text.
"Section 2.6.4  Selecting a receipients Encryption Certificate

The use of the must algorithms in this specification lead to the problem of
given a user's signing certificate from a signed message, how is the
encryption certificate determined.  Since the signing and key exchange
algorithms will no longer use the same certificates.

Section 2.5 deifnes a method by which a sending agent can optionally
announce what its perfered key-exchange certificate is.  The following
method for processing and remembering the encryption certificate attribute
in incoming signed messages SHOULD be used.

If an Encryption Key preference attribute is found in a message, this is the
certificate that should be associated as the encryption certificate for the
user.

If no Encrytion Key perference attribute is found in a message, the set of
certificates should be searched for a certificate with the same DN as the
signing certificate which can be used for encryption.  If no certificate is
found, then encryption cannot be done with the signer of the message.  If
multiple certificates are found, the MUA can make an arbitrary choice
between them. 

- If the receiving agent has not yet done an association for the sender's
encryption certificate, then, after verifiying the signature on the incoming
message and checking the timestamp, the receiving agent SHOULD create a new
associaiton containing the signing time and the encryption certificate.

- If such an association already exists, the receiving agent SHOULD verify
that the signing time in the incoming message is greater than the signing
time stored in the association and that the signature is valid.  If so, the
receiving agent SHOULD update both the signing time and the encryption
certificate association.  Values of the signing time that lie far in the
future (that is, a greater discrepancy than any reasonable clock skew), or
an encryption preference in a message whos signature cannot be verified,
MUST NOT be accepted."

-----------------------------------------------------------------------
Now for the new comments on this draft:

3.  Section 3.7 -- the first sentence of paragraph 3 and the last of
paragraph 2 are identical.  Please delete one of these.

4.  Section 4.1 -- Should make this text match the requirements above.  In
section 2.2 we said SHOULD to 512 to 1024 bit signature verification.  In
this section we are talking about old clients.  Lets be consistant.

jim

Date: Thu, 26 Mar 1998 09:26:25 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Comment on ESS and Privacy Marks
Sender: [email-masked]

At 11:09 AM 3/26/98 -0500, Bonatti, Chris wrote:
>I think that expanded character sets are generally useful, but you need to 
>recognize that you're not necessarily working from a blank slate.  The label 
>in the previous ESS draft was aligned with the X.411 security label.  This 
>label structure has gained a fair amount of acceptance, and is used in a 
>number of areas including X.500, and non-OSI systems.  I was pleased to see 
>it appear in ESS.  Changing the privacy-mark field makes the ESS label 
>incompatible with the existing X.411 security label structure.  Using an 
>alternate encoding or character set for the existing field is certain to 
>impact existing implementations that provide and consume security labels.

If the MUA creating the privacy mark wants to be compliant with X.411, it
can: it chooses the pString value in ESSPrivacyMark. If it wants to have
their mark use characters outside the PrintableString charset (for
instance, if the mark needs to include a non-ASCII text character or if the
sender wants to include an Internet mail address in the privacy mark), it
uses the utf8String value. The current label is *not* incompatible with
X.411; one of the two choices is. It is quite easy to create
X.411-compatible privacy labels if what you want to say in the label
doesn't need any characters outside the PrintableString charset.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 26 Mar 1998 11:08:31 -0500
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: "[email-masked]" <[email-masked]>
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Sender: [email-masked]

    I have some other concerns with the current restrictions on ESS security label.  As long as each instance of the label in the signedData element must contain the same value, I think there are very important scenarios that cannot be serviced.

    It may be necessary to for the signer to include multiple instances of the security label using different policy IDs and/or security category structures for the purpose of satisfying the requirements of multiple policy domains.  This would require a change to the wording of ESS clause 3.1.1.  For simplistic labeling, this is probably not a concern.  However, we don't have (nor are we likely to soon have) a standard for representing categories/compartments in varying security domains.  As long as this is the case, we are going to have variations in the labeling requirements on a per-policy basis.  This will essentially require label conversion (as John Ross suggests) or multiple signed labels with different values.

    There is another circumstance in which it may be necessary to include either or both of an "information" or "system" security label.  If both labels are present, the information label will convey the "true" label of the content from the originator to the recipient.  The system label will convey the label of the content to be used for access control purposes.  This split label may, among other things, be used to convey the actual content classification when used in a system-high environment.  Whether either or both of these labels is present is a function of security policy.  The security policy ID may, in fact, be used to discriminate between these two.  This scenario likewise requires a change to ESS clause 3.1.1.

    It should also noted that in cases where multiple labels are provided by the same signer, it would be VERY inefficient to convey each of these in a separate signerInfo elements because of the overhead of multiple signature operations.  Therefore, the implied restriction in 3.1.1 on multiple instances of the label attribute might not make sense.

    I would suggest that a better way to handle this would be to make the ESS security label attribute internally multivalued and include a mechanism for identifying the purpose of each instance of the label.  For example, the ESS label attribute could be changed to the following:

        ESSSecurityLabel ::= SEQUENCE OF LabelItem

        LabelItem ::= SEQUENCE {
            security-label    SecurityLabel,
            label-purpose    LabelPurpose }

        LabelPurpose ::= ENUMERATED {
             system-label (0),
             information-label (1), ... }

        SecurityLabel ::= SET {
            security-policy-identifier    SecurityPolicyIdentifier OPTIONAL,
            security-classification        SecurityClassification OPTIONAL,
            privacy-mark                    ESSPrivacyMark OPTIONAL,
            security-categories            SecurityCategories OPTIONAL }

This plus some better wording in secution 3 of ESS could open S/MIME up to support a more complex labeling environment.

    Thoughts?

Chris

 ---------------------------------------------------------------
 |  International Electronic Communication Analysts, Inc.      |
 |  Christopher D. Bonatti                 9010 Edgepark Road  |
 |  Vice-president                     Vienna, Virginia 22182  |
 |  [email-masked]   Tel: 301-212-9428   Fax: 703-506-8377  |
 ---------------------------------------------------------------

Date: Thu, 26 Mar 1998 11:09:59 -0500
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: [email-masked]
Subject: Re: Comment on ESS and Privacy Marks
Sender: [email-masked]

    I've noted the discussion of privacy-mark character sets here and the GREAT concern over ASN.1 encodings, but have witnessed little sound and fury over the break in backward compatibility that this change to the label will create.

    I think that expanded character sets are generally useful, but you need to recognize that you're not necessarily working from a blank slate.  The label in the previous ESS draft was aligned with the X.411 security label.  This label structure has gained a fair amount of acceptance, and is used in a number of areas including X.500, and non-OSI systems.  I was pleased to see it appear in ESS.  Changing the privacy-mark field makes the ESS label incompatible with the existing X.411 security label structure.  Using an alternate encoding or character set for the existing field is certain to impact existing implementations that provide and consume security labels.

    If the requirement for richer character sets is legitimate, then why not define a security category to convey the enhanced string value?  That has the advantages of being fully compatible with the X.411 label, providing the desired functionality, and also affording the opportunity to perhaps more accurately identify the character set (i.e., one category OID for UTF-8, another for Unicode, etc.).

Chris

 ---------------------------------------------------------------
 |  International Electronic Communication Analysts, Inc.      |
 |  Christopher D. Bonatti                 9010 Edgepark Road  |
 |  Vice-president                     Vienna, Virginia 22182  |
 |  [email-masked]   Tel: 301-212-9428   Fax: 703-506-8377  |
 ---------------------------------------------------------------

Date: Thu, 26 Mar 1998 10:18:14 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Agenda for S/MIME WG on 30 March 1998 at 0930
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Here is the agenda for the S/MIME WG Meeting on 30 March 1998 at 0930.

Russ

== == == == == == == ==

0930	Introductions					Russ Housley
0935	CMS Draft Discussion			Russ Housley
0950	MSG Draft Discussion			Blake Ramsdell
1005	ESS Draft Discussion			Paul Hoffman
1020	CERT Draft Discussion			Blake Ramsdell
1035	Authenticated Originator Cert.	John Pawling
1045	E-mail Address in Certificates	J. L. Côté
1100	Sig & Key Mgmt Certificates		Jim Schaad
1120	Certificate Distribution			Jim Schaad
1130	Adjourn

Date: Wed, 25 Mar 1998 16:12:06 -0500
To: [email-masked] (David P. Kemp)
From: Russ Housley <[email-masked]>
Subject: Re: CMS: signed attributes?
Cc: [email-masked]
Sender: [email-masked]

Dave:

With the addition of MACs in the form of authenticated-data, I think that
signedAttributes and unsignedAttributes will make it clear that signed-data
does not rely on anything in authenticated-data.

I will make the change in the next draft.

Russ

At 01:03 PM 3/23/98 -0500, David P. Kemp wrote:
>
>I suggest that the CMS SignerInfo fields "authenticatedAttributes" and
>"unauthenticatedAttributes" be renamed to "signedAttributes" and
>"unsignedAttributes" respectively.
>
>There are two justifications for this request, one trivial and one
>substantive:
>
>* Trivial reason: "signed" is easier to type than "authenticated",
>  and it sounds pretentious to use five syllables when one will do.
>
>* Real reason: signing is a mechanical process - attributes are either
>  covered by a digital signature or not.  Authentication is a process
>  involving policies and procedures - an attribute is not "authenticated"
>  unless the signature (including the cert path) verifies correctly and
>  the certificate policies allow the use of the attribute.  It is incorrect
>  to call an attribute authenticated solely because it is signed, just
>  as it is incorrect to call a certificate "valid" because it is signed.
> 

From: Tim Dean <[email-masked]>
To: Tim Dean <[email-masked]>, "'John Pawling'" <[email-masked]>
Cc: "David P. Kemp" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Signed Label (was RE: 'Signature Purpose' attribute?)
Date: Wed, 25 Mar 1998 12:56:44 -0000
Sender: [email-masked]

John, 

>Your requirements can be met by nesting signedData layers.  The original
>signer can include her eSSSecurityLabel in the original, inner signedData
>layer.  The intermediate entity can include its eSSSecurityLabel in an outer
>signedData layer that encapsulates the original, inner signedData layer.

What you describe here is exactly what we need.  Some intermediate entity adds a signed label to an 
originator's message by encapsulating it in a signedData.  (The label could be derived from reviewing the 
text, or based on some parameter in my current environment, or whatever.  It could even encrypt the 
original and slap an 'unclassified' label on it.)  However, that intermediate entity doesn't want the recipient 
or anyone else to be confused into thinking she originated the message.  So she uses sig purpose 
'contentReviewer' to indicate this.  Nothing I've read in ESS or in Dave K's original text seems to conflict 
with this model.  Where are we not 'synching' here?

Tim

-----------------------------------------------
Tim Dean
Defence Evaluation & Research Agency
Malvern
United Kingdom
telephone:      +44-1684-894239
facsimile:      +44-1684-896113
e-mail:         [email-masked]
----------------------------------------------------

----------
From:  John Pawling [SMTP:[email-masked]]
Sent:  Monday, March 23, 1998 9:31 PM
To:  Tim Dean
Cc:  David P. Kemp; [email-masked]
Subject:  RE: 'Signature Purpose' attribute?

Tim,

Your arguments only serve to further convince me that the ESS
eSSSecurityLabel processing requirements must not be changed.  Your
statement that an intermediate entity can "veto" the originator's label
confirms my fear that intermediate entities may be allowed (if given the
chance) to invalidate the original signer's eSSSecurityLabel.  If that
happens, then the original signer is not receiving the security security
services that she requested when she originally signed the content.  
  
Your requirements can be met by nesting signedData layers.  The original
signer can include her eSSSecurityLabel in the original, inner signedData
layer.  The intermediate entity can include its eSSSecurityLabel in an outer
signedData layer that encapsulates the original, inner signedData layer.
This is the optimal strategy because the recipient MUST make a separate
access control decision for each of the signedData layers.  The recipient
MUST process the eSSSecurityLabel in each
signedData object that it verifies.  Because the recipient will verify both
the outer and inner signedData objects, then it MUST process the
eSSSecurityLabel attribute in each of the signedData objects.  Therefore,
both the original signer's and intermediate entity's eSSSecurityLabels are
processed by the recipient.  

If your proposal was accepted and multiple eSSSecurityLabels were allowed in
the same signerInfo or same signedData, then there would be mass confusion
and room for contradiction when different labels are processed by the
recipient as part of the same cumulative access control decision applied to
the individual signedData object.  I believe that it is impractical to try
to force the S/MIME community into accepting a complicated access control
decision strategy such as would be required to define the rules to process
multiple eSSSecurityLabels included in the same signerInfo or same signedData.

In summary, my opinion is that Dave Kemp's security label example must be
deleted.

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================  

At 11:48 AM 3/23/98 -0000, Tim Dean wrote:
>John,

<snip>

>I must respectfully disagree that in all cases, all intermediate entities
must respect the original signer's
>wishes regarding the label.  In many environments, such as ours, security
authorities have the power of
>veto over any label created by an originator.  In electronic (S/MIME)
terms, my 'environment' will
>probably create the label automatically for me.  That 'environment' could
be the current enclave/domain
>where I am working, or the machine I am currently logged onto, or even the
client software on the
>machine, e.g. on a Compartmented Mode Workstation.  In certain cases the
labelling authority will be a
>human-being acting as a 'release authority'.  This signed label will
probably be checked by the Guard
>before onward transmission.
>
>In short, I want to create and sign messages as an originator; some third
party will counter-sign and label
>them for me.  I am very much hoping that ESS and S/MIME in general will
accommodate this model as
>well as other security policies.  As a general principle, I believe ESS and
S/MIME should be security-
>policy neutral wherever possible.  I am very much hoping that with the
addition of sig-purpose attribute
>'content Reviewer', my particular policy could be supported.  For this
reason, I would very much like all
>of Dave Kemp's original examples, including security label, to remain.
>
>Tim 
>

From: John Ross <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, Tim Dean <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: 'Signature Purpose' attribute?
Date: Wed, 25 Mar 1998 11:13:10 -0800
Sender: [email-masked]

Russ,=20

The problem with your proposal of removing the originator signature an =
replace it with a new signature, is that many international/boundary =
gateways may want to perform label mapping and still require the =
originators signatures to go end to end (i.e pass through gateways =
unaltered).=20

I also I think there is a problem with the outer-signature (double =
wrapping) proposal and the current S/MIME access control rules.  Under =
the double wrapping  proposals, an international/boundary gateway will =
need to generate an outer-signature which would includes the =
national/domain specific eSSSecuritylabel, this may be in addition to =
(and different from)  the eSSSecuritylabel in the originators signature. =
However, if I understand the current access control rules of s/mime =
correctly, it is mandatory that  both the originators eSSSecuritylabel, =
and the outer wrapped gateway eSSSecuritylabel shall be processed by the =
recipient. (i.e. local recipient access control must be based on all =
labels).  The problem is that, the inner eSSSecuritylabel may have no =
semantics in the recipients environment.  So the access control decision =
can only be based on the outer eSSSecuritylabel which as generated by =
the gateway.=20

Thus I think, the access control rules in s/mime need to be made =
dependant on the security policy identifier (which is part of the =
eSSSecuritylabel). This would allow the access control decision to be =
made based on all eSSSecuritylabel were the policy identifier is =
understood and supported by the recipient.  Any eSSSecuritylabel present =
at any  level (originators, wrapped or triple wrapped) may be ignore (as =
to the enforcement of access control rules) if the policy identifier is =
not understood or supported=20

I think the above rule, must still be subject to the criticality rules. =
The implementation implications of both rules would be to enforce =
correctly process the policy identifier  and hence determine if the =
eSSSecuritylabel was applicable or not for local access control =
processing.

John Ross

-----Original Message-----
From:	Russ Housley [SMTP:[email-masked]]
Sent:	Tuesday, March 24, 1998 11:21 AM
To:	Tim Dean
Cc:	[email-masked]
Subject:	RE: 'Signature Purpose' attribute?

Tim:

If a security authority wants to change the label, then it must remove =
the
originator signature an replace it with a new signature.

User agent processing will become overly complex if we allow there to be
multiple labels on a content.

Russ

At 11:48 AM 3/23/98 +0000, Tim Dean wrote:
>John,
>
>>>3) I like the text in ESS as it stands now, but there may be =
suggestions
>>to modify the syntax and operation of eSSSecurityLabel to accommodate =
other
>>requirements.  If ESS were changed, the example might apply.
>
>>[JSP: IMHO, the ESS text must stand.  Your example is a good reason =
why it
>>must stand.  If the original signer included an eSSSecurityLabel in =
the
>>original signedData object then additional signer's of that original
>>signedData object MUST not be allowed to include different security =
labels
>>in signerInfos within the same signedData object.  If that were to be
>>allowed, then there would be mass confusion and room for contradiction =
when
>>different labels are processed by the recipient as part of the same
>>cumulative access control decision applied to the individual =
signedData
>>object.  Furthermore, if the original signer did not include an
>>eSSSecurityLabel in the original signedData object, then the original =
signer
>>made the decision that the content did not need to be labeled and that
>>access control is not required to access the content.  In all cases, =
all
>>intermediate entities MUST respect the original signer's wishes =
regarding
>>the eSSSecurityLabel that she included in the signedData that she =
created or
>>else she is not receiving the security services that she requested =
when she
>>originally signed the content.]
>
>I must respectfully disagree that in all cases, all intermediate =
entities
must respect the original signer's
>wishes regarding the label.  In many environments, such as ours, =
security
authorities have the power of
>veto over any label created by an originator.  In electronic (S/MIME)
terms, my 'environment' will
>probably create the label automatically for me.  That 'environment' =
could
be the current enclave/domain
>where I am working, or the machine I am currently logged onto, or even =
the
client software on the
>machine, e.g. on a Compartmented Mode Workstation.  In certain cases =
the
labelling authority will be a
>human-being acting as a 'release authority'.  This signed label will
probably be checked by the Guard
>before onward transmission.
>
>In short, I want to create and sign messages as an originator; some =
third
party will counter-sign and label
>them for me.  I am very much hoping that ESS and S/MIME in general will
accommodate this model as
>well as other security policies.  As a general principle, I believe ESS
and S/MIME should be security-
>policy neutral wherever possible.  I am very much hoping that with the
addition of sig-purpose attribute
>'content Reviewer', my particular policy could be supported.  For this
reason, I would very much like all
>of Dave Kemp's original examples, including security label, to remain.
>
>Tim=20
>
>----------
>From:  John Pawling [SMTP:[email-masked]]
>Sent:  Thursday, March 19, 1998 10:34 PM
>To:  David P. Kemp; [email-masked]
>Subject:  Re: 'Signature Purpose' attribute?
>
>Dave,
>
>Please see my responses in-line:
>
>
>At 04:30 PM 3/19/98 -0500, David P. Kemp wrote:
>>> From: [email-masked] (John Pawling)

>>>=20
>>> The contentReviewer is only allowed to
>>> include an eSSSecurityLabel authenticated attribute in the =
signerInfo that
>>> she signs if there was already an eSSSecurityLabel attribute present =
in
the
>>> signerInfo(s) already included in the original signedData object.
>>
>>
>>John,
>>
>>  It was just an example, but thanks for pointing out the restrictions =
on
>>eSSSecurityLabel.  I can think of three rebuttals:
>>
>>1) the above quoted sentence isn't necessarily true in all cases, =
because
>>a security gateway could take a message (either signed or plain old =
email)
>>and wrap it in a new signedData.
>
>[JSP: I agree that an intermediate entity can encapsulate the original
>signedData object within a new outer signedData object.  The =
intermediate
>entity can then include the appropriate eSSSecurityLabel attribute, if
>required, in the signerInfo within the new outer signedData object.  =
The
>intermediate entity's eSSSecurityLabel attribute may be different than =
that
>included in the inner signedData object.  IMHO, that is acceptable =
because
>the recipient MUST make a separate access control decision for each of =
the
>signedData layers.  The recipient MUST process the eSSSecurityLabel in =
each
>signedData object that it verifies.  Because the recipient will verify =
both
>the outer and inner signedData objects, then it MUST process the
>eSSSecurityLabel attribute in each of the signedData objects.  =
Therefore,
>both the original signer's and intermediate entity's eSSSecurityLabels =
are
>processed by the recipient.  An important point to note is that the
>recipient software makes a separate access control decision for each
>signedData object.  IMHO, that is the primary difference between =
processing
>eSSSecurityLabels included in layered signedData objects versus those
>included in multiple signerInfos included in the same signedData =
object.  In
>the latter case, all eSSSecurityLabels included in the various =
signerInfos
>(that are verified) are checked as part of the same cumulative access
>control decision process applied to the individual signedData object. =20
>
>To get back to your original rebuttal, if the intermediate entity adds =
the
>outer signedData, then IMHO it is not a contentReviewer, it is a
>contentOriginator because it is creating a new signedData object.
>Therefore, I believe that my comment still stands.]
>
>
>>2) eSSSecurityLabel is defined in the ESS document, whereas =
signaturePurpose
>>has been proposed for inclusion in CMS.  CMS may be used in non-S/MIME
>>applications which have different compliance requirements than S/MIME =
and
>>which do not refer to ESS at all.
>
>[JSP: One of the major goals of ESS is to define standard attributes =
for use
>with CMS.  The CMS spec MUST NOT make statements (such as your example =
IMHO)
>that are contradictory to the principles of ESS (which CMS currently =
does
>not).  The best strategy would be for CMS not to mention security =
labels at
>all (which it currently does not).  Therefore, I recommend that you =
should
>either remove the security label example or move the signaturePurpose
>attribute to ESS and discuss eSSSecurityLabels.  Furthermore, =
applications

>that use eSSSecurityLabels attributes MUST set the attributes to be =
critical
>so if an application needs to use security labels it would be best if =
it
>were to implement eSSSecurityLabels to avoid interoperability problems =
with
>those applications that are implementing the standard =
eSSSecurityLabels.] =20
>
>
>>3) I like the text in ESS as it stands now, but there may be =
suggestions
>>to modify the syntax and operation of eSSSecurityLabel to accommodate =
other
>>requirements.  If ESS were changed, the example might apply.
>
>[JSP: IMHO, the ESS text must stand.  Your example is a good reason why =
it
>must stand.  If the original signer included an eSSSecurityLabel in the
>original signedData object then additional signer's of that original
>signedData object MUST not be allowed to include different security =
labels
>in signerInfos within the same signedData object.  If that were to be
>allowed, then there would be mass confusion and room for contradiction =
when
>different labels are processed by the recipient as part of the same
>cumulative access control decision applied to the individual signedData
>object.  Furthermore, if the original signer did not include an
>eSSSecurityLabel in the original signedData object, then the original =
signer
>made the decision that the content did not need to be labeled and that
>access control is not required to access the content.  In all cases, =
all
>intermediate entities MUST respect the original signer's wishes =
regarding
>the eSSSecurityLabel that she included in the signedData that she =
created or
>else she is not receiving the security services that she requested when =
she
>originally signed the content.]
>
>>
>>
>>     dpk
>>
>=20

Date: Wed, 25 Mar 1998 09:13:04 -0800
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: John Pawling <[email-masked]>
CC: [email-masked]
Subject: Re: Inclusion of the issuer and serial number in authenticated  information
Sender: [email-masked]

John,

Thank you for your detailed scenario. Since I am coming to the LA
meeting, I think it would be useful to have a meeting between all the
people interested on this topic to explain the story around this since I
think it will be hard to provide all the explanations by E-mail.

Some time slot in the smime working group agenda would also be
appropriate.

I would nevertheless attempt to tell what the problem is in your
scenario.

> I agree with Russ and Eric that we should stick with Jim Schaad's original
> proposal to define the signing-certificate attribute type as the CMP
> IssuerAndSerialNumber syntax.  Here is the scenario as I see it:
> 
> 1) The originator populates the signedData signerInfo signing-certificate
> authenticatedAttribute with the IssuerAndSerialNumber of the signer's cert
> containing the public key required to validate the signer's signature of the
> signedData signerInfo.
> 
> 2) The originator calculates the signature value of the CMS signedData
> signerInfo as described in CMS; therefore, the  signing-certificate
> authenticatedAttribute containing the IssuerAndSerialNumber of the signer's
> cert are bound with the content.
> 
> 3) The originator sends the signedData to the recipient.
> 
> 4) The recipient decodes the signedData to determine the signerInfo
> IssuerAndSerialNumber identifying the signer's cert.

Stop. Here is where the problem is. The IssuerAndSerialNumber may or may
not allow to fully identify the right CA, in particular when FDNs are
not used for CA names. In case of homonyms between CA names, a CA could
provide a certificate to some people with the same CA name (because of
homonymity) and the same serial number (purposely). Of course, this
"indelicate" CA would not have performed POP (Proof of Posession of the
private key) but when this would be invisible to the checking process.
The end result is to believe that the signed document has been signed by
some one else, which is pretty bad or to allow ambiguity of signature. 

> 5) The recipient obtains the signer's certificate issued by the identified
> CA which includes the designated serial number.
> 
> 6) The recipient builds a cert path connecting the retrieved signer's
> certificate with the verifier's trusted key and validates that cert path as
> per PKIX and X.509.  Among other things, this reliably binds the public key
> with the subject name, issuer name and serialNumber in the signer's cert.
> 
> 7) The recipient uses the validated signer's public key to verify the
> signature of the received signedData signerInfo.  This verifies (among other
> things) the binding between the signing-certificate authenticatedAttribute
> and signedData content.
> 
> 8) The recipient compares the verified signing-certificate
> authenticatedAttribute with the verified issuer name and serialNumber of the
> signer's cert.
> 
> This entire process verifies:
> 
> a) that the correct public key was used to verify the signature of the
> SignedData signerInfo;
> 
> b) the binding of the public key used to verify the signature with the
> subject name, issuer name and serialNumber (among other things) in the
> signer's cert;
> 
> c) the binding of the signedData content with the signing-certificate
> authenticatedAttribute (i.e. IssuerAndSerialNumber of signer's cert)
> included in the verified signerInfo; and
> 
> d) that the correct public key used to verify the SignedData signerInfo
> signature was extracted from the correct, verified signer's cert as
> identified by the verified signing-certificate authenticatedAttribute.
> 
> I don't see any holes in the aforementioned strategy.  There is always the
> "renegade CA" argument, but the renegade CA's cert must be a part of a valid
> cert path than can be verified to the verifier's trusted key.  It will be
> extremely rare for a renegade CA's cert to be a part of a valid cert path
> than can be verified to the verifier's trusted key.  The use of the
> nameConstraints extensions in each cert in the cert path can be used to
> limit the damage that can be done by a validated renegade CA.  The main
> defense is that the users will notice that something is wrong and report the
> renegade CA.  In that case, the renegade CA will be shut down or the cross
> cert to its domain revoked.
> 
> I don't see any purpose to add a hash of the certificate to this process

The purpose of the hash is to allow to make the difference between the
two certificates mentioned above. Thus, at the verification time, the
problem mentioned above is detected or suppressed.

> because the signer's cert path is verified to the verifier's trusted key.  I
> don't believe that there will ever be a case in which there are multiple
> CA's using the same Issuer DNs that are issuing certs that include the same
> serial numbers and the same public keys that can all be validated via a
> valid cert path to the verifier's trusted key.
> 
> I also don't see any purpose to use the X.509 IssuerSerial syntax because
> all subject and issuer names MUST be populated (i.e. not an empty SEQUENCE)
> in S/MIME-compliant v3 X.509 Certificates, except that the subject DN in a
> user's (i.e. end-entity) certificate MAY be an empty SEQUENCE in which case
> the subjectAltName extension will include the subject's identifier and MUST
> be marked as critical.

CMS is to be used by S/MIME and non S/MIME compliant applications.

Denis

> ================================
> John Pawling, [email-masked]
> J.G. Van Dyke & Associates, Inc.
> www.jgvandyke.com
> ================================

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Tue, 24 Mar 1998 19:18:56 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: New versions of the -cert and -msg specs now available
Sender: [email-masked]

Greetings, y'all. I've just made Blake's latest versions, -03, of the -cert
and -msg drafts available at:
<http://www.imc.org/draft-ietf-smime-cert>
<http://www.imc.org/draft-ietf-smime-msg>
These will be the versions we'll be talking from at the IETF meeting on
Monday. However, there's no need to wait until then to start commenting
(the same's true for -cms and -ess).

(BTW, you shouldn't have to clear your browser cache to get the drafts this
time.)

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 24 Mar 1998 18:29:39 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: ESS-04 Comments
Sender: [email-masked]

After talking to John and Jim, I've come up with the following wording
for the mlExpansionHistory processing in section 4.1. This replaces the
current last three paragraphs of that section. Please let me know
whether or not it is complete and OK.

==========

There can be multiple SignerInfos within a SignedData object, and each
SignerInfo may include authenticatedAttributes. Therefore, a single
SignedData object may include multiple SignerInfos, each SignerInfo having a
mlExpansionHistory attribute. For example, an MLA can send a signed message
with two SignerInfos, one containing a DSS signature, the other containing
an RSA signature.

If an MLA creates a SignerInfo that includes an mlExpansionHistory
attribute, then all of the SignerInfos created by the MLA for that
SignedData object MUST include an mlExpansionHistory attribute, and the
value of each MUST be identical. Note that other agents might later add
SignerInfo attributes to the SignedData block, and those additional
SignerInfos might not include mlExpansionHistory attributes.

A recipient MUST verify the signature of the SignerInfo which covers the
mlExpansionHistory attribute before processing the mlExpansionHistory, and
MUST NOT process the mlExpansionHistory attribute unless the signature over
it has been verified. If a SignedData object has more than one SignerInfo
that has an mlExpansionHistory attribute, the recipient MUST compare the
mlExpansionHistory attributes in all the SignerInfos, and MUST NOT process
the mlExpansionHistory attribute unless every mlExpansionHistory attribute
in the SignedData block is identical. If the mlExpansionHistory attributes
in the signerInfos are not all identical, then the receiving agent MUST
stop processing the message and SHOULD notify the user or MLA administrator
of this error condition. In the mlExpansionHistory processing, SignerInfos
that do not have an mlExpansionHistory attribute are ignored.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 24 Mar 1998 19:39:54 -0500
To: <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: CERT-02 Comments
Sender: [email-masked]

Blake,

>Used with Triple-DES as a symmetric algorithm, a certificate is suitable
>for encrypting a message iff:
>
>1. The SubjectPublicKeyInfo AlgorithmIdentifier is rsaEncryption and the
>keyUsage bit "keyEncipherment" is set (or keyUsage is not present).
>
>2. The SubjectPublicKeyInfo AlgorithmIdentifier is dhpublicnumber and
>the keyUsage bit "keyAgreement" is 1 and "decipherOnly" is 0 (or
>keyUsage is not present, God Help you).

You could just as well add:

3. The SubjectPublicKeyInfo AlgorithmIdentifier is keyExchangeAlgorithm
(KEA) and the keyUsage bit "keyAgreement" is 1 and decipherOnly" is 0 (or
keyUsage is not present).

There may be others that you could add as well.  

>Does the encipherOnly bit need to be checked at all?  Isn't our use of
>Diffie-Hellman limited to "forming a pairwise key to encrypt data"?

D-H is used by the originator to form a pairwise key (originator's private,
recipient's public) to encrypt the session key used to encrypt the data.
D-H is used by the recipient to form a pairwise key (originator's public,
recipient's private) to decrypt the session key used to decrypt the data.

The encipherOnly bit is checked during decryption (of course:).  My original
proposal is repeated here for your convenience:

11) Sec 4.4.2, last para:  Please add: "If the keyUsage keyAgreement bit is
set to 1 AND if the public key is to be used to form a pairwise key to
decrypt data, then the S/MIME agent MUST only use the public key if the
keyUsage encipherOnly bit is set to 0.  If the keyUsage keyAgreement bit is
set to 1 AND if the key is to be used to form a pairwise key to encrypt
data, then the S/MIME agent MUST only use the public key if the keyUsage
decipherOnly bit is set to 0."

>
>Blake (Diffie-Hellman impaired)
>--
>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]>
To: "[email-masked]'" <[email-masked]>, <[email-masked]>
Subject: RE: CERT-02 Comments
Date: Tue, 24 Mar 1998 16:18:13 -0800
Sender: [email-masked]

Blake "Broken Formatting" Ramsdell replies...

On Tuesday, March 24, 1998 3:32 PM, [email-masked]
[SMTP:[email-masked]] wrote:
> I believe that my comment is appropriate.  I believe that X.509 and
> PKIX
> clearly state the requirements to check the keyUsage encipherOnly and
> decipherOnly bits when the keyUsage keyAgreement bit is set to 1 and
> the
> public key is to be used to either decrypt or encrypt data directly.
I
> believe that people will wonder how that rule applies when using the
> public
> key to form a pairwise key to be used to encrypt or decrypt data.
That
> is
> where my proposed text would clarify the requirements.

First off, I have no qualm whatsoever with your statements.  I believe
that they are completely consistent with the PKIX part 1 draft and my
beef isn't with you at all.  It is with my (mis-) understanding of
Diffie-Hellman, its use in S/MIME, and its description in PKIX.

> My proposed text is not unique to D-H.  It is applicable in any
scenario
> in
> which the keyUsage keyAgreement bit is set to 1 and the public key is
to
> be
> used to form a pairwise key (this includes KEA in addition to the
> variants
> of D-H).  The S/MIME software doesn't need to make a special check of
> the
> subjectPublicKeyInfo algorithmIdentifier just so that it knows to make
> my
> proposed keyUsage check.  The S/MIME software will already know that a
> pairwise key is required based on the subjectPublicKeyInfo
> algorithmIdentifier.  It will already be executing the code required
to
> generate a pairwise key.  In that code, the check could be made, so
> there is
> not an added, special check of the algorithmIdentifier just to
indicate
> that
> the keyUsage encipherOnly and decipherOnly bits must be checked. 

In the event that an application is providing user interface for the
purpose of creating the association of certificates to email addresses,
it is necessary to know which one is the default encrypting certificate.
In order to make that association, the suitability of the certificate
must be determined before the association can occur.  This is a very
basic tenet that comes in after all of the theoretical work is done.  In
order to make this decision, both the algorithm field in the
SubjectPublicKeyInfo and the keyUsage v3 extension must be used together
to determine this.  That is the only point that I am making.

Used with Triple-DES as a symmetric algorithm, a certificate is suitable
for encrypting a message iff:

1. The SubjectPublicKeyInfo AlgorithmIdentifier is rsaEncryption and the
keyUsage bit "keyEncipherment" is set (or keyUsage is not present).

2. The SubjectPublicKeyInfo AlgorithmIdentifier is dhpublicnumber and
the keyUsage bit "keyAgreement" is 1 and "decipherOnly" is 0 (or
keyUsage is not present, God Help you).

I understand that some of this is an artifact of the shoehorning of
Diffie-Hellman into an RSA model.  Or maybe I don't.  All I know is that
the same bit that determines the suitability for an rsaEncryption
certificate for encrypting the session key cannot be checked to
determine the suitability for a dhpublicnumber certificate.

Does the encipherOnly bit need to be checked at all?  Isn't our use of
Diffie-Hellman limited to "forming a pairwise key to encrypt data"?

Blake (Diffie-Hellman impaired)
--
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

Date: Tue, 24 Mar 1998 18:31:30 -0500
To: <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: CERT-02 Comments
Sender: [email-masked]

Blake,

I believe that my comment is appropriate.  I believe that X.509 and PKIX
clearly state the requirements to check the keyUsage encipherOnly and
decipherOnly bits when the keyUsage keyAgreement bit is set to 1 and the
public key is to be used to either decrypt or encrypt data directly.  I
believe that people will wonder how that rule applies when using the public
key to form a pairwise key to be used to encrypt or decrypt data.  That is
where my proposed text would clarify the requirements.

My proposed text is not unique to D-H.  It is applicable in any scenario in
which the keyUsage keyAgreement bit is set to 1 and the public key is to be
used to form a pairwise key (this includes KEA in addition to the variants
of D-H).  The S/MIME software doesn't need to make a special check of the
subjectPublicKeyInfo algorithmIdentifier just so that it knows to make my
proposed keyUsage check.  The S/MIME software will already know that a
pairwise key is required based on the subjectPublicKeyInfo
algorithmIdentifier.  It will already be executing the code required to
generate a pairwise key.  In that code, the check could be made, so there is
not an added, special check of the algorithmIdentifier just to indicate that
the keyUsage encipherOnly and decipherOnly bits must be checked. 

By the way, here is text that was proposed for addition to the X.509 spec,
but I am not sure of the status of that change proposal:  "The encipherOnly
and decipherOnly key usages are intended to provide support for key
agreement schemes where separate shared secret keys are used in each
direction of communication.  In such a scheme, a user has more than one set
of key pairs and bits 7 (encipherOnly) and 8 (decipherOnly) are used to
distinguish between the two types.  The originator of a message would use
the recipient's public key certificate with bits 4 (keyAgreement) and 7
(encipherOnly) to create a key encryption key.  The recipient would use the
originator's certificate with bits 4 (keyAgreement) and 8 (decipherOnly) to
create the key encryption key.  Typically the originator would pass his or
her own certificate with bits 4 and 8 along with the message."

If the WG believes that my proposal is redundant to X.509 and PKIX then I
will go along with that.  Jim said he liked it, so that alone makes it all
worthwhile:)

- John Pawling

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, <[email-masked]>
Subject: RE: CERT-02 Comments
Date: Tue, 24 Mar 1998 13:55:20 -0800
Sender: [email-masked]

On Tuesday, March 24, 1998 5:11 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> My recommended text regarding the keyUsage encipherOnly and
> decipherOnly
> bits defines how those bits should be used when the public key is
being
> used
> to form a pairwise key.  The X.509 and PKIX specs are not crystal
clear
> regarding that point.  Furthermore, I believe that the X.509 and PKIX
> specs
> are clear regarding the use of the other keyUsage bits, so IMHO the
> S/MIME
> cert spec doesn't need to say anything about those bits.

Got it.

<begin slight rant>

Why is it that we have to be semantically exact in the keyUsage for
Diffie-Hellman?  For RSA encrypting certificates, we use the
keyEncipherment bit to reflect a certificate "that can be used to
encipher a key" (the protected symmetric key in the RecipientInfo).  In
the case of Diffie-Hellman, a certificate used for the exact same
semantic (protecting the symmetric key in the RecipientInfo) has
different bits set.  In order to make a decision regarding the
suitability of a certificate for the purpose of encrypting a message,
you must now take into account both the keyUsage and the
AlgorithmIdentifier that identifies the type of the public key.

<end slight rant>

Perhaps I don't understand this well enough.  Any enlightening words
welcome.

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

Date: Tue, 24 Mar 1998 14:21:02 -0500
To: Tim Dean <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: 'Signature Purpose' attribute?
Cc: [email-masked]
Sender: [email-masked]

Tim:

If a security authority wants to change the label, then it must remove the
originator signature an replace it with a new signature.

User agent processing will become overly complex if we allow there to be
multiple labels on a content.

Russ

At 11:48 AM 3/23/98 +0000, Tim Dean wrote:
>John,
>
>>>3) I like the text in ESS as it stands now, but there may be suggestions
>>to modify the syntax and operation of eSSSecurityLabel to accommodate other
>>requirements.  If ESS were changed, the example might apply.
>
>>[JSP: IMHO, the ESS text must stand.  Your example is a good reason why it
>>must stand.  If the original signer included an eSSSecurityLabel in the
>>original signedData object then additional signer's of that original
>>signedData object MUST not be allowed to include different security labels
>>in signerInfos within the same signedData object.  If that were to be
>>allowed, then there would be mass confusion and room for contradiction when
>>different labels are processed by the recipient as part of the same
>>cumulative access control decision applied to the individual signedData
>>object.  Furthermore, if the original signer did not include an
>>eSSSecurityLabel in the original signedData object, then the original signer
>>made the decision that the content did not need to be labeled and that
>>access control is not required to access the content.  In all cases, all
>>intermediate entities MUST respect the original signer's wishes regarding
>>the eSSSecurityLabel that she included in the signedData that she created or
>>else she is not receiving the security services that she requested when she
>>originally signed the content.]
>
>I must respectfully disagree that in all cases, all intermediate entities
must respect the original signer's
>wishes regarding the label.  In many environments, such as ours, security
authorities have the power of
>veto over any label created by an originator.  In electronic (S/MIME)
terms, my 'environment' will
>probably create the label automatically for me.  That 'environment' could
be the current enclave/domain
>where I am working, or the machine I am currently logged onto, or even the
client software on the
>machine, e.g. on a Compartmented Mode Workstation.  In certain cases the
labelling authority will be a
>human-being acting as a 'release authority'.  This signed label will
probably be checked by the Guard
>before onward transmission.
>
>In short, I want to create and sign messages as an originator; some third
party will counter-sign and label
>them for me.  I am very much hoping that ESS and S/MIME in general will
accommodate this model as
>well as other security policies.  As a general principle, I believe ESS
and S/MIME should be security-
>policy neutral wherever possible.  I am very much hoping that with the
addition of sig-purpose attribute
>'content Reviewer', my particular policy could be supported.  For this
reason, I would very much like all
>of Dave Kemp's original examples, including security label, to remain.
>
>Tim 
>
>----------
>From:  John Pawling [SMTP:[email-masked]]
>Sent:  Thursday, March 19, 1998 10:34 PM
>To:  David P. Kemp; [email-masked]
>Subject:  Re: 'Signature Purpose' attribute?
>
>Dave,
>
>Please see my responses in-line:
>
>
>At 04:30 PM 3/19/98 -0500, David P. Kemp wrote:
>>> From: [email-masked] (John Pawling)

>>> 
>>> The contentReviewer is only allowed to
>>> include an eSSSecurityLabel authenticated attribute in the signerInfo that
>>> she signs if there was already an eSSSecurityLabel attribute present in
the
>>> signerInfo(s) already included in the original signedData object.
>>
>>
>>John,
>>
>>  It was just an example, but thanks for pointing out the restrictions on
>>eSSSecurityLabel.  I can think of three rebuttals:
>>
>>1) the above quoted sentence isn't necessarily true in all cases, because
>>a security gateway could take a message (either signed or plain old email)
>>and wrap it in a new signedData.
>
>[JSP: I agree that an intermediate entity can encapsulate the original
>signedData object within a new outer signedData object.  The intermediate
>entity can then include the appropriate eSSSecurityLabel attribute, if
>required, in the signerInfo within the new outer signedData object.  The
>intermediate entity's eSSSecurityLabel attribute may be different than that
>included in the inner signedData object.  IMHO, that is acceptable because
>the recipient MUST make a separate access control decision for each of the
>signedData layers.  The recipient MUST process the eSSSecurityLabel in each
>signedData object that it verifies.  Because the recipient will verify both
>the outer and inner signedData objects, then it MUST process the
>eSSSecurityLabel attribute in each of the signedData objects.  Therefore,
>both the original signer's and intermediate entity's eSSSecurityLabels are
>processed by the recipient.  An important point to note is that the
>recipient software makes a separate access control decision for each
>signedData object.  IMHO, that is the primary difference between processing
>eSSSecurityLabels included in layered signedData objects versus those
>included in multiple signerInfos included in the same signedData object.  In
>the latter case, all eSSSecurityLabels included in the various signerInfos
>(that are verified) are checked as part of the same cumulative access
>control decision process applied to the individual signedData object.  
>
>To get back to your original rebuttal, if the intermediate entity adds the
>outer signedData, then IMHO it is not a contentReviewer, it is a
>contentOriginator because it is creating a new signedData object.
>Therefore, I believe that my comment still stands.]
>
>
>>2) eSSSecurityLabel is defined in the ESS document, whereas signaturePurpose
>>has been proposed for inclusion in CMS.  CMS may be used in non-S/MIME
>>applications which have different compliance requirements than S/MIME and
>>which do not refer to ESS at all.
>
>[JSP: One of the major goals of ESS is to define standard attributes for use
>with CMS.  The CMS spec MUST NOT make statements (such as your example IMHO)
>that are contradictory to the principles of ESS (which CMS currently does
>not).  The best strategy would be for CMS not to mention security labels at
>all (which it currently does not).  Therefore, I recommend that you should
>either remove the security label example or move the signaturePurpose
>attribute to ESS and discuss eSSSecurityLabels.  Furthermore, applications

>that use eSSSecurityLabels attributes MUST set the attributes to be critical
>so if an application needs to use security labels it would be best if it
>were to implement eSSSecurityLabels to avoid interoperability problems with
>those applications that are implementing the standard eSSSecurityLabels.]  
>
>
>>3) I like the text in ESS as it stands now, but there may be suggestions
>>to modify the syntax and operation of eSSSecurityLabel to accommodate other
>>requirements.  If ESS were changed, the example might apply.
>
>[JSP: IMHO, the ESS text must stand.  Your example is a good reason why it
>must stand.  If the original signer included an eSSSecurityLabel in the
>original signedData object then additional signer's of that original
>signedData object MUST not be allowed to include different security labels
>in signerInfos within the same signedData object.  If that were to be
>allowed, then there would be mass confusion and room for contradiction when
>different labels are processed by the recipient as part of the same
>cumulative access control decision applied to the individual signedData
>object.  Furthermore, if the original signer did not include an
>eSSSecurityLabel in the original signedData object, then the original signer
>made the decision that the content did not need to be labeled and that
>access control is not required to access the content.  In all cases, all
>intermediate entities MUST respect the original signer's wishes regarding
>the eSSSecurityLabel that she included in the signedData that she created or
>else she is not receiving the security services that she requested when she
>originally signed the content.]
>
>>
>>
>>     dpk
>>
> 

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: CERT-02 Comments
Date: Tue, 24 Mar 1998 09:11:57 -0800
Sender: [email-masked]

I agree with both of these statements.  

I don't think we have a problem with stating the usage of encipherOnly and
decipherOnly in the event that PKIX makes their text much more clearer, but
I agree with John that the current text is not sufficently clear on those
bits.  I think there are also some disputes on nonRepudiation, but that is a
rat hole I think we can avoid.

If you want to reference the V2 specs and provide their RFC numbers, thats
great.  I don't think there is any reason for us to put in the differences
section any more as the V2 documents will not be available "forever" for
comparision.

jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 24, 1998 5:11 AM
To: [email-masked]
Subject: RE: CERT-02 Comments

Blake,

>I need some explanation for this.  My understanding is that we have
>three uses for certificates that would be affected by the keyUsage
>extension:
>
>1. Validating a signature on a certificate or CRL
>2. Validating a signature on a message
>3. Creating a RecipientInfo on a message (encrypting the content
>encryption key)
>
>Why are we calling out this specific case, but not the others?

My recommended text regarding the keyUsage encipherOnly and decipherOnly
bits defines how those bits should be used when the public key is being used
to form a pairwise key.  The X.509 and PKIX specs are not crystal clear
regarding that point.  Furthermore, I believe that the X.509 and PKIX specs
are clear regarding the use of the other keyUsage bits, so IMHO the S/MIME
cert spec doesn't need to say anything about those bits.

The X.509 spec, sec 12.2.2.3 states:

"h) encipherOnly: public key agreement key for use only in enciphering data
when used with keyAgreement bit also set (meaning with other key usage bit
set is undefined);

i) decipherOnly: public key agreement key for use only in deciphering data
when used with keyAgreement bit also set (meaning with other key usage bit
set is undefined);"

Applying the aforementioned statements to the generation of pairwise keys
yields the proposed text:

"If the keyUsage keyAgreement bit is set to 1 AND if the public key is to be
used to form a pairwise key to decrypt data, then the S/MIME agent MUST only
use the public key if the keyUsage encipherOnly bit is set to 0.  If the
keyUsage keyAgreement bit is set to 1 AND if the key is to be used to form a
pairwise key to encrypt data, then the S/MIME agent MUST only use the public
key if the keyUsage decipherOnly bit is set to 0."

If the group decides that the X.509 and PKIX specs are sufficiently clear
and that the recommended this text is not needed, that is OK with me. 

>> 14) Appendix D, Please delete this entire Appendix because it is out
>of
>> date
>> and not needed.
>
>I will agree that it is out of date, but is it truly not needed?  Would
>it be better to fix it or throw it out?

I recommend throwing it out.  The S/MIME v2 specs are readily available for
a side-by-side comparison with the v3 specs.

Date: Tue, 24 Mar 1998 09:01:11 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Historical information in the -msg and -cert drafts
Sender: [email-masked]

Greetings again. Now that all of S/MIME v2 is specified in informational
RFCs, I think it is perferable for S/MIME v3 to refer to those RFCs and not
to repeat the information in them. Thus, I propose that Blake remove
Appendix C from -msg and -cert. Section 1.4 of -msg and Section 1.2 of
-cert should be changed to read:

S/MIME version 3 agents should attempt to have the greatest
interoperability possible with S/MIME version 2 agents. S/MIME version 2 is
described in RFC 2311 through RFC 2315, inclusive. RFC 2311 also has
historical information about the development of S/MIME.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 24 Mar 1998 08:11:00 -0500
To: <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: CERT-02 Comments
Sender: [email-masked]

Blake,

>I need some explanation for this.  My understanding is that we have
>three uses for certificates that would be affected by the keyUsage
>extension:
>
>1. Validating a signature on a certificate or CRL
>2. Validating a signature on a message
>3. Creating a RecipientInfo on a message (encrypting the content
>encryption key)
>
>Why are we calling out this specific case, but not the others?

My recommended text regarding the keyUsage encipherOnly and decipherOnly
bits defines how those bits should be used when the public key is being used
to form a pairwise key.  The X.509 and PKIX specs are not crystal clear
regarding that point.  Furthermore, I believe that the X.509 and PKIX specs
are clear regarding the use of the other keyUsage bits, so IMHO the S/MIME
cert spec doesn't need to say anything about those bits.

The X.509 spec, sec 12.2.2.3 states:

"h) encipherOnly: public key agreement key for use only in enciphering data
when used with keyAgreement bit also set (meaning with other key usage bit
set is undefined);

i) decipherOnly: public key agreement key for use only in deciphering data
when used with keyAgreement bit also set (meaning with other key usage bit
set is undefined);"

Applying the aforementioned statements to the generation of pairwise keys
yields the proposed text:

"If the keyUsage keyAgreement bit is set to 1 AND if the public key is to be
used to form a pairwise key to decrypt data, then the S/MIME agent MUST only
use the public key if the keyUsage encipherOnly bit is set to 0.  If the
keyUsage keyAgreement bit is set to 1 AND if the key is to be used to form a
pairwise key to encrypt data, then the S/MIME agent MUST only use the public
key if the keyUsage decipherOnly bit is set to 0."

If the group decides that the X.509 and PKIX specs are sufficiently clear
and that the recommended this text is not needed, that is OK with me. 

>> 14) Appendix D, Please delete this entire Appendix because it is out
>of
>> date
>> and not needed.
>
>I will agree that it is out of date, but is it truly not needed?  Would
>it be better to fix it or throw it out?

I recommend throwing it out.  The S/MIME v2 specs are readily available for
a side-by-side comparison with the v3 specs.

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, <[email-masked]>
Subject: RE: CERT-02 Comments
Date: Mon, 23 Mar 1998 18:34:47 -0800
Sender: [email-masked]

OK, Blake's awake and revising things:

On Friday, March 13, 1998 12:34 PM, [email-masked]
[SMTP:[email-masked]] wrote:
> 11) Sec 4.4.2, last para:  Please add: "If the keyUsage keyAgreement
bit
> is
> set to 1 AND if the public key is to be used to form a pairwise key to
> decrypt data, then the S/MIME agent MUST only use the public key if
the
> keyUsage encipherOnly bit is set to 0.  If the keyUsage keyAgreement
bit
> is
> set to 1 AND if the key is to be used to form a pairwise key to
encrypt
> data, then the S/MIME agent MUST only use the public key if the
> keyUsage
> decipherOnly bit is set to 0."

I need some explanation for this.  My understanding is that we have
three uses for certificates that would be affected by the keyUsage
extension:

1. Validating a signature on a certificate or CRL
2. Validating a signature on a message
3. Creating a RecipientInfo on a message (encrypting the content
encryption key)

Why are we calling out this specific case, but not the others?

> 14) Appendix D, Please delete this entire Appendix because it is out
of
> date
> and not needed.

I will agree that it is out of date, but is it truly not needed?  Would
it be better to fix it or throw it out?

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

Date: Mon, 23 Mar 1998 18:46:45 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Inclusion of the issuer and serial number in authenticated  information
Sender: [email-masked]

All,

I agree with Russ and Eric that we should stick with Jim Schaad's original
proposal to define the signing-certificate attribute type as the CMP
IssuerAndSerialNumber syntax.  Here is the scenario as I see it:

1) The originator populates the signedData signerInfo signing-certificate
authenticatedAttribute with the IssuerAndSerialNumber of the signer's cert
containing the public key required to validate the signer's signature of the
signedData signerInfo.

2) The originator calculates the signature value of the CMS signedData
signerInfo as described in CMS; therefore, the  signing-certificate
authenticatedAttribute containing the IssuerAndSerialNumber of the signer's
cert are bound with the content.

3) The originator sends the signedData to the recipient.

4) The recipient decodes the signedData to determine the signerInfo
IssuerAndSerialNumber identifying the signer's cert.

5) The recipient obtains the signer's certificate issued by the identified
CA which includes the designated serial number.   

6) The recipient builds a cert path connecting the retrieved signer's
certificate with the verifier's trusted key and validates that cert path as
per PKIX and X.509.  Among other things, this reliably binds the public key
with the subject name, issuer name and serialNumber in the signer's cert.

7) The recipient uses the validated signer's public key to verify the
signature of the received signedData signerInfo.  This verifies (among other
things) the binding between the signing-certificate authenticatedAttribute
and signedData content.

8) The recipient compares the verified signing-certificate
authenticatedAttribute with the verified issuer name and serialNumber of the
signer's cert.

This entire process verifies:

a) that the correct public key was used to verify the signature of the
SignedData signerInfo; 

b) the binding of the public key used to verify the signature with the
subject name, issuer name and serialNumber (among other things) in the
signer's cert;

c) the binding of the signedData content with the signing-certificate
authenticatedAttribute (i.e. IssuerAndSerialNumber of signer's cert)
included in the verified signerInfo; and

d) that the correct public key used to verify the SignedData signerInfo
signature was extracted from the correct, verified signer's cert as
identified by the verified signing-certificate authenticatedAttribute.

I don't see any holes in the aforementioned strategy.  There is always the
"renegade CA" argument, but the renegade CA's cert must be a part of a valid
cert path than can be verified to the verifier's trusted key.  It will be
extremely rare for a renegade CA's cert to be a part of a valid cert path
than can be verified to the verifier's trusted key.  The use of the
nameConstraints extensions in each cert in the cert path can be used to
limit the damage that can be done by a validated renegade CA.  The main
defense is that the users will notice that something is wrong and report the
renegade CA.  In that case, the renegade CA will be shut down or the cross
cert to its domain revoked.

I don't see any purpose to add a hash of the certificate to this process
because the signer's cert path is verified to the verifier's trusted key.  I
don't believe that there will ever be a case in which there are multiple
CA's using the same Issuer DNs that are issuing certs that include the same
serial numbers and the same public keys that can all be validated via a
valid cert path to the verifier's trusted key.

I also don't see any purpose to use the X.509 IssuerSerial syntax because
all subject and issuer names MUST be populated (i.e. not an empty SEQUENCE)
in S/MIME-compliant v3 X.509 Certificates, except that the subject DN in a
user's (i.e. end-entity) certificate MAY be an empty SEQUENCE in which case
the subjectAltName extension will include the subject's identifier and MUST
be marked as critical.

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

Date: Mon, 23 Mar 1998 15:16:28 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Informational RFCs for S/MIME v2
Sender: [email-masked]

The specifications for S/MIME v2 have been released as informational RFCs.
The new documents are:

S/MIME Version 2 Message Specification (RFC 2311) 
S/MIME Version 2 Certificate Handling (RFC 2312) 
PKCS #1: RSA Encryption Version 1.5 (RFC 2313) 
PKCS #10: Certification Request Syntax Version 1.5 (RFC 2314) 
PKCS #7: Cryptographic Message Syntax Version 1.5 (RFC 2315) 

All documents can be found at <http://www.imc.org/smime-pgpmime.html>.

Work to make standards-track S/MIME v3 continues, of course. :-)

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 23 Mar 1998 16:30:46 -0500
To: Tim Dean <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: 'Signature Purpose' attribute?
Cc: "David P. Kemp" <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]

Tim,

Your arguments only serve to further convince me that the ESS
eSSSecurityLabel processing requirements must not be changed.  Your
statement that an intermediate entity can "veto" the originator's label
confirms my fear that intermediate entities may be allowed (if given the
chance) to invalidate the original signer's eSSSecurityLabel.  If that
happens, then the original signer is not receiving the security security
services that she requested when she originally signed the content.  
  
Your requirements can be met by nesting signedData layers.  The original
signer can include her eSSSecurityLabel in the original, inner signedData
layer.  The intermediate entity can include its eSSSecurityLabel in an outer
signedData layer that encapsulates the original, inner signedData layer.
This is the optimal strategy because the recipient MUST make a separate
access control decision for each of the signedData layers.  The recipient
MUST process the eSSSecurityLabel in each
signedData object that it verifies.  Because the recipient will verify both
the outer and inner signedData objects, then it MUST process the
eSSSecurityLabel attribute in each of the signedData objects.  Therefore,
both the original signer's and intermediate entity's eSSSecurityLabels are
processed by the recipient.  

If your proposal was accepted and multiple eSSSecurityLabels were allowed in
the same signerInfo or same signedData, then there would be mass confusion
and room for contradiction when different labels are processed by the
recipient as part of the same cumulative access control decision applied to
the individual signedData object.  I believe that it is impractical to try
to force the S/MIME community into accepting a complicated access control
decision strategy such as would be required to define the rules to process
multiple eSSSecurityLabels included in the same signerInfo or same signedData.

In summary, my opinion is that Dave Kemp's security label example must be
deleted.

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================  

At 11:48 AM 3/23/98 -0000, Tim Dean wrote:
>John,

<snip>

>I must respectfully disagree that in all cases, all intermediate entities
must respect the original signer's
>wishes regarding the label.  In many environments, such as ours, security
authorities have the power of
>veto over any label created by an originator.  In electronic (S/MIME)
terms, my 'environment' will
>probably create the label automatically for me.  That 'environment' could
be the current enclave/domain
>where I am working, or the machine I am currently logged onto, or even the
client software on the
>machine, e.g. on a Compartmented Mode Workstation.  In certain cases the
labelling authority will be a
>human-being acting as a 'release authority'.  This signed label will
probably be checked by the Guard
>before onward transmission.
>
>In short, I want to create and sign messages as an originator; some third
party will counter-sign and label
>them for me.  I am very much hoping that ESS and S/MIME in general will
accommodate this model as
>well as other security policies.  As a general principle, I believe ESS and
S/MIME should be security-
>policy neutral wherever possible.  I am very much hoping that with the
addition of sig-purpose attribute
>'content Reviewer', my particular policy could be supported.  For this
reason, I would very much like all
>of Dave Kemp's original examples, including security label, to remain.
>
>Tim 
>

Date: Mon, 23 Mar 1998 11:48:55 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: New draft of CMS
Sender: [email-masked]

Greetings, all. The -04 version of the CMS draft is now available on the
IMC web site at
<http://www.imc.org/draft-ietf-smime-cms>
Note that this is newer than the -03 version that is in the official
Internet Drafts directory since submission of new drafts is not available
until after our WG meeting next week. We will be discussing the -04 draft
at the meeting next Monday. (You may need to clear your browser cache to
get the -04 version from the URL listed above.)

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 23 Mar 1998 13:03:55 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: CMS: signed attributes?
Sender: [email-masked]

I suggest that the CMS SignerInfo fields "authenticatedAttributes" and
"unauthenticatedAttributes" be renamed to "signedAttributes" and
"unsignedAttributes" respectively.

There are two justifications for this request, one trivial and one
substantive:

* Trivial reason: "signed" is easier to type than "authenticated",
  and it sounds pretentious to use five syllables when one will do.

* Real reason: signing is a mechanical process - attributes are either
  covered by a digital signature or not.  Authentication is a process
  involving policies and procedures - an attribute is not "authenticated"
  unless the signature (including the cert path) verifies correctly and
  the certificate policies allow the use of the attribute.  It is incorrect
  to call an attribute authenticated solely because it is signed, just
  as it is incorrect to call a certificate "valid" because it is signed.

Date: Mon, 23 Mar 1998 12:46:05 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Inclusion of the issuer and serial number in authenticated  information
Sender: [email-masked]

> From: EKR <[email-masked]>
> 
> > Russ Housley <[email-masked]> writes:
> > I do not see the value in the certificate hash.  However, if many people
> > think it is desirable, then it should be optional.  We must trust CAs to
> > never issue more than one certificate with the same serial number.
> > Revocation will be all messed up if they do....
>
> I don't see the value in the certificateHash either. Let's leave it
> out.
> 
> -Ekr

Do you not see the problem that it is trying to solve, or do you believe
that solving it is not important?

I agree that CAs have to be trusted to correctly manage serial numbers.
However, do you believe that every end user will have a single trust
point, that that trust point is worthy, and that that trust point will
use X.509 mechanisms?

The current state of web browser technology is far from this ideal:
user agents maintain a database of CAs (multiple trust points), the
average user is clueless about what to include in that database, and
the user agent has no mechanism for assigning unique serial numbers to
the CAs in the database.

Given that state of affairs, I think it is reasonable to have some
assurance that a certification path can be traced back at least to the
top-level CA in that path, and not allow a single rogue CA inserted
into the database to corrupt everything.  The certificate hash
(or hash of the public key) provides local assurance, which I believe
has some value.  (Note that an arbitrarily-assigned subjectKeyIdentifier
is no more useful here than CertificateSerialNumber, you need a
determined function of the public key.)

I have a specific disagreement with Denis' suggestion:

>There is no final position yet, but it seems that we are going towards
>the following structure:
>
>CertUID ::=     SEQUENCE {
>     issuerDN           Name,
>     issuerAltName      IssuerAltName OPTIONAL,  -- As defined in PKIX
>     serial             CertificateSerialNumber,
>     certificateHash    CertHash
>}

There is no reason to include both issuerDN and issuerAltName, since
GeneralNames includes X.400 name forms.  I think it is reasonable to
require CAs to have DNs, in which case the issuerAltName could be
eliminated altogether.  But if the rest of the world doesn't agree that
CAs MUST have DNs, then I suggest using X.509 IssuerSerial.

A hash algorithm specifier is needed too:

  CertUID ::= SEQUENCE {
     certID      IssuerSerial,
     certHash/keyHash  Hash }    -- of Certificate or SubjectPublicKeyInfo

  IssuerSerial ::= SEQUENCE {    -- defined in X.509
     issuer      GeneralNames,
     serial      CertificateSerialNumber,
     issuerUID   UniqueIdentifier OPTIONAL }

  Hash ::= CHOICE {
     sha1Hash     [0] OCTET STRING,
       .          [1] OCTET STRING,
       .
  }

Date: Mon, 23 Mar 1998 11:59:39 -0500
To: Russ Housley <[email-masked]>
From: Elliott Ginsburg <[email-masked]>
Subject: Re: cert-02 comments
Cc: [email-masked]
Sender: [email-masked]

There are a number of steps in the process of validating a signature, and
checking the cert for revocation is one of them. I think that when any of
these steps fail, the best response is to inform the user. Speaking for
myself as a user, if I receive a signed message, but the signature does not
validate, I will want to know why the validation failed; I will then make
the judgement of how much to trust the message, and I feel I can make that
judgement better, on a case-by-case basis, than can some hardcoded rules in
my user agent. For example, if a signature validation fails even though the
cert is valid, this is different than the case where the 'From' address
does not match an address in the cert, which is yet different from a
signature which is valid except that the cert was revoked. I guess I'm
saying that every time a signature on a message is checked, the user agent
should report the outcome as either successful or failed for a particular
reason. In the case we are discussing, where there is no CRL, I think the
user agent would inform the user that the signature checked, but it could
not be determined that the cert was not revoked. It would then be up to the
user to decide what to do with the message.

This is easily done with a human user, but more difficult for an automated
message reception process. One solution would be to have a set of possible
reasons for validation failure; the automated process could be setup to
decide what to do for each type of failure.

elliott ginsburg

At 10:09 AM 3/23/98 , Russ Housley wrote:
>Elliott:
>
>I agree with you; however, there are still some large Cas that do not issue
>CRLs.  How should we deal with this situation?  Should we say that
>certificates for such CAs cannot be used with S/MIME?
>
>Russ
>
>
>At 11:30 AM 3/20/98 -0500, Elliott Ginsburg wrote:
>>In section 2.1:
>>
>>"...All agents SHOULD check the nextUpdate field in the CRL against the
>>current time. If the current time is later than the nextUpdate time, the
>>actioin that the agent takes is a local decision. For instance, it could
>>warn a human user, it could retrieve a new CRL if able, and so on."
>>
>>I think that since this section requires the checking of certs against
>>CRLs, that we ought to require (MUST) that the agent check the nextUpdate
>>field. I also think that we can be a little more specific about what the
>>agent does if it is later than this time. I suggest the following:
>>
>>"...All agents MUSTcheck the nextUpdate field in the CRL against the
>>current time. If the current time is later than the nextUpdate time, the
>>agent  MUST take some appropriate action. For instance, one recommended set
>>of actions would be: 1) retrieve a new CRL if possible, or 2) issue a
>>warning that revocation could not be checked."
>>
>>elliott ginsburg
>> 
> 

To: Russ Housley <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Inclusion of the issuer and serial number in authenticated   in formation
From: EKR <[email-masked]>
Date: 23 Mar 1998 08:43:05 -0800
Lines: 15
Sender: [email-masked]

I
Russ Housley <[email-masked]> writes:

>  do not see the value in the certificate hash.  However, if many people
> think it is desirable, then it should be optional.  We must trust CAs to
> never issue more than one certificate with the same serial number.
> Revocation will be all messed up if they do....
I don't see the value in the certificateHash either. Let's leave it
out.

-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

Date: Mon, 23 Mar 1998 11:22:45 -0500
To: [email-masked], [email-masked], [email-masked]
From: [email-masked] (John Pawling)
Subject: S/MIME Freeware Library Announcement
Sender: [email-masked]

All,

The S/MIME Freeware Library (SFL) is a reference implementation of the IETF
S/MIME v3 CMS and ESS I-Ds. All source code for the SFL will be provided at
no cost and with no limitations regarding its use and distribution.
Organizations will be able to use the SFL without paying any royalties or
licensing fees.  J.G. Van Dyke and Associates, Inc, (VDA) is developing the
SFL under contract to the US Government. 

Draft versions of the SFL Fact Sheet, Software Design Description (SDD) and
Application Programming Interface (API) documents (including SFL header
files) are now available.  The Internet Mail Consortium (IMC) has
established an SFL web page at http://www.imc.org/imc-sfl/ which includes
links to the SFL documents stored on the VDA web site
(http://www.jgvandyke.com/services/infosec/sfl.html).  The IMC has also
established an SFL mail list which will be used to: distribute information
regarding SFL releases; discuss SFL-related issues; and provide a means for
SFL users to provide feedback, comments, bug reports, etc.  Please note that
all SFL-related discussion should occur on the imc-sfl mail list and not the
ietf-smime mail list.  Subscription information for the imc-sfl mailing list
is at the IMC Web site listed above.

An incomplete, "interim release" of the SFL software will be available by 31
Mar 98.  Further releases will be provided as significant capabilities are
added.  The target for completion of the SFL is June 1998. The stability of
the S/MIME v3 set of specifications is a prerequisite for meeting this
delivery goal.
  
The SFL is composed of a high-level library that performs generic CMS and
ESS processing independent of the crypto algorithms used to protect a
specific object.  The SFL high-level library makes calls to an
algorithm-independent Crypto Token Interface API.  The underlying, external
crypto token libraries will not be distributed as part of the SFL source
code.  The application developer will independently obtain these libraries
and then link them with the SFL.  This strategy will allow the SFL source
code to be freely distributed to the entire Internet community because it
does not contain software that directly implements any crypto algorithms
that are copyrighted or export controlled. 

IMC plans to add Web links pointing to freeware and commercial crypto
libraries that are compatible with SFL as they become available.

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

Date: Mon, 23 Mar 1998 10:06:54 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Inclusion of the issuer and serial number in authenticated in formation
Cc: [email-masked]
Sender: [email-masked]

I do not see the value in the certificate hash.  However, if many people
think it is desirable, then it should be optional.  We must trust CAs to
never issue more than one certificate with the same serial number.
Revocation will be all messed up if they do....

Russ

At 05:28 PM 3/20/98 -0800, Denis Pinkas wrote:
>There is no final position yet, but it seems that we are going towards
>the following structure:
>
>CertUID ::=     SEQUENCE {
>     issuerDN           Name,
>     issuerAltName      IssuerAltName OPTIONAL,  -- As defined in PKIX
>     serial             CertificateSerialNumber,
>     certificateHash    CertHash
>}
>
>This allows the support of alternate names and the certificate hash
>allows to make the difference between certificates that would be issued
>by CAs having the same name.
>
>In any case, I would recommend that the pkix group and the smime group
>adopt the same structure.
>
>Denis
>
>-- 
>      Denis Pinkas     Bull S.A.          mailto:[email-masked]
>      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
>      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21
> 

Date: Mon, 23 Mar 1998 10:09:00 -0500
To: Elliott Ginsburg <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: cert-02 comments
Cc: [email-masked]
Sender: [email-masked]

Elliott:

I agree with you; however, there are still some large Cas that do not issue
CRLs.  How should we deal with this situation?  Should we say that
certificates for such CAs cannot be used with S/MIME?

Russ

At 11:30 AM 3/20/98 -0500, Elliott Ginsburg wrote:
>In section 2.1:
>
>"...All agents SHOULD check the nextUpdate field in the CRL against the
>current time. If the current time is later than the nextUpdate time, the
>actioin that the agent takes is a local decision. For instance, it could
>warn a human user, it could retrieve a new CRL if able, and so on."
>
>I think that since this section requires the checking of certs against
>CRLs, that we ought to require (MUST) that the agent check the nextUpdate
>field. I also think that we can be a little more specific about what the
>agent does if it is later than this time. I suggest the following:
>
>"...All agents MUSTcheck the nextUpdate field in the CRL against the
>current time. If the current time is later than the nextUpdate time, the
>agent  MUST take some appropriate action. For instance, one recommended set
>of actions would be: 1) retrieve a new CRL if possible, or 2) issue a
>warning that revocation could not be checked."
>
>elliott ginsburg
> 

Date: Mon, 23 Mar 1998 15:38:54 -0800
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Ambarish Malpani <[email-masked]>
CC: "Ietf-Smime (E-mail)" <[email-masked]>, [email-masked]
Subject: Re: Unique Identification of a Certificate
Sender: [email-masked]

See an updated proposal for CertUID at the end of this E-mail.

Ambarish Malpani wrote:

> Hi Denis,
>     I joined the SMIME mailing list just recently, so I am not certain
> of the problem you guys are trying to solve. Let me explain the
> issues in RCSP and the reasoning for choosing the method I have
> for trying to uniquely identify a cert:

> In RCSP, a client is sending over one or more certificates to an
> RCSP responder, to check their revocation status.
> I think we all agree that issuer/serial is sufficient to uniquely
> identify a certificate.

I would disagree with this, unless "issuer" is a FDN in the X.521 sense.

> So the question is: how does one uniquely identify an issuer.

This is not the right question.   :-(

> I submit that the DN is not enough, because it is possible for
> the to be DN name clashes - either maliciously, or because two
> groups don't talk to each other before they choose their names.

DN can clash when they are RDNs (Relative Distinguished Names).

> There really is no way of enforcing uniqueness is issuer DNs all
> over the world.

Correct.

> However, public keys don't suffer from the problem of impersonation.
> If somebody else claims to have the same public/private key as me,
> it is easy to prove otherwise.

OK.

> Therefore, we have chosen to use the issuerDN, issuerPublicKey
> and CertificateSerialNumber to uniquely identify a cert. (I need
> to add the issuerAltName also, as you have).

The problem to consider is an empty DN and the use of an issuerAltName.
The issuerAltName and the CertificateSerialNumber do not necessarily
identify uniquely a certificate unless some additional assumptions are
made on the structure of the issuerAltName.

> As an optimization, to reduce the size of a request, we ask the
> requestor to hash the issuerDN and issuerPublicKey in the request
> rather than sending all the bytes.

Hold on a second. You suppose an upstream problem already solved !
If you get a signed message, you may need to identify who signed it and
with which certificate. The structure you propose below does not allows
this, unless by some magic you get an hint.

> Adding the certificateHash in the CertUID doesn't help us identify
> the cert at all, because as an RCSP responder, I don't have the
> cert itself - so I can't verify the CertHash against anything.

But it does help the requester  :-)

See also the response I sent today to Carlisle, where I raise the basic
question on the means to identify the right OCSP. If that question is
solved, then your problem is also solved. However, I do not claim that
the answer to that question is unique or easy. :-)

> As an aggregator of revocation data/CRLs from multiple CAs, we
> would like to be able to accept all CRLs - including ones where
> the DNs might clash.
> 
> Is the SMIME problem different from this one? Does the recipient
> already have the certificate the sender is referring to?
> 
> Regards,
> Ambarish
> 
> P.S. For those who haven't been actively following these groups,
> my suggestion for cert identification is:
> 
> CertID                  ::=     SEQUENCE {
>         issuerNameAndKeyHash            Hash,
>         serialNumber                    CertificateSerialNumber,
> }
> 
> IssuerNameAndKey                ::=     SEQUENCE {
>         issuerDN                        Name,
>         issuerAltName                   IssuerAltName OPTIONAL,
>         issuerPublicKey                 SubjectPublicKeyInfo
> }
> 
> i.e. you identify a cert by the hash of the IssuerNameAndKey
> and a serial number.
> 
> The hash includes the public key of the issuer - this prevents the
> Banana Republic CA from impersonating our well beloved and well
> trusted US CA ;-).
> 
> Ofcourse, if keeping the size of the request small is not important,
> or the recipient might not be able to figure out the issuer from
> the hash, it might make sense to send IssuerNameAndKey instead
> of its hash.
> 
> Denis Pinkas wrote:
> 
> > There is no final position yet, but it seems that we are going towards
> > the following structure:
> >
> > CertUID ::=     SEQUENCE {
> >      issuerDN           Name,
> >      issuerAltName      IssuerAltName OPTIONAL,  -- As defined in PKIX
> >      serial             CertificateSerialNumber,
> >      certificateHash    CertHash
> > }
> >
> > This allows the support of alternate names and the certificate hash
> > allows to make the difference between certificates that would be issued
> > by CAs having the same name.
> >
> > In any case, I would recommend that the pkix group and the smime group
> > adopt the same structure.
> >
> > Denis

There has been a proposal to make the certificateHash optional. If the
issuerDN is a FDN, then the certificateHash is not needed, so this is a
good reason. If the  issuerAltName has some form of hierarchy that
allows it to be unambiguous, in the same way the certificateHash is not
needed. In all the other cases, it is needed.

I would thus propose the following structure :

CertUID ::=     SEQUENCE {
      issuerDN           Name,
      issuerAltName      IssuerAltName OPTIONAL,  -- As defined in PKIX
      serial             CertificateSerialNumber,
      certificateHash    CertHash OPTIONAL
}

Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Sun, 22 Mar 1998 22:16:40 -0500
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: [email-masked]
Subject: Re: 'Signature Purpose' attribute?
Sender: [email-masked]

    I agree with Russ and John that Signature Purpose is probably more suitable to ESS than to CMS.  Restricting the semantics of a signature to a specific semantic is certainly not a capability that would be a MUST requirement.  John is also correct that we should avoid mentioning the security label in CMS.  However, I think that some very likely basic purpose codes involve the label, and it would be kind of hard to define these in the context of CMS.

Chris

_______________________

Russ Housley wrote:

> John:
>
> I agree with your analysis.  If the the working group reaches concensus on
> the current signature purpose structre, then it belongs in ESS, not CMS.
>
> Russ
>
> At 05:33 PM 3/19/98 -0500, John Pawling wrote:
> >Dave,
> >
> >Please see my responses in-line:
> >
> >
> >At 04:30 PM 3/19/98 -0500, David P. Kemp wrote:
> >>> From: [email-masked] (John Pawling)
> >>>
> >>> The contentReviewer is only allowed to
> >>> include an eSSSecurityLabel authenticated attribute in the signerInfo that
> >>> she signs if there was already an eSSSecurityLabel attribute present in
> the
> >>> signerInfo(s) already included in the original signedData object.
> >>
> >>
> >>John,
> >>
> >>  It was just an example, but thanks for pointing out the restrictions on
> >>eSSSecurityLabel.  I can think of three rebuttals:
> >>
> >>1) the above quoted sentence isn't necessarily true in all cases, because
> >>a security gateway could take a message (either signed or plain old email)
> >>and wrap it in a new signedData.
> >
> >[JSP: I agree that an intermediate entity can encapsulate the original
> >signedData object within a new outer signedData object.  The intermediate
> >entity can then include the appropriate eSSSecurityLabel attribute, if
> >required, in the signerInfo within the new outer signedData object.  The
> >intermediate entity's eSSSecurityLabel attribute may be different than that
> >included in the inner signedData object.  IMHO, that is acceptable because
> >the recipient MUST make a separate access control decision for each of the
> >signedData layers.  The recipient MUST process the eSSSecurityLabel in each
> >signedData object that it verifies.  Because the recipient will verify both
> >the outer and inner signedData objects, then it MUST process the
> >eSSSecurityLabel attribute in each of the signedData objects.  Therefore,
> >both the original signer's and intermediate entity's eSSSecurityLabels are
> >processed by the recipient.  An important point to note is that the
> >recipient software makes a separate access control decision for each
> >signedData object.  IMHO, that is the primary difference between processing
> >eSSSecurityLabels included in layered signedData objects versus those
> >included in multiple signerInfos included in the same signedData object.  In
> >the latter case, all eSSSecurityLabels included in the various signerInfos
> >(that are verified) are checked as part of the same cumulative access
> >control decision process applied to the individual signedData object.
> >
> >To get back to your original rebuttal, if the intermediate entity adds the
> >outer signedData, then IMHO it is not a contentReviewer, it is a
> >contentOriginator because it is creating a new signedData object.
> >Therefore, I believe that my comment still stands.]
> >
> >
> >>2) eSSSecurityLabel is defined in the ESS document, whereas signaturePurpose
> >>has been proposed for inclusion in CMS.  CMS may be used in non-S/MIME
> >>applications which have different compliance requirements than S/MIME and
> >>which do not refer to ESS at all.
> >
> >[JSP: One of the major goals of ESS is to define standard attributes for use
> >with CMS.  The CMS spec MUST NOT make statements (such as your example IMHO)
> >that are contradictory to the principles of ESS (which CMS currently does
> >not).  The best strategy would be for CMS not to mention security labels at
> >all (which it currently does not).  Therefore, I recommend that you should
>
> >either remove the security label example or move the signaturePurpose
> >attribute to ESS and discuss eSSSecurityLabels.  Furthermore, applications
> >that use eSSSecurityLabels attributes MUST set the attributes to be critical
> >so if an application needs to use security labels it would be best if it
> >were to implement eSSSecurityLabels to avoid interoperability problems with
> >those applications that are implementing the standard eSSSecurityLabels.]
> >
> >
> >>3) I like the text in ESS as it stands now, but there may be suggestions
> >>to modify the syntax and operation of eSSSecurityLabel to accommodate other
> >>requirements.  If ESS were changed, the example might apply.
> >
> >[JSP: IMHO, the ESS text must stand.  Your example is a good reason why it
> >must stand.  If the original signer included an eSSSecurityLabel in the
> >original signedData object then additional signer's of that original
> >signedData object MUST not be allowed to include different security labels
> >in signerInfos within the same signedData object.  If that were to be
> >allowed, then there would be mass confusion and room for contradiction when
> >different labels are processed by the recipient as part of the same
> >cumulative access control decision applied to the individual signedData
> >object.  Furthermore, if the original signer did not include an
> >eSSSecurityLabel in the original signedData object, then the original signer
> >made the decision that the content did not need to be labeled and that
> >access control is not required to access the content.  In all cases, all
> >intermediate entities MUST respect the original signer's wishes regarding
> >the eSSSecurityLabel that she included in the signedData that she created or
> >else she is not receiving the security services that she requested when she
> >originally signed the content.]
> >
> >>
> >>
> >>     dpk
> >>
> >

From: Tim Dean <[email-masked]>
To: "'John Pawling'" <[email-masked]>
Cc: "David P. Kemp" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: 'Signature Purpose' attribute?
Date: Mon, 23 Mar 1998 11:48:52 -0000
Sender: [email-masked]

John,

>>3) I like the text in ESS as it stands now, but there may be suggestions
>to modify the syntax and operation of eSSSecurityLabel to accommodate other
>requirements.  If ESS were changed, the example might apply.

>[JSP: IMHO, the ESS text must stand.  Your example is a good reason why it
>must stand.  If the original signer included an eSSSecurityLabel in the
>original signedData object then additional signer's of that original
>signedData object MUST not be allowed to include different security labels
>in signerInfos within the same signedData object.  If that were to be
>allowed, then there would be mass confusion and room for contradiction when
>different labels are processed by the recipient as part of the same
>cumulative access control decision applied to the individual signedData
>object.  Furthermore, if the original signer did not include an
>eSSSecurityLabel in the original signedData object, then the original signer
>made the decision that the content did not need to be labeled and that
>access control is not required to access the content.  In all cases, all
>intermediate entities MUST respect the original signer's wishes regarding
>the eSSSecurityLabel that she included in the signedData that she created or
>else she is not receiving the security services that she requested when she
>originally signed the content.]

I must respectfully disagree that in all cases, all intermediate entities must respect the original signer's
wishes regarding the label.  In many environments, such as ours, security authorities have the power of
veto over any label created by an originator.  In electronic (S/MIME) terms, my 'environment' will
probably create the label automatically for me.  That 'environment' could be the current enclave/domain
where I am working, or the machine I am currently logged onto, or even the client software on the
machine, e.g. on a Compartmented Mode Workstation.  In certain cases the labelling authority will be a
human-being acting as a 'release authority'.  This signed label will probably be checked by the Guard
before onward transmission.

In short, I want to create and sign messages as an originator; some third party will counter-sign and label
them for me.  I am very much hoping that ESS and S/MIME in general will accommodate this model as
well as other security policies.  As a general principle, I believe ESS and S/MIME should be security-
policy neutral wherever possible.  I am very much hoping that with the addition of sig-purpose attribute
'content Reviewer', my particular policy could be supported.  For this reason, I would very much like all
of Dave Kemp's original examples, including security label, to remain.

Tim 

----------
From:  John Pawling [SMTP:[email-masked]]
Sent:  Thursday, March 19, 1998 10:34 PM
To:  David P. Kemp; [email-masked]
Subject:  Re: 'Signature Purpose' attribute?

Dave,

Please see my responses in-line:

At 04:30 PM 3/19/98 -0500, David P. Kemp wrote:
>> From: [email-masked] (John Pawling)
>> 
>> The contentReviewer is only allowed to
>> include an eSSSecurityLabel authenticated attribute in the signerInfo that
>> she signs if there was already an eSSSecurityLabel attribute present in the
>> signerInfo(s) already included in the original signedData object.
>
>
>John,
>
>  It was just an example, but thanks for pointing out the restrictions on
>eSSSecurityLabel.  I can think of three rebuttals:
>
>1) the above quoted sentence isn't necessarily true in all cases, because
>a security gateway could take a message (either signed or plain old email)
>and wrap it in a new signedData.

[JSP: I agree that an intermediate entity can encapsulate the original
signedData object within a new outer signedData object.  The intermediate
entity can then include the appropriate eSSSecurityLabel attribute, if
required, in the signerInfo within the new outer signedData object.  The
intermediate entity's eSSSecurityLabel attribute may be different than that
included in the inner signedData object.  IMHO, that is acceptable because
the recipient MUST make a separate access control decision for each of the
signedData layers.  The recipient MUST process the eSSSecurityLabel in each
signedData object that it verifies.  Because the recipient will verify both
the outer and inner signedData objects, then it MUST process the
eSSSecurityLabel attribute in each of the signedData objects.  Therefore,
both the original signer's and intermediate entity's eSSSecurityLabels are
processed by the recipient.  An important point to note is that the
recipient software makes a separate access control decision for each
signedData object.  IMHO, that is the primary difference between processing
eSSSecurityLabels included in layered signedData objects versus those
included in multiple signerInfos included in the same signedData object.  In
the latter case, all eSSSecurityLabels included in the various signerInfos
(that are verified) are checked as part of the same cumulative access
control decision process applied to the individual signedData object.  

To get back to your original rebuttal, if the intermediate entity adds the
outer signedData, then IMHO it is not a contentReviewer, it is a
contentOriginator because it is creating a new signedData object.
Therefore, I believe that my comment still stands.]

>2) eSSSecurityLabel is defined in the ESS document, whereas signaturePurpose
>has been proposed for inclusion in CMS.  CMS may be used in non-S/MIME
>applications which have different compliance requirements than S/MIME and
>which do not refer to ESS at all.

[JSP: One of the major goals of ESS is to define standard attributes for use
with CMS.  The CMS spec MUST NOT make statements (such as your example IMHO)
that are contradictory to the principles of ESS (which CMS currently does
not).  The best strategy would be for CMS not to mention security labels at
all (which it currently does not).  Therefore, I recommend that you should
either remove the security label example or move the signaturePurpose
attribute to ESS and discuss eSSSecurityLabels.  Furthermore, applications
that use eSSSecurityLabels attributes MUST set the attributes to be critical
so if an application needs to use security labels it would be best if it
were to implement eSSSecurityLabels to avoid interoperability problems with
those applications that are implementing the standard eSSSecurityLabels.]  

>3) I like the text in ESS as it stands now, but there may be suggestions
>to modify the syntax and operation of eSSSecurityLabel to accommodate other
>requirements.  If ESS were changed, the example might apply.

[JSP: IMHO, the ESS text must stand.  Your example is a good reason why it
must stand.  If the original signer included an eSSSecurityLabel in the
original signedData object then additional signer's of that original
signedData object MUST not be allowed to include different security labels
in signerInfos within the same signedData object.  If that were to be
allowed, then there would be mass confusion and room for contradiction when
different labels are processed by the recipient as part of the same
cumulative access control decision applied to the individual signedData
object.  Furthermore, if the original signer did not include an
eSSSecurityLabel in the original signedData object, then the original signer
made the decision that the content did not need to be labeled and that
access control is not required to access the content.  In all cases, all
intermediate entities MUST respect the original signer's wishes regarding
the eSSSecurityLabel that she included in the signedData that she created or
else she is not receiving the security services that she requested when she
originally signed the content.]

>
>
>     dpk
>

Date: Fri, 20 Mar 1998 19:34:05 -0500
To: Russ Housley <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Inclusion of the issuer and serial number in authenticated  in formation 
Cc: [email-masked]
Sender: [email-masked]

Russ,

I agree.  In fact, this was one of my comments to CERT-02:

"8) Sec 3.1, last para: This change is required because it is impossible for
a subject or issuer name to have the value of ASN.1 NULL. The subject DN in
a user's (i.e. end-entity) certificate MAY be an empty SEQUENCE.  Please
change:  

OLD: "All subject and issuer names MUST be non-NULL in S/MIME-compliant v3
X.509 Certificates, except that the subject DN in a user's (i.e. end-entity)
certificate MAY be NULL in which case the subjectAltName extension will
include the subject's identifier and MUST be marked as critical."  

NEW: "All subject and issuer names MUST be populated (i.e. not an empty
SEQUENCE) in S/MIME-compliant v3 X.509 Certificates, except that the subject
DN in a user's (i.e. end-entity) certificate MAY be an empty SEQUENCE in
which case the subjectAltName extension will include the subject's
identifier and MUST be marked as critical."

- John Pawling

At 01:07 PM 3/20/98 -0500, Russ Housley wrote:
>I thought that we decides to say that the names could not be empty.
>Several readers have confused the NULL with the ASN.1 type.
>
>Russ
>
>
>At 01:52 PM 3/19/98 -0500, John Pawling wrote:
>>Marc,
>>
>>The S/MIME Cert spec, Sec 3.1, last paragraph states: "All subject and
>>issuer names MUST be non-NULL in S/MIME-compliant v3 X.509 Certificates,
>>except that the subject DN in a user's (i.e. end-entity) certificate MAY be
>>NULL in which case the subjectAltName extension will include the subject's
>>identifier and MUST be marked as critical."
>>
>>Therefore, IssuerAltName is not required to identify an S/MIME-compliant
>>certificate because there will not be any "DN-less" CAs. 
>>
>>================================
>>John Pawling   
>>[email-masked]                             
>>J.G. Van Dyke & Associates, Inc.           
>>================================
>>
>>
>>>I'm late to this thread and new to the list, so my apologies if the 
>>>following isn't germane or a new idea.
>>>
>>>I believe the PKCS#7 IssuerAndSerialNumber type is an inadequate
>certificate 
>>>identifier now that we have IssuerAlternativeName extensions.
>>>
>>>The type should be redefined to something like:
>>>
>>>IssuerAndSerialNumber ::= SEQUENCE {
>>>     issuerDN          Name,
>>>     issuerAltName     IssuerAltName OPTIONAL,  -- As defined in PKIX
>>>     serial            CertificateSerialNumber
>>>}
>>>
>>>This would make it acceptable for certificates from DN-less CAs.
>>>
>>>		Marc
>>>
>>>+------------------------------------------------------------------------+
>>> Marc Branchaud                                  \/
>>> Chief PKI Architect                             /\CERT INTERNATIONAL INC.
>>> [email-masked]        PKI References page:              www.xcert.com
>>> 604-640-6227          www.xcert.com/~marcnarc/PKI/
>> 
>

Date: Fri, 20 Mar 1998 19:31:37 -0500
To: <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: cert-02 comments
Sender: [email-masked]

All,

I agree that this text should be deleted.

- John Pawling

At 03:19 PM 3/20/98 -0800, Blake Ramsdell wrote:
>On Friday, March 20, 1998 8:31 AM, Elliott Ginsburg
>[SMTP:[email-masked]] wrote:
>> "...All agents MUSTcheck the nextUpdate field in the CRL against the
>> current time. If the current time is later than the nextUpdate time,
>> the
>> agent  MUST take some appropriate action. For instance, one
>recommended
>> set
>> of actions would be: 1) retrieve a new CRL if possible, or 2) issue a
>> warning that revocation could not be checked."
>
>Actually, do we need to mention anything about CRLs and times in the
>draft at all?  Can this point to [KEYM}?
>
>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
>
>

Date: Fri, 20 Mar 1998 13:07:54 -0500
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: Re: Inclusion of the issuer and serial number in authenticated in formation 
Cc: [email-masked]
Sender: [email-masked]

I thought that we decides to say that the names could not be empty.
Several readers have confused the NULL with the ASN.1 type.

Russ

At 01:52 PM 3/19/98 -0500, John Pawling wrote:
>Marc,
>
>The S/MIME Cert spec, Sec 3.1, last paragraph states: "All subject and
>issuer names MUST be non-NULL in S/MIME-compliant v3 X.509 Certificates,
>except that the subject DN in a user's (i.e. end-entity) certificate MAY be
>NULL in which case the subjectAltName extension will include the subject's
>identifier and MUST be marked as critical."
>
>Therefore, IssuerAltName is not required to identify an S/MIME-compliant
>certificate because there will not be any "DN-less" CAs. 
>
>================================
>John Pawling   
>[email-masked]                             
>J.G. Van Dyke & Associates, Inc.           
>================================
>
>
>>I'm late to this thread and new to the list, so my apologies if the 
>>following isn't germane or a new idea.
>>
>>I believe the PKCS#7 IssuerAndSerialNumber type is an inadequate
certificate 
>>identifier now that we have IssuerAlternativeName extensions.
>>
>>The type should be redefined to something like:
>>
>>IssuerAndSerialNumber ::= SEQUENCE {
>>     issuerDN          Name,
>>     issuerAltName     IssuerAltName OPTIONAL,  -- As defined in PKIX
>>     serial            CertificateSerialNumber
>>}
>>
>>This would make it acceptable for certificates from DN-less CAs.
>>
>>		Marc
>>
>>+------------------------------------------------------------------------+
>> Marc Branchaud                                  \/
>> Chief PKI Architect                             /\CERT INTERNATIONAL INC.
>> [email-masked]        PKI References page:              www.xcert.com
>> 604-640-6227          www.xcert.com/~marcnarc/PKI/
> 

Date: Fri, 20 Mar 1998 14:14:15 -0500
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: Re: 'Signature Purpose' attribute?
Cc: [email-masked]
Sender: [email-masked]

John:

I agree with your analysis.  If the the working group reaches concensus on
the current signature purpose structre, then it belongs in ESS, not CMS.

Russ

At 05:33 PM 3/19/98 -0500, John Pawling wrote:
>Dave,
>
>Please see my responses in-line:
>
>
>At 04:30 PM 3/19/98 -0500, David P. Kemp wrote:
>>> From: [email-masked] (John Pawling)
>>> 
>>> The contentReviewer is only allowed to
>>> include an eSSSecurityLabel authenticated attribute in the signerInfo that
>>> she signs if there was already an eSSSecurityLabel attribute present in
the
>>> signerInfo(s) already included in the original signedData object.
>>
>>
>>John,
>>
>>  It was just an example, but thanks for pointing out the restrictions on
>>eSSSecurityLabel.  I can think of three rebuttals:
>>
>>1) the above quoted sentence isn't necessarily true in all cases, because
>>a security gateway could take a message (either signed or plain old email)
>>and wrap it in a new signedData.
>
>[JSP: I agree that an intermediate entity can encapsulate the original
>signedData object within a new outer signedData object.  The intermediate
>entity can then include the appropriate eSSSecurityLabel attribute, if
>required, in the signerInfo within the new outer signedData object.  The
>intermediate entity's eSSSecurityLabel attribute may be different than that
>included in the inner signedData object.  IMHO, that is acceptable because
>the recipient MUST make a separate access control decision for each of the
>signedData layers.  The recipient MUST process the eSSSecurityLabel in each
>signedData object that it verifies.  Because the recipient will verify both
>the outer and inner signedData objects, then it MUST process the
>eSSSecurityLabel attribute in each of the signedData objects.  Therefore,
>both the original signer's and intermediate entity's eSSSecurityLabels are
>processed by the recipient.  An important point to note is that the
>recipient software makes a separate access control decision for each
>signedData object.  IMHO, that is the primary difference between processing
>eSSSecurityLabels included in layered signedData objects versus those
>included in multiple signerInfos included in the same signedData object.  In
>the latter case, all eSSSecurityLabels included in the various signerInfos
>(that are verified) are checked as part of the same cumulative access
>control decision process applied to the individual signedData object.  
>
>To get back to your original rebuttal, if the intermediate entity adds the
>outer signedData, then IMHO it is not a contentReviewer, it is a
>contentOriginator because it is creating a new signedData object.
>Therefore, I believe that my comment still stands.]
>
>
>>2) eSSSecurityLabel is defined in the ESS document, whereas signaturePurpose
>>has been proposed for inclusion in CMS.  CMS may be used in non-S/MIME
>>applications which have different compliance requirements than S/MIME and
>>which do not refer to ESS at all.
>
>[JSP: One of the major goals of ESS is to define standard attributes for use
>with CMS.  The CMS spec MUST NOT make statements (such as your example IMHO)
>that are contradictory to the principles of ESS (which CMS currently does
>not).  The best strategy would be for CMS not to mention security labels at
>all (which it currently does not).  Therefore, I recommend that you should

>either remove the security label example or move the signaturePurpose
>attribute to ESS and discuss eSSSecurityLabels.  Furthermore, applications
>that use eSSSecurityLabels attributes MUST set the attributes to be critical
>so if an application needs to use security labels it would be best if it
>were to implement eSSSecurityLabels to avoid interoperability problems with
>those applications that are implementing the standard eSSSecurityLabels.]  
>
>
>>3) I like the text in ESS as it stands now, but there may be suggestions
>>to modify the syntax and operation of eSSSecurityLabel to accommodate other
>>requirements.  If ESS were changed, the example might apply.
>
>[JSP: IMHO, the ESS text must stand.  Your example is a good reason why it
>must stand.  If the original signer included an eSSSecurityLabel in the
>original signedData object then additional signer's of that original
>signedData object MUST not be allowed to include different security labels
>in signerInfos within the same signedData object.  If that were to be
>allowed, then there would be mass confusion and room for contradiction when
>different labels are processed by the recipient as part of the same
>cumulative access control decision applied to the individual signedData
>object.  Furthermore, if the original signer did not include an
>eSSSecurityLabel in the original signedData object, then the original signer
>made the decision that the content did not need to be labeled and that
>access control is not required to access the content.  In all cases, all
>intermediate entities MUST respect the original signer's wishes regarding
>the eSSSecurityLabel that she included in the signedData that she created or
>else she is not receiving the security services that she requested when she
>originally signed the content.]
>
>>
>>
>>     dpk
>>
> 

From: "Blake Ramsdell" <[email-masked]>
To: "'Elliott Ginsburg'" <[email-masked]>, <[email-masked]>
Subject: RE: cert-02 comments
Date: Fri, 20 Mar 1998 15:19:46 -0800
Sender: [email-masked]

On Friday, March 20, 1998 8:31 AM, Elliott Ginsburg
[SMTP:[email-masked]] wrote:
> "...All agents MUSTcheck the nextUpdate field in the CRL against the
> current time. If the current time is later than the nextUpdate time,
> the
> agent  MUST take some appropriate action. For instance, one
recommended
> set
> of actions would be: 1) retrieve a new CRL if possible, or 2) issue a
> warning that revocation could not be checked."

Actually, do we need to mention anything about CRLs and times in the
draft at all?  Can this point to [KEYM}?

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

Date: Fri, 20 Mar 1998 14:54:45 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: RE: 'Signature Purpose' attribute?
Sender: [email-masked]

> From: Trevor Freeman <[email-masked]>
> 
> I am still unclear what this is really trying to solve.
> It truly sounds like it is trying to do simple workflow.

Workflow is specifically *not* a goal of the proposal; as you
suggest, that may be accomplished by appropriate structuring of
signature layers.

The sole goal of signaturePurpose is to limit the use to which a
signature may be put, to prevent signed data which has been created
in one context from being misused in another.  A verifier will accept
a signature for n different purposes, based on what the verifier trusts
the CA to certify, and reduced by whatever the CA does not enable in
the particular certificate used to verify the signature.  However,
the signer may wish to limit the signature even further, on a
per-signature basis.

Example: a user has a cert with the non-repudiation keyUsage bit set,
which he normally uses to sign S/MIME messages.  However, he also uses
the key associated with that cert to sign files on his hard drive to
prevent tampering.  One of the files happens to be a working draft,
or something picked up off a mail list with which he totally disagrees.
Without some mechanism to distinguish signature purposes, the integrity
signature may be mistaken for an originator signature, causing the poor
user acute embarassment or worse :-).

The user could of course use different certificates with different keys
for different purposes, but as we have seen, users want to use a single
certificate for multiple purposes, and some misguided souls even want
to use the same key in multiple certificates :-).

> As a matter of principal, I do not see that this kind of extension should be
> part of the base CMS specification. I would far prefer we get CMS finished,
> then we add new functionality by new standards as we are doing with ESS.

The signaturePurpose attribute was originally proposed for CMS, so
that's where the discussion has followed.  But as you imply, it really
belongs in ESS.  The charter has ESS trailing CMS by a month; I assume
that still holds even though CMS has slipped by three months.

Date: Fri, 20 Mar 1998 11:39:05 -0800
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: [email-masked]
CC: "Jim Schaad (Exchange)" <[email-masked]>, Blake Ramsdell <[email-masked]>, "[email-masked]'" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>, [email-masked]
Subject: Unique Identification of a Certificate
Sender: [email-masked]

Hi Denis,
    I joined the SMIME mailing list just recently, so I am not certain
of the problem you guys are trying to solve. Let me explain the
issues in RCSP and the reasoning for choosing the method I have
for trying to uniquely identify a cert:

In RCSP, a client is sending over one or more certificates to an
RCSP responder, to check their revocation status.
I think we all agree that issuer/serial is sufficient to uniquely
identify a certificate.
So the question is: how does one uniquely identify an issuer.
I submit that the DN is not enough, because it is possible for
the to be DN name clashes - either maliciously, or because two
groups don't talk to each other before they choose their names.
There really is no way of enforcing uniqueness is issuer DNs all
over the world.
However, public keys don't suffer from the problem of impersonation.
If somebody else claims to have the same public/private key as me,
it is easy to prove otherwise.
Therefore, we have chosen to use the issuerDN, issuerPublicKey
and CertificateSerialNumber to uniquely identify a cert. (I need
to add the issuerAltName also, as you have).
As an optimization, to reduce the size of a request, we ask the
requestor to hash the issuerDN and issuerPublicKey in the request
rather than sending all the bytes.

Adding the certificateHash in the CertUID doesn't help us identify
the cert at all, because as an RCSP responder, I don't have the
cert itself - so I can't verify the CertHash against anything.

As an aggregator of revocation data/CRLs from multiple CAs, we
would like to be able to accept all CRLs - including ones where
the DNs might clash.

Is the SMIME problem different from this one? Does the recipient
already have the certificate the sender is referring to?

Regards,
Ambarish

P.S. For those who haven't been actively following these groups,
my suggestion for cert identification is:

CertID                  ::=     SEQUENCE {
        issuerNameAndKeyHash            Hash,
        serialNumber                    CertificateSerialNumber,
}

IssuerNameAndKey                ::=     SEQUENCE {
        issuerDN           		Name,
        issuerAltName      		IssuerAltName OPTIONAL,
        issuerPublicKey                 SubjectPublicKeyInfo
}

i.e. you identify a cert by the hash of the IssuerNameAndKey
and a serial number.

The hash includes the public key of the issuer - this prevents the
Banana Republic CA from impersonating our well beloved and well
trusted US CA ;-).

Ofcourse, if keeping the size of the request small is not important,
or the recipient might not be able to figure out the issuer from
the hash, it might make sense to send IssuerNameAndKey instead
of its hash.

Denis Pinkas wrote:
> 
> There is no final position yet, but it seems that we are going towards
> the following structure:
> 
> CertUID ::=     SEQUENCE {
>      issuerDN           Name,
>      issuerAltName      IssuerAltName OPTIONAL,  -- As defined in PKIX
>      serial             CertificateSerialNumber,
>      certificateHash    CertHash
> }
> 
> This allows the support of alternate names and the certificate hash
> allows to make the difference between certificates that would be issued
> by CAs having the same name.
> 
> In any case, I would recommend that the pkix group and the smime group
> adopt the same structure.
> 
> Denis
> 
> --
>       Denis Pinkas     Bull S.A.          mailto:[email-masked]
>       Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
>       78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303

From: Trevor Freeman <[email-masked]>
To: [email-masked]
Subject: RE: 'Signature Purpose' attribute?
Date: Fri, 20 Mar 1998 10:36:47 -0800
Sender: [email-masked]

I am still unclear what this is really trying to solve.
It truly sounds like it is trying to do simple workflow. I also think is
adds little to what is possible within the cms specification as is.
If Alice sends a signed message to Bob. If Bob truly wants to show the
sequence, that he is a reviewer and has seen the document after Alice, the
originator, then he does not add a new signer info structure to the existing
layer with some attribute, but adds a new signed data envelope. Bob now
cannot be a originator because his signature has been added after Alice's.
What is important in this case is the sequence, that is signature should be
added with new envelopes to show they are in series, not some other
authenticated attribute.
As a matter of principal, I do not see that this kind of extension should be
part of the base CMS specification. I would far prefer we get CMS finished,
then we add new functionality by new standards as we are doing with ESS.
Nothing which is being discussed here impacts the base CMS specification.
This new functionality can be worked on in parallel and debated in parallel,
so there should be minimal time impact.
I would like to keep a strong focus on finishing CMS.
Trevor

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Friday, March 20, 1998 6:26 AM
> To:	[email-masked]
> Subject:	Re: 'Signature Purpose' attribute?
> 
> 
> > From: [email-masked] (John Pawling)
> > 
> > In summary, I believe that the example should be removed because it
> causes
> > confusion. 
> 
> That's OK with me.
> 
> Someone (I can guess who :-) will need to write up a concrete chunk of
> text for inclusion in CMS.  The proposal isn't quite useable as is,
> but the needed wordsmithing and merger with Tim's original text should
> be minor.
> 
> Rich Ankney, do you have any opinions on how easily the X9.45 and ASTM
> purposes would fit into the proposed framework?  Are the four basic
> purposes sufficient?
> 
> Trevor Freeman, Michael Warner and others, do you have any comments on
> the latest proposal?

Date: Fri, 20 Mar 1998 11:30:49 -0500
To: [email-masked]
From: Elliott Ginsburg <[email-masked]>
Subject: cert-02 comments
Sender: [email-masked]

In section 2.1:

"...All agents SHOULD check the nextUpdate field in the CRL against the
current time. If the current time is later than the nextUpdate time, the
actioin that the agent takes is a local decision. For instance, it could
warn a human user, it could retrieve a new CRL if able, and so on."

I think that since this section requires the checking of certs against
CRLs, that we ought to require (MUST) that the agent check the nextUpdate
field. I also think that we can be a little more specific about what the
agent does if it is later than this time. I suggest the following:

"...All agents MUSTcheck the nextUpdate field in the CRL against the
current time. If the current time is later than the nextUpdate time, the
agent  MUST take some appropriate action. For instance, one recommended set
of actions would be: 1) retrieve a new CRL if possible, or 2) issue a
warning that revocation could not be checked."

elliott ginsburg

Date: Fri, 20 Mar 1998 17:28:55 -0800
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: "Jim Schaad (Exchange)" <[email-masked]>, Blake Ramsdell <[email-masked]>, "[email-masked]'" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: Re: Inclusion of the issuer and serial number in authenticated in formation
Sender: [email-masked]

There is no final position yet, but it seems that we are going towards
the following structure:

CertUID ::=     SEQUENCE {
     issuerDN           Name,
     issuerAltName      IssuerAltName OPTIONAL,  -- As defined in PKIX
     serial             CertificateSerialNumber,
     certificateHash    CertHash
}

This allows the support of alternate names and the certificate hash
allows to make the difference between certificates that would be issued
by CAs having the same name.

In any case, I would recommend that the pkix group and the smime group
adopt the same structure.

Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Fri, 20 Mar 1998 09:25:32 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: 'Signature Purpose' attribute?
Sender: [email-masked]

> From: [email-masked] (John Pawling)
> 
> In summary, I believe that the example should be removed because it causes
> confusion. 

That's OK with me.

Someone (I can guess who :-) will need to write up a concrete chunk of
text for inclusion in CMS.  The proposal isn't quite useable as is,
but the needed wordsmithing and merger with Tim's original text should
be minor.

Rich Ankney, do you have any opinions on how easily the X9.45 and ASTM
purposes would fit into the proposed framework?  Are the four basic
purposes sufficient?

Trevor Freeman, Michael Warner and others, do you have any comments on
the latest proposal?

Date: Thu, 19 Mar 1998 13:09:50 -0500
To: "Blake Ramsdell" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Key pair generation in MSG
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Blake:

Different hardware implementations will have limitations.  This situation
is quite similar to software.  Hardware is generally optimized for a
particular modulus, and if you select a modulus larger than the optimized
one, it either fails or runs slower.

Russ

At 03:18 PM 3/18/98 -0800, Blake Ramsdell wrote:
>On Wednesday, March 18, 1998 7:00 AM, EKR [SMTP:[email-masked]] wrote:
>> I agree that having a maximum size is a bad idea. 
>
>I agree also.  My concern centers around optimized implementations that
>require an upper bound (hardware implementations, specifically).  I
>don't know if this is actually an issue, but Russ will.
>
>>From a security point of view, more is better of course.  Well, that's
>what people tell me anyway.
>
>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
> 

Date: Thu, 19 Mar 1998 19:49:39 -0500
To: [email-masked] (David P. Kemp), [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: 'Signature Purpose' attribute?
Sender: [email-masked]

Dave,

"release authority" has different meanings (or no meaning) to various folks.
For example, the DMS organizational releaser (not the drafter) is the
"content originator" of the DMS organizational message.  

Any entity that creates an eSSSecurityLabel different from those included in
the original signedData object MUST create a new outer signedData to contain
the new eSSSecurityLabel and that entity is the original signer of the new
outer signedData. 

In summary, I believe that the example should be removed because it causes
confusion. 

- John Pawling

At 05:59 PM 3/19/98 -0500, David P. Kemp wrote:
>> From: [email-masked] (John Pawling)
>>
>> To get back to your original rebuttal, if the intermediate entity adds the
>> outer signedData, then IMHO it is not a contentReviewer, it is a
>> contentOriginator because it is creating a new signedData object.
>> Therefore, I believe that my comment still stands.]
>
>I find it hard to accept that a release authority, which may add a label
>as part of it's processing, is a content originator.  Capturing the
>distinction between signing something that you wrote and signing something
>that someone else wrote is precisely the reason for defining a
>signaturePurpose extension.  It doesn't matter whether the contentReviewer
>adds a parallel signature, a wrapped signature, or a countersignature - 
>it's still a reviewer, not an originator.
>
>I'm not averse to removing the example; it's just an illustration of the
>possibilities.  If it causes more confusion than it dispels, then it
>should go.  But I think the case where a reviewer adds another wrapping
>layer with a label is legitimate, and does not contradict ESS.
>

Date: Thu, 19 Mar 1998 17:59:29 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: 'Signature Purpose' attribute?
Sender: [email-masked]

> From: [email-masked] (John Pawling)
>
> To get back to your original rebuttal, if the intermediate entity adds the
> outer signedData, then IMHO it is not a contentReviewer, it is a
> contentOriginator because it is creating a new signedData object.
> Therefore, I believe that my comment still stands.]

I find it hard to accept that a release authority, which may add a label
as part of it's processing, is a content originator.  Capturing the
distinction between signing something that you wrote and signing something
that someone else wrote is precisely the reason for defining a
signaturePurpose extension.  It doesn't matter whether the contentReviewer
adds a parallel signature, a wrapped signature, or a countersignature - 
it's still a reviewer, not an originator.

I'm not averse to removing the example; it's just an illustration of the
possibilities.  If it causes more confusion than it dispels, then it
should go.  But I think the case where a reviewer adds another wrapping
layer with a label is legitimate, and does not contradict ESS.

Date: Thu, 19 Mar 1998 17:33:41 -0500
To: [email-masked] (David P. Kemp), [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: 'Signature Purpose' attribute?
Sender: [email-masked]

Dave,

Please see my responses in-line:

At 04:30 PM 3/19/98 -0500, David P. Kemp wrote:
>> From: [email-masked] (John Pawling)
>> 
>> The contentReviewer is only allowed to
>> include an eSSSecurityLabel authenticated attribute in the signerInfo that
>> she signs if there was already an eSSSecurityLabel attribute present in the
>> signerInfo(s) already included in the original signedData object.
>
>
>John,
>
>  It was just an example, but thanks for pointing out the restrictions on
>eSSSecurityLabel.  I can think of three rebuttals:
>
>1) the above quoted sentence isn't necessarily true in all cases, because
>a security gateway could take a message (either signed or plain old email)
>and wrap it in a new signedData.

[JSP: I agree that an intermediate entity can encapsulate the original
signedData object within a new outer signedData object.  The intermediate
entity can then include the appropriate eSSSecurityLabel attribute, if
required, in the signerInfo within the new outer signedData object.  The
intermediate entity's eSSSecurityLabel attribute may be different than that
included in the inner signedData object.  IMHO, that is acceptable because
the recipient MUST make a separate access control decision for each of the
signedData layers.  The recipient MUST process the eSSSecurityLabel in each
signedData object that it verifies.  Because the recipient will verify both
the outer and inner signedData objects, then it MUST process the
eSSSecurityLabel attribute in each of the signedData objects.  Therefore,
both the original signer's and intermediate entity's eSSSecurityLabels are
processed by the recipient.  An important point to note is that the
recipient software makes a separate access control decision for each
signedData object.  IMHO, that is the primary difference between processing
eSSSecurityLabels included in layered signedData objects versus those
included in multiple signerInfos included in the same signedData object.  In
the latter case, all eSSSecurityLabels included in the various signerInfos
(that are verified) are checked as part of the same cumulative access
control decision process applied to the individual signedData object.  

To get back to your original rebuttal, if the intermediate entity adds the
outer signedData, then IMHO it is not a contentReviewer, it is a
contentOriginator because it is creating a new signedData object.
Therefore, I believe that my comment still stands.]

>2) eSSSecurityLabel is defined in the ESS document, whereas signaturePurpose
>has been proposed for inclusion in CMS.  CMS may be used in non-S/MIME
>applications which have different compliance requirements than S/MIME and
>which do not refer to ESS at all.

[JSP: One of the major goals of ESS is to define standard attributes for use
with CMS.  The CMS spec MUST NOT make statements (such as your example IMHO)
that are contradictory to the principles of ESS (which CMS currently does
not).  The best strategy would be for CMS not to mention security labels at
all (which it currently does not).  Therefore, I recommend that you should
either remove the security label example or move the signaturePurpose
attribute to ESS and discuss eSSSecurityLabels.  Furthermore, applications
that use eSSSecurityLabels attributes MUST set the attributes to be critical
so if an application needs to use security labels it would be best if it
were to implement eSSSecurityLabels to avoid interoperability problems with
those applications that are implementing the standard eSSSecurityLabels.]  

>3) I like the text in ESS as it stands now, but there may be suggestions
>to modify the syntax and operation of eSSSecurityLabel to accommodate other
>requirements.  If ESS were changed, the example might apply.

[JSP: IMHO, the ESS text must stand.  Your example is a good reason why it
must stand.  If the original signer included an eSSSecurityLabel in the
original signedData object then additional signer's of that original
signedData object MUST not be allowed to include different security labels
in signerInfos within the same signedData object.  If that were to be
allowed, then there would be mass confusion and room for contradiction when
different labels are processed by the recipient as part of the same
cumulative access control decision applied to the individual signedData
object.  Furthermore, if the original signer did not include an
eSSSecurityLabel in the original signedData object, then the original signer
made the decision that the content did not need to be labeled and that
access control is not required to access the content.  In all cases, all
intermediate entities MUST respect the original signer's wishes regarding
the eSSSecurityLabel that she included in the signedData that she created or
else she is not receiving the security services that she requested when she
originally signed the content.]

>
>
>     dpk
>

Date: Thu, 19 Mar 1998 16:30:40 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: 'Signature Purpose' attribute?
Sender: [email-masked]

> From: [email-masked] (John Pawling)
> 
> The contentReviewer is only allowed to
> include an eSSSecurityLabel authenticated attribute in the signerInfo that
> she signs if there was already an eSSSecurityLabel attribute present in the
> signerInfo(s) already included in the original signedData object.

John,

  It was just an example, but thanks for pointing out the restrictions on
eSSSecurityLabel.  I can think of three rebuttals:

1) the above quoted sentence isn't necessarily true in all cases, because
a security gateway could take a message (either signed or plain old email)
and wrap it in a new signedData.

2) eSSSecurityLabel is defined in the ESS document, whereas signaturePurpose
has been proposed for inclusion in CMS.  CMS may be used in non-S/MIME
applications which have different compliance requirements than S/MIME and
which do not refer to ESS at all.

3) I like the text in ESS as it stands now, but there may be suggestions
to modify the syntax and operation of eSSSecurityLabel to accommodate other
requirements.  If ESS were changed, the example might apply.

     dpk

Date: Thu, 19 Mar 1998 15:01:22 -0500
To: Tim Dean <[email-masked]>, "[email-masked]" <[email-masked]>, "'David P. Kemp'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: 'Signature Purpose' attribute?
Sender: [email-masked]

Tim,

I don't object to the inclusion of the 'Signature Purpose' attribute as a
SHOULD requirement in CMS.  I don't believe that it needs to be a MUST
requirement.  Furthermore, I believe that it should always be non-critical.
If an application doesn't support it, then it will ignore it.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

Date: Thu, 19 Mar 1998 14:56:04 -0500
To: [email-masked] (David P. Kemp), [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: 'Signature Purpose' attribute?
Sender: [email-masked]

Dave,

You stated:
> * contentReviewer - the signer did not originate the content, but is
>    claiming to provide some value-added service to it.  Provides
>    integrity, authentication, and non-repudiation of the claimed
>    value-added purpose, but not non-repudiation of the content.
>    Examples: virus scanning, release approval, timestamping, or
>    adding a security label.

Please delete "or adding a security label" because the contentReviewer
cannot "add any value" by adding an eSSSecurityLabel authenticated attribute
to the original signedData object.  The contentReviewer is only allowed to
include an eSSSecurityLabel authenticated attribute in the signerInfo that
she signs if there was already an eSSSecurityLabel attribute present in the
signerInfo(s) already included in the original signedData object.
Furthermore, the eSSSecurityLabel attribute included in the
contentReviewer's signerInfo MUST be identical to the eSSSecurityLabel
attribute present in the signerInfo(s) already included in the original
signedData object.  Therefore, if the contentReviewer includes an
eSSSecurityLabel attribute in her signerInfo, she is not adding any value,
she is merely replicating the eSSSecurityLabel that already existed in the
signerInfo(s) included in the original signedData.  

This is true because the last para of ESS-04, sec 3.1.1 reads as follows:

"There can be multiple SignerInfos within a SignedData object, and each
SignerInfo may include authenticatedAttributes. Therefore, a single
SignedData object may include multiple eSSSecurityLabels, each SignerInfo
having an eSSSecurityLabel attribute. For example, an originator can send a
signed message with two SignerInfos, one containing a DSS signature, the
other containing an RSA signature. If any of the SignerInfos included in a
SignedData object include an eSSSecurityLabel attribute, then all of the
SignerInfos in that SignedData object MUST include an eSSSecurityLabel
attribute and the value of each MUST be identical."

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

Date: Thu, 19 Mar 1998 13:52:54 -0500
To: Marc Branchaud <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Inclusion of the issuer and serial number in authenticated in formation 
Sender: [email-masked]

Marc,

The S/MIME Cert spec, Sec 3.1, last paragraph states: "All subject and
issuer names MUST be non-NULL in S/MIME-compliant v3 X.509 Certificates,
except that the subject DN in a user's (i.e. end-entity) certificate MAY be
NULL in which case the subjectAltName extension will include the subject's
identifier and MUST be marked as critical."

Therefore, IssuerAltName is not required to identify an S/MIME-compliant
certificate because there will not be any "DN-less" CAs. 

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

>I'm late to this thread and new to the list, so my apologies if the 
>following isn't germane or a new idea.
>
>I believe the PKCS#7 IssuerAndSerialNumber type is an inadequate certificate 
>identifier now that we have IssuerAlternativeName extensions.
>
>The type should be redefined to something like:
>
>IssuerAndSerialNumber ::= SEQUENCE {
>     issuerDN          Name,
>     issuerAltName     IssuerAltName OPTIONAL,  -- As defined in PKIX
>     serial            CertificateSerialNumber
>}
>
>This would make it acceptable for certificates from DN-less CAs.
>
>		Marc
>
>+------------------------------------------------------------------------+
> Marc Branchaud                                  \/
> Chief PKI Architect                             /\CERT INTERNATIONAL INC.
> [email-masked]        PKI References page:              www.xcert.com
> 604-640-6227          www.xcert.com/~marcnarc/PKI/

From: Tim Dean <[email-masked]>
To: "[email-masked]" <[email-masked]>, "'David P. Kemp'" <[email-masked]>
Subject: RE: 'Signature Purpose' attribute?
Date: Thu, 19 Mar 1998 12:58:29 -0000
Sender: [email-masked]

Dave,

I really like your proposed generalisations of the original text - it hangs together much better like that.
One option would be just add this new text to CMS 'as is', and allow people to implement it if they so 
choose, along with the other authenticated attributes.  Or it might be better in the interests of
interoperability to make it a 'SHALL' implement and support in protocol.
I personally much prefer the latter option, for a variety of reasons.

Thoughts?
Tim

----------
From:  David P. Kemp [SMTP:[email-masked]]
Sent:  Wednesday, March 18, 1998 10:15 PM
To:  [email-masked]
Subject:  Re: 'Signature Purpose' attribute?

Tim,

I agree that designating the purpose of a signature is a useful
capability to include in CMS.  Your original proposal is included
below, and Phil Griffin suggested an alternative syntax which used a
BIT STRING for basic purpose codes.  I have some comments on your
proposal, and have a third syntax suggestion to throw into the pot.

It seems to me that the example purposes you listed are almost but not
quite general enough.  Phil's syntax made a distinction between basic
and extended purpose codes, thereby accentuating concerns with the
specific purposes included in the basic set.

I propose that a signature have a single basic purpose selected from
a small list of mutually-exclusive options.  In addition, a signature
could have zero or more qualifiers in addition to (not instead of)
the basic purpose.  Qualifiers could have an OID, a string description,
or both:

  SignaturePurpose ::= SEQUENCE {
     basicPurpose      BasicPurpose,
     qualifiers        SEQUENCE SIZE(1..MAX) OF Qualifier OPTIONAL }

  BasicPurpose ::= ENUMERATED {
     integrityOnly      (0),
     contentForwarder   (1),
     contentReviewer    (2),
     contentOriginator  (3) }

  Qualifier ::= SEQUENCE {
     purposeCode   OBJECT IDENTIFIER OPTIONAL,
     description   [0] IMPLICIT OCTET STRING (SIZE(1..maxDescSize))
                       OPTIONAL   -- Must contain UTF-8 string  }

The basic purposes are:

 * integrityOnly - the signer does not intend the signature to be used
    for any form of non-repudiation; it is intended only to provide
    data integrity.  This is equivalent to Tim's Content Originator
    purpose used to sign files on a local disk, but not distributed to
    anyone else.

 * contentForwarder - the signer did not either originate or examine
    the content; the signature is intended to provide data integrity and
    data origin authentication. Equivalent to Tim's Message Forwarder,
    used by a Mail List Agent.

 * contentReviewer - the signer did not originate the content, but is
    claiming to provide some value-added service to it.  Provides
    integrity, authentication, and non-repudiation of the claimed
    value-added purpose, but not non-repudiation of the content.
    Examples: virus scanning, release approval, timestamping, or
    adding a security label.

 * contentOriginator - the signer claims authorship.  Equivalent to
    Tim's Message Originator and HTML Originator (I don't know why there
    is a distinction between a plain text message and an HTML message,
    but if the distinction is important, a qualifier could be used.)

Note that anyone can add a signature claiming ownership/authorship of a
document; the primary reason for signaturePurpose is therefore to
enable the signer to disclaim some responsibility which is otherwise
authorized by the signer's certificate.  Therefore the contentOriginator
purpose is really a "null-disclaimer".

I expect that extended purpose codes (OIDs), if needed at all, would
only be used in conjunction with the contentReviewer basic purpose.
Timestamp and security label purposes can be inferred from the presence
of the respective signed attributes; virus scanning and release approval
are categories that probably require privileges to be set in the signer's
certificate, rather than being set or unset in each signature.  I would
like to see solid justification before defining any S/MIME extended
signature purpose OIDs. The syntax accommodates the use of private OIDs
for community-specific purposes; that should be sufficient to gain the
operational experience needed before recommending standardized purpose
codes.

Note that the Qualifier description field is a UTF8 string; it's
syntax should be consistent with whatever is used for UTF8 elsewhere
in S/MIME.

Comments welcome,
Dave Kemp

-------------------------------------------------------------------------

> From: "Phillip H. Griffin" <[email-masked]>
> 
> It seems to me that having a set of basic purpose codes as static 
> definitions might make them more useful for applications, and easier 
> to implement. The capability to provide application-specific OIDs with 
> accompanying qualifier text is still provided in the design. 
> 
> Still, to have it both ways, my proposed type could be changed to:
> 
>   SignaturePurpose ::= SEQUENCE {
>      basics      BasicPurposeCodes,
>      basicQuals  SEQUENCE OF VisibleString  OPTIONAL,
>      others      SigPurposeCodes  OPTIONAL
>   }
> 
> The SEQUENCE OF would not be sorted under DER, so the order
> specified by the sender would be maintained. One string per
> bit flag could optionally be included in the message, with
> the order assumed mapped to the high bits in 'basics'.

-------------------------------------------------------------------------

> From: Tim Dean <[email-masked]>
> Date: Tue, 13 Jan 1998 10:36:39 -0000
> 
> After discussion with one or two people I have put together some
> suggested text for the signature purpose attribute.  This is now
> offered to the list for comment.  The intent would be to add this text
> as part of section 10 of CMS, providing there is WG consensus.
> 
> Comments welcome!
> Tim Dean
> ------------------- cut here ---------------------------------
> 
> 10.x Signature Purpose
> 
> The signature purpose attribute specifies the purpose for which the
> signature was created.  It is intended to be used in circumstances
> where there may otherwise be ambiguity in the intention of the signer.
> For example, it assists in preventing signed content created in one
> application (e.g. a signed file or HTTP transaction) being
> unintentionally or maliciously mis-used by another (e.g. to
> authenticate a message originator).  It can also be used to protect an
> entity wishing to sign and forward a message from being wrongly
> implicated as being the message originator.
> 
> The signature purpose attribute is identified by the following object
> identifier:
> 
>       id-sigPurpose OBJECT IDENTIFIER ::= { iso(1) member-body(2)
>           us(840) rsadsi(113549) pkcs(1) pkcs9(9) xxx }
> 
> Signature purpose attribute values have ASN.1 type SignaturePurpose:
> 
>       SignaturePurpose ::= SET OF SignaturePurposeCode
> 
>       SignaturePurposeCode ::= SEQUENCE {
>             sigPurposeId OBJECT IDENTIFIER,
>             purposeQualifier PrintableString (SIZE (1..maxPurposeQualifierSize))}
> 
>       maxPurposeQualifierSize INTEGER ::= 1024
> 
> The signature purpose attribute MUST be an authenticated attribute; it
> MUST NOT be included as part of authenticated attributes.  When signing
> content an S/MIME application SHOULD include at least one purpose code,
> taken either from the list below or an application-specific purpose
> code.  An S/MIME application may include more than one purpose code.
> There can be multiple SignerInfos associated with a SignedData object,
> and each one may include a different set of purpose codes.  The
> signature purpose attribute applies only to the signature in SignerInfo
> which contains it.  It does not apply to any other signature.
> 
> A number of basic purpose codes are defined here for use by S/MIME
> applications.  Further purpose codes may be defined on an
> application-specific basis. An implementation may choose to populate
> the purposeQualifier field with text which further describes the
> purpose.
> 
> The following basic S/MIME purpose codes are defined:
> 
> * Message originator - the signer originated the message together with
> the content of the message.  Signature purpose code
> id-SigPurposeMessageOriginator is used for this purpose.
> 
> * Message forwarder - the signer forwarded the message but did not
> originate it.  Signature purpose code id-SigPurposeMessageForwarder is
> used for this purpose.  One use of this purpose code is by a Mail List
> Agent (MLA) expanding a message to a distribution list.
> 
> * Content originator - the signer originated the signed content, but
> does not intend sending it out as a mail message. Signature purpose
> code id-SigPurposeContentOriginator is used for this purpose.  A
> typical use of this purpose code is to add an S/MIME signature to local
> files and documents inside a system.
> 
> * HTTP originator - the signer originated the HTTP content. Signature
> purpose code id-SigPurposeHTTPOriginator is used for this purpose.
> 
> * Content review and approval - the signer reviewed and approved the
> content but did not originate it. Signature purpose code
> id-SigPurposeContentReviewer is used for this purpose. A possible use
> of this purpose code is by a 'virus scanner' checking for malicious
> code in content.  Another use is by 'release authorities' used in some
> situations to release messages through a firewall.  In both cases,
> further qualifying text could be added in the purposeQualifier field.
> 
> * Security label - the signer added the signed security label but did
> not originate the content. Signature purpose code
> id-SigPurposeSecurityLabel is used for this purpose.
> 
> * Timestamp - the signer added a signed timestamp but did not originate
> the content. Signature purpose code id-SigPurposeTimestamp is used for
> this purpose.
> 
> 'Message Originator', 'Content Originator', and 'HTTP originator',
> may be used in a SignerInfo on content but SHOULD NOT be used in a
> countersignature.  All the other codes listed may be used in either a
> SignerInfo on content or in a countersignature.  An implementation may
> choose to compare the signature purpose field with fields in the
> certificate before deciding whether the signature is valid.

Date: Wed, 18 Mar 1998 15:29:06 -0800
To: <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Key pair generation in MSG
Sender: [email-masked]

At 03:18 PM 3/18/98 -0800, Blake Ramsdell wrote:
>I agree also.  My concern centers around optimized implementations that
>require an upper bound (hardware implementations, specifically).

Which is why this is in a SHOULD statement in my proposed rewording. A
SHOULD allows the implementor to make an upper-bound decision based on
local policy.

--Paul Hoffman, Director
--Internet Mail Consortium

From: Nuttapong Tungdajahirun <[email-masked]>
To: "'Tim Matthews'" <[email-masked]>, "'Nuttapong Tungdajahirun'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Using S-MIME in Perl (sendmail.pl)
Date: Wed, 18 Mar 1998 18:26:35 -0500
Sender: [email-masked]

Thank you for your suggestion
Unfortunately after I check Raph Levien's Premail site, I just figure
out that this might not suitable in my case.
I forgot to tell you that we're using NT w/ IIS4.0, while Premail work
on Unix only.
Could you give me other alternative?

Many Thanks. 

Jeen
	-----Original Message-----
	From:	Tim Matthews [SMTP:[email-masked]]
	Sent:	Wednesday, March 18, 1998 6:00 PM
	To:	'Nuttapong Tungdajahirun'; [email-masked]'
	Subject:	RE: Using S-MIME in Perl (sendmail.pl)

	Check our Raph Levien's Premail here
	http://atropos.c2.net/~raph/premail.html.  This should get you
going.

	Tim

	> -----Original Message-----
	> From:	Nuttapong Tungdajahirun [SMTP:[email-masked]]
	> Sent:	Wednesday, March 18, 1998 2:40 PM
	> To:	[email-masked]'
	> Subject:	Using S-MIME in Perl (sendmail.pl)
	> 
	> 
	> In our website, we are using perl program that it
automatically sends
	> a
	> client's fill-out form to our supplier email address directly.
	> 
	> How can I change perl script to automatically send email text
to
	> supplier in S-MIME format?

From: "Blake Ramsdell" <[email-masked]>
To: "'EKR'" <[email-masked]>, "Paul Hoffman / IMC" <[email-masked]>
cc: <[email-masked]>
Subject: RE: Key pair generation in MSG
Date: Wed, 18 Mar 1998 15:18:51 -0800
Sender: [email-masked]

On Wednesday, March 18, 1998 7:00 AM, EKR [SMTP:[email-masked]] wrote:
> I agree that having a maximum size is a bad idea. 

I agree also.  My concern centers around optimized implementations that
require an upper bound (hardware implementations, specifically).  I
don't know if this is actually an issue, but Russ will.

>From a security point of view, more is better of course.  Well, that's
what people tell me anyway.

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: Tim Matthews <[email-masked]>
To: "'Nuttapong Tungdajahirun'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Using S-MIME in Perl (sendmail.pl)
Date: Wed, 18 Mar 1998 15:00:21 -0800
Sender: [email-masked]

Check our Raph Levien's Premail here
http://atropos.c2.net/~raph/premail.html.  This should get you going.

Tim

> -----Original Message-----
> From:	Nuttapong Tungdajahirun [SMTP:[email-masked]]
> Sent:	Wednesday, March 18, 1998 2:40 PM
> To:	[email-masked]'
> Subject:	Using S-MIME in Perl (sendmail.pl)
> 
> 
> In our website, we are using perl program that it automatically sends
> a
> client's fill-out form to our supplier email address directly.
> 
> How can I change perl script to automatically send email text to
> supplier in S-MIME format?

From: Nuttapong Tungdajahirun <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Using S-MIME in Perl (sendmail.pl)
Date: Wed, 18 Mar 1998 17:40:19 -0500
Sender: [email-masked]

In our website, we are using perl program that it automatically sends a
client's fill-out form to our supplier email address directly.

How can I change perl script to automatically send email text to
supplier in S-MIME format?

Date: Wed, 18 Mar 1998 17:15:24 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: 'Signature Purpose' attribute?
Sender: [email-masked]

Tim,

I agree that designating the purpose of a signature is a useful
capability to include in CMS.  Your original proposal is included
below, and Phil Griffin suggested an alternative syntax which used a
BIT STRING for basic purpose codes.  I have some comments on your
proposal, and have a third syntax suggestion to throw into the pot.

It seems to me that the example purposes you listed are almost but not
quite general enough.  Phil's syntax made a distinction between basic
and extended purpose codes, thereby accentuating concerns with the
specific purposes included in the basic set.

I propose that a signature have a single basic purpose selected from
a small list of mutually-exclusive options.  In addition, a signature
could have zero or more qualifiers in addition to (not instead of)
the basic purpose.  Qualifiers could have an OID, a string description,
or both:

  SignaturePurpose ::= SEQUENCE {
     basicPurpose      BasicPurpose,
     qualifiers        SEQUENCE SIZE(1..MAX) OF Qualifier OPTIONAL }

  BasicPurpose ::= ENUMERATED {
     integrityOnly      (0),
     contentForwarder   (1),
     contentReviewer    (2),
     contentOriginator  (3) }

  Qualifier ::= SEQUENCE {
     purposeCode   OBJECT IDENTIFIER OPTIONAL,
     description   [0] IMPLICIT OCTET STRING (SIZE(1..maxDescSize))
                       OPTIONAL   -- Must contain UTF-8 string  }

The basic purposes are:

 * integrityOnly - the signer does not intend the signature to be used
    for any form of non-repudiation; it is intended only to provide
    data integrity.  This is equivalent to Tim's Content Originator
    purpose used to sign files on a local disk, but not distributed to
    anyone else.

 * contentForwarder - the signer did not either originate or examine
    the content; the signature is intended to provide data integrity and
    data origin authentication. Equivalent to Tim's Message Forwarder,
    used by a Mail List Agent.

 * contentReviewer - the signer did not originate the content, but is
    claiming to provide some value-added service to it.  Provides
    integrity, authentication, and non-repudiation of the claimed
    value-added purpose, but not non-repudiation of the content.
    Examples: virus scanning, release approval, timestamping, or
    adding a security label.

 * contentOriginator - the signer claims authorship.  Equivalent to
    Tim's Message Originator and HTML Originator (I don't know why there
    is a distinction between a plain text message and an HTML message,
    but if the distinction is important, a qualifier could be used.)

Note that anyone can add a signature claiming ownership/authorship of a
document; the primary reason for signaturePurpose is therefore to
enable the signer to disclaim some responsibility which is otherwise
authorized by the signer's certificate.  Therefore the contentOriginator
purpose is really a "null-disclaimer".

I expect that extended purpose codes (OIDs), if needed at all, would
only be used in conjunction with the contentReviewer basic purpose.
Timestamp and security label purposes can be inferred from the presence
of the respective signed attributes; virus scanning and release approval
are categories that probably require privileges to be set in the signer's
certificate, rather than being set or unset in each signature.  I would
like to see solid justification before defining any S/MIME extended
signature purpose OIDs. The syntax accommodates the use of private OIDs
for community-specific purposes; that should be sufficient to gain the
operational experience needed before recommending standardized purpose
codes.

Note that the Qualifier description field is a UTF8 string; it's
syntax should be consistent with whatever is used for UTF8 elsewhere
in S/MIME.

Comments welcome,
Dave Kemp

-------------------------------------------------------------------------

> From: "Phillip H. Griffin" <[email-masked]>
> 
> It seems to me that having a set of basic purpose codes as static 
> definitions might make them more useful for applications, and easier 
> to implement. The capability to provide application-specific OIDs with 
> accompanying qualifier text is still provided in the design. 
> 
> Still, to have it both ways, my proposed type could be changed to:
> 
>   SignaturePurpose ::= SEQUENCE {
>      basics      BasicPurposeCodes,
>      basicQuals  SEQUENCE OF VisibleString  OPTIONAL,
>      others      SigPurposeCodes  OPTIONAL
>   }
> 
> The SEQUENCE OF would not be sorted under DER, so the order
> specified by the sender would be maintained. One string per
> bit flag could optionally be included in the message, with
> the order assumed mapped to the high bits in 'basics'.

-------------------------------------------------------------------------

> From: Tim Dean <[email-masked]>
> Date: Tue, 13 Jan 1998 10:36:39 -0000
> 
> After discussion with one or two people I have put together some
> suggested text for the signature purpose attribute.  This is now
> offered to the list for comment.  The intent would be to add this text
> as part of section 10 of CMS, providing there is WG consensus.
> 
> Comments welcome!
> Tim Dean
> ------------------- cut here ---------------------------------
> 
> 10.x Signature Purpose
> 
> The signature purpose attribute specifies the purpose for which the
> signature was created.  It is intended to be used in circumstances
> where there may otherwise be ambiguity in the intention of the signer.
> For example, it assists in preventing signed content created in one
> application (e.g. a signed file or HTTP transaction) being
> unintentionally or maliciously mis-used by another (e.g. to
> authenticate a message originator).  It can also be used to protect an
> entity wishing to sign and forward a message from being wrongly
> implicated as being the message originator.
> 
> The signature purpose attribute is identified by the following object
> identifier:
> 
>       id-sigPurpose OBJECT IDENTIFIER ::= { iso(1) member-body(2)
>           us(840) rsadsi(113549) pkcs(1) pkcs9(9) xxx }
> 
> Signature purpose attribute values have ASN.1 type SignaturePurpose:
> 
>       SignaturePurpose ::= SET OF SignaturePurposeCode
> 
>       SignaturePurposeCode ::= SEQUENCE {
>             sigPurposeId OBJECT IDENTIFIER,
>             purposeQualifier PrintableString (SIZE (1..maxPurposeQualifierSize))}
> 
>       maxPurposeQualifierSize INTEGER ::= 1024
> 
> The signature purpose attribute MUST be an authenticated attribute; it
> MUST NOT be included as part of authenticated attributes.  When signing
> content an S/MIME application SHOULD include at least one purpose code,
> taken either from the list below or an application-specific purpose
> code.  An S/MIME application may include more than one purpose code.
> There can be multiple SignerInfos associated with a SignedData object,
> and each one may include a different set of purpose codes.  The
> signature purpose attribute applies only to the signature in SignerInfo
> which contains it.  It does not apply to any other signature.
> 
> A number of basic purpose codes are defined here for use by S/MIME
> applications.  Further purpose codes may be defined on an
> application-specific basis. An implementation may choose to populate
> the purposeQualifier field with text which further describes the
> purpose.
> 
> The following basic S/MIME purpose codes are defined:
> 
> * Message originator - the signer originated the message together with
> the content of the message.  Signature purpose code
> id-SigPurposeMessageOriginator is used for this purpose.
> 
> * Message forwarder - the signer forwarded the message but did not
> originate it.  Signature purpose code id-SigPurposeMessageForwarder is
> used for this purpose.  One use of this purpose code is by a Mail List
> Agent (MLA) expanding a message to a distribution list.
> 
> * Content originator - the signer originated the signed content, but
> does not intend sending it out as a mail message. Signature purpose
> code id-SigPurposeContentOriginator is used for this purpose.  A
> typical use of this purpose code is to add an S/MIME signature to local
> files and documents inside a system.
> 
> * HTTP originator - the signer originated the HTTP content. Signature
> purpose code id-SigPurposeHTTPOriginator is used for this purpose.
> 
> * Content review and approval - the signer reviewed and approved the
> content but did not originate it. Signature purpose code
> id-SigPurposeContentReviewer is used for this purpose. A possible use
> of this purpose code is by a 'virus scanner' checking for malicious
> code in content.  Another use is by 'release authorities' used in some
> situations to release messages through a firewall.  In both cases,
> further qualifying text could be added in the purposeQualifier field.
> 
> * Security label - the signer added the signed security label but did
> not originate the content. Signature purpose code
> id-SigPurposeSecurityLabel is used for this purpose.
> 
> * Timestamp - the signer added a signed timestamp but did not originate
> the content. Signature purpose code id-SigPurposeTimestamp is used for
> this purpose.
> 
> 'Message Originator', 'Content Originator', and 'HTTP originator',
> may be used in a SignerInfo on content but SHOULD NOT be used in a
> countersignature.  All the other codes listed may be used in either a
> SignerInfo on content or in a countersignature.  An implementation may
> choose to compare the signature purpose field with fields in the
> certificate before deciding whether the signature is valid.

To: [email-masked]
Subject: Re: Inclusion of the issuer and serial number in authenticated in formation 
Date: Wed, 18 Mar 1998 18:59:13 +0000
From: Andrew Farrell <[email-masked]>
Sender: [email-masked]

Denis Pinkas writes:
>(Response from Jim)

>> Denis,
 
>> This is not sufficent to fix your problem.  If the Postal Service
>> in Banana Republic is using the same name, why would they not use 
>> the same serial number as well?  

>In the case I described, they do use the same serial number.

I believe that you are mistaking Jim's point. He was suggesting that the
Postal Service use the same serial number in its own (self-signed)
certificate that the Postal Service in the US uses. This produces an
identical sequence either way.

>> Then you would not have any advantage by putting in the
>> sequence to the issuer.

>Not exactly. The next sequence (assuming it ends up to a trust point)
>will allow to make the difference between the Postal Service from the US
>and the postal Service from the Banana Republic. If this is not yet a
>trust point, then you add another leg and so on until you reach a trust
>point. A I said, this is one possibility among others.

But supposing that our cracker is churning out certificates willy-nilly,
he can reproduce and replace as many issuer-serialnumber pairs as he
wishes. The point at which his attack fails is when the chain you're
validating reaches a trust point. The solution to this is that you don't
trust the certificates in the message independant of other verification,
and a sequence of IaSNs doesn't affect this one way or the other.

To recap: Jim's suggestion was a solution to the problem of a cracker
substituting one of my certs for the other, when both contain the same
public key, but they have different legal meanings. I'm not aware of a
CA anywhere which has seperate certs for itself with different dnames
and the same public key; I'd imagine that CA would be asking for
trouble.

>Instead we should have something like:

>CertUID ::=     SEQUENCE {
>       issuerAndserialNumber   IssuerAndserialNumber,
>       certificateHash         CertHash,
>}

>The certUID is the Certificate Unique Identifier.

I have no problem with this as an authenticated attribute.

Andrew.

To: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: Re: Inclusion of the issuer and serial number in authenticated in formation 
Date: Wed, 18 Mar 1998 09:43:01 -0800
From: Marc Branchaud <[email-masked]>
Sender: [email-masked]

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

Content-Type: text/plain; charset=us-ascii

Denis Pinkas <[email-masked]> scrawled:
> 
> Ambarish Malpani has been proposing the following:
> 
> ==================================================
> 
> > Here is something that I have proposed in the past to help
> > identify a cert uniquely, that might work for you:
> 
> CertID                  ::=     SEQUENCE {
>         issuerNameAndKeyHash            Hash,
>         serialNumber                    CertificateSerialNumber,
> }
> 
> IssuerNameAndKey                ::=     SEQUENCE {
>         issuer                          Name,
>         issuerPublicKey                 SubjectPublicKeyInfo
> }
> 
> i.e. you identify a cert by the hash of the IssuerNameAndKey
> and a serial number.
> 
> The hash includes the public key of the issuer - this prevents the
> Banana Republic CA from impersonating our well beloved and well
> trusted US CA ;-).
> 
> ==================================================
> 
> This is not the right solution since the hash is not usable to point to
> the certificate, but only there to make sure that the right certificate
> is being selected.
> 
> Instead we should have something like:
> 
> CertUID ::=     SEQUENCE {
>        issuerAndserialNumber   IssuerAndserialNumber,
>        certificateHash         CertHash,
> }
> 
> The certUID is the Certificate Unique Identifier.
> 
> The advantage is that other links do not need to be explored, nor
> indicated. So my preference would be to fix the start point, as you
> suggested.
> 
> Denis
> 

I'm late to this thread and new to the list, so my apologies if the 
following isn't germane or a new idea.

I believe the PKCS#7 IssuerAndSerialNumber type is an inadequate certificate 
identifier now that we have IssuerAlternativeName extensions.

The type should be redefined to something like:

IssuerAndSerialNumber ::= SEQUENCE {
     issuerDN          Name,
     issuerAltName     IssuerAltName OPTIONAL,  -- As defined in PKIX
     serial            CertificateSerialNumber
}

This would make it acceptable for certificates from DN-less CAs.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

To: Paul Hoffman / IMC <[email-masked]>
Cc: [email-masked]
Subject: Re: Key pair generation in MSG
From: EKR <[email-masked]>
Date: 18 Mar 1998 06:59:34 -0800
Lines: 27
Sender: [email-masked]

Paul Hoffman / IMC <[email-masked]> writes:

> Hi again. Section 4.1 of MSG says:
> 
>   A user agent SHOULD generate RSA key pairs at a minimum key size of
>   768 bits and a maximum key size of 1024 bits. A user agent MUST NOT
>   generate RSA key pairs less than 512 bits long. ...stuff about 512...
> 
> I think having a maximum size on the key, even as a SHOULD, is a bad idea.
> This is a leftover from earlier S/MIME where some toolkits couldn't verify
> with key sizes over 1024. Other applications are requiring keys longer than
> 1024 bits, and it would be good if those keys were usable with S/MIME. I
> propose the above wording be changed to:
> 
>   A user agent SHOULD generate RSA key pairs at a minimum key size of
>   768 bits. A user agent MUST NOT generate RSA key pairs less than 512
>   bits long. Creating keys longer than 1024 bits may cause some older
>   S/MIME receiving agents to not be able to verify signatures, but gives
>   better security and is therefore valuable. A receiving agent SHOULD be
>   able to verify signatures with keys of any size over 512 bits.
I agree that having a maximum size is a bad idea. 

-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

Date: Wed, 18 Mar 1998 13:56:24 -0800
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: "Jim Schaad (Exchange)" <[email-masked]>
CC: Blake Ramsdell <[email-masked]>, "[email-masked]'" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: Re: Inclusion of the issuer and serial number in authenticated in formation
Sender: [email-masked]

(Response from Jim)

> Denis,
> 
> This is not sufficent to fix your problem.  If the Postal Service
> in Banana Republic is using the same name, why would they not use 
> the same serial number as well?  

In the case I described, they do use the same serial number.

> Then you would not have any advantage by putting in the
> sequence to the issuer.

Not exactly. The next sequence (assuming it ends up to a trust point)
will allow to make the difference between the Postal Service from the US
and the postal Service from the Banana Republic. If this is not yet a
trust point, then you add another leg and so on until you reach a trust
point. A I said, this is one possibility among others.
  
> If you really want to solve this problem you should
> proprose that we add a hash of the certificate to 
> the single issuer serial number in the signing certificate 
> attribute.  This way everyone can be sure that we are 
> starting at the same point.  

You are right. This is another way to solve the problem, without the
need to indicate the other legs.

Ambarish Malpani has been proposing the following:

==================================================

> Here is something that I have proposed in the past to help
> identify a cert uniquely, that might work for you:

CertID                  ::=     SEQUENCE {
        issuerNameAndKeyHash            Hash,
        serialNumber                    CertificateSerialNumber,
}

IssuerNameAndKey                ::=     SEQUENCE {
        issuer                          Name,
        issuerPublicKey                 SubjectPublicKeyInfo
}

i.e. you identify a cert by the hash of the IssuerNameAndKey
and a serial number.

The hash includes the public key of the issuer - this prevents the
Banana Republic CA from impersonating our well beloved and well
trusted US CA ;-).

==================================================

This is not the right solution since the hash is not usable to point to
the certificate, but only there to make sure that the right certificate
is being selected.

Instead we should have something like:

CertUID ::=     SEQUENCE {
       issuerAndserialNumber   IssuerAndserialNumber,
       certificateHash         CertHash,
}

The certUID is the Certificate Unique Identifier.

The advantage is that other links do not need to be explored, nor
indicated. So my preference would be to fix the start point, as you
suggested.

Denis

(previous E-mail from Denis)
 
> Let us start by some intuition. If CA names can be confusing, then the
> identity of the signer may also be confused. The signer is identified by
> a CA name and a serial number. It is thus possible to retrieve the
> corresponding certificate that contains the signature verification key
> and the name of the signer.
> 
> Suppose there exists two CAs with the name "Postal Service", one located
> in the US and the other one in the Banana Republic of Barracuda. James
> Brown is signing a document. The CA name "Postal Service" (located in
> the US) and the certificate serial number are included in the signed
> stuff.
> 
> The CA named "Postal Service" located in the Banana Republic of
> Barracuda issues for 200 $ (instead of the regular 20 $) a certificate
> for Willy Hacker with the same serial number (let us assume that this
> number has not yet be used by the CA) and the same public key value. Of
> course, for 200 $ that CA omits to perform POP (Proof of Possession of
> the private key) as it should normally do.
> 
> Now the document appears to be signed by Willy Hacker instead of James
> Brown.
> 
> There may be different ways to solve the problem, one of them is to use
> a SEQUENCE OF issuer names and serial number.
> 
> Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Tue, 17 Mar 1998 17:46:41 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Key pair generation in MSG
Sender: [email-masked]

Hi again. Section 4.1 of MSG says:

  A user agent SHOULD generate RSA key pairs at a minimum key size of
  768 bits and a maximum key size of 1024 bits. A user agent MUST NOT
  generate RSA key pairs less than 512 bits long. ...stuff about 512...

I think having a maximum size on the key, even as a SHOULD, is a bad idea.
This is a leftover from earlier S/MIME where some toolkits couldn't verify
with key sizes over 1024. Other applications are requiring keys longer than
1024 bits, and it would be good if those keys were usable with S/MIME. I
propose the above wording be changed to:

  A user agent SHOULD generate RSA key pairs at a minimum key size of
  768 bits. A user agent MUST NOT generate RSA key pairs less than 512
  bits long. Creating keys longer than 1024 bits may cause some older
  S/MIME receiving agents to not be able to verify signatures, but gives
  better security and is therefore valuable. A receiving agent SHOULD be
  able to verify signatures with keys of any size over 512 bits.

  ...stuff about 512...

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 17 Mar 1998 13:57:55 -0800
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: "Jim Schaad (Exchange)" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, Blake Ramsdell <[email-masked]>, "[email-masked]'" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: Re: Inclusion of the issuer and serial number in authenticated in formation
Sender: [email-masked]

Hi Guys,
    Here is something that I have proposed in the past to help
identify a cert uniquely, that might work for you:

CertID			::=	SEQUENCE {
	issuerNameAndKeyHash		Hash,
	serialNumber			CertificateSerialNumber,
}

IssuerNameAndKey		::=	SEQUENCE {
	issuer				Name,
	issuerPublicKey			SubjectPublicKeyInfo
}

i.e. you identify a cert by the hash of the IssuerNameAndKey
and a serial number.

The hash includes the public key of the issuer - this prevents the
Banana Republic CA from impersonating our well beloved and well
trusted US CA ;-).

Any comments?

Ambarish

Jim Schaad (Exchange) wrote:
> 
> Denis,
> 
> This is not sufficent to fix your problem.  If the Postal Service in Banana
> Republic is using the same name, why would they not use the same serial
> number as well?  Then you would not have any advantage by putting in the
> sequence to the issuer.  If you really want to solve this problem you should
> proprose that we add a hash of the certificate to the single issuer serial
> number in the signing certificate attribute.  This way everyone can be sure
> that we are starting at the same point.   If the Postal Service in Banana
> Republic captures the real Postal Serice private keys then you are
> completely out of luck about everything as you now have a rogue CA running.
> 
> jim
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Tuesday, March 17, 1998 5:42 PM
> To: Blake Ramsdell
> Cc: Jim Schaad (Exchange); [email-masked]'; Ietf-Smime (E-mail)
> Subject: Re: Inclusion of the issuer and serial number in authenticated
> in formation
> 
> Blake,
> 
> You wrote:
> 
> > I suspect that it won't hurt anything to specify a SEQUENCE OF
> > IssuerAndSerialNumber, but I don't think that CA namespace collisions
> > pose a significant problem.
> 
> (...)
> 
> > I certainly agree that solving the "I stuck another
> > IssuerAndSerialNumber for another certificate with the same public key
> > in a SignerInfo" problem is a Very Good Idea, and is A Necessity.  I
> > just don't know if we need to go the extra step for the SEQUENCE with
> > the IssuerAndSerialNumbers for the entire chain.
> 
> > Comments welcome.
> 
> Sorry for the delay to respond.
> 
> Let us start by some intuition. If CA names can be confusing, then the
> identity of the signer may also be confused. The signer is identified by
> a CA name and a serial number. It is thus possible to retrieve the
> corresponding certificate that contains the signature verification key
> and the name of the signer.
> 
> Suppose there exists two CAs with the name "Postal Service", one located
> in the US and the other one in the Banana Republic of Barracuda. James
> Brown is signing a document. The CA name "Postal Service" (located in
> the US) and the certificate serial number are included in the signed
> stuff.
> 
> The CA named "Postal Service" located in the Banana Republic of
> Barracuda issues for 200 $ (instead of the regular 20 $) a certificate
> for Willy Hacker with the same serial number (let us assume that this
> number has not yet be used by the CA) and the same public key value. Of
> course, for 200 $ that CA omits to perform POP (Proof of Possession of
> the private key) as it should normally do.
> 
> Now the document appears to be signed by Willy Hacker instead of James
> Brown.
> 
> There may be different ways to solve the problem, one of them is to use
> a SEQUENCE OF issuer names and serial number.
> 
> Denis
> 
> --
>       Denis Pinkas     Bull S.A.          mailto:[email-masked]
>       Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
>       78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303

Date: Tue, 17 Mar 1998 16:06:53 -0500
To: Russ Housley <[email-masked]>, [email-masked]
From: [email-masked] (John Pawling)
Subject: RE: ESS-01 issues not finished
Sender: [email-masked]

Russ,

We did not change course.  ESS-04 includes your proposal regarding multiple
eSSSecurityLabel attributes included in a signedData object.  The recent
debate has been regarding the processing of multiple mlExpansionHistory
attributes in a signedData object.  The last para of ESS-04, sec 3.1.1 and
first paras of 3.1.2 read as follows:

"There can be multiple SignerInfos within a SignedData object, and each
SignerInfo may include authenticatedAttributes. Therefore, a single
SignedData object may include multiple eSSSecurityLabels, each SignerInfo
having an eSSSecurityLabel attribute. For example, an originator can send a
signed message with two SignerInfos, one containing a DSS signature, the
other containing an RSA signature. If any of the SignerInfos included in a
SignedData object include an eSSSecurityLabel attribute, then all of the
SignerInfos in that SignedData object MUST include an eSSSecurityLabel
attribute and the value of each MUST be identical.

3.1.2 Processing Security Labels

Before processing an eSSSecurityLabel authenticatedAttribute, the receiving
agent MUST verify the signature of the SignerInfo which covers the
eSSSecurityLabel attribute. A recipient MUST NOT process an
eSSSecurityLabel attribute that has not been verified.

A receiving agent MUST process the eSSSecurityLabel attribute, if present,
in each SignerInfo in the SignedData object for which it verifies the
signature. This may result in the receiving agent processing multiple
eSSSecurityLabels included in a single SignedData object. Because all
eSSSecurityLabels in a SignedData object must be identical, the receiving
agent processes (such as performing access control) on the first
eSSSecurityLabel that it encounters in a SignerInfo that it verifies, and
then ensures that all other eSSSecurityLabels in signerInfos that it
verifies are identical to the first one encountered. If the
eSSSecurityLabels in the signerInfos that it verifies are not all
identical, then the receiving agent MUST warn the user of this condition."

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

At 06:21 AM 3/16/98 -0500, Russ Housley wrote:
>S/MIME WG:
>
>I thought we were going down this track, but I still see a fair amount of
>discussion of recipient processing of mis-matched labels.  When did we
>change course, and why?
>
>Russ
>

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Blake Ramsdell <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Inclusion of the issuer and serial number in authenticated in formation
Date: Tue, 17 Mar 1998 10:44:33 -0800
Sender: [email-masked]

Denis,

This is not sufficent to fix your problem.  If the Postal Service in Banana
Republic is using the same name, why would they not use the same serial
number as well?  Then you would not have any advantage by putting in the
sequence to the issuer.  If you really want to solve this problem you should
proprose that we add a hash of the certificate to the single issuer serial
number in the signing certificate attribute.  This way everyone can be sure
that we are starting at the same point.   If the Postal Service in Banana
Republic captures the real Postal Serice private keys then you are
completely out of luck about everything as you now have a rogue CA running.

jim

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Tuesday, March 17, 1998 5:42 PM
To: Blake Ramsdell
Cc: Jim Schaad (Exchange); [email-masked]'; Ietf-Smime (E-mail)
Subject: Re: Inclusion of the issuer and serial number in authenticated
in formation

Blake,

You wrote:

> I suspect that it won't hurt anything to specify a SEQUENCE OF
> IssuerAndSerialNumber, but I don't think that CA namespace collisions
> pose a significant problem.  

(...)

> I certainly agree that solving the "I stuck another
> IssuerAndSerialNumber for another certificate with the same public key
> in a SignerInfo" problem is a Very Good Idea, and is A Necessity.  I
> just don't know if we need to go the extra step for the SEQUENCE with
> the IssuerAndSerialNumbers for the entire chain.
 
> Comments welcome.

Sorry for the delay to respond.

Let us start by some intuition. If CA names can be confusing, then the
identity of the signer may also be confused. The signer is identified by
a CA name and a serial number. It is thus possible to retrieve the
corresponding certificate that contains the signature verification key
and the name of the signer.

Suppose there exists two CAs with the name "Postal Service", one located
in the US and the other one in the Banana Republic of Barracuda. James
Brown is signing a document. The CA name "Postal Service" (located in
the US) and the certificate serial number are included in the signed
stuff.

The CA named "Postal Service" located in the Banana Republic of
Barracuda issues for 200 $ (instead of the regular 20 $) a certificate
for Willy Hacker with the same serial number (let us assume that this
number has not yet be used by the CA) and the same public key value. Of
course, for 200 $ that CA omits to perform POP (Proof of Possession of
the private key) as it should normally do.

Now the document appears to be signed by Willy Hacker instead of James
Brown.

There may be different ways to solve the problem, one of them is to use
a SEQUENCE OF issuer names and serial number. 

Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Tue, 17 Mar 1998 17:41:44 -0800
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Blake Ramsdell <[email-masked]>
CC: "Jim Schaad (Exchange)" <[email-masked]>, "[email-masked]'" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: Re: Inclusion of the issuer and serial number in authenticated in formation
Sender: [email-masked]

Blake,

You wrote:

> I suspect that it won't hurt anything to specify a SEQUENCE OF
> IssuerAndSerialNumber, but I don't think that CA namespace collisions
> pose a significant problem.  

(...)

> I certainly agree that solving the "I stuck another
> IssuerAndSerialNumber for another certificate with the same public key
> in a SignerInfo" problem is a Very Good Idea, and is A Necessity.  I
> just don't know if we need to go the extra step for the SEQUENCE with
> the IssuerAndSerialNumbers for the entire chain.
 
> Comments welcome.

Sorry for the delay to respond.

Let us start by some intuition. If CA names can be confusing, then the
identity of the signer may also be confused. The signer is identified by
a CA name and a serial number. It is thus possible to retrieve the
corresponding certificate that contains the signature verification key
and the name of the signer.

Suppose there exists two CAs with the name "Postal Service", one located
in the US and the other one in the Banana Republic of Barracuda. James
Brown is signing a document. The CA name "Postal Service" (located in
the US) and the certificate serial number are included in the signed
stuff.

The CA named "Postal Service" located in the Banana Republic of
Barracuda issues for 200 $ (instead of the regular 20 $) a certificate
for Willy Hacker with the same serial number (let us assume that this
number has not yet be used by the CA) and the same public key value. Of
course, for 200 $ that CA omits to perform POP (Proof of Possession of
the private key) as it should normally do.

Now the document appears to be signed by Willy Hacker instead of James
Brown.

There may be different ways to solve the problem, one of them is to use
a SEQUENCE OF issuer names and serial number. 

Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Tue, 17 Mar 1998 04:50:34 -0500 (EST)
From: Bancroft Scott <[email-masked]>
To: Russ Housley <[email-masked]>
Cc: [email-masked]
Subject: Re: ESS-04 Comments
Sender: [email-masked]

On Mon, 16 Mar 1998, Russ Housley wrote:

> Bancroft:
> 
> Okay.  CMS uses values from zero through three.  So:
> 
>     Version ::= INTEGER  { v0(0), v1(1), v2(2), v3(3) }
> 
> Agree?

Sounds good.

--------------------------------------------------------------------------
Bancroft Scott                                Toll Free    :1-888-OSS-ASN1
Open Systems Solutions, Inc.                  International:1-609-987-9073
[email-masked]                                  Tech Support :1-732-249-5107
http://www.oss.com                            Fax          :1-732-249-4636

Date: Mon, 16 Mar 1998 06:21:49 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: RE: ESS-01 issues not finished
Sender: [email-masked]

S/MIME WG:

I thought we were going down this track, but I still see a fair amount of
discussion of recipient processing of mis-matched labels.  When did we
change course, and why?

Russ

At 09:04 AM 3/6/98 -0500, David P. Kemp wrote:
>> 
>> Blake & Russ:
>> 
>> Actually there is a third choice which is to wrap the whole thing in a new
>> signature blob.
>> 
>> However, I am afraid that I have to agree with Blake, I think that the act
>> of just simply adding a signature from some unknown (and stupid) third
party
>> should not cause the message to be unavailable.  I think it is sufficent to
>> check for some attribute (after all you are already check for duplciates
>> anyway) and say that you must verify some Security Label if it exists.
>> 
>> jim
>
>
>The unknown third party, if he were malicious, could do anything, including
>adding a signature with a non-matching label to cause the message to be
>unavailable (which the recipient could just strip off to make it available
>again :-).  If the third party were just stupid, his user agent should
>warn him if he tries to add an unlabeled signature to a labelled message.
>
>I agree with Russ that interpreting a mix of labelled and unlabelled
>signatures is more confusing than requiring all signatures to be generated
>with a consistent label.  The onus of making sense should fall on the
>generators, not the receivers.
>
>  Dave Kemp
> 

Date: Mon, 16 Mar 1998 02:24:43 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Inclusion of the issuer and serial number in authenticated information
Cc: "Jim Schaad (Exchange)" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>, [email-masked]
Sender: [email-masked]

At 02:53 PM 3/12/98 -0800, Denis Pinkas wrote:
>>From John :
>CMS (sec 5.3 and 5.4) already requires two
>separate hash calculations when authenticated attributes are used.  First,
>the content is hashed and the resulting hash value is included in the
>messageDigest authenticated attribute.  Then the DER-encoded
>authenticatedAttributes are hashed.  The signature value is generated
>from the resulting hash value.
>
>>From Jim :
>The message is hashed and then the message hash is included
>in the authenticated attributes as a new attribute.  The authenticiated
>attributes are then hashed and this is the value that is actually signed.
>The only requirement is that the same hash function be applied to both sets
>of data to be hashed (not an oderous requirement as you should only use
>hash functions that you think are good anyway).

The first sentence of 5.3 says: "The message digest calculation process
computes
a message digest on either the content being signed or the content together
with the signer's authenticated attributes."  Doesn't this prepare the reader
for two ways to calculate the signature?

Do you have problems with the description in 5.3 or 5.4?

Russ 

Date: Mon, 16 Mar 1998 02:08:33 -0500
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: Re: Comments to MSG-02
Cc: [email-masked]
Sender: [email-masked]

At 06:26 PM 3/12/98 -0500, John Pawling wrote:
>
>5) Sec 2.5.2: Jim Schaad commented (There was debate regarding this comment,
>but I don't remember the answer.  Russ, I believe that you had the answer.
>Can you please provide it.) 
>"Section 2.5.2  This is a politics question and one I am not capable of
>deciding.  Do we need to change from using the IMC as the registration agent
>for the OIDs of SMIMECapabilites?  I don't see any techincal reasons to
>change this at this point in time.  I don't see IMC as disappearing any time
>soon and from what I hear it would be much faster to get updates than using
>IANA.  But I don't know if the IESG will be willing to leave this as it is."

IMC is not the registration authority.  IMC is providing a location on
their Web site for distribution of the assigned OIDs.  I am assigning OIDs
from the arc provided to the IETF S/MIME WG by RSA Labs.

Russ

Date: Mon, 16 Mar 1998 01:38:15 -0500
To: [email-masked], [email-masked]
From: Russ Housley <[email-masked]>
Subject: RE: Inclusion of the issuer and serial number in authenticated in formation
Cc: [email-masked]
Sender: [email-masked]

John & Jim:

In general, the originator cannot know the certificate path that will be
used by the recipient, especially when cross certificates are involved.
Given this situation, the signature should not cover any more than the
terminal certificate in the path.  It seems to me that Issuer and Serial
Number is sufficient for this.

Russ

\At 06:50 PM 3/12/98 -0800, Jim Schaad (Exchange) wrote:
>John,
>
>I don't think you are being fickle,  I thought hard about it before I
>endorsed the expacted proposal.  I decided that the additional capability
>did not hurt anything since only one item was required (as oppose the entire
>chain).  
>
>I think that my original proposal actually addressed the issue that I was
>worried about and is sufficent for that.  I think that for the issued raised
>by Denis and some others in private mail is not really addressed by the
>sequence approach.  Specifically there is nothing that prevents a CA from
>issing a new certificate with the same serial number and issuer name, but
>different extensions.  I don't know if this is really a problem that needs
>to be solved or should be solved at this time by us.  This really requires a
>sequece of both issuer/serial number and hash of the certificate pairs to
>say that this is the certificate I wanted to use and you can see that the
>certificate has not been changed in anyway.
>
>I can easily go either way with this issue as the full sequence is not
>required by the proposal that Denis made, and thus the minimal version of
>this extension solves my problem and that is really all that I cared about.
>
>jim
>
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Thursday, March 12, 1998 4:16 PM
>To: Ietf-Smime (E-mail)
>Subject: RE: Inclusion of the issuer and serial number in authenticated
>in formation
>
>
>All,
>
>I apologize for being fickle, but I agree with Blake's most excellent
>argument that the "Signing Certificate Attribute" should only contain the
>IssuerAndSerialNumber of the signer's cert and should not be a SEQUENCE OF
>IssuerAndSerialNumber.  Once the app has obtained the signer's cert, it will
>very probably include an authorityKeyIdentifier extension that includes the
>IssuerAndSerialNumber of the issuer's cert, so the app can identify the
>issuer's cert in that manner.  In summary, I agree with Jim's original
>proposal.
>
>================================
>John Pawling   
>[email-masked]                             
>J.G. Van Dyke & Associates, Inc.           
>================================
> 

Date: Mon, 16 Mar 1998 00:40:56 -0500
To: Bancroft Scott <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: ESS-04 Comments
Cc: [email-masked]
Sender: [email-masked]

Bancroft:

Okay.  CMS uses values from zero through three.  So:

    Version ::= INTEGER  { v0(0), v1(1), v2(2), v3(3) }

Agree?

Russ

At 09:17 PM 3/13/98 -0500, Bancroft Scott wrote:
>On Fri, 13 Mar 1998, John Pawling wrote:
>
>> 10) Sec 3.2 and App A: Please define "v1" and "v2" referred to in
>> ESSSecurityLabel and ESSPrivacyMark syntaxes.  Recommend the following:
>> 
>> v1 INTEGER ::= 1
>> v2 INTEGER ::= 2
>
>I think it would be clearer if we changed the definition of "Version" in
>smime-cms from:
>
> Version ::= INTEGER
>to
> Version ::= INTEGER { v1(1), v2(2) }
>
>Doing so makes clear in the definition of Version that the currently
>expected values are v1 and v2, while allowing other "NamedNumbers" to be
>added in the future.  It tightly relates the version numbers v1 and v2
>to Version, as opposed to directly defining v1 and v2 as valuereferences.
>
>--------------------------------------------------------------------------
>Bancroft Scott                                Toll Free    :1-888-OSS-ASN1
>Open Systems Solutions, Inc.                  International:1-609-987-9073
>[email-masked]                                  Tech Support :1-732-249-5107
><http://www.oss.com/>http://www.oss.com                           
Fax         
:1-732-249-4636
>  

Date: Mon, 16 Mar 1998 00:45:17 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Fwd: CMMF and CMC drafts
Sender: [email-masked]

I post this as notification of the CRS work.  PLease do not discuss these
drafts on the S/MIME mail list.  Comments should be sent to the PKIX list.

Russ

>From: Michael Myers <[email-masked]>
>Subject: CMMF and CMC drafts
>
>All,
>
>I haven't yet seen any notification to this effect yet but the following two
>drafts are available for review and comment on the IETF web site:
>
>-- Certificate Management Message Formats
>      ietf-draft-pkix-cmmf-00.txt
>
>-- Certificate Management over CMS
>      ietf-draft-pkix-cmc-00.txt
>
>CMMF integrates PKI message bodies into one document (although points to
>CRMF).
>
>The CMC draft carries forward the CRS work which was submitted at the last
>IETF to the S/MIME group and which was subsequently redirected to PKIX.
>
>Mike

Date: Mon, 16 Mar 1998 14:19:57 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: ESS-04 Comments
Sender: [email-masked]

I agree with John on this one: the recipient should never reject a message
based solely on un-authenticated information. There are too many things
that can futzle with unauthenticated information, and almost all a user
cares about is the authenticated information. And, fortunately, it's very
clear in S/MIME which is authenticated and which isn't.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 16 Mar 1998 16:44:57 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: RE: ESS-04 Comments
Sender: [email-masked]

Jim,

I respectfully disagree with your recommended solution.  There are many ways
that a renegade entity can flood a mail box with messages.  There are many
easier ways to do this then to: intercept a message, decode it, add a bogus
signerInfo, sign the bogus signerInfo, re-encode it and then re-send it.  In
fact, your recommendation would make the flooding renegade entity's job
easier, because it could simply add a bogus signerInfo to every message
without even taking the time to calculate the signature value.  In summary,
I believe that the proposals in my enclosed message should be adopted.
Furthermore, I believe that the recipient should never reject a message
based solely on un-authenticated info.

- John Pawling

At 10:22 AM 3/16/98 -0800, Jim Schaad (Exchange) wrote:
>John,
>
>No this does address my problem.  It still means that I can flood your
>mailbox by intercepting all messages, adding a good signature and corrupting
>the one with the mlExpansionHistory in it.  While I agree that I don't like
>the fact that the MLA does not accept the data based on unauthenticatable
>information, that is exactly what you have in this case.  Having the MLA
>reject on unauthenticatable information is the ONLY way to fix this problem.
>
>jim
>
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Monday, March 16, 1998 9:54 AM
>To: [email-masked]
>Subject: RE: ESS-04 Comments
>
>
>Jim,
>
>You make an excellent point, but I don't agree with your specific
>recommendation because I don't believe that the MLA should reject a message
>based on unauthenticated information.  I believe that the best way to
>resolve this issue is to change ESS so that it requires that multiple
>mlExpansionHistory attributes must be processed similar to multiple
>eSSSecurityLabel attributes (except I don't believe that mlExpansionHistory
>attributes MUST always be critical).  In addition to my original comments, I
>propose the following changes to ESS, Sec 4.1:
>
>1) Sec 4.1, 4th para, last sent: Please make the following change:
>
>OLD: "Not all of the SignerInfos need to include mlExpansionHistory
>attributes, but in all of the SignerInfos that do contain mlExpansionHistory
>attributes, the mlExpansionHistory attributes MUST be identical."
>
>NEW: "If any of the SignerInfos included in a SignedData object include an
>mlExpansionHistory attribute, then all of the SignerInfos in that SignedData
>object MUST include an mlExpansionHistory attribute and the value of each
>MUST be identical."
>
>
>2) Sec 4.1, 5th para: Please make the following change:  This replaces my
>original comment 11:
>
>OLD: "A recipient SHOULD only process an mlExpansionHistory attribute if the
>recipient can verify the signature of the SignerInfo which covers the
>attribute. A recipient SHOULD NOT use an mlExpansionHistory attribute which
>the recipient cannot authenticate."
>
>NEW: "A recipient MUST verify the signature of the SignerInfo which covers
>the mlExpansionHistory attribute before processing it. A recipient MUST NOT
>process an mlExpansionHistory attribute which the recipient has not
>verified."
>
>
>These new comments combined with my original comments result in the
>following text for the last three paragraphs in Sec 4.1:
>
>"There can be multiple SignerInfos within a SignedData object, and each
>SignerInfo may include authenticatedAttributes. Therefore, a single
>SignedData object may include multiple SignerInfos, each SignerInfo having a
>mlExpansionHistory attribute. For example, an MLA can send a signed message
>with two SignerInfos, one containing a DSS signature, the other containing
>an RSA signature. If any of the SignerInfos included in a SignedData object
>include an mlExpansionHistory attribute, then all of the SignerInfos in that
>SignedData object MUST include an mlExpansionHistory attribute and the value
>of each MUST be identical.
>
>A recipient MUST verify the signature of the SignerInfo which covers the
>mlExpansionHistory attribute before processing it. A recipient MUST NOT
>process an mlExpansionHistory attribute which the recipient has not been
>verified.
>
>When receiving a message that includes an outer SignedData object, a
>receiving agent that processes mlExpansionHistory attributes MUST process
>the mlExpansionHistory attribute, if present, in each SignerInfo in the
>SignedData object for which it verifies the signature. This may result in
>the receiving agent processing multiple mlExpansionHistory attributes
>included in a single SignedData object. Because all mlExpansionHistory
>attributes must be identical, the receiving application processes the first
>mlExpansionHistory attribute that it encounters in a SignerInfo that it can
>verify, and then ensures that all other mlExpansionHistory attributes in
>signerInfos that it verifies are identical to the first one encountered.  If
>the mlExpansionHistory attributes in the signerInfos that it verifies are
>not all identical, then the receiving agent MUST stop processing the message
>and MUST notify the user or MLA administrator of this error condition."
>
>
>Does that sound meet your requirement?
>
>- John Pawling
>
>
>
>At 08:08 AM 3/16/98 -0800, Jim Schaad (Exchange) wrote:
>>John,
>>
>>I have a small problem with the following change.  While I agree that it is
>>correct, there is a possiblity that this can lead to exactly the situation
>>we were trying to avoid.  If A cannot verify B's signature and B cannot
>>verify A's signature.  What is to stop them from sending messages back and
>>forth if some other item (such as a gateway) is also sticking in
>signatures.
>>
>>
>>11) Sec 4.1, 5th para: Please make the following change:
>>
>>OLD: "A recipient SHOULD only process an mlExpansionHistory attribute if
>the
>>recipient can verify the signature of the SignerInfo which covers the
>>attribute. A recipient SHOULD NOT use an mlExpansionHistory attribute which
>>the recipient cannot authenticate."
>>
>>NEW: "A recipient MUST verify the signature of the SignerInfo which covers
>>an mlExpansionHistory attribute before processing it. A recipient MUST NOT
>>process an mlExpansionHistory attribute which the recipient cannot
>>authenticate."
>>
>>We perhaps should add a sentence along the lines of "If an
>>mlExpansionHistory is found in a signature which cannot be verified, and no
>>matching mlExpansionHistory is found in a verifiable signature, the MLA
>>SHOULD stop processing."
>>
>>jim
>>
>>
>>
>>
>

Date: Mon, 16 Mar 1998 16:33:28 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: RE: CERT-02 Comments
Sender: [email-masked]

All,

I agree with the majority of Jim's comments with the following responses
in-line:

At 08:08 AM 3/16/98 -0800, Jim Schaad (Exchange) wrote:
>John,
>
>1) Sec 1, 1rst para: Please make the following change: 
>[Jim Schaad:  What is the benifit of putting in the ITU-T reference?  Is it
>not sufficent to reference just PKIX?]

[JSP: Agree.  Just refer to PKIX.]

>10) Sec 4.2, 1rst para, last sent: Please  change: 
>
>OLD: "This is necessary when a) verifying a signature from a correspondent
>and, b) creating a digital envelope with the correspondent as the intended
>recipient."
>
>NEW: "This is necessary before using a public key to provide security
>services such as: verifying a signature; encrypting a content-encryption key
>(ex: RSA); or forming a pairwise symmetric key (ex: Diffie-Hellman) to be
>used to encrypt or decrypt a content-encryption key."
>[Jim Schaad:  Please remove "or decrypt" in the last sentence.  In some
>circumstances there is no need to verify the senders certificate for a
>simple decryption operation.  What do I care if the sender's certificate has
>been revoked, it will still decrypt and that is all I care about.
>Encryption does not carry any information about authentication.]

[JSP: I agree with your sentence "In some circumstances there is no need to
verify the senders certificate..".  However, in some circumstances, people
care very much. With the D-H, KEA and other key agreement algorithms, the
recipient forms a pairwise key with the originator using the originator's
public key as a part of this process.  The pairwise key is then used to
decrypt the content-encryption key which is then used to decrypt the
content.  My experience has been that people do care about the identity of
the originator when a pairwise key is formed.  How about if we add the
following sentence: "If an envelopedData object is received in which the
recipient's copy of the content encryption key is protected using a key
agreement algorithm, then the recipient organization's policy may include
processing requirements that omit the validation of the originator's
certification path before using the originator's public key to form the
pairwise symmetric key as part of the decryption process."]

>Names for chaining
>JSP: IMHO, the existing text is fine, so please delete this bullet.
>Jim Schaad: I am not sure that I agree with this.  There are now more ways
>of chaining and we should add these in or at least acknowledge them.

[JSP: The PKIX X.509 Certificate and CRL Profile, Sec 6, Pass Processing
bullet a.4 states that the cert path validation software must ensure that:
"(4) the subject and issuer names chain correctly.  (If the certificate has
an empty sequence in the name field, name chaining will use the critical
subjectAltNames and issuerAltNames fields.)"  I believe that this statement
satisfies the requirement to document alternate strategies for chaining.
Furthermore, since the S/MIME CERT spec (Sec 3.1, last para) requires that
the subject and issuer DNs MUST be populated in S/MIME-compliant certs
(except for the end-entity cert subject DN which may be empty), then the DNs
required for chaining MUST always be present in S/MIME certs.]

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

Date: Mon, 16 Mar 1998 15:00:15 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: RE: Comments to MSG-02
Sender: [email-masked]

Jim,

I agree.

- John

At 10:23 AM 3/16/98 -0800, Jim Schaad (Exchange) wrote:

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Monday, March 16, 1998 10:03 AM
>To: [email-masked]
>Subject: RE: Comments to MSG-02
>
>
>Jim,
>
>I agree with Jim's comments and have the following further comment:
>
>>13) Sec 3.2, 2nd para: Please make the following change: 
>>
>>OLD: "The contentInfo field of the carried CMS object always contains a
>MIME
>>entity that is prepared as described in section 3.1. The contentInfo field
>>must never be empty."
>>
>>NEW: "The carried CMS object always contains a MIME entity that is prepared
>>as described in section 3.1.  Also, see Section 2.4.1 for instructions on
>>including the id-data OID and MIME entity in the CMS objects."
>>
>>[Jim Schaad:  This is no longer as true of a statement.  Unless we are
>>prepared to say that we are going to use a different mime type for items
>>such as SignedData/Receipts.  I don't know that this should change or just
>>be a gotta to future implementors.]
>
>[JSP: How about this: "The carried CMS object always contains a MIME entity
>that is prepared as described in section 3.1 except in the case of a
>signedData encapsulating a Receipt content type (i.e. signed receipt).  See
>Section 2.4.1 for instructions on including the id-data OID and MIME entity
>in CMS objects.  See [ESS] for instructions regarding signed receipts."
>
>- John Pawling
>
>[Jim Schaad: How about this:  "The carried CMS object always contains a MIME
>entity that is prepared as described in section 3.1 if the eContentType is
>id-data.  Other contents may be carried when the eContentType contains
>different values.  See [ESS] for an example of this with signed receipts."
>

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: Comments to MSG-02
Date: Mon, 16 Mar 1998 10:23:50 -0800
Sender: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, March 16, 1998 10:03 AM
To: [email-masked]
Subject: RE: Comments to MSG-02

Jim,

I agree with Jim's comments and have the following further comment:

>13) Sec 3.2, 2nd para: Please make the following change: 
>
>OLD: "The contentInfo field of the carried CMS object always contains a
MIME
>entity that is prepared as described in section 3.1. The contentInfo field
>must never be empty."
>
>NEW: "The carried CMS object always contains a MIME entity that is prepared
>as described in section 3.1.  Also, see Section 2.4.1 for instructions on
>including the id-data OID and MIME entity in the CMS objects."
>
>[Jim Schaad:  This is no longer as true of a statement.  Unless we are
>prepared to say that we are going to use a different mime type for items
>such as SignedData/Receipts.  I don't know that this should change or just
>be a gotta to future implementors.]

[JSP: How about this: "The carried CMS object always contains a MIME entity
that is prepared as described in section 3.1 except in the case of a
signedData encapsulating a Receipt content type (i.e. signed receipt).  See
Section 2.4.1 for instructions on including the id-data OID and MIME entity
in CMS objects.  See [ESS] for instructions regarding signed receipts."

- John Pawling

[Jim Schaad: How about this:  "The carried CMS object always contains a MIME
entity that is prepared as described in section 3.1 if the eContentType is
id-data.  Other contents may be carried when the eContentType contains
different values.  See [ESS] for an example of this with signed receipts."

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: ESS-04 Comments
Date: Mon, 16 Mar 1998 10:22:02 -0800
Sender: [email-masked]

John,

No this does address my problem.  It still means that I can flood your
mailbox by intercepting all messages, adding a good signature and corrupting
the one with the mlExpansionHistory in it.  While I agree that I don't like
the fact that the MLA does not accept the data based on unauthenticatable
information, that is exactly what you have in this case.  Having the MLA
reject on unauthenticatable information is the ONLY way to fix this problem.

jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, March 16, 1998 9:54 AM
To: [email-masked]
Subject: RE: ESS-04 Comments

Jim,

You make an excellent point, but I don't agree with your specific
recommendation because I don't believe that the MLA should reject a message
based on unauthenticated information.  I believe that the best way to
resolve this issue is to change ESS so that it requires that multiple
mlExpansionHistory attributes must be processed similar to multiple
eSSSecurityLabel attributes (except I don't believe that mlExpansionHistory
attributes MUST always be critical).  In addition to my original comments, I
propose the following changes to ESS, Sec 4.1:

1) Sec 4.1, 4th para, last sent: Please make the following change:

OLD: "Not all of the SignerInfos need to include mlExpansionHistory
attributes, but in all of the SignerInfos that do contain mlExpansionHistory
attributes, the mlExpansionHistory attributes MUST be identical."

NEW: "If any of the SignerInfos included in a SignedData object include an
mlExpansionHistory attribute, then all of the SignerInfos in that SignedData
object MUST include an mlExpansionHistory attribute and the value of each
MUST be identical."

2) Sec 4.1, 5th para: Please make the following change:  This replaces my
original comment 11:

OLD: "A recipient SHOULD only process an mlExpansionHistory attribute if the
recipient can verify the signature of the SignerInfo which covers the
attribute. A recipient SHOULD NOT use an mlExpansionHistory attribute which
the recipient cannot authenticate."

NEW: "A recipient MUST verify the signature of the SignerInfo which covers
the mlExpansionHistory attribute before processing it. A recipient MUST NOT
process an mlExpansionHistory attribute which the recipient has not
verified."

These new comments combined with my original comments result in the
following text for the last three paragraphs in Sec 4.1:

"There can be multiple SignerInfos within a SignedData object, and each
SignerInfo may include authenticatedAttributes. Therefore, a single
SignedData object may include multiple SignerInfos, each SignerInfo having a
mlExpansionHistory attribute. For example, an MLA can send a signed message
with two SignerInfos, one containing a DSS signature, the other containing
an RSA signature. If any of the SignerInfos included in a SignedData object
include an mlExpansionHistory attribute, then all of the SignerInfos in that
SignedData object MUST include an mlExpansionHistory attribute and the value
of each MUST be identical.

A recipient MUST verify the signature of the SignerInfo which covers the
mlExpansionHistory attribute before processing it. A recipient MUST NOT
process an mlExpansionHistory attribute which the recipient has not been
verified.

When receiving a message that includes an outer SignedData object, a
receiving agent that processes mlExpansionHistory attributes MUST process
the mlExpansionHistory attribute, if present, in each SignerInfo in the
SignedData object for which it verifies the signature. This may result in
the receiving agent processing multiple mlExpansionHistory attributes
included in a single SignedData object. Because all mlExpansionHistory
attributes must be identical, the receiving application processes the first
mlExpansionHistory attribute that it encounters in a SignerInfo that it can
verify, and then ensures that all other mlExpansionHistory attributes in
signerInfos that it verifies are identical to the first one encountered.  If
the mlExpansionHistory attributes in the signerInfos that it verifies are
not all identical, then the receiving agent MUST stop processing the message
and MUST notify the user or MLA administrator of this error condition."

Does that sound meet your requirement?

- John Pawling

At 08:08 AM 3/16/98 -0800, Jim Schaad (Exchange) wrote:
>John,
>
>I have a small problem with the following change.  While I agree that it is
>correct, there is a possiblity that this can lead to exactly the situation
>we were trying to avoid.  If A cannot verify B's signature and B cannot
>verify A's signature.  What is to stop them from sending messages back and
>forth if some other item (such as a gateway) is also sticking in
signatures.
>
>
>11) Sec 4.1, 5th para: Please make the following change:
>
>OLD: "A recipient SHOULD only process an mlExpansionHistory attribute if
the
>recipient can verify the signature of the SignerInfo which covers the
>attribute. A recipient SHOULD NOT use an mlExpansionHistory attribute which
>the recipient cannot authenticate."
>
>NEW: "A recipient MUST verify the signature of the SignerInfo which covers
>an mlExpansionHistory attribute before processing it. A recipient MUST NOT
>process an mlExpansionHistory attribute which the recipient cannot
>authenticate."
>
>We perhaps should add a sentence along the lines of "If an
>mlExpansionHistory is found in a signature which cannot be verified, and no
>matching mlExpansionHistory is found in a verifiable signature, the MLA
>SHOULD stop processing."
>
>jim
>
>
>
>

Date: Mon, 16 Mar 1998 13:02:36 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: RE: Comments to MSG-02
Sender: [email-masked]

Jim,

I agree with Jim's comments and have the following further comment:

>13) Sec 3.2, 2nd para: Please make the following change: 
>
>OLD: "The contentInfo field of the carried CMS object always contains a MIME
>entity that is prepared as described in section 3.1. The contentInfo field
>must never be empty."
>
>NEW: "The carried CMS object always contains a MIME entity that is prepared
>as described in section 3.1.  Also, see Section 2.4.1 for instructions on
>including the id-data OID and MIME entity in the CMS objects."
>
>[Jim Schaad:  This is no longer as true of a statement.  Unless we are
>prepared to say that we are going to use a different mime type for items
>such as SignedData/Receipts.  I don't know that this should change or just
>be a gotta to future implementors.]

[JSP: How about this: "The carried CMS object always contains a MIME entity
that is prepared as described in section 3.1 except in the case of a
signedData encapsulating a Receipt content type (i.e. signed receipt).  See
Section 2.4.1 for instructions on including the id-data OID and MIME entity
in CMS objects.  See [ESS] for instructions regarding signed receipts."

- John Pawling

Date: Mon, 16 Mar 1998 12:53:32 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: RE: ESS-04 Comments
Sender: [email-masked]

Jim,

You make an excellent point, but I don't agree with your specific
recommendation because I don't believe that the MLA should reject a message
based on unauthenticated information.  I believe that the best way to
resolve this issue is to change ESS so that it requires that multiple
mlExpansionHistory attributes must be processed similar to multiple
eSSSecurityLabel attributes (except I don't believe that mlExpansionHistory
attributes MUST always be critical).  In addition to my original comments, I
propose the following changes to ESS, Sec 4.1:

1) Sec 4.1, 4th para, last sent: Please make the following change:

OLD: "Not all of the SignerInfos need to include mlExpansionHistory
attributes, but in all of the SignerInfos that do contain mlExpansionHistory
attributes, the mlExpansionHistory attributes MUST be identical."

NEW: "If any of the SignerInfos included in a SignedData object include an
mlExpansionHistory attribute, then all of the SignerInfos in that SignedData
object MUST include an mlExpansionHistory attribute and the value of each
MUST be identical."

2) Sec 4.1, 5th para: Please make the following change:  This replaces my
original comment 11:

OLD: "A recipient SHOULD only process an mlExpansionHistory attribute if the
recipient can verify the signature of the SignerInfo which covers the
attribute. A recipient SHOULD NOT use an mlExpansionHistory attribute which
the recipient cannot authenticate."

NEW: "A recipient MUST verify the signature of the SignerInfo which covers
the mlExpansionHistory attribute before processing it. A recipient MUST NOT
process an mlExpansionHistory attribute which the recipient has not verified."

These new comments combined with my original comments result in the
following text for the last three paragraphs in Sec 4.1:

"There can be multiple SignerInfos within a SignedData object, and each
SignerInfo may include authenticatedAttributes. Therefore, a single
SignedData object may include multiple SignerInfos, each SignerInfo having a
mlExpansionHistory attribute. For example, an MLA can send a signed message
with two SignerInfos, one containing a DSS signature, the other containing
an RSA signature. If any of the SignerInfos included in a SignedData object
include an mlExpansionHistory attribute, then all of the SignerInfos in that
SignedData object MUST include an mlExpansionHistory attribute and the value
of each MUST be identical.

A recipient MUST verify the signature of the SignerInfo which covers the
mlExpansionHistory attribute before processing it. A recipient MUST NOT
process an mlExpansionHistory attribute which the recipient has not been
verified.

When receiving a message that includes an outer SignedData object, a
receiving agent that processes mlExpansionHistory attributes MUST process
the mlExpansionHistory attribute, if present, in each SignerInfo in the
SignedData object for which it verifies the signature. This may result in
the receiving agent processing multiple mlExpansionHistory attributes
included in a single SignedData object. Because all mlExpansionHistory
attributes must be identical, the receiving application processes the first
mlExpansionHistory attribute that it encounters in a SignerInfo that it can
verify, and then ensures that all other mlExpansionHistory attributes in
signerInfos that it verifies are identical to the first one encountered.  If
the mlExpansionHistory attributes in the signerInfos that it verifies are
not all identical, then the receiving agent MUST stop processing the message
and MUST notify the user or MLA administrator of this error condition."

Does that sound meet your requirement?

- John Pawling

At 08:08 AM 3/16/98 -0800, Jim Schaad (Exchange) wrote:
>John,
>
>I have a small problem with the following change.  While I agree that it is
>correct, there is a possiblity that this can lead to exactly the situation
>we were trying to avoid.  If A cannot verify B's signature and B cannot
>verify A's signature.  What is to stop them from sending messages back and
>forth if some other item (such as a gateway) is also sticking in signatures.
>
>
>11) Sec 4.1, 5th para: Please make the following change:
>
>OLD: "A recipient SHOULD only process an mlExpansionHistory attribute if the
>recipient can verify the signature of the SignerInfo which covers the
>attribute. A recipient SHOULD NOT use an mlExpansionHistory attribute which
>the recipient cannot authenticate."
>
>NEW: "A recipient MUST verify the signature of the SignerInfo which covers
>an mlExpansionHistory attribute before processing it. A recipient MUST NOT
>process an mlExpansionHistory attribute which the recipient cannot
>authenticate."
>
>We perhaps should add a sentence along the lines of "If an
>mlExpansionHistory is found in a signature which cannot be verified, and no
>matching mlExpansionHistory is found in a verifiable signature, the MLA
>SHOULD stop processing."
>
>jim
>
>
>
>

Date: Mon, 16 Mar 1998 08:27:51 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: ESS-04 Comments 
Sender: [email-masked]

>The final boundary lines in the first example in section 1.2 (i.e. the
>third --innerboundary and the third --outerboundary) should end in the
>delimiter -- (i.e. should read --innerboundary-- and --outerboundary--)

My hand-coded MIME leaves a bit to be desired! You can see why I rely on
programming tools....

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 16 Mar 1998 08:31:16 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: ESS-04 Comments
Sender: [email-masked]

At 08:08 AM 3/16/98 -0800, Jim Schaad (Exchange) wrote:
>I would prefer not to have the version be imported if we are going to start
>using the enumerated list of version information.  If that is the case then
>I think that each draft should define its own version of version so that
>only the version numbers pertaining to the structures in the draft can be
>used.  I have no particular preference on either definition, just a
>preference that if the second one is used it be done explicitly in the ESS
>draft rather than importing from the CMS draft.

I'm not sure why you want us to redefine "Version" as an integer with
values of 1, 2, 3, and so on in each draft. Further, if someone compiles
all the modules together, their compiler should give them a warning (or
error!) that says Version is defined twice. That's why I'd like to just
import them from CMS, since ESS makes no sense without CMS.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Jim Schaad (Exchange)" <[email-masked]>
To: Paul Hoffman / IMC <[email-masked]>, [email-masked]
Subject: RE: ESS-04 Comments
Date: Mon, 16 Mar 1998 08:08:20 -0800
Sender: [email-masked]

I currently agree with Paul on this issue.  I see no special benefit in
adding the block delimiters.  Having the border down the side is sufficent
for me.

jim

-----Original Message-----
From: Paul Hoffman / IMC [mailto:[email-masked]]
Sent: Friday, March 13, 1998 5:31 PM
To: [email-masked]
Subject: Re: ESS-04 Comments

Somehow, I just knew that John would be the first one to jump in on the ESS
draft. :-)

>IMHO, Paul has done a miraculous job of incorporating the group's comments
>into ESS-04.

Hmmm. At the current rate of increase in your superlatives, I believe I
will turn into a diety before this becomes an RFC. At that point, I may
become less interested in these mundane earthly matters.

I agree with all of your requests except the following:

>2) Sec 1.2: I agree that the "|" characters delineate the encrypted data
>correctly and that the accompanying footnote explains that the encrypted
>data is encapsulated in an envelopedData block, but I believe that it is
>extremely useful to see the "envelopedData block" text as part of the
>"picture" to make it inherently obvious to even the most casual observer.

I disagree. In order to show a "block" you have to show the beginning and
end. That's why I used the characters at the right margin. If we list
"envelopedData block begin" and "envelopedData block end", it will add no
information other than what's in the right margin.

If you think it will be clearer to the most casual observer, I can move the
marks from the right margin to the left margin.

>4) Sec 1.2:  Same logic as Comment 2, please change the triple wrapped
>message example that uses application/pkcs7-mime for both signatures as
>follows:  

Same disagreeent as above.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Jim Schaad (Exchange)" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: Comments to MSG-02
Date: Mon, 16 Mar 1998 08:08:22 -0800
Sender: [email-masked]

John,

Some odd ball comments on your mail.  I have not looked carefully at the new
draft, but conversations with Blake have told me that my comments have not
yet been incorperated so I don't know its really worth my time for another
detailed review.

5) Sec 2.5.2: Jim Schaad commented (There was debate regarding this comment,
but I don't remember the answer.  Russ, I believe that you had the answer.
Can you please provide it.) 
"Section 2.5.2  This is a politics question and one I am not capable of
deciding.  Do we need to change from using the IMC as the registration agent
for the OIDs of SMIMECapabilites?  I don't see any techincal reasons to
change this at this point in time.  I don't see IMC as disappearing any time
soon and from what I hear it would be much faster to get updates than using
IANA.  But I don't know if the IESG will be willing to leave this as it is."

[Jim Schaad:  This should remain as it is in the original.  Russ is the
authority for assigning OIDs in the S/MIME arc and IMC is just acting as a
publishing agent.  No problems here]

12) Sec 3, first para: Please add as last sentences: "The Enhanced Security
Services for S/MIME [ESS] document provides examples of how nested, secured
S/MIME messages are formatted.  For example, there is an example of how a
triple-wrapped S/MIME message is formatted using multipart/signed and
application/pkcs7-mime for the signatures."

[Jim Schaad:  Lets change this slightly.  "For example, there is an example"
should be "ESS provides an example...".]

13) Sec 3.2, 2nd para: Please make the following change: 

OLD: "The contentInfo field of the carried CMS object always contains a MIME
entity that is prepared as described in section 3.1. The contentInfo field
must never be empty."

NEW: "The carried CMS object always contains a MIME entity that is prepared
as described in section 3.1.  Also, see Section 2.4.1 for instructions on
including the id-data OID and MIME entity in the CMS objects."

[Jim Schaad:  This is no longer as true of a statement.  Unless we are
prepared to say that we are going to use a different mime type for items
such as SignedData/Receipts.  I don't know that this should change or just
be a gotta to future implementors.]

25) Sec 4, 1rst para, last sent: 

OLD: "S/MIME certification issues are covered in a different document."

NEW: "S/MIME certification issues are covered in the "S/MIME Version 3
Certificate Handling [CERT3]" document."

[Jim Schaad] Don't put in the name here just the [CERT3] reference.  This
appears to be the standard method we are using in these docs.  "covered in
the [CERT3] document."

30) App D: Recommend deleting Appendix D because it is out of date and is
not needed, IMHO.
[Jim Schaad: I agree -- we don't need to do this since the history of RFCs
is now present.  However intro sections MUST say that this document
obsoletes [SMIME2].]

From: "Jim Schaad (Exchange)" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: ESS-04 Comments
Date: Mon, 16 Mar 1998 08:08:21 -0800
Sender: [email-masked]

John,

I have a small problem with the following change.  While I agree that it is
correct, there is a possiblity that this can lead to exactly the situation
we were trying to avoid.  If A cannot verify B's signature and B cannot
verify A's signature.  What is to stop them from sending messages back and
forth if some other item (such as a gateway) is also sticking in signatures.

11) Sec 4.1, 5th para: Please make the following change:

OLD: "A recipient SHOULD only process an mlExpansionHistory attribute if the
recipient can verify the signature of the SignerInfo which covers the
attribute. A recipient SHOULD NOT use an mlExpansionHistory attribute which
the recipient cannot authenticate."

NEW: "A recipient MUST verify the signature of the SignerInfo which covers
an mlExpansionHistory attribute before processing it. A recipient MUST NOT
process an mlExpansionHistory attribute which the recipient cannot
authenticate."

We perhaps should add a sentence along the lines of "If an
mlExpansionHistory is found in a signature which cannot be verified, and no
matching mlExpansionHistory is found in a verifiable signature, the MLA
SHOULD stop processing."

jim

From: "Jim Schaad (Exchange)" <[email-masked]>
To: Paul Hoffman / IMC <[email-masked]>, [email-masked]
Subject: RE: ESS-04 Comments
Date: Mon, 16 Mar 1998 08:08:21 -0800
Sender: [email-masked]

I would prefer not to have the version be imported if we are going to start
using the enumerated list of version information.  If that is the case then
I think that each draft should define its own version of version so that
only the version numbers pertaining to the structures in the draft can be
used.  I have no particular preference on either definition, just a
preference that if the second one is used it be done explicitly in the ESS
draft rather than importing from the CMS draft.

jim

-----Original Message-----
From: Paul Hoffman / IMC [mailto:[email-masked]]
Sent: Friday, March 13, 1998 7:47 PM
To: [email-masked]
Subject: Re: ESS-04 Comments

>I think it would be clearer if we changed the definition of "Version" in
>smime-cms from:
>
>	Version ::= INTEGER
>to
>	Version ::= INTEGER { v1(1), v2(2) }

This is fine with me, although we need to add "v3(3)" since CMS has many
things that have versions that must be 3. I'd actually prefer this, so that
ESS simply IMPORTS Version and doesn't have to define anything new.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Jim Schaad (Exchange)" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: CERT-02 Comments
Date: Mon, 16 Mar 1998 08:08:22 -0800
Sender: [email-masked]

John,

1) Sec 1, 1rst para: Please make the following change: 

OLD: "In order to validate the keys of a message sent to it, an S/MIME agent
needs to certify that the key is valid. This draft describes the mechanisms
S/MIME uses to create and validate keys using certificates."

NEW: "Before using a public key to provide security services, the S/MIME
agent MUST certify that the public key is valid.  S/MIME agents MUST use
X.509 certificates to validate public keys as described in the ITU-T
Recommendation X.509 (1997) [X.509] and the Internet Public Key
Infrastructure (PKIX) X.509 Certificate and CRL Profile [KEYM].  S/MIME
agents MUST meet the S/MIME-specific requirements documented in this I-D in
addition to those stated in [X.509] and [KEYM]." 
[Jim Schaad:  What is the benifit of putting in the ITU-T reference?  Is it
not sufficent to reference just PKIX?]

10) Sec 4.2, 1rst para, last sent: Please  change: 

OLD: "This is necessary when a) verifying a signature from a correspondent
and, b) creating a digital envelope with the correspondent as the intended
recipient."

NEW: "This is necessary before using a public key to provide security
services such as: verifying a signature; encrypting a content-encryption key
(ex: RSA); or forming a pairwise symmetric key (ex: Diffie-Hellman) to be
used to encrypt or decrypt a content-encryption key."
[Jim Schaad:  Please remove "or decrypt" in the last sentence.  In some
circumstances there is no need to verify the senders certificate for a
simple decryption operation.  What do I care if the sender's certificate has
been revoked, it will still decrypt and that is all I care about.
Encryption does not carry any information about authentication.]

12) Sec 4.4.3.  Recommend deleting this TBD section, because subjectAltName
is described in PKIX I.
[Jim Schaad:  I disagree with this.  Specifically we should state that this
is the place to put the RFC 822 name again.]

14) Appendix D, Please delete this entire Appendix because it is out of date
and not needed.
[Jim Schaad:  Again this is fine with the caveat that we should obsolete the
SMIME2 spec in the intro.]

15) App F, Needed changes:

Algorithms for certs
JSP: This is specified in PKIX I, so please delete this bullet.

Names for chaining
JSP: IMHO, the existing text is fine, so please delete this bullet.
Jim Schaad: I am not sure that I agree with this.  There are now more ways
of chaining and we should add these in or at least acknowledge them.

Rewrite 5.2 for CMP and id-dsa-with-sha1
JSP: This section is gone, so please delete this bullet.

Make references [PKCS-*] consistent with smime-msg spec
JSP: Please incorporate aforementioned related comment and then please
delete this bullet.

2.2.1 -- are they "proposed" revisions, or actual revisions? 
JSP: Please incorporate aforementioned related comment and then please
delete this bullet.

Section A.7 -- bit 7 is encipherOnly, bit 8 is decipherOnly.  Are we going
to use these?
JSP: Please incorporate aforementioned related comment and then please
delete this bullet.

Challenge password -- CHOICE should be tagged for assigning values, and
should UTF8 should be an option? 
JSP: Challenge password has been deprecated from the S/MIME v3 specs, so
please delete this bullet.

A.7 -- certificate extensions.  Are we keeping this up-to-date, or do we
just refer to PKIX? 
JSP: Please incorporate aforementioned related comment and then please
delete this bullet.

subjectAltName is an extension -- we need to deal with it as such
JSP: This is specified in PKIX I, so please delete this bullet.
Jim Schaad:  I disagree with this, we should have some minimal text to cover
this extension and what we expect to see.

Key usage for signing / encrypting certificate explanation
JSP: Please incorporate aforementioned related comment and then please
delete this bullet.

RFC # for PKCS #1
JSP: Is this really necessary for the CERT I-D to move forward?? If not,
please delete this bullet.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-ess-04.txt
Date: Mon, 16 Mar 1998 08:57:19 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Enhanced Security Services for S/MIME
	Author(s)	: P. Hoffman
	Filename	: draft-ietf-smime-ess-04.txt
	Pages		: 29
	Date		: 13-Mar-98
	
This document describes three optional security service extensions for
S/MIME. These services provide functionality that is similar to the Message
Security Protocol [MSP], but are useful in many other environments,
particularly business and finance. The services are:
- signed receipts
- security labels
- secure mailing lists

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-ess-04.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-ess-04.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-ess-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-ess-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-ess-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 16 Mar 1998 08:34:36 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: ESS/CMS ANY DEFINED BY
Sender: [email-masked]

Bancroft,

It is fine with me if ESS SecurityCategory is changed to:

SecurityCategory ::= SEQUENCE {
  type  [0] OBJECT IDENTIFIER,
  value [1] ANY DEFINED BY type
}

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

Date: Mon, 16 Mar 1998 08:29:28 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: ESS-04 Comments
Sender: [email-masked]

Paul,

I agree with your response to my comments 2 and 4, please disregard them.  

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

Date: Mon, 16 Mar 1998 08:28:08 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: CMS Version (was Re: ESS-04 Comments)
Sender: [email-masked]

Bancroft, Paul and friends,

I agree with your comments.  CMS uses the values 0 and 3, so the definition
needs to be:

Version ::= INTEGER { v0(0), v1(1), v2(2), v3(3) }

Russ: Please note that this is a proposed change to CMS.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

At 07:47 PM 3/13/98 -0800, Paul Hoffman / IMC wrote:
>>I think it would be clearer if we changed the definition of "Version" in
>>smime-cms from:
>>
>>	Version ::= INTEGER
>>to
>>	Version ::= INTEGER { v1(1), v2(2) }
>
>This is fine with me, although we need to add "v3(3)" since CMS has many
>things that have versions that must be 3. I'd actually prefer this, so that
>ESS simply IMPORTS Version and doesn't have to define anything new.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
>

To: [email-masked]
Subject: Re: ESS-04 Comments 
Date: Mon, 16 Mar 1998 12:39:59 +0000
From: Andrew Farrell <[email-masked]>
Sender: [email-masked]

A comment of Jim Schaad's not picked up by either Paul or John:

The final boundary lines in the first example in section 1.2 (i.e. the
third --innerboundary and the third --outerboundary) should end in the
delimiter -- (i.e. should read --innerboundary-- and --outerboundary--)

Andrew.

Date: Fri, 13 Mar 1998 23:10:46 -0500 (EST)
From: Bancroft Scott <[email-masked]>
To: [email-masked]
Subject: ESS/CMS ANY DEFINED BY
Sender: [email-masked]

Paul,

In the ESS doc there is:

	SecurityCategory ::= SEQUENCE {
	  type  [0] OBJECT IDENTIFIER,
	  value [1] ANY -- defined by type
	}

while in the CMS doc there is:

	OtherKeyAttribute ::= SEQUENCE {
	  keyAttrId OBJECT IDENTIFIER,
	  keyAttr ANY DEFINED BY keyAttrId OPTIONAL
	}

What's the rationale for using "-- defined by type" in the ESS doc?  Why
not use the ASN.1 syntax "ANY DEFINED BY type" as is used in the CMS doc?

--------------------------------------------------------------------------
Bancroft Scott                                Toll Free    :1-888-OSS-ASN1
Open Systems Solutions, Inc.                  International:1-609-987-9073
[email-masked]                                  Tech Support :1-732-249-5107
http://www.oss.com                            Fax          :1-732-249-4636

Date: Fri, 13 Mar 1998 19:47:12 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: ESS-04 Comments
Sender: [email-masked]

>I think it would be clearer if we changed the definition of "Version" in
>smime-cms from:
>
>	Version ::= INTEGER
>to
>	Version ::= INTEGER { v1(1), v2(2) }

This is fine with me, although we need to add "v3(3)" since CMS has many
things that have versions that must be 3. I'd actually prefer this, so that
ESS simply IMPORTS Version and doesn't have to define anything new.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 13 Mar 1998 21:17:33 -0500 (EST)
From: Bancroft Scott <[email-masked]>
To: John Pawling <[email-masked]>
Cc: [email-masked]
Subject: Re: ESS-04 Comments
Sender: [email-masked]

On Fri, 13 Mar 1998, John Pawling wrote:

> 10) Sec 3.2 and App A: Please define "v1" and "v2" referred to in
> ESSSecurityLabel and ESSPrivacyMark syntaxes.  Recommend the following:
> 
> v1 INTEGER ::= 1
> v2 INTEGER ::= 2

I think it would be clearer if we changed the definition of "Version" in
smime-cms from:

	Version ::= INTEGER
to
	Version ::= INTEGER { v1(1), v2(2) }

Doing so makes clear in the definition of Version that the currently
expected values are v1 and v2, while allowing other "NamedNumbers" to be
added in the future.  It tightly relates the version numbers v1 and v2
to Version, as opposed to directly defining v1 and v2 as valuereferences.

--------------------------------------------------------------------------
Bancroft Scott                                Toll Free    :1-888-OSS-ASN1
Open Systems Solutions, Inc.                  International:1-609-987-9073
[email-masked]                                  Tech Support :1-732-249-5107
http://www.oss.com                            Fax          :1-732-249-4636

Date: Fri, 13 Mar 1998 17:31:15 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: ESS-04 Comments
Sender: [email-masked]

Somehow, I just knew that John would be the first one to jump in on the ESS
draft. :-)

>IMHO, Paul has done a miraculous job of incorporating the group's comments
>into ESS-04.

Hmmm. At the current rate of increase in your superlatives, I believe I
will turn into a diety before this becomes an RFC. At that point, I may
become less interested in these mundane earthly matters.

I agree with all of your requests except the following:

>2) Sec 1.2: I agree that the "|" characters delineate the encrypted data
>correctly and that the accompanying footnote explains that the encrypted
>data is encapsulated in an envelopedData block, but I believe that it is
>extremely useful to see the "envelopedData block" text as part of the
>"picture" to make it inherently obvious to even the most casual observer.

I disagree. In order to show a "block" you have to show the beginning and
end. That's why I used the characters at the right margin. If we list
"envelopedData block begin" and "envelopedData block end", it will add no
information other than what's in the right margin.

If you think it will be clearer to the most casual observer, I can move the
marks from the right margin to the left margin.

>4) Sec 1.2:  Same logic as Comment 2, please change the triple wrapped
>message example that uses application/pkcs7-mime for both signatures as
>follows:  

Same disagreeent as above.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 13 Mar 1998 19:45:40 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: ESS-04 Comments
Sender: [email-masked]

All,

IMHO, Paul has done a miraculous job of incorporating the group's comments
into ESS-04.  I have the following comments regarding the 12 Mar 98 ESS-04 I-D:

1) Sec 1: Please change "[MSP]" to "[MSP4]".

2) Sec 1.2: I agree that the "|" characters delineate the encrypted data
correctly and that the accompanying footnote explains that the encrypted
data is encapsulated in an envelopedData block, but I believe that it is
extremely useful to see the "envelopedData block" text as part of the
"picture" to make it inherently obvious to even the most casual observer.
Please change the triple wrapped message example that uses multipart/signed
for both signatures as follows:  

After [step 6] please add:

[step 5] envelopedData block                            )
[step 5]                                              | )

3) Sec 1.2:  Please change the triple wrapped message example that uses
multipart/signed for both signatures as follows:  

OLD:  [step 7] outer signedData block

NEW:  [step 7] outer signedData block (eContent is missing) 

4) Sec 1.2:  Same logic as Comment 2, please change the triple wrapped
message example that uses application/pkcs7-mime for both signatures as
follows:  

After [step 6] please add:

[step 5] envelopedData block                          )  O
[step 5]                                           |  )  O

5) Sec 1.3.4, Table: Please add "sMIMEEncryptionKeyPreference | id-TBD [MSG]
| either | yes".  OID not yet assigned.

6) Sec 1.3.4, Table: Please add "signingCertificate | id-TBD [CMS] | either
| yes".  OID not yet assigned.

7) Sec 2.3, 2nd para: Please make the following change:

OLD: "Because all receiptRequest attributes in a SignedData object must be
identical, the receiving application fully processes (as described in the
following paragraphs) the first receiptRequest that it encounters in a
SignerInfo that it can verify, and it then ensures that all other
receiptRequests are identical to the first one encountered.  If
ReceiptRequests which conflict are present, then the processing software
MUST NOT return any receipt."

NEW: "Before processing a receiptRequest authenticatedAttribute, the
receiving agent MUST verify the signature of the SignerInfo which covers the
receiptRequest attribute. A recipient MUST NOT process a receiptRequest
attribute that has not been verified.  Because all receiptRequest attributes
in a SignedData object must be identical, the receiving application fully
processes (as described in the following paragraphs) the first
receiptRequest attribute that it encounters in a SignerInfo that it
verifies, and it then ensures that all other receiptRequest attributes in
signerInfos that it verifies are identical to the first one encountered.  If
verified ReceiptRequest attributes which conflict are present, then the
processing software MUST NOT return any signed receipt.  A signed receipt
SHOULD be returned if any signerInfo containing a receiptRequest attribute
can be validated, even if other signerInfos containing the same
receiptRequest attribute cannot be validated because they are signed using
an algorithm not supported by the receiving agent."

8) Sec 2.3, 3rd para: Please delete the last sentence because it is now part
of the 2nd paragraph: "A receipt SHOULD be returned if any signature
containing a receipt request can be validated, even if other signatures
containing the same receipt request cannot be validated."

9) Sec 3.1.2, Please add as 3rd para:  (This text was included in ESS-03,
but was mistakenly deleted from ESS-04.)

"Receiving agents SHOULD have a local policy regarding whether or not to
show the inner content of a signedData object that includes an
eSSSecurityLabel security-policy-identifier that the processing software
does not recognize.  If the receiving agent does not recognize the
eSSSecurityLabel security-policy-identifier value, then it SHOULD stop
processing the message and indicate an error."

10) Sec 3.2 and App A: Please define "v1" and "v2" referred to in
ESSSecurityLabel and ESSPrivacyMark syntaxes.  Recommend the following:

v1 INTEGER ::= 1
v2 INTEGER ::= 2

11) Sec 4.1, 5th para: Please make the following change:

OLD: "A recipient SHOULD only process an mlExpansionHistory attribute if the
recipient can verify the signature of the SignerInfo which covers the
attribute. A recipient SHOULD NOT use an mlExpansionHistory attribute which
the recipient cannot authenticate."

NEW: "A recipient MUST verify the signature of the SignerInfo which covers
an mlExpansionHistory attribute before processing it. A recipient MUST NOT
process an mlExpansionHistory attribute which the recipient cannot
authenticate."

12) Sec 4.1, last para, last sent: Please change:

OLD: "and then ensures that all other mlExpansionHistory attributes are
identical to the first one encountered."

NEW: "and then ensures that all other mlExpansionHistory attributes in
signerInfos that it verifies are identical to the first one encountered.  If
the mlExpansionHistory attributes in the signerInfos that it verifies are
not all identical, then the receiving agent MUST stop processing the message
and MUST notify the user or MLA administrator of this error condition."

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

Date: Fri, 13 Mar 1998 15:33:50 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: CERT-02 Comments
Sender: [email-masked]

All,

First, I want to thank Blake for incorporating the majority of my previous
comments into the March 11, 1998, S/MIME V3 Certificate Handling
Specification.  I have the following comments.  I have also taken the
liberty to include comments submitted by others that I believe have achieved
WG consensus, but were not included in CERT-02.  Recommend that everybody
should look at this list to ensure that they agree with the comments and
that I did not omit a comment:

1) Sec 1, 1rst para: Please make the following change: 

OLD: "In order to validate the keys of a message sent to it, an S/MIME agent
needs to certify that the key is valid. This draft describes the mechanisms
S/MIME uses to create and validate keys using certificates."

NEW: "Before using a public key to provide security services, the S/MIME
agent MUST certify that the public key is valid.  S/MIME agents MUST use
X.509 certificates to validate public keys as described in the ITU-T
Recommendation X.509 (1997) [X.509] and the Internet Public Key
Infrastructure (PKIX) X.509 Certificate and CRL Profile [KEYM].  S/MIME
agents MUST meet the S/MIME-specific requirements documented in this I-D in
addition to those stated in [X.509] and [KEYM]." 

2) Sec 1, 3rd para: Please delete the following paragraph because it is
ambiguous and the previous comment will replace this para:
"In order to handle S/MIME certificates, an agent has to follow
specifications in this draft, as well as some of the specifications listed
in the following documents:
 - "PKCS #1: RSA Encryption", [PKCS-1].
 - "Cryptographic Message Syntax", [CMS]."

3) Sec 1.1, certificate definition, last sent: Please add "and extensions as
defined in [KEYM]." to the following sentence: "This type also contains the
distinguished name of the certificate issuer (the signer), an
issuer-specific serial number, the issuer's signature algorithm identifier,
and a validity period."
 
4) Sec 1.1, CRL definition, 2nd sent: Please add "and extensions as defined
in [KEYM]." to the following sentence: "The information consists of an
issuer name, the time of issue, the next scheduled time of issue, and a list
of certificate serial numbers and their associated revocation times."

5) Sec 2.2, first para: Please change "MUST" to "MAY" in "End entity
certificates MUST include an Internet mail address" 

6) Sec 2.2.1, first sent: Jim Schaad commented: "-- There are now three
different certificate formats supported by CMS.  Please add attribute
certificates to the list."

7) Sec 2.2.1, 3rd sent: similar to Jim Schaad's comment:  Please change:

OLD: "In addition, proposed revisions of X.509 certificates address much of
the same functionality and flexibility as was intended in the PKCS #6."

NEW: "In addition, v3 X.509 certificate extensions address much of the same
functionality and flexibility as was intended in the PKCS #6."

8) Sec 3.1, last para: This change is required because it is impossible for
a subject or issuer name to have the value of ASN.1 NULL. The subject DN in
a user's (i.e. end-entity) certificate MAY be an empty SEQUENCE.  Please
change:  

OLD: "All subject and issuer names MUST be non-NULL in S/MIME-compliant v3
X.509 Certificates, except that the subject DN in a user's (i.e. end-entity)
certificate MAY be NULL in which case the subjectAltName extension will
include the subject's identifier and MUST be marked as critical."  

NEW: "All subject and issuer names MUST be populated (i.e. not an empty
SEQUENCE) in S/MIME-compliant v3 X.509 Certificates, except that the subject
DN in a user's (i.e. end-entity) certificate MAY be an empty SEQUENCE in
which case the subjectAltName extension will include the subject's
identifier and MUST be marked as critical."

9) Sec 4, intro, last para, 1rst sent: Please replace "PKCS #7" with "CMS".

10) Sec 4.2, 1rst para, last sent: Please  change: 

OLD: "This is necessary when a) verifying a signature from a correspondent
and, b) creating a digital envelope with the correspondent as the intended
recipient."

NEW: "This is necessary before using a public key to provide security
services such as: verifying a signature; encrypting a content-encryption key
(ex: RSA); or forming a pairwise symmetric key (ex: Diffie-Hellman) to be
used to encrypt or decrypt a content-encryption key."

11) Sec 4.4.2, last para:  Please add: "If the keyUsage keyAgreement bit is
set to 1 AND if the public key is to be used to form a pairwise key to
decrypt data, then the S/MIME agent MUST only use the public key if the
keyUsage encipherOnly bit is set to 0.  If the keyUsage keyAgreement bit is
set to 1 AND if the key is to be used to form a pairwise key to encrypt
data, then the S/MIME agent MUST only use the public key if the keyUsage
decipherOnly bit is set to 0."

12) Sec 4.4.3.  Recommend deleting this TBD section, because subjectAltName
is described in PKIX I.

13) Appendix A, Please delete this entire Appendix because it is redundant
to info contained in PKIX I.  Also, it includes an obsolete definition of
keyUsage.

14) Appendix D, Please delete this entire Appendix because it is out of date
and not needed.

15) App F, Needed changes:

Algorithms for certs
JSP: This is specified in PKIX I, so please delete this bullet.

Names for chaining
JSP: IMHO, the existing text is fine, so please delete this bullet.

Rewrite 5.2 for CMP and id-dsa-with-sha1
JSP: This section is gone, so please delete this bullet.

Make references [PKCS-*] consistent with smime-msg spec
JSP: Please incorporate aforementioned related comment and then please
delete this bullet.

2.2.1 -- are they "proposed" revisions, or actual revisions? 
JSP: Please incorporate aforementioned related comment and then please
delete this bullet.

Section A.7 -- bit 7 is encipherOnly, bit 8 is decipherOnly.  Are we going
to use these?
JSP: Please incorporate aforementioned related comment and then please
delete this bullet.

Challenge password -- CHOICE should be tagged for assigning values, and
should UTF8 should be an option? 
JSP: Challenge password has been deprecated from the S/MIME v3 specs, so
please delete this bullet.

A.7 -- certificate extensions.  Are we keeping this up-to-date, or do we
just refer to PKIX? 
JSP: Please incorporate aforementioned related comment and then please
delete this bullet.

subjectAltName is an extension -- we need to deal with it as such
JSP: This is specified in PKIX I, so please delete this bullet.

Key usage for signing / encrypting certificate explanation
JSP: Please incorporate aforementioned related comment and then please
delete this bullet.

RFC # for PKCS #1
JSP: Is this really necessary for the CERT I-D to move forward?? If not,
please delete this bullet.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

Date: Fri, 13 Mar 1998 09:54:10 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: RE: Inclusion of the issuer and serial number in authenticated in formation
Sender: [email-masked]

> From: [email-masked] (John Pawling)
> 
> Jim,
> 
> In your reply to my message you said: "Specifically there is nothing that
> prevents a CA from issing a new certificate with the same serial number and
> issuer name, but different extensions."  I respectfully disagree with this
> statement, because X.509, verse 3.3.24, defines serial number as follows:
> "certificate serial number:  An integer value, unique within the issuing CA,
> which is unambiguously associated with a certificate issued by that CA." 

Perhaps "nothing" is too strong a word, but when the issue is
cryptographic binding of a certificate chain into the signed data,
the fact is that a rogue CA could do something against the rules.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cert-02.txt
Date: Fri, 13 Mar 1998 08:39:27 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: S/MIME Version 3 Certificate Handling
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-cert-02.txt
	Pages		: 11
	Date		: 12-Mar-98
	
S/MIME (Secure/Multipurpose Internet Mail Extensions), described in
[SMIME-MSG], provides a method to send and receive secure MIME
messages. In order to validate the keys of a message sent to it, an
S/MIME agent needs to certify that the key is valid. This draft
describes the mechanisms S/MIME uses to create and validate keys using
certificates.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-cert-02.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-cert-02.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-cert-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cert-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-cert-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-msg-02.txt
Date: Fri, 13 Mar 1998 08:39:15 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: S/MIME Version 3 Message Specification
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-msg-02.txt
	Pages		: 25
	Date		: 12-Mar-98
	
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
consistent way to send and receive secure MIME data. Based on the
popular Internet MIME standard, S/MIME provides the following
cryptographic security services for electronic messaging applications:
authentication, message integrity and non-repudiation of origin (using
digital signatures) and privacy and data security (using encryption).

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-msg-02.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-msg-02.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-msg-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-msg-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-msg-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Fri, 13 Mar 1998 08:18:06 -0500
To: "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Inclusion of the issuer and serial number in authenticated in formation
Sender: [email-masked]

Jim,

I agree with your original proposal which was: "Signing-certficate attribute
value has the ASN.1 type IssuerAndSerialNumber."     I agree with Blake that
carrying the IssuerAndSerialNumber for each issuer cert in the signer's cert
path is not needed.  Furthermore, once the app has obtained the signer's
cert, then the issuer name and authorityKeyIdentifier extension, if present,
in the signer's cert can be used to identify the CA cert.  If the
authorityKeyIdentifier extension is not present in the signer's cert and
there are multiple CA certs with the same subject DN, then the app will have
to use the trial and error method described by Blake.  

In your reply to my message you said: "Specifically there is nothing that
prevents a CA from issing a new certificate with the same serial number and
issuer name, but different extensions."  I respectfully disagree with this
statement, because X.509, verse 3.3.24, defines serial number as follows:
"certificate serial number:  An integer value, unique within the issuing CA,
which is unambiguously associated with a certificate issued by that CA." 

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

Date: Thu, 12 Mar 1998 19:56:01 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Draft -04 of ESS
Sender: [email-masked]

Hi again. I've updated the web site with the newest version of ESS (which
has also been turned into the Internet Drafts editor). You should flush
your brower cache before trying to retrieve it. It's at
<http://www.imc.org/draft-ietf-smime-ess>.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Inclusion of the issuer and serial number in authenticated in formation
Date: Thu, 12 Mar 1998 18:50:57 -0800
Sender: [email-masked]

John,

I don't think you are being fickle,  I thought hard about it before I
endorsed the expacted proposal.  I decided that the additional capability
did not hurt anything since only one item was required (as oppose the entire
chain).  

I think that my original proposal actually addressed the issue that I was
worried about and is sufficent for that.  I think that for the issued raised
by Denis and some others in private mail is not really addressed by the
sequence approach.  Specifically there is nothing that prevents a CA from
issing a new certificate with the same serial number and issuer name, but
different extensions.  I don't know if this is really a problem that needs
to be solved or should be solved at this time by us.  This really requires a
sequece of both issuer/serial number and hash of the certificate pairs to
say that this is the certificate I wanted to use and you can see that the
certificate has not been changed in anyway.

I can easily go either way with this issue as the full sequence is not
required by the proposal that Denis made, and thus the minimal version of
this extension solves my problem and that is really all that I cared about.

jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 12, 1998 4:16 PM
To: Ietf-Smime (E-mail)
Subject: RE: Inclusion of the issuer and serial number in authenticated
in formation

All,

I apologize for being fickle, but I agree with Blake's most excellent
argument that the "Signing Certificate Attribute" should only contain the
IssuerAndSerialNumber of the signer's cert and should not be a SEQUENCE OF
IssuerAndSerialNumber.  Once the app has obtained the signer's cert, it will
very probably include an authorityKeyIdentifier extension that includes the
IssuerAndSerialNumber of the issuer's cert, so the app can identify the
issuer's cert in that manner.  In summary, I agree with Jim's original
proposal.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

Date: Thu, 12 Mar 1998 19:16:08 -0500
To: "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Inclusion of the issuer and serial number in authenticated in formation
Sender: [email-masked]

All,

I apologize for being fickle, but I agree with Blake's most excellent
argument that the "Signing Certificate Attribute" should only contain the
IssuerAndSerialNumber of the signer's cert and should not be a SEQUENCE OF
IssuerAndSerialNumber.  Once the app has obtained the signer's cert, it will
very probably include an authorityKeyIdentifier extension that includes the
IssuerAndSerialNumber of the issuer's cert, so the app can identify the
issuer's cert in that manner.  In summary, I agree with Jim's original proposal.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

Date: Thu, 12 Mar 1998 18:26:52 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Comments to MSG-02
Sender: [email-masked]

All,

First, I want to thank Blake for incorporating my previous comments into the
March 11, 1998, S/MIME V3 Message Specification.  I have some new comments
as follows.  I have also taken the liberty to include comments submitted by
others that I believe have achieved WG consensus, but were not included in
MSG-02.  Recommend that everybody should look at this list to ensure that
they agree with the comments and that I did not omit a comment:

1) Sec 2.1, 1rst sent: Please replace "Receiving agents MUST support SHA-1
[SHA1]." with "Sending and receiving agents MUST support SHA-1 [SHA1]."

2) Sec 2.4.1: Please make the following change: 

OLD: "Sending agents MUST use the "data" content type as the content within
other content types to indicate the message content which has had security
services applied to it." 

NEW: "Sending agents MUST use the id-data content type identifier to
indicate the message content which has had security services applied to it.
For example, when applying a digital signature to MIME data, the CMS
signedData encapContentInfo eContentType MUST include the id-data object
identifier and the MIME content MUST be stored in the SignedData
encapContentInfo eContent OCTET STRING.  As another example, when applying
encryption to MIME data, the CMS EnvelopedData encryptedContentInfo
ContentType MUST include the id-data object identifier and the encrypted
MIME content MUST be stored in the envelopedData encryptedContentInfo
encryptedContent OCTET STRING."

3) Sec 2.5, para 3: Jim Schaad commented:
"Section 2.5  paragraph 3.  Encryption Key Preference is not an attribute
that is needed by all senders of S/MIME messages.  I suggest we change this
to: "Sending agents SHOULD be able to generate one instance of each of the
signed attributes described in this section, and SHOULD include the signing
time and SMIMEcapabilities attributes in each signed message sent."

4) Sec 2.5.1:  Please make the following change: 

OLD: "Agents MUST interpret the year field (YY) as follows:"

NEW: "When the UTCTime CHOICE is used, agents MUST interpret the year field
(YY) as follows:"

5) Sec 2.5.2: Jim Schaad commented (There was debate regarding this comment,
but I don't remember the answer.  Russ, I believe that you had the answer.
Can you please provide it.) 
"Section 2.5.2  This is a politics question and one I am not capable of
deciding.  Do we need to change from using the IMC as the registration agent
for the OIDs of SMIMECapabilites?  I don't see any techincal reasons to
change this at this point in time.  I don't see IMC as disappearing any time
soon and from what I hear it would be much faster to get updates than using
IANA.  But I don't know if the IESG will be willing to leave this as it is."

6) Sec 2.5.2: Jim Schaad commented:   
"Section 2.5.2  I guess this is really an issue for Paul as the owner of the
SMIMECapabilites list.   I hearby request that a new capability be added to
the list called "smimeVersions".   This will have a content of a single
integer which will contain the version number of the highest S/MIME
specification understandable by the client.  I hearby designate [SMIMEV2] to
have the number 2 and this draft to have the number 3.  This will allow for
sending MUAs to be able to prevent sending critical attributes to clients
which will not understand them.  This will also address any new
incompatabilies placed in the S/MIME specifications at a later time."

7) Sec 2.6, first para, every sent: Paul Hoffman wrote: 
"Related to this, the paragraph at the beginning of 2.6 should have "Sending
and receiving..." at the beginning of each of the sentences. The "Receiving"
only is an artifact from our wigglywaggling in S/MIME v2."

8) Sec 2.6.1, last para: Please replace "2.6.2.1 through 2.6.2.4" with
"2.6.1.1 through 2.6.1.4" and re-number the sections accordingly.

9) Section 2.6.2.3 and 2.6.2.4: Jim Schaad commented:
"Section 2.6.2.3 and 2.6.2.4.  The wording no longer works for these two
sections now that 3DES is a must and RC2/40 is an optional.  I have switched
the order of the rules as tripleDES is now a MUST algorithm and is therefore
by definition supported, but we know that not everyone does support it.  I
suggest that these sections be re-written as follows:

	"2.6.1.3 Rule 3: Low Encryption Interopt Mode

	If:
	 - the sending agent has no knowledge of the encryption
            capabilities of the recipient,
	 - and the sending agent has reason to believe that the 
            recipient does not support high level encryption,
	    then the sending agent SHOULD use RC2/40.

	2.6.1.4  Rule 4: Unknown Capabilities

	If:
	 - the sending agent has no knowledge of the encryption 
            capabilities of the recipient, then the sending agent MUST 
            use tripleDES."

10) Section 2.6.4: Jim Schaad commented:
"Insert a new section 2.6.4 with the following text.
"Section 2.6.4  Selecting a Recipients Encryption Certificate

The use of the MUST algorithms in this specification lead to the problem of
given a user's signing certificate from a signed message, how is the
encryption certificate determined.  Since the signing and key exchange
algorithms will no longer use the same certificates.

Section 2.5 defines a method by which a sending agent can optionally
announce what its perfered key-exchange certificate is.  The following
method for processing and remembering the encryption certificate attribute
in incoming signed messages SHOULD be used.

If an Encryption Key preference attribute is found in a message, this is the
certificate that should be associated as the encryption certificate for the
user.

If no Encrytion Key preference attribute is found in a message, the set of
certificates should be searched for a certificate with the same DN as the
signing certificate which can be used for encryption.  If no certificate is
found, then encryption cannot be done with the signer of the message.  If
multiple certificates are found, the MUA can make an arbitrary choice
between them. 

- If the receiving agent has not yet done an association for the sender's
encryption certificate, then, after verifiying the signature on the incoming
message and checking the timestamp, the receiving agent SHOULD create a new
associaiton containing the signing time and the encryption certificate.

- If such an association already exists, the receiving agent SHOULD verify
that the signing time in the incoming message is greater than the signing
time stored in the association and that the signature is valid.  If so, the
receiving agent SHOULD update both the signing time and the encryption
certificate association.  Values of the signing time that lie far in the
future (that is, a greater discrepancy than any reasonable clock skew), or
an encryption preference in a message whos signature cannot be verified,
MUST NOT be accepted."

11) Sec 3, first para: Please replace "PKCS" with "CMS".

12) Sec 3, first para: Please add as last sentences: "The Enhanced Security
Services for S/MIME [ESS] document provides examples of how nested, secured
S/MIME messages are formatted.  For example, there is an example of how a
triple-wrapped S/MIME message is formatted using multipart/signed and
application/pkcs7-mime for the signatures."

13) Sec 3.2, 2nd para: Please make the following change: 

OLD: "The contentInfo field of the carried CMS object always contains a MIME
entity that is prepared as described in section 3.1. The contentInfo field
must never be empty."

NEW: "The carried CMS object always contains a MIME entity that is prepared
as described in section 3.1.  Also, see Section 2.4.1 for instructions on
including the id-data OID and MIME entity in the CMS objects."

14) Sec 3.4, first sent:  Please change "application/pkcs7-mime and
SignedData" to "application/pkcs7-mime with SignedData" in the following:
"There are two formats for signed messages defined for S/MIME:
application/pkcs7-mime and SignedData, and multipart/signed.:

15) Sec 3.4.2, title:  Please change "application/pkcs7-mime and SignedData"
to "application/pkcs7-mime with SignedData" in the following: "3.4.2 Signing
Using application/pkcs7-mime and SignedData"

16) Sec 3.4.2: Please change "application/pkcs7-mime and SignedData" to
"application/pkcs7-mime with SignedData" in the following: "The smime-type
parameter for messages using application/pkcs7-mime and SignedData is
"signed-data"."

17) Sec 3.4.3, last sent:  Please make the following change:

OLD: "The first part contains the MIME entity that is to be signed; the
second part contains the signature, which is a CMS detached signature."

NEW: "The first part contains the MIME entity that is signed; the second
part contains the "detached signature" CMS SignedData object in which the
encapContentInfo eContent field is absent."

18) Sec 3.4.3, 2nd sent: Please replace "PKCS" with "CMS" in the following:
"This format is a clear-signing format. Recipients without any S/MIME or
PKCS processing facilities are able to view the message."

19) Sec 3.4.3.1,  2nd sent:  Please make the following change:

OLD: "The contentInfo field of the CMS object must be empty."

NEW: "The signedData encapContentInfo eContent field MUST be absent."

20) Sec 3.4.3.2, Step 2:  Please make the following change:

OLD: "Step 2. The MIME entity is presented to CMS processing in order to
obtain an object of type signedData with an empty contentInfo field."

NEW: "Step 2. The MIME entity is presented to CMS processing in order to
obtain an object of type signedData in which the encapContentInfo eContent
field is absent."

21) Sec 3.4.3.2, Step 4:  Please make the following change:

OLD: "Step 4. Transfer encoding is applied to the detached signature and it
is inserted into a MIME entity of type application/pkcs7-signature"

NEW: "Step 4. Transfer encoding is applied to the "detached signature" CMS
SignedData object and it is inserted into a MIME entity of type
application/pkcs7-signature"

22) Section 3.4.3.2, paragraph 8: Jim Schaad commented:
"Section 3.4.3.2, paragraph 8. micalg can contain a list of values.
Suggest the paragraph be re-worded as follows:

"The micalg paramter allows for one-pass processing when the signature is
being verified.  The value of the micalg parameter is dependent on the
message digest algorithm(s) used in the calculation of the Message Integrity
Check.  If multiple message digest algorithms are used they should be
seperated by commas.  The values to be placed int eh micalg parameter SHOULD
be from the following:"

23) Sec 3.6, Step 1, last para:  Please make the following change:

OLD: "The contentInfo and signerInfos fields must be empty."

NEW: "The signedData encapContentInfo eContent field MUST be absent and
signerInfos field MUST be empty."

24) Sec 3.7, last para, last sent: Please delete: "S/MIME v2 specified a
non-standard technology for certificate management." 

25) Sec 4, 1rst para, last sent: 

OLD: "S/MIME certification issues are covered in a different document."

NEW: "S/MIME certification issues are covered in the "S/MIME Version 3
Certificate Handling [CERT3]" document."

26) App A: Jim Schaad proposed:
"Appendix A.  I would like to update the ASN for
SMIMEEncryptionKeyPreference as follows:
  SMIMEEncryptionKeyPreference ::= CHOICE {
   issuerAndSerialNumber   IMPLICIT [0] IssuerAndSerialNumber,
   receipentKeyId          IMPLICIT [1] RecipientKeyIdentifier,
   subjectAltKeyIdentifier IMPLICIT [2] KeyIdentifier,
   sha1Hash                IMPLICIT [3] OCTET STRING
	}

On the inclusion of a certificate identifier in the signed data object,
several people have asked to be able to use a hash as this is generally much
smaller than an issuerAndSerialNumber, thus I have included it here first."

27) App B, Please add: "[CERT3] "S/MIME Version 3 Certificate Handling",
Internet Draft, draft-ietf-smime-cert-*.txt."

28) App B, Please add: "[ESS] "Enhanced Security Services for S/MIME",
Internet draft, draft-ietf-smime-ess-*.txt."

29) App B, CMS reference: Please make the following change:

OLD: "[CMS] "Cryptographic Message Syntax", Internet Draft
draft-housley-smime-cms"

NEW: "[CMS] "Cryptographic Message Syntax", Internet Draft,
draft-ietf-smime-cms-*.txt."

30) App D: Recommend deleting Appendix D because it is out of date and is
not needed, IMHO.

31) App F.1, 3rd para, next to last sent: Please change "PKCS7-object" to
"CMS object".

32) App H. Needed changes #1: "We need to document Diffie-Hellman parameters
(key lengths, etc.) -- is this a separate draft?"  This is provided in CMS,
so this bullet should be deleted.

33) App H. Needed changes #2: "Section A cleanup (SMIMECapabilities and
SMIMEEncryptionKeyPreference in their own sections?)"  Leave as is and
delete this bullet.

34) App H. Needed changes #3: "Should SMIMEEncryptionKeyPreference simply be
IssuerAndSerialNumber?"  See Jim Schaad's proposed change.  If accepted,
delete this bullet.

35) App H. Needed changes #4: "ASN.1 issues -- syntax, CCITT vs. ITU-T in
section 1.3, OID cleanup"  Jim Schaad wrote: "NEW: Need to get an OID for
SMIMEEncryptionKeyPreference and smimeVersions."  Recommend deleting this
bullet.

36) App H. Needed changes #5:  "Section 1.1 -- what documents are needed to
implement S/MIME.  Should probably include X9.42, X9.57, etc."  These are
provided in CMS, so this bullet should be deleted.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Jim Schaad (Exchange)" <[email-masked]>, "[email-masked]'" <[email-masked]>
cc: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Inclusion of the issuer and serial number in authenticated in formation
Date: Thu, 12 Mar 1998 14:03:42 -0800
Sender: [email-masked]

On Wednesday, March 11, 1998 12:29 PM, Denis Pinkas
[SMTP:[email-masked]] wrote:
> This is a good start, but this is not sufficient to handle all the
> cases. If one trust point (ie. root CA) of the verifier is also the CA
> that is identified in that attribute, this is fine and sufficient. If
a
> certificate chain is needed to end up to the trust point of the
> verifier, then a SEQUENCE OF IssuerAndSerialNumber *may* be needed.
The
> reason is the following : CA names are not necessarily unique. One CA
> is
> only mandated to issue a name that is unique to it, but does not need
> to
> check that the name is not used by another CA. However if you take a
> given CA as a trust point, the SEQUENCE OF IssuerAndSerialNumber is
> unique. The side advantage is that this works without using
> Distinguished Names (ie X.521 names).

You bring up an interesting point, but with cross-certification and
other deviations from missionary, strict-hierarchical cert chain
traversal, does this add any value?

I suspect that it won't hurt anything to specify a SEQUENCE OF
IssuerAndSerialNumber, but I don't think that CA namespace collisions
pose a significant problem.  Consider the following:

Two CAs exist, I'll call them A and A'.  Each one has a different public
key in their certificate.  You are trying to validate the signature on
end-entity certificate E.  E is signed by the private key corresponding
to certificate A.  If your chaining code tries to validate E with A', it
will fail.  At this point, your code will try using A and succeed.

Also, because issuer certificates sometimes expire (VeriSign has
re-issued both their Class 1 and Class 2 individual certificates), the
IssuerAndSerialNumber for the CA will be "stale" in an old message.

I certainly agree that solving the "I stuck another
IssuerAndSerialNumber for another certificate with the same public key
in a SignerInfo" problem is a Very Good Idea, and is A Necessity.  I
just don't know if we need to go the extra step for the SEQUENCE with
the IssuerAndSerialNumbers for the entire chain.

Comments welcome.

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

Date: Thu, 12 Mar 1998 14:53:00 -0800
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: "Jim Schaad (Exchange)" <[email-masked]>
CC: "Ietf-Smime (E-mail)" <[email-masked]>, [email-masked]
Subject: Re: Inclusion of the issuer and serial number in authenticated information
Sender: [email-masked]

In my first E-mail to the group, I made a proposal that got the support
from John (Pawling):

> I agree with Denis' enhancement to Jim's Signing Certificate 
> Attribute proposal.

and from Jim (Schaad)

> I have no problems with exentending this from a single instance to a
> sequence of instances. 

I also asked for a specific scheme that is already there. Jim said : "I
think you have misread how to compute CMS signatures." . This is true.
More precisely, I must admit that I could only understand the section
5.3 while (re-)reading the section 11.2 that says : " The message-digest
attribute type is required if there are any authenticated attributes
present."

I like the explanations provided by John and Jim. Could we re-use some
parts of them to clarify the current section 5.3. ? There are reproduced
below:
  
>From John :

CMS (sec 5.3 and 5.4) already requires two
separate hash calculations when authenticated attributes are used. 
First,
the content is hashed and the resulting hash value is included in the
messageDigest authenticated attribute.  Then the DER-encoded
authenticatedAttributes are hashed.  The signature value is generated
from
the resulting hash value.

>From Jim :

The message is hashed and then the message hash is included
in the authenticated attributes as a new attribute.  The authenticiated
attributes are then hashed and this is the value that is actually
signed.
The only requirement is that the same hash function be applied to both
sets
of data to be hashed (not an oderous requirement as you should only use
hash
functions that you think are good anyway).

Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

From: "Blake Ramsdell" <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, <[email-masked]>
Subject: RE: New versions of the -msg and -cert drafts
Date: Wed, 11 Mar 1998 18:33:48 -0800
Sender: [email-masked]

On Wednesday, March 11, 1998 5:21 PM, Paul Hoffman / IMC
[SMTP:[email-masked]] wrote:
> Greetings again. Blake has turned in new versions of the -msg and
-cert
> drafts (both at the -02 level). Because the turnaround time for drafts
> at
> this point is quite long (due to the rush to get them in before the
> cutoff
> on Friday), I've posted them to the web site now. Thus, if you look at
> <http://www.imc.org/draft-ietf-smime-cert> and
> <http://www.imc.org/draft-ietf-smime-cert>, you will get the -02
drafts.

One of these should be -msg.

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

Date: Wed, 11 Mar 1998 17:21:17 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: New versions of the -msg and -cert drafts
Sender: [email-masked]

Greetings again. Blake has turned in new versions of the -msg and -cert
drafts (both at the -02 level). Because the turnaround time for drafts at
this point is quite long (due to the rush to get them in before the cutoff
on Friday), I've posted them to the web site now. Thus, if you look at
<http://www.imc.org/draft-ietf-smime-cert> and
<http://www.imc.org/draft-ietf-smime-cert>, you will get the -02 drafts.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: New ESS-03 MLA Proposal 
Date: Wed, 11 Mar 1998 10:10:27 -0800
Sender: [email-masked]

John -- This looks good to me, lets go with it.  
Paul -- as my MLA modification message seems to have been eaten by
majordommo last Tuesday let me know if you have a copy of it.  I don't think
however that it needs to be included in the new text as this addresses the
same issue in a better manner.

jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 11, 1998 7:02 AM
To: [email-masked]
Subject: New ESS-03 MLA Proposal 

All,

Based on comments from Jim Schaad and Andrew Farrell, I have modified the
proposal to enhance ESS-03, Sec 4.2 as follows: 

17) Sec 4.2, first para:  This change addresses the Open Issue regarding MLA
processing.  Please replace the first para with the following text: 

"The first few paragraphs provide a high-level description of MLA
processing.  The rest of the section provides a detailed description of MLA
processing.  MLA processing depends on the structure of the S/MIME layers in
the message sent to the MLA for expansion.  An entity can send a message to
the MLA in which any combination of security services has been applied.  For
example, an entity can send a quadruple-wrapped message to the MLA (i.e. a
well-formed triple-wrapped message was sent through a gateway that added an
outer SignedData layer).

In all cases, the MLA MUST parse all layers of the received message to
determine if there are any signedData layers that include an
eSSSecurityLabel authenticatedAttribute.  This may include decrypting an
EnvelopedData layer to determine if an encapsulated SignedData layer
includes an eSSSecurityLabel attribute.  The MLA MUST fully process each
eSSSecurityLabel attribute found in the various signedData layers including
performing access control checks before distributing the message to the ML
members.  The details of the access control checks are beyond the scope of
this document.  The MLA MUST verify the signature of the signerInfo
including the eSSSecurityLabel attribute before using it.  

In all cases, the MLA MUST sign the message to be sent to the ML members in
a new "outer" signedData layer.  The MLA MUST add or update an
mlExpansionHistory attribute in the "outer" signedData that it creates to
document MLA processing.  If there was an "outer" signedData layer included
in the original message received by the MLA, then the MLA-created "outer"
signedData layer MUST include each authenticated attribute present in the
original "outer" signedData layer, unless the MLA explicitly replaces an
attribute (such as signingTime or mlExpansionHistory) with a new value.    

When an S/MIME message is received by the MLA, the MLA MUST first determine
which received signedData layer, if any, is the "outer" signedData layer.
To identify the received "outer" signedData layer, the MLA MUST verify the
signature and fully process the authenticatedAttributes in each of the outer
signedData layers (working from the outside in) to determine if any of them:

1) include an mlExpansionHistory attribute; or
2) encapsulate an envelopedData object.

The MLA's search for the "outer" signedData layer is completed when it finds
one of the following: the "outer" signedData layer meeting one of the above
properties; an envelopedData layer; or the original content (i.e. not
envelopedData and not signedData).  

If the MLA finds an "outer" signedData layer, then the MLA MUST: strip off
all of the signedData layers that encapsulated the "outer" signedData layer;
strip off the "outer" signedData layer itself (after remembering the
included authenticatedAttributes); expand the envelopedData (if present);
and sign the message to be sent to the ML members in a new "outer"
signedData layer that includes the authenticatedAttributes (unless explictly
replaced) from the original, received "outer" signedData layer.

If the MLA finds an "outer" signedData layer that includes an
mlExpansionHistory attribute AND the MLA subsequently finds an envelopedData
layer buried deeper with the layers of the received message, then the MLA
MUST strip off all of the signedData layers down to the envelopedData layer
(including stripping off the original "outer" signedData layer) and MUST
sign the expanded envelopedData in a new "outer" signedData layer that
includes the authenticatedAttributes (unless explictly replaced) from the
original, received "outer" signedData layer.

If the MLA does not find an "outer" signedData layer AND does not find an
envelopedData layer, then the MLA MUST sign the original, received message
in a new "outer" signedData layer.  If the MLA does not find an "outer"
signedData AND does find an envelopedData layer then it MUST expand the
envelopedData layer, if present, and sign it in a new "outer" signedData
layer. 

Consider the following examples: 

1) A message (S1(Original Content)) (where S = SignedData) is sent to the
MLA in which the signedData layer does not include an MLExpansionHistory
attribute.  The MLA verifies and fully processes the authenticatedAttributes
in S1.  The MLA decides that there is not an original, received "outer"
signedData layer since it finds the original content, but never finds an
envelopedData and never finds an mlExpansionHistory attribute.  The MLA
calculates a new signedData layer, S2, resulting in the following message
sent to the ML recipients: (S2(S1(Original Content))).  The MLA includes 
an mlExpansionHistory attribute in S2. 

2) A message (S3(S2(S1(Original Content)))) is sent to the MLA in which none
of the signedData layers includes an MLExpansionHistory attribute.  The MLA
verifies and fully processes the authenticatedAttributes in S3, S2 and S1.
The MLA decides that there is not an original, received "outer" signedData
layer since it finds the original content, but never finds an envelopedData
and never finds an mlExpansionHistory attribute. The MLA calculates a new
signedData layer, S4, resulting in the following message sent to the ML
recipients: (S4(S3(S2(S1(Original Content))))).  The MLA includes an
mlExpansionHistory attribute in S4. 

3) A message (E1(S1(Original Content))) (where E = envelopedData) is sent to
the MLA in which S1 does not include an MLExpansionHistory attribute. The
MLA decides that there is not an original, received "outer" signedData layer
since it finds the E1 as the outer layer.  The MLA expands the
recipientInformation in E1.  The MLA calculates a new signedData layer, S2,
resulting in the following message sent to the ML recipients:
(S2(E1(S1(Original Content)))).  The MLA includes an mlExpansionHistory
attribute in S2. 

4) A message (S2(E1(S1(Original Content)))) is sent to the MLA in which S2
includes an MLExpansionHistory attribute.  The MLA verifies the signature
and fully processes the authenticatedAttributes in S2.  The MLA finds the
mlExpansionHistory attribute in S2, so it decides that S2 is the "outer"
signedData.  The MLA remembers the authenticatedAttributes included in S2
for later inclusion in the new outer signedData that it applies to the
message.  The MLA strips off S2.  The MLA then expands the
recipientInformation in E1 (this invalidates the signature in S2 which is
why it was stripped).  The MLA calculates a new signedData layer, S3,
resulting in the following message sent to the ML recipients:
(S3(E1(S1(Original Content)))).  The MLA includes in S3 the attributes from
S2 (unless it specifically replaces an attribute value) including an updated
mlExpansionHistory attribute. 

5) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which
none of the signedData layers include an MLExpansionHistory attribute.  The
MLA verifies the signature and fully processes the authenticatedAttributes
in S3 and S2.  When the MLA encounters E1, then it decides that S2 is the
"outer" signedData since S2 encapuslates E1.  The MLA remembers the
authenticatedAttributes included in S2 for later inclusion in the new outer
signedData that it applies to the message.  The MLA strips off S3 and S2.
The MLA then expands the recipientInformation in E1 (this invalidates the
signatures in S3 and S2 which is why they were stripped). The MLA calculates
a new signedData layer, S4, resulting in the following message sent to the
ML recipients: (S4(E1(S1(Original Content)))).  The MLA includes in S4 the
attributes from S2 (unless it specifically replaces an attribute value) and
includes a new mlExpansionHistory attribute. 

6) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which
S3 includes an MLExpansionHistory attribute.  In this case, the MLA verifies
the signature and fully processes the authenticatedAttributes in S3. The MLA
finds the mlExpansionHistory in S3, so it decides that S3 is the "outer"
signedData.  The MLA remembers the authenticatedAttributes included in S3
for later inclusion in the new outer signedData that it applies to the
message.  The MLA keeps on parsing encapsulated layers because it must 
determine if there are any eSSSecurityLabel attributes contained within.
The MLA verifies the signature and fully processes the
authenticatedAttributes in S2.  When the MLA encounters E1, then it strips
off S3 and S2.  The MLA then expands the recipientInformation in E1 (this
invalidates the signatures in S3 and S2 which is why they were stripped).
The MLA calculates a new signedData layer, S4, resulting in the following
message sent to the ML recipients: (S4(E1(S1(Original Content)))).  The MLA
includes in S4 the attributes from S3 (unless it specifically replaces an
attribute value) including an updated mlExpansionHistory attribute.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Inclusion of the issuer and serial number in authenticated in formation
Date: Wed, 11 Mar 1998 10:24:09 -0800
Sender: [email-masked]

Denis,

I have no problems with exentending this from a single instance to a
sequence of instances.  With this modification however it may be come even
more interesting to fingure how how to switch to hashes as we are now
looking at a much large blob of data to add to the message.

With respect to your other problem, I think you have misread how to compute
CMS signatures.  The message is hashed and then the message hash is included
in the authenticated attributes as a new attribute.  The authenticiated
attributes are then hashed and this is the value that is actually signed.
The only requirement is that the same hash function be applied to both sets
of data to be hashed (not an oderous requirement as you should only use hash
functions that you think are good anyway).  

jim

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Wednesday, March 11, 1998 12:29 PM
To: Jim Schaad (Exchange)
Cc: Ietf-Smime (E-mail)
Subject: Re: Inclusion of the issuer and serial number in authenticated
information

Hello Jim,

I am new to the smime list. A discussion is currently taking place on
the pkix mailing list (Multiple certificates for the same key ?) and as
the solution lies in the CMS document, I subscribed to the smime mailing
list only this week, to follow both discussions.  So, please apologize,
if I do not have all the history on the smime list. 

I am using your proposal related to the addition of a new section 11.5
to the CMS document.

> 11.5  Signing Certificate Attribute

> The signing-certificate attribute type specifies the exact certificate
used
> to sign the signed-data.  This provides for an authenticated method of
> linking the certificate used to create the signed-data object and the
> signed-data object itself.  

This is a good start, but this is not sufficient to handle all the
cases. If one trust point (ie. root CA) of the verifier is also the CA
that is identified in that attribute, this is fine and sufficient. If a
certificate chain is needed to end up to the trust point of the
verifier, then a SEQUENCE OF IssuerAndSerialNumber *may* be needed. The
reason is the following : CA names are not necessarily unique. One CA is
only mandated to issue a name that is unique to it, but does not need to
check that the name is not used by another CA. However if you take a
given CA as a trust point, the SEQUENCE OF IssuerAndSerialNumber is
unique. The side advantage is that this works without using
Distinguished Names (ie X.521 names).

> If this attribute is not used and two different
> certificates are used for the same keys, it is possible to substitute the
> certificates without breaking the signature. 

True.

> It is suggested that the
> signing-certificate attribute be present if there are any authenticated
> attributes present.

What do you mean exactly by this ?

> The signing-certificate attribute MAY be critical.  The
signing-certificate
> attribute MUST be authenticated.  Only one instance of the
> signing-certificate attribute may appear in an attribute set.

> The following object identifier identifies the signing-certificate
> attribute:
>    id-signingCert OBJECT IDENTIFIER ::= <TBD>

> Signing-certificate attribute value has the ASN.1 type
IssuerAndSerialNumber.

--- END ---

As a summary, my proposal would be to consider a Signing Chain Attribute
instead, that can be reduced to a single Signing Certificate Attribute.
The attribute then becomes a SEQUENCE OF IssuerAndSerialNumber.

Re-using your text, we would then have :

--- BEGINNING OF TEXT PROPOSAL ---

11.5  Signing Chain Attribute

The signing-Chain attribute type specifies the exact certification path
that is acknowledged by the signer to sign the signed-data.  This
provides a method of linking the certification path accepted by the
signer to create the signed-data object with the signed-data object
itself. This certification path may be reduced to one leg, ie. a
identifier of the certificate of the signer. If this attribute is not
used and two different certificates are used for the same keys, it is
possible to substitute the certificates without breaking the signature.

The signing-chain attribute MAY be critical.  The signing-chain
attribute MUST be authenticated.  Only one instance of the signing-chain
attribute may appear in an attribute set.

The following object identifier identifies the signing-chain attribute:
   id-signingChain OBJECT IDENTIFIER ::= <TBD>

Signing-chain attribute value has the ASN.1 type SigningChain.

SigningChain :: = SEQUENCE OF IssuerAndSerialNumber.

The first certificate identifier of the chain is the one from the
signer, optionally followed by certificate identifiers from CAs. 

--- END OF TEXT PROPOSAL ---

This solves one concern, but not another one. For the case where this
attribute is used, with the actual CMS text, the signature process
involves one hash function only. Thus the signature of the authenticated
attribute is done by computing a hash over a message data (e.g. a 1 Mo
message) to which the authenticated attribute is happened. There may be
some advantages to be able to pre-compute the hash of the message
independently and so that the overall signature applies to the imprint
of the message (ie. the hash result together with the hash OID)
concatenated with the authenticated attributes. 

We could thus consider to sign the hash of the message, instead of the
message itself. What is nice is that the imprint of a message is a
characteristic of the message that can be computed independently of the
context of the signature. It can be generated or checked in advance or
in parallel.

I do not see this as a replacement to what exists today, but as a new
format "to be used where necessary". 

Any comments ?

Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Wed, 11 Mar 1998 10:41:28 -0500
To: "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Inclusion of the issuer and serial number in authenticated information
Sender: [email-masked]

All,

I agree with Denis' enhancement to Jim's Signing Certificate Attribute proposal.

Regarding Denis' last comment, CMS (sec 5.3 and 5.4) already requires two
separate hash calculations when authenticated attributes are used.  First,
the content is hashed and the resulting hash value is included in the
messageDigest authenticated attribute.  Then the DER-encoded
authenticatedAttributes are hashed.  The signature value is generated from
the resulting hash value.  In summary, CMS already specifies Denis'
recommendations.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

From: Tim Dean <[email-masked]>
To: "[email-masked]" <[email-masked]>, "'David P. Kemp'" <[email-masked]>
Subject: RE: Tolerance on Message Digest Attribute
Date: Wed, 11 Mar 1998 15:11:02 -0000
Sender: [email-masked]

All,

I must say I for one prefer Chris Bonatti's original proposal, purely from the perspective of the current 
protocol.  Without it, a small slip in implementation seems to open up some very undesirable possibilities, 
IMHO.  The proposal closes that door.

However, I can understand the backward compatibility arguments, and I'm prepared to go with the flow
on this.

Tim Dean 
----------------------------------------------------

----------
From:  David P. Kemp [SMTP:[email-masked]]
Sent:  Wednesday, March 04, 1998 5:46 PM
To:  [email-masked]
Subject:  Re: Tolerance on Message Digest Attribute

> All,
> 
> I agree with Eric that the proposals to omit the message digest attribute
> from the transmitted signedData object do not enhance security and do create
> a needless incompatibility between S/MIME v3 and v2 implementations.
> 
> - John Pawling

I'm willing to accept either outcome; I just want to achieve closure,
and give potential non-S/MIME users of CMS (in particular Tim Dean and
the European community) one last chance to weigh in on the issue.

Date: Wed, 11 Mar 1998 10:02:04 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: New ESS-03 MLA Proposal 
Sender: [email-masked]

All,

Based on comments from Jim Schaad and Andrew Farrell, I have modified the
proposal to enhance ESS-03, Sec 4.2 as follows: 

17) Sec 4.2, first para:  This change addresses the Open Issue regarding MLA
processing.  Please replace the first para with the following text: 

"The first few paragraphs provide a high-level description of MLA
processing.  The rest of the section provides a detailed description of MLA
processing.  MLA processing depends on the structure of the S/MIME layers in
the message sent to the MLA for expansion.  An entity can send a message to
the MLA in which any combination of security services has been applied.  For
example, an entity can send a quadruple-wrapped message to the MLA (i.e. a
well-formed triple-wrapped message was sent through a gateway that added an
outer SignedData layer).

In all cases, the MLA MUST parse all layers of the received message to
determine if there are any signedData layers that include an
eSSSecurityLabel authenticatedAttribute.  This may include decrypting an
EnvelopedData layer to determine if an encapsulated SignedData layer
includes an eSSSecurityLabel attribute.  The MLA MUST fully process each
eSSSecurityLabel attribute found in the various signedData layers including
performing access control checks before distributing the message to the ML
members.  The details of the access control checks are beyond the scope of
this document.  The MLA MUST verify the signature of the signerInfo
including the eSSSecurityLabel attribute before using it.  

In all cases, the MLA MUST sign the message to be sent to the ML members in
a new "outer" signedData layer.  The MLA MUST add or update an
mlExpansionHistory attribute in the "outer" signedData that it creates to
document MLA processing.  If there was an "outer" signedData layer included
in the original message received by the MLA, then the MLA-created "outer"
signedData layer MUST include each authenticated attribute present in the
original "outer" signedData layer, unless the MLA explicitly replaces an
attribute (such as signingTime or mlExpansionHistory) with a new value.    

When an S/MIME message is received by the MLA, the MLA MUST first determine
which received signedData layer, if any, is the "outer" signedData layer.
To identify the received "outer" signedData layer, the MLA MUST verify the
signature and fully process the authenticatedAttributes in each of the outer
signedData layers (working from the outside in) to determine if any of them: 
1) include an mlExpansionHistory attribute; or
2) encapsulate an envelopedData object.

The MLA's search for the "outer" signedData layer is completed when it finds
one of the following: the "outer" signedData layer meeting one of the above
properties; an envelopedData layer; or the original content (i.e. not
envelopedData and not signedData).  

If the MLA finds an "outer" signedData layer, then the MLA MUST: strip off
all of the signedData layers that encapsulated the "outer" signedData layer;
strip off the "outer" signedData layer itself (after remembering the
included authenticatedAttributes); expand the envelopedData (if present);
and sign the message to be sent to the ML members in a new "outer"
signedData layer that includes the authenticatedAttributes (unless explictly
replaced) from the original, received "outer" signedData layer.

If the MLA finds an "outer" signedData layer that includes an
mlExpansionHistory attribute AND the MLA subsequently finds an envelopedData
layer buried deeper with the layers of the received message, then the MLA
MUST strip off all of the signedData layers down to the envelopedData layer
(including stripping off the original "outer" signedData layer) and MUST
sign the expanded envelopedData in a new "outer" signedData layer that
includes the authenticatedAttributes (unless explictly replaced) from the
original, received "outer" signedData layer.

If the MLA does not find an "outer" signedData layer AND does not find an
envelopedData layer, then the MLA MUST sign the original, received message
in a new "outer" signedData layer.  If the MLA does not find an "outer"
signedData AND does find an envelopedData layer then it MUST expand the
envelopedData layer, if present, and sign it in a new "outer" signedData layer. 

Consider the following examples: 

1) A message (S1(Original Content)) (where S = SignedData) is sent to the
MLA in which the signedData layer does not include an MLExpansionHistory
attribute.  The MLA verifies and fully processes the authenticatedAttributes
in S1.  The MLA decides that there is not an original, received "outer"
signedData layer since it finds the original content, but never finds an
envelopedData and never finds an mlExpansionHistory attribute.  The MLA
calculates a new signedData layer, S2, resulting in the following message
sent to the ML recipients: (S2(S1(Original Content))).  The MLA includes 
an mlExpansionHistory attribute in S2. 

2) A message (S3(S2(S1(Original Content)))) is sent to the MLA in which none
of the signedData layers includes an MLExpansionHistory attribute.  The MLA
verifies and fully processes the authenticatedAttributes in S3, S2 and S1.
The MLA decides that there is not an original, received "outer" signedData
layer since it finds the original content, but never finds an envelopedData
and never finds an mlExpansionHistory attribute. The MLA calculates a new
signedData layer, S4, resulting in the following message sent to the ML
recipients: (S4(S3(S2(S1(Original Content))))).  The MLA includes an
mlExpansionHistory attribute in S4. 

3) A message (E1(S1(Original Content))) (where E = envelopedData) is sent to
the MLA in which S1 does not include an MLExpansionHistory attribute. The
MLA decides that there is not an original, received "outer" signedData layer
since it finds the E1 as the outer layer.  The MLA expands the
recipientInformation in E1.  The MLA calculates a new signedData layer, S2,
resulting in the following message sent to the ML recipients:
(S2(E1(S1(Original Content)))).  The MLA includes an mlExpansionHistory
attribute in S2. 

4) A message (S2(E1(S1(Original Content)))) is sent to the MLA in which S2
includes an MLExpansionHistory attribute.  The MLA verifies the signature
and fully processes the authenticatedAttributes in S2.  The MLA finds the
mlExpansionHistory attribute in S2, so it decides that S2 is the "outer"
signedData.  The MLA remembers the authenticatedAttributes included in S2
for later inclusion in the new outer signedData that it applies to the
message.  The MLA strips off S2.  The MLA then expands the
recipientInformation in E1 (this invalidates the signature in S2 which is
why it was stripped).  The MLA calculates a new signedData layer, S3,
resulting in the following message sent to the ML recipients:
(S3(E1(S1(Original Content)))).  The MLA includes in S3 the attributes from
S2 (unless it specifically replaces an attribute value) including an updated
mlExpansionHistory attribute. 

5) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which
none of the signedData layers include an MLExpansionHistory attribute.  The
MLA verifies the signature and fully processes the authenticatedAttributes
in S3 and S2.  When the MLA encounters E1, then it decides that S2 is the
"outer" signedData since S2 encapuslates E1.  The MLA remembers the
authenticatedAttributes included in S2 for later inclusion in the new outer
signedData that it applies to the message.  The MLA strips off S3 and S2.
The MLA then expands the recipientInformation in E1 (this invalidates the
signatures in S3 and S2 which is why they were stripped). The MLA calculates
a new signedData layer, S4, resulting in the following message sent to the
ML recipients: (S4(E1(S1(Original Content)))).  The MLA includes in S4 the
attributes from S2 (unless it specifically replaces an attribute value) and
includes a new mlExpansionHistory attribute. 

6) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which
S3 includes an MLExpansionHistory attribute.  In this case, the MLA verifies
the signature and fully processes the authenticatedAttributes in S3. The MLA
finds the mlExpansionHistory in S3, so it decides that S3 is the "outer"
signedData.  The MLA remembers the authenticatedAttributes included in S3
for later inclusion in the new outer signedData that it applies to the
message.  The MLA keeps on parsing encapsulated layers because it must 
determine if there are any eSSSecurityLabel attributes contained within.
The MLA verifies the signature and fully processes the
authenticatedAttributes in S2.  When the MLA encounters E1, then it strips
off S3 and S2.  The MLA then expands the recipientInformation in E1 (this
invalidates the signatures in S3 and S2 which is why they were stripped).
The MLA calculates a new signedData layer, S4, resulting in the following
message sent to the ML recipients: (S4(E1(S1(Original Content)))).  The MLA
includes in S4 the attributes from S3 (unless it specifically replaces an
attribute value) including an updated mlExpansionHistory attribute.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

Date: Wed, 11 Mar 1998 09:50:26 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: ESS-03 Comments 
Sender: [email-masked]

Andrew,

I agree completely.  I will update my proposal and re-send it to the list.

- John Pawling 

At 11:53 AM 3/11/98 +0000, Andrew Farrell wrote:
>
>One small note.
>
>John Pawling writes:
>
>>When an S/MIME message is received by the MLA, the MLA MUST first determine
>>which received signedData layer, if any, is the "outer" signedData layer.
>>To identify the received "outer" signedData layer, the MLA MUST verify the
>>signature and fully process the authenticatedAttributes in each of the outer
>>signedData layers (working from the outside in) to determine if any of them: 
>>1) include an mlExpansionHistory attribute; 
>>2) encapsulate an envelopedData object; or
>>3) encapsulate the original content (i.e. not envelopedData and not signedData
>>).
>
>>If the MLA does not find an "outer" signedData layer then it MUST sign the
>>original, received message in a new "outer" signedData layer.  
>
>A literal interpretation of this rule would change the (S3(S2(S1(Orig
>Content)))) to S4(Orig Content). We should perhaps add a note that in
>case 3, an "outer" signedData layer has not been found.
>
>Andrew.
>

To: [email-masked]
Subject: Re: ESS-03 Comments 
Date: Wed, 11 Mar 1998 11:53:26 +0000
From: Andrew Farrell <[email-masked]>
Sender: [email-masked]

One small note.

John Pawling writes:

>When an S/MIME message is received by the MLA, the MLA MUST first determine
>which received signedData layer, if any, is the "outer" signedData layer.
>To identify the received "outer" signedData layer, the MLA MUST verify the
>signature and fully process the authenticatedAttributes in each of the outer
>signedData layers (working from the outside in) to determine if any of them: 
>1) include an mlExpansionHistory attribute; 
>2) encapsulate an envelopedData object; or
>3) encapsulate the original content (i.e. not envelopedData and not signedData
>).

>If the MLA does not find an "outer" signedData layer then it MUST sign the
>original, received message in a new "outer" signedData layer.  

A literal interpretation of this rule would change the (S3(S2(S1(Orig
Content)))) to S4(Orig Content). We should perhaps add a note that in
case 3, an "outer" signedData layer has not been found.

Andrew.

Date: Wed, 11 Mar 1998 12:28:38 -0800
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: "Jim Schaad (Exchange)" <[email-masked]>
CC: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: Re: Inclusion of the issuer and serial number in authenticated information
Sender: [email-masked]

Hello Jim,

I am new to the smime list. A discussion is currently taking place on
the pkix mailing list (Multiple certificates for the same key ?) and as
the solution lies in the CMS document, I subscribed to the smime mailing
list only this week, to follow both discussions.  So, please apologize,
if I do not have all the history on the smime list. 

I am using your proposal related to the addition of a new section 11.5
to the CMS document.

> 11.5  Signing Certificate Attribute

> The signing-certificate attribute type specifies the exact certificate used
> to sign the signed-data.  This provides for an authenticated method of
> linking the certificate used to create the signed-data object and the
> signed-data object itself.  

This is a good start, but this is not sufficient to handle all the
cases. If one trust point (ie. root CA) of the verifier is also the CA
that is identified in that attribute, this is fine and sufficient. If a
certificate chain is needed to end up to the trust point of the
verifier, then a SEQUENCE OF IssuerAndSerialNumber *may* be needed. The
reason is the following : CA names are not necessarily unique. One CA is
only mandated to issue a name that is unique to it, but does not need to
check that the name is not used by another CA. However if you take a
given CA as a trust point, the SEQUENCE OF IssuerAndSerialNumber is
unique. The side advantage is that this works without using
Distinguished Names (ie X.521 names).

> If this attribute is not used and two different
> certificates are used for the same keys, it is possible to substitute the
> certificates without breaking the signature. 

True.

> It is suggested that the
> signing-certificate attribute be present if there are any authenticated
> attributes present.

What do you mean exactly by this ?

> The signing-certificate attribute MAY be critical.  The signing-certificate
> attribute MUST be authenticated.  Only one instance of the
> signing-certificate attribute may appear in an attribute set.

> The following object identifier identifies the signing-certificate
> attribute:
>    id-signingCert OBJECT IDENTIFIER ::= <TBD>

> Signing-certificate attribute value has the ASN.1 type IssuerAndSerialNumber.

--- END ---

As a summary, my proposal would be to consider a Signing Chain Attribute
instead, that can be reduced to a single Signing Certificate Attribute.
The attribute then becomes a SEQUENCE OF IssuerAndSerialNumber.

Re-using your text, we would then have :

--- BEGINNING OF TEXT PROPOSAL ---

11.5  Signing Chain Attribute

The signing-Chain attribute type specifies the exact certification path
that is acknowledged by the signer to sign the signed-data.  This
provides a method of linking the certification path accepted by the
signer to create the signed-data object with the signed-data object
itself. This certification path may be reduced to one leg, ie. a
identifier of the certificate of the signer. If this attribute is not
used and two different certificates are used for the same keys, it is
possible to substitute the certificates without breaking the signature.

The signing-chain attribute MAY be critical.  The signing-chain
attribute MUST be authenticated.  Only one instance of the signing-chain
attribute may appear in an attribute set.

The following object identifier identifies the signing-chain attribute:
   id-signingChain OBJECT IDENTIFIER ::= <TBD>

Signing-chain attribute value has the ASN.1 type SigningChain.

SigningChain :: = SEQUENCE OF IssuerAndSerialNumber.

The first certificate identifier of the chain is the one from the
signer, optionally followed by certificate identifiers from CAs. 

--- END OF TEXT PROPOSAL ---

This solves one concern, but not another one. For the case where this
attribute is used, with the actual CMS text, the signature process
involves one hash function only. Thus the signature of the authenticated
attribute is done by computing a hash over a message data (e.g. a 1 Mo
message) to which the authenticated attribute is happened. There may be
some advantages to be able to pre-compute the hash of the message
independently and so that the overall signature applies to the imprint
of the message (ie. the hash result together with the hash OID)
concatenated with the authenticated attributes. 

We could thus consider to sign the hash of the message, instead of the
message itself. What is nice is that the imprint of a message is a
characteristic of the message that can be computed independently of the
context of the signature. It can be generated or checked in advance or
in parallel.

I do not see this as a replacement to what exists today, but as a new
format "to be used where necessary". 

Any comments ?

Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Tue, 10 Mar 1998 19:31:33 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: RE: ESS-03 Comments
Sender: [email-masked]

Jim,

I agree with all of Jim Schaad's comments except for the following:

>17) Sec 4.2, first para: 
<snip>
>[Jim Schaad:  I can accept this up to the last paragraph. 

[JSP: I agree that Jim makes some good points and that my proposal needs to
be enhanced.  Please read on.]

>Does the following algrithm sound reasonable for identification of "the"
>outer signature:
>Verifiy signatures in until you find
>1)  A mlExpansionHistory Attribute or
>2)  The enclosed data is encryptedData
>The signature which has this property is the "outer" signature.  If you
>don't find an outer signature you add a new one.  If you find an outer
>signature you strip everything including that signature and resign.  If you
>find an outer signature from test 1 AND you find an encryptedData farther
>in, you strip all signature to the encryptedData and then re-sign using the
>"defined" outer signature.

[JSP: I agree except please change "Verifiy signatures in" to "Verify
signatures and fully process authenticatedAttributes in".  Also, please
change "2) The enclosed data is encryptedData" to "2) The enclosed data is
envelopedData, or".  Also, please add "3) The enclosed data is the original
content".  Consider the example (S3(S2(S1(Orig Content)))) in which none of
the layers include an MLExpansion history attribute.  In this case the MLA
verifies and fully processes the authenticatedAttributes in S3, S2 and S1,
but never finds an envelopedData and never finds an mlExpansionHistory
attribute.  In this case, the MLA calculates a new signedData layer, S4,
resulting in the following message sent to the ML recipients:
(S4(S3(S2(S1(Orig Content))))).  S4 includes an mlExpansionHistory attribute
created by the MLA.]

[JSP: Based on Jim's comments, I re-submit my comment 17 to ESS-03 as
follows: "17) Sec 4.2, first para:  This change addresses the Open Issue
regarding MLA processing.  Please replace the first para with: "MLA message
processing depends on the structure of the S/MIME layers in the message sent
to the MLA for expansion.  For example, an entity can send a single-wrapped
signedData or envelopedData message to an MLA.  As another example, an
entity can send a double-wrapped message (i.e. signed and enveloped;
enveloped and signed; signed and signed; etc) to an MLA.  As another
example, an entity can send a quadruple-wrapped message to the MLA (i.e. a
well-formed triple-wrapped message was sent through a gateway that added an
outer SignedData layer).  In all cases, the MLA MUST sign the message to be
sent to the ML members in a new "outer" signedData layer.  The MLA MUST add
or update an mlExpansionHistory attribute in the "outer" signedData that it
creates to document MLA processing.  If there was an "outer" signedData
layer included in the original message received by the MLA, then the
MLA-created "outer" signedData layer MUST include each authenticated
attribute present in the original "outer" signedData layer, unless the MLA
explicitly replaces an attribute (such as mlExpansionHistory) with a new
value.    

When an S/MIME message is received by the MLA, the MLA MUST first determine
which received signedData layer, if any, is the "outer" signedData layer.
To identify the received "outer" signedData layer, the MLA MUST verify the
signature and fully process the authenticatedAttributes in each of the outer
signedData layers (working from the outside in) to determine if any of them: 
1) include an mlExpansionHistory attribute; 
2) encapsulate an envelopedData object; or
3) encapsulate the original content (i.e. not envelopedData and not signedData).

If the MLA does not find an "outer" signedData layer then it MUST sign the
original, received message in a new "outer" signedData layer.  If the MLA
finds an "outer" signedData layer, then the MLA MUST: strip off all of the
signedData layers that encapsulated the "outer" signedData layer; strip off
the "outer" signedData layer itself (after remembering the included
authenticatedAttributes); expand the envelopedData (if present); and sign
the message to be sent to the ML members in a new "outer" signedData layer
that includes the authenticatedAttributes (unless explictly replaced) from
the original, received "outer" signedData layer.  If the MLA finds an
"outer" signedData layer that includes an mlExpansionHistory attribute AND
the MLA also finds an envelopedData layer buried deeper with the layers of
the received message, then the MLA MUST strip off all of the signedData
layers down to the envelopedData layer (including stripping off the original
"outer" signedData layer) and MUST sign the expanded envelopedData in a new
"outer" signedData layer that includes the authenticatedAttributes (unless
explictly replaced) from the original, received "outer" signedData layer.    .

Consider the following examples: 

1) A message (S1(Original Content)) (where S = SignedData) is sent to the
MLA in which the signedData layer does not include an MLExpansionHistory
attribute.  The MLA verifies and fully processes the authenticatedAttributes
in S1.  The MLA decides that there is not an original, received "outer"
signedData layer since it finds the original content, but never finds an
envelopedData and never finds an mlExpansionHistory attribute.  The MLA
calculates a new signedData layer, S2, resulting in the following message
sent to the ML recipients: (S2(S1(Original Content))).  S2 includes an
mlExpansionHistory attribute created by the MLA.

2) A message (S2(E1(S1(Original Content)))) (where E = envelopedData) is
sent to the MLA in which S2 includes an MLExpansionHistory attribute.  The
MLA verifies the signature and fully processes the authenticatedAttributes
in S2.  The MLA finds the mlExpansionHistory attribute in S2, so it decides
that S2 is the "outer" signedData.  The MLA remembers the
authenticatedAttributes included in S2 for later inclusion in the new outer
signedData that it applies to the message.  The MLA strips off S2.  The MLA
then expands the recipientInformation in E1 (this invalidates the signature
in S2 which is why it was stripped).  The MLA calculates a new signedData
layer, S3, resulting in the following message sent to the ML recipients:
(S3(E1(S1(Original Content)))).  The MLA includes in S3 the attributes from
S2 (unless it specifically replaces an attribute value) including an updated
mlExpansionHistory attribute. 

3) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which
none of the signedData layers include an MLExpansionHistory attribute.  In
this case, the MLA verifies the signature and fully processes the
authenticatedAttributes in S3 and S2.  When the MLA encounters E1, then it
will consider S2 to be the "outer" signedData since S2 encapuslates E1.  The
MLA remembers the authenticatedAttributes included in S2 for later inclusion
in the new outer signedData that it applies to the message.  The MLA strips
off S3 and S2.  The MLA then expands the recipientInformation in E1 (this
invalidates the signatures in S3 and S2 which is why they were stripped).
The MLA calculates a new signedData layer, S4, resulting in the following
message sent to the ML recipients: (S4(E1(S1(Original Content)))).  The MLA
includes in S4 the attributes from S2 (unless it specifically replaces an
attribute value) and includes a new mlExpansionHistory attribute. 

4) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which
S3 includes an MLExpansionHistory attribute.  In this case, the MLA verifies
the signature and fully processes the authenticatedAttributes in S3. The MLA
finds the mlExpansionHistory in S3, so it decides that S3 is the "outer"
signedData.  The MLA remembers the authenticatedAttributes included in S3
for later inclusion in the new outer signedData that it applies to the
message.  The MLA verifies the signature and fully processes the
authenticatedAttributes in S2.  When the MLA encounters E1, then it strips
off S3 and S2.  The MLA then expands the recipientInformation in E1 (this
invalidates the signatures in S3 and S2 which is why they were stripped).
The MLA calculates a new signedData layer, S4, resulting in the following
message sent to the ML recipients: (S4(E1(S1(Original Content)))).  The MLA
includes in S4 the attributes from S3 (unless it specifically replaces an
attribute value) including an updated mlExpansionHistory attribute.]

>The problem with
>this is that security labels which I (as sender) apply to a signedData
>object will get lost potentially.  For example consider the case of
>S1(S2(E1(S3)).  If S1 and/or S2 has a security label on it, that label will
>get lost by the process of MLA expansion.  I am starting to admit defeat and
>say that the processing just cannot be done correctly in all cases.

[JSP: In your example, (S1(S2(E1(S3)))), the security label that is used for
end-to-end, writer-to-reader security is the one in S3.  The security
labels, if any, included in S1 and S2 are intended to be "processed
hop-by-hop, where each hop is an intermediate entity" (ESS, Sec 1.1.1, last
para).  As implied in the aforementioned examples, the MLA verifies the
signature and fully processes the authenticatedAttributes in S1 and S2.  It
fully processes the securityLabel attributes found in S1 and S2, if present.
In summary, the security labels in S1 and S2 are fully processed by the MLA,
so they are not "lost".  They are processes as was intended by ESS, Sec 1.1.1.] 

>This means that all sorts of critical attributes can be stripped off by an
>MLA without notice to ANYBODY.  Is this acceptable?]

[JSP:  The critical attributes in the inner signedData (S3 in your example)
cannot be stripped off by the MLA without invalidating the signature of the
inner signedData.  The critical attributes in outer signedData layers (S1
and S2) can be stripped off by the MLA.  This is consistent with the
definition of "outer signature" as stated in ESS, sec 1.1.1:

"The outside signature provides authentication and integrity for information
that is processed hop-by-hop, where each hop is an intermediate entity such
as a mail list agent. The outer signature binds attributes (such as a
security label) to the encrypted body. These attributes can be used for
access control and routing decisions."]

- John Pawling

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Inclusion of the issuer and serial number in authenticated in form ation
Date: Tue, 10 Mar 1998 13:04:17 -0800
Sender: [email-masked]

OK -- Here is a concrete proposal for this:

Add a new section 11.5 to the CMS document.

11.5  Signing Certificate Attribute

The signing-certificate attribute type specifies the exact certificate used
to sign the signed-data.  This provides for an authencticated method of
linking the certificate used to create the signed-data object and the
signed-data object itself.  If this attribute is not used and two different
certificates are used for the same keys, it is possible to substitute the
certificates without breaking the signature. It is suggested that the
signing-certificate attribute be present if there are any authenticated
attributes present.

The signing-certificate attribute MAY be critical.  The signing-certificate
attribute MUST be authenticated.  Only one instance of the
signing-certficiate attribute may appear in an attribute set.

The following object identifier identifies the signing-certificate
attribute:
   id-signingCert OBJECT IDENTIFIER ::= <TBD>

Signing-certficate attribute value has the ASN.1 type IssuerAndSerialNumber.

--- END ---

Some people suggested that we put the hash either as a choice to or instead
of the issuer and serial number.  I did not do this for two reasons:  A)
You would need to have a field defining which hash algrithm you are going to
use to compute the has and B) this would create a new ASN structure to hold
the data.  There is already well understood ways of doing the issure and
serial number look up, so this is current code which already exists.

jim

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: ESS-03 Comments
Date: Tue, 10 Mar 1998 12:39:50 -0800
Sender: [email-masked]

John,

I agree with you except for the following:

6) Sec 2.3, Bullet 2.2: Please append "in the outer signedData layer" to the
following:  "2.2. If the value of allOrFirstTier is firstTierRecipients, do
one of the following two steps based on the presence of an
mlExpansionHistory attribute:"
[Jim Schaad  I think this should be "in an outer signedData layer" to deal
with the multiple outer layer problems]

14) Sec 2.4.1, last sent:  Please change as follows:

OLD:
"The MLA cannot change the authenticatedAttributes of the received
SignedData/Receipt object, so it can't add the MLExpansionHistory to the
SignedData/Receipt."

NEW:
"The MLA cannot change the authenticatedAttributes of the received
SignedData/Receipt object without invalidating the signature, so the MLA
MUST NOT add the MLExpansionHistory to the SignedData/Receipt."

[Jim Schaad:  I don't see the need for this change.  At this point we are
not talking about the MLA adding the MLExpansionHistory but the receipient
adding it to the signature they are applying.  I think the wording stands as
originally written.]

17) Sec 4.2, first para:  This change addresses the Open Issue regarding MLA
processing.  Please replace the first para with: "MLA message processing
depends on the structure of the S/MIME layers in the message sent to the MLA
for expansion.  For example, an entity can send a single-wrapped signedData
or envelopedData message to an MLA.  As another example, an entity can send
a double-wrapped message (i.e. signed and enveloped;  enveloped and signed;
signed and signed; etc) to an MLA.  As another example, an entity can send a
quadruple-wrapped message to the MLA (i.e. a well-formed triple-wrapped
message was sent through a gateway that added an outer SignedData layer).
In all cases, the MLA MUST sign the message and create a new "outer"
signedData layer encapsulating the message before it distributes it to the
ML members.  Furthermore, it MUST add or update an mlExpansionHistory
attribute to document MLA processing.

When a S/MIME message is received by the MLA, it MUST first determine if
there is an outer signedData layer that already includes an
mlExpansionHistory attribute.  If there are several outer signedData layers,
then the MLA MUST decode each of the outer layers to determine if any of
them include an mlExpansionHistory attribute.  If the MLA finds a signedData
layer that includes an mlExpansionHistory attribute, then that is the
"outer" signedData layer that is referred to in the rest of this section.
In this case, the MLA must strip off the "outer" layer (after remembering
the included authenticated attributes) and must strip off all of the
signedData layers that encapsulated the "outer" layer.  This is required
because the MLA MUST change the existing mlExpansionHistory attribute and
that change invalidates all of the encapsulating signedData signatures. 

If the MLA decodes the outer signedData layers and does not find an
mlExpansionHistory attribute, then the MLA MUST add a new signedData layer
that encapsulates all of the existing signedData layers.  In this case, the
new signedData layer created by the MLA is the "outer" signedData layer that
is referred to in the rest of this section."

[Jim Schaad:  I can accept this up to the last paragraph.  The problem with
this is that security labels which I (as sender) apply to a signedData
object will get lost potentially.  For example consider the case of
S1(S2(E1(S3)).  If S1 and/or S2 has a security label on it, that label will
get lost by the process of MLA expansion.  I am starting to admit defeat and
say that the processing just cannot be done correctly in all cases.

Does the following algrithm sound reasonable for identification of "the"
outer signature:
Verifiy signatures in until you find
1)  A mlExpansionHistory Attribute or
2)  The enclosed data is encryptedData
The signature which has this property is the "outer" signature.  If you
don't find an outer signature you add a new one.  If you find an outer
signature you strip everything including that signature and resign.  If you
find an outer signature from test 1 AND you find an encryptedData farther
in, you strip all signature to the encryptedData and then re-sign using the
"defined" outer signature.

This means that all sorts of critical attributes can be stripped off by an
MLA without notice to ANYBODY.  Is this acceptable?]

18) Sec 4.2, third para:  Recommend moving the following existing text from
the old para 1 to a new para that follows the mlExpansionHistory para:  "In
all cases, the MLA may need to perform access control before distributing
the message to mail list members if the message contains a SignedData block
and an associated eSSSecurityLabel attribute. If a eSSSecurityLabel
authenticated attribute is used for access control, then the signature of
the signerInfo block including the eSSSecurityLabel authenticated attribute
MUST be verified before using the security label.  The MLA should continue
parsing the MIME-encapsulated message to determine if there is a security
label associated with an encapsulated SignedData object. This may include
decrypting an EnvelopedData object to determine if an encapsulated
SignedData object includes a eSSSecurityLabel attribute."

[Jim Schaad: I agree we need to keep this]

20) Open Issues #1:  I agree that contentHints should be moved to CMS.
[Jim Schaad:  I suggested this.  I still think it is the right thing to do.]

21) Open Issues #2:  I believe that my recommended text for Sec 4.2 resolves
the MLA procesing issue.
[Jim Schaad:  Still open -- see above]

22) Open Issues #3:  I believe that the mlExpansionHistory size should be
left as 64.
[Jim Schaad:  Agreed -- Keep this at 64, I think it is probably far enough
that nobody should reasonably hit it.]

  

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>, "Tom Arnold" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Simple Commerce Messaging Protocol
Date: Tue, 10 Mar 1998 08:09:01 -0700
Sender: [email-masked]

Tom,

Could you forward me a copy of the draft associated with this proposal?  I
know we had discussed this initiative six months ago but it appears that
some additional work has been done since then.

Mike

-----Original Message-----
From: Tom Arnold <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Sunday, March 08, 1998 1:08 AM
Subject: Simple Commerce Messaging Protocol

>Hello all,
>
>In a prior discussion with Russ, we proposed expanding the group's charter
>to include a discussion of a S/MIME based commerce messaging protocol.
>After reviewing this withRuss, he suggested I ask the group for comments on
>the possiblity of extending the S/MIME working group's charter.  I've
>included an abstract from the document.
>
> Title : Simple Commerce Messaging Protocol (SCMP)
> Author(s) : T. Arnold, J. Pettitt, M. Myers
> Filename : draft-arnold-scmp.txt
> Pages : 11
> Date : 05-Feb-1998
>
>1. Introduction
>
>The Simple Commerce Messaging Protocol (SCMP) is a general-purpose
>commerce transport protocol for securely communicating a set of data
>from a sending agent’s application to a receiving agent’s server.
>The intent of this protocol is to define a method where trading
>partners can perform on-line business transactions in an environment
>where the sending partner is fully authenticated, and the message
>cannot be repudiated.
>
>The SCMP message content (referred to as message payload) is not
>intended to be defined or specified. This intent is to permit
>trading partners to either implement a standard commerce message
>format as in ANSI-X12 Electronic Data Interchange (EDI), EMAP
>General Internet commerce message format [BOSE], or any other
>proprietary transaction format.
>
>The only specification about the payload is that it be identified to
>the receiver utilizing a naming convention similar to standard MIME
>naming and formatting [MIME] is used to identify the type of payload
>contained in the SCMP data area.
>
>In this manner, SCMP fundamentally differs from many emerging
>Internet commerce message protocols, like the VISA sponsored Secure
>Electronic Transaction (SET) protocol. Beyond specifying the method
>for transport, encryption, authentication and handling, SET
>specifies the contents of the message and details how trading
>partners are to process and handle the messages. SCMP does not
>specify payload contents or how trading partners are expected to
>process requests, beyond gateway server handling.
>
>SCMP is intended as both an on-line and batch protocol.  The exact
>content of the message and the processing constraints are specified
>in SCMP- headers.
>

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>
Cc: [email-masked]
Subject: RE: MSG-01 Feedback
Date: Mon, 9 Mar 1998 15:58:40 -0800 
Sender: [email-masked]

Then it sounds like we have no problems.  I am glad as things seem to work
very well this way.

jim

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Saturday, March 07, 1998 4:52 PM
To: Jim Schaad (Exchange)
Cc: [email-masked]
Subject: Re: MSG-01 Feedback

At 12:27 PM 3/4/98 -0800, Jim Schaad (Exchange) wrote:
>3.  Section 2.5.2  This is a politics question and one I am not capable of
>deciding.  Do we need to change from using the IMC as the registration
agent
>for the OIDs of SMIMECapabilites?  I don't see any techincal reasons to
>change this at this point in time.  I don't see IMC as disappearing any
time
>soon and from what I hear it would be much faster to get updates than using
>IANA.  But I don't know if the IESG will be willing to leave this as it is.

IMC is not the registration agent for the S/MIME working group.  RSADSI
gave an arc to the working group when they released the S/MIME v2 and
related specifications.  I have performed the registration actions for that
arc.  That arc belongs to the IETF S/MIME WG.

IMC has been distributing information about the arc.  Paul has been very
helpful in distributing this information. TheS/MIME WG has geatly benifited
from the IMC Web site.

Russ

Date: Sat, 07 Mar 1998 19:51:51 -0500
To: "Jim Schaad (Exchange)" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: MSG-01 Feedback
Cc: [email-masked]
Sender: [email-masked]

At 12:27 PM 3/4/98 -0800, Jim Schaad (Exchange) wrote:
>3.  Section 2.5.2  This is a politics question and one I am not capable of
>deciding.  Do we need to change from using the IMC as the registration agent
>for the OIDs of SMIMECapabilites?  I don't see any techincal reasons to
>change this at this point in time.  I don't see IMC as disappearing any time
>soon and from what I hear it would be much faster to get updates than using
>IANA.  But I don't know if the IESG will be willing to leave this as it is.

IMC is not the registration agent for the S/MIME working group.  RSADSI
gave an arc to the working group when they released the S/MIME v2 and
related specifications.  I have performed the registration actions for that
arc.  That arc belongs to the IETF S/MIME WG.

IMC has been distributing information about the arc.  Paul has been very
helpful in distributing this information. TheS/MIME WG has geatly benifited
from the IMC Web site.

Russ

Date: Mon, 9 Mar 1998 14:39:47 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Checking abilities of ASN.1 compilers
Sender: [email-masked]

All,

In the enclosed message, when I said "Both toolkits support the "utf8String
[0] IMPLICIT UTF8String" as is", I really meant to say: "Both toolkits
support the "utf8String [0] IMPLICIT UTF8String" definition in which
"UTF8String" is replaced with "OCTET STRING"".  

Neither SNACC nor DSET support UTF8String as a standard type.  Bancroft's
Scott recommendation for ESSPrivacyMark (below) could still be used by 1988
toolkits if they include "UTF8String ::= OCTET STRING".  

- John Pawling

>All,
>
>We (VDA) use two ASN.1 toolkits: GNU SNACC freeware and DSET ASN.C v3.4.
>
>As retrieved from the GNU server, the SNACC freeware does not support
>"[UNIVERSAL 12]".  We made a minor enhancement to the SNACC freeware to
>expand the UNIVERSAL values that it would accept.  After we made this minor
>enhancement, then the "[UNIVERSAL 12]" trick worked.
>
>DSET supports the "[UNIVERSAL 12]" trick as is.
>
>Both toolkits support the "utf8String [0] IMPLICIT UTF8String" as is.
>
>Based on our results and Jim Schaad's trouble implementing "[UNIVERSAL 12]"
>(reported in an earlier message), we recommend ESSPrivacyMark should be:
>
>ESSPrivacyMark ::= CHOICE {
>    pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
>    utf8String   [0] IMPLICIT UTF8String (SIZE (1..ub-privacy-mark-length))
> }
>
>================================
>John Pawling   
>[email-masked]                             
>J.G. Van Dyke & Associates, Inc.           
>================================
>
>

Date: Mon, 9 Mar 1998 13:40:15 -0500 (EST)
From: Bancroft Scott <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, [email-masked]
Subject: Re: Checking abilities of ASN.1 compilers
Sender: [email-masked]

Paul,

The following which I posted a few weeks ago shows some pros and cons
of the various approaches.

I am not sure what you mean by: 

    On a related issue: why do people who support the second format want
    "[0]"?  This is unneeded since there's no chance the item will get
    confused with the PrintableString. 

What alternative would you suggest?  It is the key to forward
compatibility.

--------------------------------------------------------------------------
Bancroft Scott                                Toll Free    :1-888-OSS-ASN1
Open Systems Solutions, Inc.                  International:1-609-987-9073
[email-masked]                                  Tech Support :1-732-249-5107
http://www.oss.com                            Fax          :1-732-249-4636

---------- Forwarded message ----------
Date: Thu, 19 Feb 1998 00:25:19 -0500 (EST)
From: Bancroft Scott <[email-masked]>
To: "Jim Schaad (Exchange)" <[email-masked]>
Cc: 'Paul Hoffman / IMC' <[email-masked]>, [email-masked]
Subject: RE: Comment on ESS and Privacy Marks

On Wed, 18 Feb 1998, Jim Schaad (Exchange) wrote:

> At this point I am feeling really over my head on the question of UTF-8
> vs OCTECT string, I don't have enough knowledge to put in useful input
> on that issue.  My general impression however is that I would perfer to
> have the type explicit in this case rather than implicit.
> 
> Independent of that issue however, I think we should consider doing
> either an implicit [0] or explicit [0] tag on the utf8String field.
> Thus we would use
> 
> ESEPrivacyMark ::= CHOICE {
>  pString	PrintableString (SIZE (1..ub-privacy-mark-length)),
>  utf8String EXPLICIT [0] OCTET STRING
> }

I can not think of a single case where an explicit tag is useful on
type OCTET STRING, for the contents is always opaque and is never
affected by tagging, whether IMPLICIT or EXPLICIT.  Given this, the
only purpose that explicit tagging on this type serves is to increase
code size, message size and transmission time.

If we are hell-bent on using OCTET STRING to carry UTF8String
characters then I strongly recommend that you use an implicitly
tagged OCTET STRING.  That is:

 ESEPrivacyMark ::= CHOICE {
    pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
    utf8String   [0] IMPLICIT OCTET STRING -- MUST contain UTF-8-encoded characters
 }

The benefits of doing this are:

a) People who use tools that *do not* support UTF8String can accomplish
the same thing as they can if the type is tagged EXPLICIT, except that
there is no double tagging.  For those not familiar with the details, "[0]
EXPLICIT OCTET STRING" results in a double-tagged encoding of: 

	[0] length1 [UNIVERSAL 4] length2 UTF8String-value

whereas "[0] IMPLICIT OCTET STRING" results in an encoding of:

	[0] length UTF8String-value

b) People who use tools that *do* support UTF8String can leave the
definition as [0] IMPLICIT OCTET STRING if they wish, or they can change
the definition to "[0] IMPLICIT UTF8String" and end up with exactly the
same encoding as with no change.  The benefit to doing is that they can
then rely on the tool they are using to automatically check the validity
of the UTF8String value (especially during development) if they wish. 

c) Implicit tagging of OCTET STRING is most efficient all around and
does not impact anyone adversely.

d) If in a future version of S/MIME you choose to use valid ASN.1 
consisting solely of the current ASN.1 version, you will be able
to change the "[0] IMPLICIT OCTET STRING" to "[0] IMPLICIT UTF8String"
without affecting the bits on the wire (i.e., the resulting encoding),
whereas "[0] EXPLICIT OCTET STRING" cannot be changed to use UTF8String
under any circumstance without introducing interoperability problems.

e) "[0] IMPLICIT OCTET STRING is absolutely no pain to folks who wish to
use X.208-specific toolkits, for it is simply an implicitly tagged octet
string that they all support.

My personal preference is to define:

 ESEPrivacyMark ::= CHOICE {
    pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
    utf8String   [0] IMPLICIT UTF8String (SIZE (1..ub-privacy-mark-length))
 }

One benefit is that you are able to clearly express the type and properly
constrain it in size (something you can't do with OCTET STRING that
carries a UTF8String value, other than by a comment - see below.)  Another
benefit is that if someone is using a tool that does not support
UTF8String they can simply change it to "[0] OCTET STRING" and get the
same encoding.  The down side to this is that it is invalid ASN.1 since
the S/MIME module mixes use of UTF8String with ANY, but this violation
is already occuring since BMPString is being used, so matters are not
being made any worse.

> It would also be instructive to look at the issue of the size of the
> utf8String field.  It was limited to a specific length for the
> PrintableString version.  Should the utf8String version also be of
> limited length?

Yes, a length would be ideal, for it tells implementors the max number of
characters they need to support.  Note though that with OCTET STRING
there is no practical way to indicate the maximum number of characters
that is to be supported, only the maximum number of bytes used to encode
the character string value, for a size constraint on OCTET STRING 
is a byte count, while a size constraint on UTF8String is a count of
the number of characters.  

--------------------------------------------------------------------------
Bancroft Scott                                Toll Free    :1-888-OSS-ASN1
Open Systems Solutions, Inc.                  International:1-609-987-9073
[email-masked]                                  Tech Support :1-732-249-5107
http://www.oss.com                            Fax          :1-732-249-4636

From: "Jim Schaad (Exchange)" <[email-masked]>
To: [email-masked]
Subject: RE: Checking abilities of ASN.1 compilers
Date: Mon, 9 Mar 1998 10:25:20 -0800 
Sender: [email-masked]

I was running my ASN compiler last night, and I also discovered that we have
put UTF8String into ContentHints, so whatever solution/resolution we come to
should modify that structure as well.

jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, March 09, 1998 8:51 AM
To: [email-masked]
Subject: Re: Checking abilities of ASN.1 compilers

> From: Paul Hoffman / IMC <[email-masked]>
> So now people have asked instead for:
> 
> ESSPrivacyMark ::= CHOICE {
>     pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
>     utf8String   [0] IMPLICIT UTF8String
>  }
>
> without the UNIVERSAL 12 defintion. Before I do this, however, I want to
> check: whose compilers will choke on this? I would imagine that some
would,
> because the thing after the IMPLICIT is undefined. If no one's compiler
> chokes on this, I'd say we can go with it, but if some people's compilers
> die, then we're gonna have to get creative.
> 
> On a related issue: why do people who support the second format want
"[0]"?
> This is unneeded since there's no chance the item will get confused with
> the PrintableString.

The "[0] IMPLICIT" is the whole key to interoperability, because with
either "UTF8String" or "[0] EXPLICIT UTF8String" (the latter being silly,
as you note), the [UNIVERSAL 12] tag goes on the wire.  With the suggested
syntax, only the [CONTEXT 0] tag is sent, which is legal in all compilers.

I believe the suggestion was made for the syntax to be:

       utf8String  [0] IMPLICIT OCTET STRING  -- must contain a UTF8 string

If it is ever determined that 1997 compilers are widespread enough to
update the spec, then the definition could be changed to:

       utf8String  [0] IMPLICIT UTF8String

without any change to the bits on the wire.

(Someone has already noted that the first version is not an example of
the dreaded "octet string hole", because there is no explicit OCTET
STRING being used to encapsulate another data type.)

Date: Mon, 09 Mar 1998 10:12:02 -0800
To: [email-masked] (Tom Arnold), [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Simple Commerce Messaging Protocol
Cc: [email-masked]
Sender: [email-masked]

Hold it. We're discussing a security technology based on an introduction
when we can't look at the technology. We' just guessing, and that's a waste
of time. There have already been claims and counter-claims about SSL/TLS,
and the S/MIME WG is *not* the place for that debate, eh?

At 11:48 PM 3/7/98 -0800, Tom Arnold wrote:

>	Title		: Simple Commerce Messaging Protocol (SCMP)
>	Author(s)	: T. Arnold, J. Pettitt, M. Myers
>	Filename	: draft-arnold-scmp.txt
>	Pages		: 11
>	Date		: 05-Feb-1998

Nope, sorry, that draft doesn't exist. In fact, no draft with the word
"arnold" or "scmp" in its title exists. No draft with "Arnold" as an author
exists. No draft with "Commerce" in the title exists.

I propose that we cut off this thread right now, and wait until we can
actually read what is being proposed. We've got real-world work to do, and
debating unspecified technologies isn't going to help us here. When the
authors of the draft actually publish it instead of just talking about it,
we can decide whether or not it is appropriate for the S/MIME WG.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 9 Mar 1998 13:05:53 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Checking abilities of ASN.1 compilers
Sender: [email-masked]

All,

In the enclosed message, when I said "Both toolkits support the "utf8String
[0] IMPLICIT UTF8String" as is", I really meant to say: "Both toolkits
support the "utf8String [0] IMPLICIT UTF8String" definition in which
"UTF8String" is replaced with "OCTET STRING"".  

Neither SNACC nor DSET support UTF8String as a standard type.  Bancroft's
Scott recommendation for ESSPrivacyMark (below) could still be used by 1988
toolkits if they include "UTF8String ::= OCTET STRING".  

- John Pawling

>All,
>
>We (VDA) use two ASN.1 toolkits: GNU SNACC freeware and DSET ASN.C v3.4.
>
>As retrieved from the GNU server, the SNACC freeware does not support
>"[UNIVERSAL 12]".  We made a minor enhancement to the SNACC freeware to
>expand the UNIVERSAL values that it would accept.  After we made this minor
>enhancement, then the "[UNIVERSAL 12]" trick worked.
>
>DSET supports the "[UNIVERSAL 12]" trick as is.
>
>Both toolkits support the "utf8String [0] IMPLICIT UTF8String" as is.
>
>Based on our results and Jim Schaad's trouble implementing "[UNIVERSAL 12]"
>(reported in an earlier message), we recommend ESSPrivacyMark should be:
>
>ESSPrivacyMark ::= CHOICE {
>    pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
>    utf8String   [0] IMPLICIT UTF8String (SIZE (1..ub-privacy-mark-length))
> }
>
>================================
>John Pawling   
>[email-masked]                             
>J.G. Van Dyke & Associates, Inc.           
>================================
>
>

From: Rik Drummond <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: Simple Commerce Messaging Protocol
Date: Mon, 9 Mar 1998 11:46:56 -0600
Sender: [email-masked]

I guess then that I don't understand why and what the extended charter will 
offer over and above what the EDIINT workgroup has been doing. Just 
attempting to understand. Thanks, Rik

-----Original Message-----
From:	EKR [SMTP:[email-masked]]
Sent:	Monday, March 09, 1998 11:36 AM
To:	Rik Drummond
Cc:	'Tom Arnold'; [email-masked]
Subject:	Re: Simple Commerce Messaging Protocol

Rik Drummond <[email-masked]> writes:
> Thanks Tom.  Non-repudiation is supported with the current EDIINT spec. 
and
> this list workgroup's efforts. Quality of service can be handled by
> http/posts. Does SSL offer safety against man-in-the-middle attacks?
Yes.

-Ekr

--
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

To: Rik Drummond <[email-masked]>
Cc: "'Tom Arnold'" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Simple Commerce Messaging Protocol
From: EKR <[email-masked]>
Date: 09 Mar 1998 09:35:48 -0800
Lines: 11
Sender: [email-masked]

Rik Drummond <[email-masked]> writes:
> Thanks Tom.  Non-repudiation is supported with the current EDIINT spec. and 
> this list workgroup's efforts. Quality of service can be handled by 
> http/posts. Does SSL offer safety against man-in-the-middle attacks?
Yes.

-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

Date: Mon, 09 Mar 1998 09:12:15 -0800
From: [email-masked] (Bob Relyea)
To: Rik Drummond <[email-masked]>
CC: "'Tom Arnold'" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Simple Commerce Messaging Protocol
Sender: [email-masked]

Rik Drummond wrote:

> Thanks Tom.  Non-repudiation is supported with the current EDIINT spec. and
> this list workgroup's efforts. Quality of service can be handled by
> http/posts. Does SSL offer safety against man-in-the-middle attacks?

Yes. That was one of the design points of SSL. (and also why proxy servers can
only pass SSL traffic, not cache it).

SSL also defends against replay attacks.  It would be pretty useless if it
didn't provide these functions.

Date: Mon, 9 Mar 1998 11:50:33 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Checking abilities of ASN.1 compilers
Sender: [email-masked]

> From: Paul Hoffman / IMC <[email-masked]>
> So now people have asked instead for:
> 
> ESSPrivacyMark ::= CHOICE {
>     pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
>     utf8String   [0] IMPLICIT UTF8String
>  }
>
> without the UNIVERSAL 12 defintion. Before I do this, however, I want to
> check: whose compilers will choke on this? I would imagine that some would,
> because the thing after the IMPLICIT is undefined. If no one's compiler
> chokes on this, I'd say we can go with it, but if some people's compilers
> die, then we're gonna have to get creative.
> 
> On a related issue: why do people who support the second format want "[0]"?
> This is unneeded since there's no chance the item will get confused with
> the PrintableString.

The "[0] IMPLICIT" is the whole key to interoperability, because with
either "UTF8String" or "[0] EXPLICIT UTF8String" (the latter being silly,
as you note), the [UNIVERSAL 12] tag goes on the wire.  With the suggested
syntax, only the [CONTEXT 0] tag is sent, which is legal in all compilers.

I believe the suggestion was made for the syntax to be:

       utf8String  [0] IMPLICIT OCTET STRING  -- must contain a UTF8 string

If it is ever determined that 1997 compilers are widespread enough to
update the spec, then the definition could be changed to:

       utf8String  [0] IMPLICIT UTF8String

without any change to the bits on the wire.

(Someone has already noted that the first version is not an example of
the dreaded "octet string hole", because there is no explicit OCTET
STRING being used to encapsulate another data type.)

From: Rik Drummond <[email-masked]>
To: "'Tom Arnold'" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Simple Commerce Messaging Protocol
Date: Mon, 9 Mar 1998 10:51:40 -0600
Sender: [email-masked]

Thanks Tom.  Non-repudiation is supported with the current EDIINT spec. and 
this list workgroup's efforts. Quality of service can be handled by 
http/posts. Does SSL offer safety against man-in-the-middle attacks?

Best regards, Rik
-----Original Message-----
From:	Tom Arnold [SMTP:[email-masked]]
Sent:	Monday, March 09, 1998 10:17 AM
To:	Rik Drummond; [email-masked]
Subject:	RE: Simple Commerce Messaging Protocol

At 07:33 AM 3/9/98 -0600, Rik Drummond wrote:
>Interesting.... what will this will give use over and above SSL (using the
HTTP/Post protocol) for the non-store-and-forward application?
>

Thanks for the comment.

Non-repudiation, defense against man-in-the-middle replay attacks, and
quality of services to suggest a couple.

>Best Regards, Rik
>
>-----Original Message-----
>From:	Tom Arnold [SMTP:[email-masked]]
>Sent:	Sunday, March 08, 1998 1:48 AM
>To:	[email-masked]
>Cc:	[email-masked]
>Subject:	Simple Commerce Messaging Protocol
>
>Hello all,
>
>In a prior discussion with Russ, we proposed expanding the group's charter
>to include a discussion of a S/MIME based commerce messaging protocol.
>After reviewing this withRuss, he suggested I ask the group for comments 
on
>the possiblity of extending the S/MIME working group's charter.  I've
>included an abstract from the document.
>
>	Title		: Simple Commerce Messaging Protocol (SCMP)
>	Author(s)	: T. Arnold, J. Pettitt, M. Myers
>	Filename	: draft-arnold-scmp.txt
>	Pages		: 11
>	Date		: 05-Feb-1998
>
>1. Introduction
>
>The Simple Commerce Messaging Protocol (SCMP) is a general-purpose
>commerce transport protocol for securely communicating a set of data
>from a sending agent's application to a receiving agent's server.
>The intent of this protocol is to define a method where trading
>partners can perform on-line business transactions in an environment
>where the sending partner is fully authenticated, and the message
>cannot be repudiated.
>
>The SCMP message content (referred to as message payload) is not
>intended to be defined or specified. This intent is to permit
>trading partners to either implement a standard commerce message
>format as in ANSI-X12 Electronic Data Interchange (EDI), EMAP
>General Internet commerce message format [BOSE], or any other
>proprietary transaction format.
>
>The only specification about the payload is that it be identified to
>the receiver utilizing a naming convention similar to standard MIME
>naming and formatting [MIME] is used to identify the type of payload
>contained in the SCMP data area.
>
>In this manner, SCMP fundamentally differs from many emerging
>Internet commerce message protocols, like the VISA sponsored Secure
>Electronic Transaction (SET) protocol. Beyond specifying the method
>for transport, encryption, authentication and handling, SET
>specifies the contents of the message and details how trading
>partners are to process and handle the messages. SCMP does not
>specify payload contents or how trading partners are expected to
>process requests, beyond gateway server handling.
>
>SCMP is intended as both an on-line and batch protocol.  The exact
>content of the message and the processing constraints are specified
>in SCMP- headers.
>

Tom Arnold
VP of Engineering
CyberSource Corporation
[email-masked]

Date: Mon, 9 Mar 1998 11:41:37 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Checking abilities of ASN.1 compilers
Sender: [email-masked]

All,

We (VDA) use two ASN.1 toolkits: GNU SNACC freeware and DSET ASN.C v3.4.

As retrieved from the GNU server, the SNACC freeware does not support
"[UNIVERSAL 12]".  We made a minor enhancement to the SNACC freeware to
expand the UNIVERSAL values that it would accept.  After we made this minor
enhancement, then the "[UNIVERSAL 12]" trick worked.

DSET supports the "[UNIVERSAL 12]" trick as is.

Both toolkits support the "utf8String [0] IMPLICIT UTF8String" as is.

Based on our results and Jim Schaad's trouble implementing "[UNIVERSAL 12]"
(reported in an earlier message), we recommend ESSPrivacyMark should be:

ESSPrivacyMark ::= CHOICE {
    pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
    utf8String   [0] IMPLICIT UTF8String (SIZE (1..ub-privacy-mark-length))
 }

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

Date: Mon, 9 Mar 1998 11:31:09 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Simple Commerce Messaging Protocol
Sender: [email-masked]

> From: [email-masked] (Tom Arnold)
> 
>  The SCMP message content (referred to as message payload) is not 
>  intended to be defined or specified.
>
>  The only specification about the payload is that it be identified to 
>  the receiver utilizing a naming convention similar to standard MIME 
>  naming and formatting [MIME] is used to identify the type of payload 
>  contained in the SCMP data area.

Tom,

It would be helpful if you described the manner in which the S/MIME WG
charter would need to be modified to accommmodate SCMP.  We all hope and
expect that S/MIME will be useful and used for carrying all types of
protected content, including commerce messages in standard or proprietary
transaction formats.

But if you are not intending to specify the content format, and the
existing CMS specification allows any content type (treats encapsulated
content as an opaque blob), what more needs to be done in this WG?

And instead of using a naming format "similar to standard MIME", why
not just define real standard MIME types for commerce data objects,
enabling SCMP messages to be carried by any MIME software?

I haven't seen the entire SCMP draft, but it seems that this basic
statement of purpose should appear in the abstract.

Dave Kemp

Date: Mon, 09 Mar 1998 08:16:52 -0800
To: Rik Drummond <[email-masked]>, "[email-masked]" <[email-masked]>
From: [email-masked] (Tom Arnold)
Subject: RE: Simple Commerce Messaging Protocol
Sender: [email-masked]

At 07:33 AM 3/9/98 -0600, Rik Drummond wrote:
>Interesting.... what will this will give use over and above SSL (using the
HTTP/Post protocol) for the non-store-and-forward application?
>

Thanks for the comment.

Non-repudiation, defense against man-in-the-middle replay attacks, and
quality of services to suggest a couple.

>Best Regards, Rik
>
>-----Original Message-----
>From:	Tom Arnold [SMTP:[email-masked]]
>Sent:	Sunday, March 08, 1998 1:48 AM
>To:	[email-masked]
>Cc:	[email-masked]
>Subject:	Simple Commerce Messaging Protocol
>
>Hello all,
>
>In a prior discussion with Russ, we proposed expanding the group's charter
>to include a discussion of a S/MIME based commerce messaging protocol.
>After reviewing this withRuss, he suggested I ask the group for comments on
>the possiblity of extending the S/MIME working group's charter.  I've
>included an abstract from the document.
>
>	Title		: Simple Commerce Messaging Protocol (SCMP)
>	Author(s)	: T. Arnold, J. Pettitt, M. Myers
>	Filename	: draft-arnold-scmp.txt
>	Pages		: 11
>	Date		: 05-Feb-1998
>
>1. Introduction
>
>The Simple Commerce Messaging Protocol (SCMP) is a general-purpose 
>commerce transport protocol for securely communicating a set of data 
>from a sending agent's application to a receiving agent's server. 
>The intent of this protocol is to define a method where trading 
>partners can perform on-line business transactions in an environment 
>where the sending partner is fully authenticated, and the message 
>cannot be repudiated.
>
>The SCMP message content (referred to as message payload) is not 
>intended to be defined or specified. This intent is to permit 
>trading partners to either implement a standard commerce message 
>format as in ANSI-X12 Electronic Data Interchange (EDI), EMAP 
>General Internet commerce message format [BOSE], or any other 
>proprietary transaction format.  
>
>The only specification about the payload is that it be identified to 
>the receiver utilizing a naming convention similar to standard MIME 
>naming and formatting [MIME] is used to identify the type of payload 
>contained in the SCMP data area.
>
>In this manner, SCMP fundamentally differs from many emerging 
>Internet commerce message protocols, like the VISA sponsored Secure 
>Electronic Transaction (SET) protocol. Beyond specifying the method 
>for transport, encryption, authentication and handling, SET 
>specifies the contents of the message and details how trading 
>partners are to process and handle the messages. SCMP does not 
>specify payload contents or how trading partners are expected to 
>process requests, beyond gateway server handling.
>
>SCMP is intended as both an on-line and batch protocol.  The exact 
>content of the message and the processing constraints are specified 
>in SCMP- headers.
>

Tom Arnold
VP of Engineering
CyberSource Corporation
[email-masked]

From: Rik Drummond <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RE: Simple Commerce Messaging Protocol
Date: Mon, 9 Mar 1998 07:33:34 -0600
Sender: [email-masked]

Interesting.... what will this will give use over and above SSL (using the HTTP/Post protocol) for the non-store-and-forward application?

Best Regards, Rik

-----Original Message-----
From:	Tom Arnold [SMTP:[email-masked]]
Sent:	Sunday, March 08, 1998 1:48 AM
To:	[email-masked]
Cc:	[email-masked]
Subject:	Simple Commerce Messaging Protocol

Hello all,

In a prior discussion with Russ, we proposed expanding the group's charter
to include a discussion of a S/MIME based commerce messaging protocol.
After reviewing this withRuss, he suggested I ask the group for comments on
the possiblity of extending the S/MIME working group's charter.  I've
included an abstract from the document.

	Title		: Simple Commerce Messaging Protocol (SCMP)
	Author(s)	: T. Arnold, J. Pettitt, M. Myers
	Filename	: draft-arnold-scmp.txt
	Pages		: 11
	Date		: 05-Feb-1998

1. Introduction

The Simple Commerce Messaging Protocol (SCMP) is a general-purpose 
commerce transport protocol for securely communicating a set of data 
from a sending agent's application to a receiving agent's server. 
The intent of this protocol is to define a method where trading 
partners can perform on-line business transactions in an environment 
where the sending partner is fully authenticated, and the message 
cannot be repudiated.

The SCMP message content (referred to as message payload) is not 
intended to be defined or specified. This intent is to permit 
trading partners to either implement a standard commerce message 
format as in ANSI-X12 Electronic Data Interchange (EDI), EMAP 
General Internet commerce message format [BOSE], or any other 
proprietary transaction format.  

The only specification about the payload is that it be identified to 
the receiver utilizing a naming convention similar to standard MIME 
naming and formatting [MIME] is used to identify the type of payload 
contained in the SCMP data area.

In this manner, SCMP fundamentally differs from many emerging 
Internet commerce message protocols, like the VISA sponsored Secure 
Electronic Transaction (SET) protocol. Beyond specifying the method 
for transport, encryption, authentication and handling, SET 
specifies the contents of the message and details how trading 
partners are to process and handle the messages. SCMP does not 
specify payload contents or how trading partners are expected to 
process requests, beyond gateway server handling.

SCMP is intended as both an on-line and batch protocol.  The exact 
content of the message and the processing constraints are specified 
in SCMP- headers.

Date: Sun, 08 Mar 1998 19:33:19 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Checking abilities of ASN.1 compilers
Sender: [email-masked]

Man, we've been all around this #$%^ UTF8String mess. The current ESS uses:

UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
. . .
ESSPrivacyMark ::= CHOICE {
    pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
    utf8String   UTF8String
}

This poses a problem for people whose ASN.1 compiler is unable to do the
first part (namely the OSS compiler). So now people have asked instead for:

ESSPrivacyMark ::= CHOICE {
    pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
    utf8String   [0] IMPLICIT UTF8String
 }
without the UNIVERSAL 12 defintion. Before I do this, however, I want to
check: whose compilers will choke on this? I would imagine that some would,
because the thing after the IMPLICIT is undefined. If no one's compiler
chokes on this, I'd say we can go with it, but if some people's compilers
die, then we're gonna have to get creative.

On a related issue: why do people who support the second format want "[0]"?
This is unneeded since there's no chance the item will get confused with
the PrintableString.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Sat, 07 Mar 1998 23:48:29 -0800
To: [email-masked]
From: [email-masked] (Tom Arnold)
Subject: Simple Commerce Messaging Protocol
Cc: [email-masked]
Sender: [email-masked]

Hello all,

In a prior discussion with Russ, we proposed expanding the group's charter
to include a discussion of a S/MIME based commerce messaging protocol.
After reviewing this withRuss, he suggested I ask the group for comments on
the possiblity of extending the S/MIME working group's charter.  I've
included an abstract from the document.

	Title		: Simple Commerce Messaging Protocol (SCMP)
	Author(s)	: T. Arnold, J. Pettitt, M. Myers
	Filename	: draft-arnold-scmp.txt
	Pages		: 11
	Date		: 05-Feb-1998

1. Introduction

The Simple Commerce Messaging Protocol (SCMP) is a general-purpose 
commerce transport protocol for securely communicating a set of data 
from a sending agent’s application to a receiving agent’s server. 
The intent of this protocol is to define a method where trading 
partners can perform on-line business transactions in an environment 
where the sending partner is fully authenticated, and the message 
cannot be repudiated.

The SCMP message content (referred to as message payload) is not 
intended to be defined or specified. This intent is to permit 
trading partners to either implement a standard commerce message 
format as in ANSI-X12 Electronic Data Interchange (EDI), EMAP 
General Internet commerce message format [BOSE], or any other 
proprietary transaction format.  

The only specification about the payload is that it be identified to 
the receiver utilizing a naming convention similar to standard MIME 
naming and formatting [MIME] is used to identify the type of payload 
contained in the SCMP data area.

In this manner, SCMP fundamentally differs from many emerging 
Internet commerce message protocols, like the VISA sponsored Secure 
Electronic Transaction (SET) protocol. Beyond specifying the method 
for transport, encryption, authentication and handling, SET 
specifies the contents of the message and details how trading 
partners are to process and handle the messages. SCMP does not 
specify payload contents or how trading partners are expected to 
process requests, beyond gateway server handling.

SCMP is intended as both an on-line and batch protocol.  The exact 
content of the message and the processing constraints are specified 
in SCMP- headers.

From: "Surendra Reddy" <[email-masked]>
To: <[email-masked]>
Subject: RE: Redundant Cert Mgmt Protocols
Date: Fri, 6 Mar 1998 15:02:45 -0800
Sender: [email-masked]

>I'd like to take a different approach to what John said. I think that
> the S/MIME
> spec should simply get out of the PKI business. S/MIME v3 tells how to
> send
> end-to-end secure messages, and does not need to deal with how you
> should talk
> to your CA. 

This makes absolute sense.I support this idea.This is only the way we can
take  PKI  hurdles out of S/MIME. May be someone can write up
an informational RFC describing PKI in the context of SMIME.

-- Surendra

> -----Original Message-----
> From: Paul Hoffman / IMC [SMTP:[email-masked]]  
> Sent: Monday, February 02, 1998 2:07 PM
> To: [email-masked] [SMTP:[email-masked]] 
> Subject: Re: Redundant Cert Mgmt Protocols
> 
> I'd like to take a different approach to what John said. I think that
> the S/MIME
> spec should simply get out of the PKI business. S/MIME v3 tells how to
> send
> end-to-end secure messages, and does not need to deal with how you
> should talk
> to your CA. The latest -cert spec shows how awful the PKI stuff can
> get.
> 
> A bit of history: S/MIME v2 included two PKI functions:
> - enrolling or requesting a cert
> - getting a CRL list
> 
> These both use PKCS 10 due to the fact that PKIX wasn't around.
> Unfortunately,
> PKIX part 3, which specifies how to do these actions, is still not
> around, and I
> suspect it is many months off due to political hassles in the PKIX WG.
> The
> CMP/CRS/CRMF debates seem like so much posturing, given that all
> parties agree
> that the other parties have no or few technical problems. However,
> they are
> absolutely getting in the way of S/MIME.
> 
> It is not clear to me that S/MIME v3 needs to do any PKI. Instead, we
> can
> mandate:
> - a sending MUA already has a cert (instead of telling them how to get
> one)
> - a receiving MUA already know how to get a CRL (instead of telling
> them how to
> get one)
> If we make these two assumptions, we can strip out most of the guck
> that has
> appeared in -cert. Of course, we should give guidance about how both
> of these
> were done in the past, as well as saying that it is likely that PKIX
> will finish
> at some point and implementors might want to look at that for PKI
> work.
> 
> If there is general agreement on the principle of us not specifying
> how to do
> PKI, I'll draft a list of changes to the current -cert draft and
> circulate it
> here on the list so Blake has a good shot at both what to take out as
> well as
> what suggestions to put in.
> 
> 
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium

Date: Fri, 6 Mar 1998 17:07:14 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: RE: ESS-01 issues not finished
Sender: [email-masked]

All,

I agree with Dave's recommendation except that I believe that the user agent
MUST warn the user when non-identical eSSSecurityLabel attributes are
verified.  Recommend that ESS, Sec 3.1.1, last two paras, and Sec 3.1.2,
first para, should be replaced with the following paras:    

"There can be multiple SignerInfos within a SignedData object, and each
SignerInfo may include authenticatedAttributes. Therefore, a single
SignedData object may include multiple eSSSecurityLabels, each SignerInfo
having an eSSSecurityLabel attribute. For example, an originator can send a
signed message with two SignerInfos, one containing a DSS signature, the
other containing an RSA signature. If any of the SignerInfos included in
a SignedData object include an eSSSecurityLabel attribute, then all of 
the SignerInfos in that SignedData object MUST include an eSSSecurityLabel
attribute and the value of each MUST be identical.

3.1.2 Processing Security Labels

Before processing an eSSSecurityLabel authenticatedAttribute, the receiving
agent MUST verify the signature of the SignerInfo which covers the
eSSSecurityLabel attribute.  A recipient MUST NOT process an eSSSecurityLabel 
attribute that has not been verified.

A receiving agent MUST process the eSSSecurityLabel attribute, if present, 
in each SignerInfo in the SignedData object for which it verifies the 
signature. This may result in the receiving agent processing multiple
eSSSecurityLabels included in a single SignedData object. Because all
eSSSecurityLabels in a SignedData object must be identical, the 
receiving agent processes (such as performing access control) 
on the first eSSSecurityLabel that it encounters in a SignerInfo that
it verifies, and then ensures that all other eSSSecurityLabels in
signerInfos that it verifies are identical to the first one encountered.
If the eSSSecurityLabels in the signerInfos that it verifies are not
all identical, then the receiving agent MUST warn the user of this 
condition."

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: ESS-03 Comments
Date: Fri, 6 Mar 1998 13:41:14 -0800 
Sender: [email-masked]

There are three occurences of innterboundaries and that is correct.  They
occur before, after and between each section of a mulitpart object.  There
is only one terminiator boundary (with the trailing --) as is corect.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 06, 1998 1:16 PM
To: Ietf-Smime (E-mail)
Subject: RE: ESS-03 Comments

Jim,

I agree with your addition of the "%" characters to the lines marked "[step
2]".

I am not a MIME expert, so I am not going to debate your other changes.
However, there are three occurrences of the following line:  "[step 4]
--innerboundary--       |)".  Is that correct??

- John Pawling

Date: Fri, 6 Mar 1998 16:16:16 -0500
To: "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: ESS-03 Comments
Sender: [email-masked]

Jim,

I agree with your addition of the "%" characters to the lines marked "[step 2]".

I am not a MIME expert, so I am not going to debate your other changes.
However, there are three occurrences of the following line:  "[step 4]
--innerboundary--       |)".  Is that correct??

- John Pawling

From: "Flanigan, Bill" <[email-masked]>
To: Paul Hoffman / IMC <[email-masked]>, [email-masked]
Subject: RE: Redundant Cert Mgmt Protocols
Date: Fri, 6 Mar 1998 15:50:25 -0500
Sender: [email-masked]

This makes sense raised to the power of at least 10.  It also makes the
"S" in S/MIME stand for both "Secure" and "Simple."  Let's do it!

Bill Flanigan

> -----Original Message-----
> From:	Paul Hoffman / IMC [SMTP:[email-masked]]  
> Sent:	Monday, February 02, 1998 2:07 PM
> To:	[email-masked] [SMTP:[email-masked]] 
> Subject:	Re: Redundant Cert Mgmt Protocols
> 
> I'd like to take a different approach to what John said. I think that
> the S/MIME
> spec should simply get out of the PKI business. S/MIME v3 tells how to
> send
> end-to-end secure messages, and does not need to deal with how you
> should talk
> to your CA. The latest -cert spec shows how awful the PKI stuff can
> get.
> 
> A bit of history: S/MIME v2 included two PKI functions:
> - enrolling or requesting a cert
> - getting a CRL list
> 
> These both use PKCS 10 due to the fact that PKIX wasn't around.
> Unfortunately,
> PKIX part 3, which specifies how to do these actions, is still not
> around, and I
> suspect it is many months off due to political hassles in the PKIX WG.
> The
> CMP/CRS/CRMF debates seem like so much posturing, given that all
> parties agree
> that the other parties have no or few technical problems. However,
> they are
> absolutely getting in the way of S/MIME.
> 
> It is not clear to me that S/MIME v3 needs to do any PKI. Instead, we
> can
> mandate:
> - a sending MUA already has a cert (instead of telling them how to get
> one)
> - a receiving MUA already know how to get a CRL (instead of telling
> them how to
> get one)
> If we make these two assumptions, we can strip out most of the guck
> that has
> appeared in -cert. Of course, we should give guidance about how both
> of these
> were done in the past, as well as saying that it is likely that PKIX
> will finish
> at some point and implementors might want to look at that for PKI
> work.
> 
> If there is general agreement on the principle of us not specifying
> how to do
> PKI, I'll draft a list of changes to the current -cert draft and
> circulate it
> here on the list so Blake has a good shot at both what to take out as
> well as
> what suggestions to put in.
> 
> 
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "Paul Hoffman (E-mail)" <[email-masked]>, "John Pawling (E-mail)" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: ESS-03 Comments
Date: Fri, 6 Mar 1998 12:53:01 -0800 
Sender: [email-masked]

A correction to John's correction.

3)  Section 1.2 -- actually I have a few changes from what John said.
NEW:
[step 8] Content-type: multipart/signed;
[step 8]    protocol="application/pkcs7-signature";
[step 8]    boundary=outerboundary
[step 8]
[step 8] --outerboundary
[step 6] Content-type: application/pkcs7-mime;          )
[step 6]    smime-type=enveloped-data                   )
[step 6]                                                )
[step 5] envelopedData block                            )
[step 5]                                              | )
[step 4] Content-type: multipart/signed;              | )
[step 4]    protocol="application/pkcs7-signature";   | )
[step 4]    boundary=innerboundary                    | )
[step 4]                                              | )
[step 4] --innerboundary                              | )
[step 2] Content-type: text/plain                   % | )
[step 2]                                            % | )
[step 1] Original content                           % | )
[step 4]                                              | )
[step 4] --innerboundary                              | )
[step 4] Content-type: application/pkcs7-signature    | )
[step 4]                                              | )
[step 3] inner SignedData block (eContent is missing) | )
[step 6]								| )
[step 4] --innerboundary--					| )
[step 8]
[step 8] --outerboundary
[step 8] Content-type: application/pkcs7-signature
[step 8]
[step 7] Outer SignedData block (eContent is missing) 
[step 8]
[step 8] --outerboundary--    

Date: Fri, 6 Mar 1998 15:18:30 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: ESS-03 Comments
Sender: [email-masked]

All,

IMHO, Paul has done a fabulous job of incorporating the group's comments
into ESS-03.  I have the following comments regarding the 1 Mar 98 ESS-03 I-D:

1) Sec 1.1.2, bullet 3:  Please change as follows:

OLD:
"3. Sign the result of step 2 (the inner MIME headers and the original
content). The SignedData structure is encapsulated by a ContentInfo SEQUENCE
with a contentType of data. If the structure you create in step 4 is
multipart/signed, the eContent is missing; if the structure you create in
step 4 is application/pkcs7-mime, the eContent is the result of step 2 above."

NEW:
"3. Sign the result of step 2 (the inner MIME headers and the original
content). The SignedData encapContentInfo eContentType object identifier
MUST be id-data.  If the structure you create in step 4 is multipart/signed,
then the SignedData encapContentInfo eContent MUST be absent.  If the
structure you create in step 4 is application/pkcs7-mime, then the
SignedData encapContentInfo eContent MUST contain the result of step 2
above.  The SignedData structure is encapsulated by a ContentInfo SEQUENCE
with a contentType of id-signedData."

2) Sec 1.1.2, bullet 5:  Please change as follows:

OLD:
"5. Encrypt the result of step 4 as a single block, turning it into an
application/pkcs7-mime object. The EnvelopedData structure is encapsulated
by a ContentInfo SEQUENCE with a contentType of data. This is called the
"encrypted body"."

NEW:
"5. Encrypt the result of step 4 as a single block, turning it into an
application/pkcs7-mime object. The EnvelopedData encryptedContentInfo
contentType MUST be id-data.  The EnvelopedData structure is encapsulated by
a ContentInfo SEQUENCE with a contentType of id-envelopedData. This is
called the "encrypted body"."

3) Sec 1.2:  Please change the triple wrapped message example that uses
multipart/signed for both signatures as follows:  
NEW:
[step 8] Content-type: multipart/signed;
[step 8]    protocol="application/pkcs7-signature";
[step 8]    boundary=outerboundary
[step 8]
[step 8] --outerboundary
[step 6] Content-type: application/pkcs7-mime;          )
[step 6]    smime-type=enveloped-data                   )
[step 6]                                                )
[step 5] envelopedData block                            )
[step 5]                                              | )
[step 4] Content-type: multipart/signed;              | )
[step 4]    protocol="application/pkcs7-signature";   | )
[step 4]    boundary=innerboundary                    | )
[step 4]                                              | )
[step 4] --innerboundary                              | )
[step 2] Content-type: text/plain                     | )
[step 2]                                              | )
[step 1] Original content                           % | )
[step 4]                                              | )
[step 4] --innerboundary                              | )
[step 4] Content-type: application/pkcs7-signature    | )
[step 4]                                              | )
[step 3] inner SignedData block (eContent is missing) | )
[step 6]
[step 8] --outerboundary
[step 8] Content-type: application/pkcs7-signature
[step 8]
[step 7] Outer SignedData block (eContent is missing)     

4) Sec 1.2: Please change the sentence immediately prior to the triple
wrapped message example that uses application/pkcs7-mime for both signatures
as follows:  

OLD:
"The format of a triple wrapped message that uses application/pkcs7-mime for
the outer signature is:"

NEW:
"The format of a triple wrapped message that uses application/pkcs7-mime for
both signatures is:"

5) Sec 1.2:  Please change the triple wrapped message example that uses
application/pkcs7-mime for both signatures as follows:  
NEW:
[step 8] Content-type: application/pkcs7-mime;
[step 8]    smime-type=signed-data
[step 8]
[step 7] Outer SignedData block (eContent is present)       !
[step 6] Content-type: application/pkcs7-mime;            )
[step 6]    smime-type=enveloped-data;                    )
[step 6]                                                  )
[step 5] envelopedData block                              )
[step 5]                                                | )
[step 4] Content-type: application/pkcs7-mime;          | )
[step 4]    smime-type=signed-data                      | )
[step 4]                                                | )
[step 3] Inner SignedData block (eContent is present) $ | )

6) Sec 2.3, Bullet 2.2: Please append "in the outer signedData layer" to the
following:  "2.2. If the value of allOrFirstTier is firstTierRecipients, do
one of the following two steps based on the presence of an
mlExpansionHistory attribute:"

7) Sec 2.3, Flow Chart: Please append "in outer signedData" to the
following: "1. Has mlExpansionHistory?"

8) Sec 2.3, Flow Chart: Please change "1.2.1. Use ML's policy, then -> STOP"
to "1.2.2. STOP".  IMHO, this change is required because the ML's policy is
to STOP.  The current wording implies that the software must do something
based on the ML's policy and then STOP.

9) Sec 2.3, Flow Chart: Please append "in outer signedData" to the
following: "2.2. Has mlExpansionHistory?"

10) Sec 2.4, bullet 1.1: Please delete "ASN.1 DER encoded" from the
following sentence: "1.1. The ASN.1 DER encoded content of the original
signedData object is digested as described in [CMS]."

11) Sec 2.4, bullet 2.2: Please make the following change:

OLD:
"2.2. The original signedData encapContentInfo eContentType object
identifier is copied into the Receipt contentType."

NEW:
"2.2. The object identifier from the contentType attribute included in the
original signedData signerInfo that includes the receiptRequest attribute is
copied into the Receipt contentType."

Note about the change: The signerInfo contentType OID and signedData
encapContentInfo eContentType OID express the same value, so this change
does not change the outcome of the processing described by this text.  This
change makes the Signed Receipt creation process consistent with other
sections of the text that deal with the signed receipt verification process.
In other words, this single change saves us from having to make several
other changes.

12) Sec 2.4, bullet 2.4: Please add the following bullet: "2.4. The
signature value from the original signedData signerInfo that includes the
receiptRequest attribute is copied into the Receipt originatorSignatureValue."

13) Sec 2.4, bullet 9, 2nd sent:  Please change "eContent" to "eContentType"
in the following sent: "The
id-ct-receipt object identifier MUST be included in the signedData
encapContentInfo eContent."

14) Sec 2.4.1, last sent:  Please change as follows:

OLD:
"The MLA cannot change the authenticatedAttributes of the received
SignedData/Receipt object, so it can't add the MLExpansionHistory to the
SignedData/Receipt."

NEW:
"The MLA cannot change the authenticatedAttributes of the received
SignedData/Receipt object without invalidating the signature, so the MLA
MUST NOT add the MLExpansionHistory to the SignedData/Receipt."

15) Sec 2.7: Please delete the following sent: "A contentType attribute
including the id-ct-receipt object identifier must be part of the receipt
request."

16) Sec 3.2 and Appendix A: Recommend that ESSPrivacyMark should be changed
to the following:

ESSPrivacyMark ::= CHOICE {
    pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
    utf8String   [0] IMPLICIT UTF8String (SIZE (1..ub-privacy-mark-length))
 }

17) Sec 4.2, first para:  This change addresses the Open Issue regarding MLA
processing.  Please replace the first para with: "MLA message processing
depends on the structure of the S/MIME layers in the message sent to the MLA
for expansion.  For example, an entity can send a single-wrapped signedData
or envelopedData message to an MLA.  As another example, an entity can send
a double-wrapped message (i.e. signed and enveloped;  enveloped and signed;
signed and signed; etc) to an MLA.  As another example, an entity can send a
quadruple-wrapped message to the MLA (i.e. a well-formed triple-wrapped
message was sent through a gateway that added an outer SignedData layer).
In all cases, the MLA MUST sign the message and create a new "outer"
signedData layer encapsulating the message before it distributes it to the
ML members.  Furthermore, it MUST add or update an mlExpansionHistory
attribute to document MLA processing.

When a S/MIME message is received by the MLA, it MUST first determine if
there is an outer signedData layer that already includes an
mlExpansionHistory attribute.  If there are several outer signedData layers,
then the MLA MUST decode each of the outer layers to determine if any of
them include an mlExpansionHistory attribute.  If the MLA finds a signedData
layer that includes an mlExpansionHistory attribute, then that is the
"outer" signedData layer that is referred to in the rest of this section.
In this case, the MLA must strip off the "outer" layer (after remembering
the included authenticated attributes) and must strip off all of the
signedData layers that encapsulated the "outer" layer.  This is required
because the MLA MUST change the existing mlExpansionHistory attribute and
that change invalidates all of the encapsulating signedData signatures. 

If the MLA decodes the outer signedData layers and does not find an
mlExpansionHistory attribute, then the MLA MUST add a new signedData layer
that encapsulates all of the existing signedData layers.  In this case, the
new signedData layer created by the MLA is the "outer" signedData layer that
is referred to in the rest of this section."

18) Sec 4.2, third para:  Recommend moving the following existing text from
the old para 1 to a new para that follows the mlExpansionHistory para:  "In
all cases, the MLA may need to perform access control before distributing
the message to mail list members if the message contains a SignedData block
and an associated eSSSecurityLabel attribute. If a eSSSecurityLabel
authenticated attribute is used for access control, then the signature of
the signerInfo block including the eSSSecurityLabel authenticated attribute
MUST be verified before using the security label.  The MLA should continue
parsing the MIME-encapsulated message to determine if there is a security
label associated with an encapsulated SignedData object. This may include
decrypting an EnvelopedData object to determine if an encapsulated
SignedData object includes a eSSSecurityLabel attribute."

19) ASN.1 module:  Please change "contentType OBJECT IDENTIFIER" to
"contentType ContentType" in the ContnetHints syntax.

20) Open Issues #1:  I agree that contentHints should be moved to CMS.

21) Open Issues #2:  I believe that my recommended text for Sec 4.2 resolves
the MLA procesing issue.

22) Open Issues #3:  I believe that the mlExpansionHistory size should be
left as 64.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

  

Date: Fri, 6 Mar 1998 15:07:08 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: RE: ESS-01 issues not finished
Sender: [email-masked]

Paul, thanks for noticing that.  Most of the discussion concerned
"what is a conformant message", i.e. what must the sender do to conform.

The requirements on receivers are important too.  Jim's original
text included:

> Additionally, a client
> SHOULD NOT allow access to the mail if it cannot verify at least
> one of the SignerInfos which contains the security label.

I'm at a loss to recommend what a receiver should do if it receives
a message that is illegal as a result of non-cryptographically-protected
information.  Since anyone can add and delete outer signatures, it
doesn't seem right to deny access to the mail if the recipient or
any third party could massage the message into conformant form.

If the S/MIME spec is allowed to recommend User Interface behavior, I'd
say:

 "If any of the SignerInfos includes a security label attribute,
  then all of the SignerInfos MUST include the security label
  authenticated attribute, and the value of each MUST be identical.
  A client SHOULD warn the user if a message not meeting this
  requirement is received."

In a cursory scan of the CMS and MSG drafts, I didn't come across
any requirements on receivers.  The following probably belongs
in the MSG draft if we are going to make UI recommendations:

 "A client SHOULD warn the user if it cannot verify at least one
  of the SignerInfos in a SignedData.", or

 "A client SHOULD warn the user if it cannot verify all of the
  SignerInfos in a SignedData."

If we say "SHOULD NOT allow access", and the user can get access
simply by deleting a SignerInfo, the S/MIME spec doesn't pass the
laugh test.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-ess-03.txt
Date: Fri, 06 Mar 1998 14:31:02 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Enhanced Security Services for S/MIME
	Author(s)	: P. Hoffman
	Filename	: draft-ietf-smime-ess-03.txt
	Pages		: 27
	Date		: 05-Mar-98
	
This document describes three optional security service extensions for
S/MIME. These services provide functionality that is similar to the Message
Security Protocol [MSP], but are useful in many other environments,
particularly business and finance. The services are:

  - signed receipts
  - security labels
  - secure mailing lists

The services described here are extensions to S/MIME version 3 [SMIME3],
and some of them can also be added to S/MIME version 2 [SMIME2]. The
extensions described here will not cause an S/MIME version 3 recipient to
be unable to read messages from an S/MIME version 2 sender. However, some
of the extensions will cause messages created by an S/MIME version 3 sender
to be unreadable by an S/MIME version 2 recipient.
 
The format of the messages are described in ASN.1:1988 [ASN1-1988] with the
modification that UTF8String from ASN.1:1994 [ASN1-1994] is used in the
descriptions.
 
This draft is being discussed on the ''ietf-smime'' mailing list. To
subscribe, send a message to:
     [email-masked]
with the single word
     subscribe
in the body of the message. There is a Web site for the mailing list at
<http://www.imc.org/ietf-smime/>.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-ess-03.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-ess-03.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-ess-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-ess-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-ess-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Fri, 06 Mar 1998 08:53:57 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: ESS-01 issues not finished
Sender: [email-masked]

At 09:04 AM 3/6/98 -0500, David P. Kemp wrote:
>The unknown third party, if he were malicious, could do anything, including
>adding a signature with a non-matching label to cause the message to be
>unavailable (which the recipient could just strip off to make it available
>again :-).  If the third party were just stupid, his user agent should
>warn him if he tries to add an unlabeled signature to a labelled message.
>
>I agree with Russ that interpreting a mix of labelled and unlabelled
>signatures is more confusing than requiring all signatures to be generated
>with a consistent label.  The onus of making sense should fall on the
>generators, not the receivers.

Dave, these two paragraphs seem to contradict each other. Are you
supporting "must throw away if the labels don't match" or "must ignore
mismatched outers"?

Personally, I'm very wary of "must throw away if the labels don't match"
due to arguments like you have in your first paragraph. But I think we need
better wording than we have now.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 6 Mar 1998 09:04:32 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: RE: ESS-01 issues not finished
Sender: [email-masked]

> 
> Blake & Russ:
> 
> Actually there is a third choice which is to wrap the whole thing in a new
> signature blob.
> 
> However, I am afraid that I have to agree with Blake, I think that the act
> of just simply adding a signature from some unknown (and stupid) third party
> should not cause the message to be unavailable.  I think it is sufficent to
> check for some attribute (after all you are already check for duplciates
> anyway) and say that you must verify some Security Label if it exists.
> 
> jim

The unknown third party, if he were malicious, could do anything, including
adding a signature with a non-matching label to cause the message to be
unavailable (which the recipient could just strip off to make it available
again :-).  If the third party were just stupid, his user agent should
warn him if he tries to add an unlabeled signature to a labelled message.

I agree with Russ that interpreting a mix of labelled and unlabelled
signatures is more confusing than requiring all signatures to be generated
with a consistent label.  The onus of making sense should fall on the
generators, not the receivers.

  Dave Kemp

From: Ludwig Wiechers <[email-masked]>
To: "'Jim Schaad (Exchange)'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: AW: New way of transporting certificates
Date: Fri, 6 Mar 1998 09:20:06 +0100
Sender: [email-masked]

Jim,
I like this proposition. I feel that S/MIMECapabilities and =
PreferedEncryptionKey should play a much more important role. They are =
necessary in a multi vendor environment, where products with strong =
cryptography and others , which are cryptographically crippled by US =
export restrictions, have to interoperate.
Ludwig Wiechers
Siemens Nixdorf, Munich, Germany

----------
Von: 	Jim Schaad (Exchange)[SMTP:[email-masked]]
Gesendet: 	Donnerstag, 5. M=E4rz 1998 22:22
An: 	Ietf-Smime (E-mail)
Betreff: 	New way of transporting certificates

I would like to propose to the working group a new way of carrying
certificates between clients (as an export/import mechinism) and for =
storage
in directory services (such as LDAP).  The current mechinism are lacking =
in
that they have no way to convey certian fields which are desirable.  One
such field is the SMIMECapabilities of a user.  As I am not a believer =
in
inventing new things which I don't have to, I am followin the PKCS #7 =
certs
only format as a basis.

Define a new content type id-smime-certs-only.
Construct a CMS SignedData message the the following:
   1. Inner content type is id-smime-certs-only
   2. Inner content is NULL (i.e. no content).
   3. One optional SignerInfo may be placed in the message.  This =
SignerInfo
MUST be signed by the end-entity certificate.
   4.  If the optional SignerInfo is used, then authenticated attributes
such as SMIMECapabilities and PreferedEncryptionKey may be placed here =
and
would be evaluated in a normal manner of receiving an signed message =
from
the user.
   5.  Standard verification rules apply.  If you can form a chain to a
trusted root, then don't use this information (just like a plain certs =
only
PKCS #7 message).

Comments?

jim

Date: Thu, 05 Mar 1998 15:23:33 -0800
From: [email-masked] (Jeff Weinstein)
To: Blake Ramsdell <[email-masked]>
CC: "'Jim Schaad (Exchange)'" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: Re: New way of transporting certificates
Sender: [email-masked]

Blake Ramsdell wrote:
> I believe that at least one vendor (Netscape) deals with this by
> creating a SignedData message with no content, and a single SignerInfo.
> I don't know if this was the right thing or not, so further comments are
> welcome.
> 
> I don't know if Jeff, Jamie, or whoever is still on the list and can
> comment about this.

  I'm still lurking, and Lisa will be back in 2 weeks!!

  You correctly describe what we do.  I don't think it has been very
widely used though.  It would be nice to have a standard way of
publishing the capabilities.  One thing that has caused problems is
that there is already a directory attribute for holding the user's
certificate, but it is defined as a raw x509 cert.  We put our
SignedData in a different attribute, and use it if present.  If not,
we use the standard one (without the recipient's capabilities).  The
presence of two certs in the directory entry, one put there by
the user and the other by the CA, which can get out of sync, has
caused confusion.

	--Jeff

Date: Thu, 5 Mar 1998 18:16:17 -0500
To: "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: CERT-01 comments
Sender: [email-masked]

All,

I agree with everything that Jim wrote in his message except that I have the
following questions/comments:

Jim wrote:
>4.  Section 2.3, paragraph 5.  This paragraph deals with chaining of
>certificates and states that DN parsing is a MUST and nothing else is
>recommended.   We put this in at the very end of the V2 draft with the
>intention of changing it later.  I know that at Microsoft we are looking at
>alternate methods of building chains.  I think that we want to expand this
>paragraph, but I don't know what the current PKIX proposals are and I would
>not wish to go beyond that point.  Is there anyone out there who can tell me
>what the PKIX working group is thinking on:
>A.  DN chaining.
>B.  AltIssuer/AltSubjectName chaining.
>C.  AltKeyId chaining in each of its three variations.  keyIdentifier,
>authorityCertIssuer and authorityCertSerialNumber.

[JSP: The only text in PKIX I that I can find is in section 6 as follows:

  (4) the subject and issuer names chain correctly.  (If the
      certificate has an empty sequence in the name field, name
      chaining will use the critical subjectAltNames and
      issuerAltNames fields.)

However, at the 14 Jan 98 informal meeting in San Francisco we agreed that
the Cert Handling I-D will be enhanced to include the following statement:
"All subject and issuer names must be non-NULL in S/MIME-compliant v3 X.509
Certificates, except that the subject DN in a user's (i.e. end-entity)
certificate may be NULL in which case the subjectAltName extension will
include the subject's identifier and will be marked as critical."  This new
rule allows the CMS IssuerAndSerialNumber syntax to be continued to be used
to identify X.509 Certificates.  This also allows chaining to always occur
on the DNs.  The subjectKeyIdentifier and authorityKeyIdentifier extesnions
are also required during the chaining process to distinguish between certs
issued by the same CA that have different public keys.  In summary, I
believe that the current Sec 2.3, para 5 is sufficient.]

Jim wrote:
>Section A.7 -- bit 7 is encipherOnly, bit 8 is decipherOnly.  Are we going
>to use these? -- I recommend that we remove the following appendixes A.5 and
>A.6 as we no longer do PKI work in this document.  We should "import" the
>definitions of basicConstraints and keyUsage from PKIX part one and not put
>them in this document.

[JSP: Recommend deleting the entire Appendix A.]

- John Pawling

From: "Blake Ramsdell" <[email-masked]>
To: "'Jim Schaad (Exchange)'" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: New way of transporting certificates
Date: Thu, 5 Mar 1998 14:56:53 -0800
Sender: [email-masked]

On Thursday, March 05, 1998 1:22 PM, Jim Schaad (Exchange)
[SMTP:[email-masked]] wrote:
> I would like to propose to the working group a new way of carrying
> certificates between clients (as an export/import mechinism) and for
> storage
> in directory services (such as LDAP).  The current mechinism are
lacking
> in
> that they have no way to convey certian fields which are desirable.
>  One
> such field is the SMIMECapabilities of a user.  As I am not a believer
> in
> inventing new things which I don't have to, I am followin the PKCS #7
> certs
> only format as a basis.

I believe that at least one vendor (Netscape) deals with this by
creating a SignedData message with no content, and a single SignerInfo.
I don't know if this was the right thing or not, so further comments are
welcome.

I don't know if Jeff, Jamie, or whoever is still on the list and can
comment about this.

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

Date: Thu, 5 Mar 1998 17:48:13 -0500
To: "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: New way of transporting certificates
Sender: [email-masked]

Jim,

This sounds good to me, but I have two comments:

1) What goes in the messageDigest attribute in the authenticatedAttributes?
Normally this is the digest of the content, but in your proposal there would
be no content.  Do we want to make a special rule that the messageDigest
attribute is omitted or do we want to say that some special value is
included in messageDigest?

2) You said "If you can form a chain to a trusted root, then don't use this
information..."  Do you mean: "If you can't form a chain to a trusted root,
then don't use this information..."???

- John Pawling

At 01:22 PM 3/5/98 -0800, Jim Schaad (Exchange) wrote:
>I would like to propose to the working group a new way of carrying
>certificates between clients (as an export/import mechinism) and for storage
>in directory services (such as LDAP).  The current mechinism are lacking in
>that they have no way to convey certian fields which are desirable.  One
>such field is the SMIMECapabilities of a user.  As I am not a believer in
>inventing new things which I don't have to, I am followin the PKCS #7 certs
>only format as a basis.
>
>Define a new content type id-smime-certs-only.
>Construct a CMS SignedData message the the following:
>   1. Inner content type is id-smime-certs-only
>   2. Inner content is NULL (i.e. no content).
>   3. One optional SignerInfo may be placed in the message.  This SignerInfo
>MUST be signed by the end-entity certificate.
>   4.  If the optional SignerInfo is used, then authenticated attributes
>such as SMIMECapabilities and PreferedEncryptionKey may be placed here and
>would be evaluated in a normal manner of receiving an signed message from
>the user.
>   5.  Standard verification rules apply.  If you can form a chain to a
>trusted root, then don't use this information (just like a plain certs only
>PKCS #7 message).
>
>Comments?
>
>jim
>
>
>
>

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, Blake Ramsdell <[email-masked]>
Cc: [email-masked]
Subject: RE: ESS-01 issues not finished
Date: Thu, 5 Mar 1998 14:15:27 -0800 
Sender: [email-masked]

Blake & Russ:

Actually there is a third choice which is to wrap the whole thing in a new
signature blob.

However, I am afraid that I have to agree with Blake, I think that the act
of just simply adding a signature from some unknown (and stupid) third party
should not cause the message to be unavailable.  I think it is sufficent to
check for some attribute (after all you are already check for duplciates
anyway) and say that you must verify some Security Label if it exists.

jim

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Wednesday, March 04, 1998 8:41 PM
To: Blake Ramsdell
Cc: Jim Schaad (Exchange); [email-masked]
Subject: RE: ESS-01 issues not finished

Blake:

I understand your concern.  I just think that the resulting message will be
very confusing.

I see it this way.  If a signer want to add a signature to a previousley
signed, unlabeled message, then the signer has two choices:

1.  Add a signature that does not include a label.

2.  Remove the previous signatures, and generate a message with a single,
labeled signature.

Russ

At 01:10 PM 3/3/98 -0800, Blake Ramsdell wrote:
>On Monday, March 02, 1998 8:56 PM, Russ Housley
>[SMTP:[email-masked]] wrote:
>> Jim:
>> 
>> I would prefer a stronger statement.  I would like to say that if any
>> of
>> the SignerInfos includes a security label authenticated attribute,
>then
>> all
>> of the SignerInfos MUST include the security label authenticated
>> attribute,
>> and the value of each MUST be identical.
>
>I understand the intent of this.  However, I believe that it is certain
>that more than one entity might sign the message in sequence if there
>are multiple signatures.  If this is the case, if some subsequent
>signature is applied with a security label, all previous signers had
>better have the same security label, and likewise if a prior signature
>has a security label, the new signature must have it also.
>
>Is this reasonable to live with?  I'm still mulling this over.
>
>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: "Jim Schaad (Exchange)" <[email-masked]>
To: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: New way of transporting certificates
Date: Thu, 5 Mar 1998 13:22:11 -0800 
Sender: [email-masked]

I would like to propose to the working group a new way of carrying
certificates between clients (as an export/import mechinism) and for storage
in directory services (such as LDAP).  The current mechinism are lacking in
that they have no way to convey certian fields which are desirable.  One
such field is the SMIMECapabilities of a user.  As I am not a believer in
inventing new things which I don't have to, I am followin the PKCS #7 certs
only format as a basis.

Define a new content type id-smime-certs-only.
Construct a CMS SignedData message the the following:
   1. Inner content type is id-smime-certs-only
   2. Inner content is NULL (i.e. no content).
   3. One optional SignerInfo may be placed in the message.  This SignerInfo
MUST be signed by the end-entity certificate.
   4.  If the optional SignerInfo is used, then authenticated attributes
such as SMIMECapabilities and PreferedEncryptionKey may be placed here and
would be evaluated in a normal manner of receiving an signed message from
the user.
   5.  Standard verification rules apply.  If you can form a chain to a
trusted root, then don't use this information (just like a plain certs only
PKCS #7 message).

Comments?

jim

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "Blake Ramsdell (E-mail)" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: CERT-01 comments
Date: Thu, 5 Mar 1998 13:22:11 -0800 
Sender: [email-masked]

1.  You have said that we are removing we are removing request syntax from
the Message and certificates drafts.  I am going to assume that you are
really doing that and not point out all of the locations in this draft where
it needs to be done.  I would suggest keeping a short sentence at some point
point to the CRMF/PKIP drafts, except that I don't think they are going to
be finished in time.

2.  Please remove section 1.2 and Appendix C.  We no longer need to document
past behavior as this is now done for us by use of the IETF archive.  Please
add a sentence to the introduction stating that this document supperceeds
the informational draft SMIMEV2-CERTS.

3.  Section 2.2.1 -- There are now three different certificate formats
supported by CMS.  Please add attribute certificates to the list.

4.  Section 2.3, paragraph 5.  This paragraph deals with chaining of
certificates and states that DN parsing is a MUST and nothing else is
recommended.   We put this in at the very end of the V2 draft with the
intention of changing it later.  I know that at Microsoft we are looking at
alternate methods of building chains.  I think that we want to expand this
paragraph, but I don't know what the current PKIX proposals are and I would
not wish to go beyond that point.  Is there anyone out there who can tell me
what the PKIX working group is thinking on:
A.  DN chaining.
B.  AltIssuer/AltSubjectName chaining.
C.  AltKeyId chaining in each of its three variations.  keyIdentifier,
authorityCertIssuer and authorityCertSerialNumber.

5.  Section 2.2.1.  If I could find a good one, I would like to get a
pointer to attribute certificaets in this section (i.e. reference a
document).  As I don't think such a think exists, this comment should be
ignored.

6. Appendix F

UNIVERSAL STRING for Challenge Password?  Should this simply be BMPString?
--- This dies as we don't play the PKIP game anymore.

Rewrite 5.2 for CMP and id-dsa-with-sha1 --- ditto

Stronger MD2 / MD5 language needed?  --- ditto

2.2.1 -- are they "proposed" revisions, or actual revisions? --- My
understanding is that these are real revisions -- it is refering to the X509
V3 specification.  We can treat this as real and lets change to "In
addition, the V3 revision of X.509 certificates ..."

Names for chaining -- see comment 4 as a request for information.

Algorithms for certs --- I don't understand the question.

Capitalization of OIDs -- lets be consistent, but not to the point of
stupidity.  Also the spaces in Postal Code and Phone Number should be
removed.

Only one "official" email address?  --- Please describe you issue with this.
I don't see any reason to restrict myself to one "official" address although
some CAs may wish to do this a part of local policy.

Make references [PKCS-*] consistent with smime-msg spec --- Yes you should

Section A.7 -- bit 7 is encipherOnly, bit 8 is decipherOnly.  Are we going
to use these? -- I recommend that we remove the following appendixes A.5 and
A.6 as we no longer do PKI work in this document.  We should "import" the
definitions of basicConstraints and keyUsage from PKIX part one and not put
them in this document.

Date: Wed, 04 Mar 1998 22:27:35 -0500
To: Bruce Greenblatt <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Comment on ESS and Privacy Marks
Cc: Christian Rinderknecht <[email-masked]>, [email-masked], Bancroft Scott <[email-masked]>
Sender: [email-masked]

The PKIX WG is using [UNIVERSAL xx] to include types that were defined
after publication of 1988 ASN.1.  S/MIME is following their lead.

Russ

At 01:05 PM 3/3/98 -0800, Bruce Greenblatt wrote:
>I generally agree with the Comments made by Bancroft Scott, and would
>strongly prefer to not see the use of UNIVERSAL tagging in the ESS
>document.  The specification of the Privacy Mark in the ESS-02 is legal
>ASN.1, will work, and I've not seen any compelling reason to use
>anything different.  The definition:
>
>ESSPrivacyMark ::= CHOICE {
>  pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
>  utf8String   OCTET STRING
>  -- If utf8String is used, the contents must be in UTF-8 [UTF8]
>
>}
>
>uses precisely the same mechanism that has already been used in the LDAP
>v3 (RFC 2251) standards track document in the definition of Directory
>String.  Can someone (maybe Paul) explain the compelling reason that the
>current ESS spec is wrong?
>
>Thanks,
>
>Bruce 
>
>> -----Original Message-----
>> From:	Russ Housley [SMTP:[email-masked]]
>> Sent:	Monday, March 02, 1998 7:02 PM
>> To:	Christian Rinderknecht
>> Cc:	[email-masked]
>> Subject:	Re: Comment on ESS and Privacy Marks
>> 
>> Christian:
>> 
>> Since S/MIME and PKIX are using the 1988 ASN.1, we need to use the
>> [UNIVERSAL xx] trick to support any types that have been defined in
>> the
>> subsequent releases of ASN.1.  Several implementations of 1988 ASN.1
>> support the use of [UNIVERSAL xx].
>> 
>> Russ
>> 
>> At 03:22 PM 3/2/98 +0100, Christian Rinderknecht wrote:
>> >On Mon, 2 Mar 1998, Russ Housley wrote:
>> >
>> >>>I agree with Bancroft Scott that ESSPrivacyMark should be
>> re-defined
>> >+as follows:
>> >>>
>> >>>> ESSPrivacyMark ::= CHOICE {
>> >>>>    pString      PrintableString (SIZE
>> >+(1..ub-privacy-mark-length)),
>> >>>>    utf8String   [0] IMPLICIT UTF8String (SIZE
>> >+(1..ub-privacy-mark-length))
>> >>>> }
>> >>>
>> >>>
>> >>>Note Bancroft's point as follows:
>> >>>
>> >>>Another
>> >>>benefit is that if someone is using a tool that does not support
>> >>>UTF8String they can simply change it to "[0] OCTET STRING" and get
>> >+the
>> >>>same encoding.
>> >>
>> >> I do not agree. I think we should use the UNIVERSAL tag.  This will
>> >> align us with the correct implementation of UTF8 in the future,
>> >+rather 
>> >> than creating an octet hole to carry a UTF8.
>> >
>> >
>> >An "octet hole" is use of an OCTET STRING type to carry data of some
>> >other type, so [0] IMPLICIT UTF8String is not an octet hole for the
>> >type of the value is clearly specified as UTF8String.  The suggestion
>> >below to define the utf8String component with an IMPLICIT tag is a
>> >good idea, for it does not put an octet hole in the standard, while
>> at
>> >the same time gives implementors the freedom to use octet holes if
>> >that is how they would like to support UTF8String.
>> >
>> >At most there should be a comment:
>> >
>> >  --        UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
>> >  
>> >Doing so does not break the 1988 and 1997 standards which both forbid
>> >the use of UNIVERSAL tags in type definitions in ASN.1 modules, it
>> >makes it clear how this type is formally defined for those people who
>> >don't know that the tag is UNIVERSAL 12, and it is convenient for

>> >anyone whose tool does not support UTF8String to simply remove the
>> >"--" if doing so helps their tool to properly handle UTF8String.
>> >
>> >
>> >
>> >Christian
>> >
>> >---
>> >
>> >Christian Rinderknecht       Alcatel Alsthom Corporate Research
>> Center
>> >Object Architectures Unit    Tel : +33 (0) 1 69 63 17 60
>> >Route de Nozay               Fax : +33 (0) 1 69 63 17 69
>> >91460 Marcoussis, France     
>> >mailto:[email-masked]
>> > 
> 

Date: Wed, 04 Mar 1998 23:40:34 -0500
To: "Blake Ramsdell" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: ESS-01 issues not finished
Cc: "Jim Schaad (Exchange)" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Blake:

I understand your concern.  I just think that the resulting message will be
very confusing.

I see it this way.  If a signer want to add a signature to a previousley
signed, unlabeled message, then the signer has two choices:

1.  Add a signature that does not include a label.

2.  Remove the previous signatures, and generate a message with a single,
labeled signature.

Russ

At 01:10 PM 3/3/98 -0800, Blake Ramsdell wrote:
>On Monday, March 02, 1998 8:56 PM, Russ Housley
>[SMTP:[email-masked]] wrote:
>> Jim:
>> 
>> I would prefer a stronger statement.  I would like to say that if any
>> of
>> the SignerInfos includes a security label authenticated attribute,
>then
>> all
>> of the SignerInfos MUST include the security label authenticated
>> attribute,
>> and the value of each MUST be identical.
>
>I understand the intent of this.  However, I believe that it is certain
>that more than one entity might sign the message in sequence if there
>are multiple signatures.  If this is the case, if some subsequent
>signature is applied with a security label, all previous signers had
>better have the same security label, and likewise if a prior signature
>has a security label, the new signature must have it also.
>
>Is this reasonable to live with?  I'm still mulling this over.
>
>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: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: Tolerance on Message Digest Attribute
Date: Wed, 4 Mar 1998 12:44:36 -0800 
Sender: [email-masked]

This proposal would break the current implementation that I have.  I compute
the message digest, compare it to message digest in the attributes.  Then I
hash the attributes and compare the result to the signature.  Your proposal
would break my old implementation and I am therefore againist it.

jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 04, 1998 5:58 AM
To: [email-masked]
Subject: Re: Tolerance on Message Digest Attribute

I don't believe we ever reached closure on Chris Bonnatti's suggestion
from January 15.  To recap:

>   What I would propose is simple.  We modify the CMS spec to allow a
>   variation in the processing of the authenticatedAttributes in the
>   SignedData such that:
>
>   1.  It allows originating implementations to OPTIONALLY delete this
>   attribute from the attribute set AFTER the calculation of the
>   signature value is complete.
>
>   2.  If the authenticatedAttributes are present but the MessageDigest
>   attribute is absent on reception, the recipient implementation
>   will recreate the attribute using it's local calculation of the hash
>   value.  The signature validation can then proceed normally.
>
>   3.  The procedure should remain as it is now if the attribute is
>   present.
>
>   4.  Add a note that to achieve backward compatibility with
>   an existing implementation this attribute should be present.

I agree with Chris' proposal, but in the interest of guaranteeing
backward compatibility with S/MIME v2, here is another somewhat less
elegant suggestion:

 1. AFTER the originator computes the signature value, the value
    of the Message Digest attribute is deleted.  The Message Digest
    attribute, with the empty value, is transmitted on the wire.

This has the disadvantage of including a few unnecessary bytes on
the wire, but it ensures that S/MIME v2 implementations which expect
to receive that attribute will get it.

> Date: Tue, 27 Jan 1998 12:18:32 -0500
> From: Russ Housley <[email-masked]>
> 
> Dave & Eric:
> 
> I understand the security issue.  The recipient must recompute the message
> digest.  However, vendors have been very clear that they want CMS to be
> backward compatible with PKCS#7v1.5.  So, in the last version of CMS, I
> included text requiring the recipinet to recompute the message digest.
> 
> Russ

Since the recipient is incorrect and cryptographically vulnerable if it
does not recompute the message digest, all correct S/MIME v2 / PKCS#7
v1.5 implementations will compute the digest from the content, and will
not be adversely affected if the digest value is not included in the
transmitted messageDigest attribute.  In other words, if receiving an
empty messageDigest causes an application to fail to verify signatures,
then that is an indication that the application may have the very
implementation bug we are trying to protect against.

I propose modifying CMS as follows:

  1) add the following after the second paragraph of section 5.3:
     "After the signature has been generated, the value of the
      messageDigest authenticatedAttribute is deleted, i.e. the
      transmitted value of the messageDigest attribute is always
      a zero-length OCTET STRING."

  2) delete the last sentence of section 5.5:
     "For the signature to be valid, the message digest value calculated
      by the recipient must be the same as the value of the messageDigest
      attribute included in the authenticatedAttributes of the signedData
      signerInfo."

     Even if no changes are made in messageDigest handling in CMS, this
     requirement to check the received and computed values is unnecessary.
     The computed value is used in signature validation; the received value
     should be ignored.

  3) just for redundancy's sake, add the following after the first
     paragraph of section 11.2:
     "Although the complete message-digest attribute is included in the
      signature generation and validation computations, the transmitted
      value of this attribute is always a zero-length OCTET STRING.
      Non-empty values of this attribute received from earlier versions
      of this specification are accepted and must be ignored."

Eric and everyone else: are there any objections to including either
Chris' original proposal or my more-backwards-compatible version
into CMS?  Which proposal is preferred?  If there are no objections
can we declare consensus and incorporate the changes into the next
draft?

Regards,
Dave Kemp

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Bancroft Scott <[email-masked]>
Cc: [email-masked]
Subject: RE: Comment on ESS and Privacy Marks
Date: Wed, 4 Mar 1998 12:42:30 -0800 
Sender: [email-masked]

I REALLY agree with this.  I have found out and verified that I can't do the
UNIVERSAL tag trick with my ASN compiler, and I don't know when we are going
to get a new one which supports UTF8String.   I REALLY DON'T want to end up
with something I can't implement.

jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 04, 1998 5:29 AM
To: Bancroft Scott
Cc: [email-masked]
Subject: Re: Comment on ESS and Privacy Marks

All,

I agree with Bancroft Scott that ESSPrivacyMark should be:

ESSPrivacyMark ::= CHOICE {
    pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
    utf8String   [0] IMPLICIT UTF8String (SIZE (1..ub-privacy-mark-length))
 }

- John Pawling

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "Paul Hoffman (E-mail)" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: MIME wrapping of Signed Receipts
Date: Wed, 4 Mar 1998 12:27:50 -0800 
Sender: [email-masked]

I would like to be specific about the mime wrapping of a Signed Receipt so
we can see consistant behavior on it.  To be specific I want to insert a new
item between bullets 9 and 10 in section 2.4

10.  The signedData/Receipt is then wrapped in an application/pkcs7-mime
wrapper with the smime-type parameter set to "signed-receipt".  This will
allow for identification of signed receipts without haveing to crack the
ASN. The smime-type paramter would still be set as normal in any securiting
layer wrapped around this message.  It makes no sense to try and use a
multipart/signed at this point be cause there is no mime on receipt itself
so the content cannot be detached and placed in a multipart/signed.

Process question:  I don't see any place in the request for the pkcsk7-mime
request where the values of smime-type are restricted.  Are they just
restricted by the S/MIME message draft or are they completely unrestricted?
In one case this edit would need a corresponding change in the message draft
and in the other no changes by Blake are required.

jim

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "Blake Ramsdell (E-mail)" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: MSG-01 Feedback
Date: Wed, 4 Mar 1998 12:27:50 -0800 
Sender: [email-masked]

1.  A general question for the list to look at.  In S/MIME V2 we used
id-data as the ContentType oid to say the contents are MIME,  there is
general conses that this was a mistake.  The question is can this be
remedied at this point in time?  Ways that this could be dealt with is to
say that id-data should continue to be used for SignedData version 1 objects
and EncryptedData version 0 objects, but a new oid should be used in other
cases.  This would allow future versions of S/MIME to cut away from this old
method and put id-data back to its original intent, some arbitrary data is
here.  What is the feelings of the list on this issue?  My personal feeling
is that in an ideal world I would recommend doing this, however in reality I
think it would be a mistake because of the potential for error.  

2.  Section 2.5  paragraph 3.  Encryption Key Preference is not an attribute
that is needed by all senders of S/MIME messages.  I suggest we change this
to:
"Sending agents SHOULD be able to generate one instance of each of the
signed attributes described in this section, and SHOULD include the signing
time and SMIMEcapabilities
attributes in each signed message sent."

3.  Section 2.5.2  This is a politics question and one I am not capable of
deciding.  Do we need to change from using the IMC as the registration agent
for the OIDs of SMIMECapabilites?  I don't see any techincal reasons to
change this at this point in time.  I don't see IMC as disappearing any time
soon and from what I hear it would be much faster to get updates than using
IANA.  But I don't know if the IESG will be willing to leave this as it is.

4.  Section 2.5.2  I guess this is really an issue for Paul as the owner of
the SMIMECapabilites list.   I hearby request that a new capability be added
to the list called "smimeVersions".   This will have a content of a single
integer which will contain the version number of the highest S/MIME
specification understandable by the client.  I hearby designate [SMIMEV2] to
have the number 2 and this draft to have the number 3.  This will allow for
sending MUAs to be able to prevent sending critical attributes to clients
which will not understand them.  This will also address any new
incompatabilies placed in the S/MIME specifications at a later time.
 
5.  Section 2.6.2.1  Two issues.  First the numbering is incorrect.  It
should be section 2.6.1.1.  Secondly capabilitie is misspelt in the 4th
paragraph.

6.  Section 2.6.2.3 and 2.6.2.4.  The wording no longer works for these two
sections now that 3DES is a must and RC2/40 is an optional.  I have switched
the order of the rules as tripleDES is now a MUST algorithm and is therefore
by definition supported, but we know that not everyone does support it.  I
suggest that these sections be re-written as follows:

	"2.6.1.3 Rule 3: Low Encryption interopt mode

	If:
	 - the sending agent has no knowledge of the encryption capabilities
of the recipient,
	 - and the sending agent is has reason to believe that the recipient
does not support high level encryption,
	then the sending agent SHOULD use RC2/40.

	2.6.1.4  Rule 4: Unknown Capabilities

	If:
	 - the sending agent has no knowledge of the encryption capabilities
of the recipient,
	then the sending agent MUST use tripleDES."

7.  Insert a new section 2.6.4 with the following text.
	"Section 2.6.4  Selecting a receipients Encryption Certificate

	The use of the must algorithms in this specification lead to the
problem of given a user's signing certificate from a signed message, how is
the encryption certificate determined.  Since the signing and key exchange
algorithms will no longer use the same certificates.

	Section 2.5 deifnes a method by which a sending agent can optionally
announce what its perfered key-exchange certificate is.  The following
method for processing and remembering the encryption certificate attribute
in incoming signed messages SHOULD be used.

	If an Encryption Key preference attribute is found in a message,
this is the certificate that should be associated as the encryption
certificate for the user.

	If no Encrytion Key perference attribute is found in a message, the
set of certificates should be searched for a certificate with the same DN as
the signing certificate which can be used for encryption.  If no certificate
is found, then encryption cannot be done with the signer of the message.  If
multiple certificates are found, the MUA can make an arbitrary choice
between them. 

	- If the receiving agent has not yet done an association for the
sender's encryption certificate, then, after verifiying the signature on the
incoming message and checking the timestamp, the receiving agent SHOULD
create a new associaiton containing the signing time and the encryption
certificate.

	- If such an association already exists, the receiving agent SHOULD
verify that the signing time in the incoming message is greater than the
signing time stored in the association and that the signature is valid.  If
so, the receiving agent SHOULD update both the signing time and the
encryption certificate association.  Values of the signing time that lie far
in the future (that is, a greater discrepancy than any reasonable clock
skew), or an encryption preference in a message whos signature cannot be
verified, MUST NOT be accepted."

8.  Section 3.4.3.2, paragraph 8. micalg can contain a list of values.
Suggest the paragraph be re-worded as follows:
	"The micalg paramter allows for one-pass processing when the
signature is being verified.  The value of the micalg parameter is dependent
on the message digest algorithm(s) used in the calculation of the Message
Integrity Check.  If multiple message digest algorithms are used they should
be seperated by commas.  The values to be placed int eh micalg parameter
SHOULD be from the following:"

9.  Section 3.7.  We are no longer in the game of doing PKI work.  I
recommend we delete this entire paragraph.  If people feel strongly that
something is needed then we should replace with a reference to SMIMEV2,
however I would argue that even this is not needed.  If this goes then
Appendix E.3 should also go.

10.  Appendix C.  Delete the entire section.  This should not be of any
importance now we are on standards track. (I may be too agressive on this
one.)

11.  Appendix A.  I would like to update the ASN for
SMIMEEncryptionKeyPreference as follows:
	SMIMEEncryptionKeyPreference ::= CHOICE {
	   issuerAndSerialNumber   IMPLICIT [0] IssuerAndSerialNumber,
	   receipentKeyId          IMPLICIT [1] RecipientKeyIdentifier,
	   subjectAltKeyIdentifier IMPLICIT [2] KeyIdentifier,
	   sha1Hash                 IMPLICIT [3] OCTET STRING
	}

	On the inclusion of a certificate identifier in the signed data
object, several people have asked to be able to use a hash as this is
generally much smaller than an issuerAndSerialNumber, thus I have included
it here first.

12.  Open issues from Appendix H.
Need OIDs for Diffie-Hellman  -- This should no longer be true, we get the
D-H oids from the CMS draft.

What do we need to do for 4.1 in order to make it Diffie-Hellman? -- Remove
the entire section.  At most we should put in a paragraph about recommended
key lengths and nothing more about generation.

Cert generation in section 4.1 needs to talk about CMP from PKIX.   --- No
we don't we should never talk about key generation.

Section 4.1 needs to talk about DSS and DH minimum key lengths for strong
crypto --- Yes -- see above comments.

Is [DSS] the correct reference? ---- Sorry I can't help you here.  Copy the
reference from CMS when it gets one.

Algorithm identifiers need more cleanup  ---   I don't understand this issue
beyond the addtion of SMIMEEncrytionKeyPreference.  Yes the ones duplicated
in CMS could be removed, but I don't see any real urgency on this.l

Section A cleanup (SMIMECapabilities and SMIMEEncryptionKeyPreference in
their own sections?) --- Why bother.

Should SMIMEEncryptionKeyPreference simply be IssuerAndSerialNumber? --- No
see above recommended change.

ASN.1 issues -- syntax, CCITT vs. ITU-T in section 1.3 --- I can't help you
here, except to say as we are now in the IETF rather than being an
independent spec, I see no problems with just deleting this section out of
hand.

NEW:
Need to get an OID for SMIMEEncryptionKeyPreference
Need to get an OID for smimeVersions.

From: Bruce Greenblatt <[email-masked]>
To: [email-masked]
Subject: FW: Comment on ESS and Privacy Marks
Date: Wed, 4 Mar 1998 10:12:37 -0800
Sender: [email-masked]

> I generally agree with the Comments made by Bancroft Scott, and would
> strongly prefer to not see the use of UNIVERSAL tagging in the ESS
> document.  The specification of the Privacy Mark in the ESS-02 is
> legal ASN.1, will work, and I've not seen any compelling reason to use
> anything different.  The definition:
> 
> ESSPrivacyMark ::= CHOICE {
>   pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
>   utf8String   OCTET STRING
>   -- If utf8String is used, the contents must be in UTF-8 [UTF8]
> 
> }
> 
> uses precisely the same mechanism that has already been used in the
> LDAP v3 (RFC 2251) standards track document in the definition of
> Directory String.  Can someone (maybe Paul) explain the compelling
> reason that the current ESS spec is wrong?
> 
> Thanks,
> 
> Bruce 
> 
> -----Original Message-----
> From:	Russ Housley [SMTP:[email-masked]]
> Sent:	Monday, March 02, 1998 7:02 PM
> To:	Christian Rinderknecht
> Cc:	[email-masked]
> Subject:	Re: Comment on ESS and Privacy Marks
> 
> Christian:
> 
> Since S/MIME and PKIX are using the 1988 ASN.1, we need to use the
> [UNIVERSAL xx] trick to support any types that have been defined in
> the
> subsequent releases of ASN.1.  Several implementations of 1988 ASN.1
> support the use of [UNIVERSAL xx].
> 
> Russ
> 
> At 03:22 PM 3/2/98 +0100, Christian Rinderknecht wrote:
> >On Mon, 2 Mar 1998, Russ Housley wrote:
> >
> >>>I agree with Bancroft Scott that ESSPrivacyMark should be
> re-defined
> >+as follows:
> >>>
> >>>> ESSPrivacyMark ::= CHOICE {
> >>>>    pString      PrintableString (SIZE
> >+(1..ub-privacy-mark-length)),
> >>>>    utf8String   [0] IMPLICIT UTF8String (SIZE
> >+(1..ub-privacy-mark-length))
> >>>> }
> >>>
> >>>
> >>>Note Bancroft's point as follows:
> >>>
> >>>Another
> >>>benefit is that if someone is using a tool that does not support
> >>>UTF8String they can simply change it to "[0] OCTET STRING" and get
> >+the
> >>>same encoding.
> >>
> >> I do not agree. I think we should use the UNIVERSAL tag.  This will
> >> align us with the correct implementation of UTF8 in the future,
> >+rather 
> >> than creating an octet hole to carry a UTF8.
> >
> >
> >An "octet hole" is use of an OCTET STRING type to carry data of some
> >other type, so [0] IMPLICIT UTF8String is not an octet hole for the
> >type of the value is clearly specified as UTF8String.  The suggestion
> >below to define the utf8String component with an IMPLICIT tag is a
> >good idea, for it does not put an octet hole in the standard, while
> at
> >the same time gives implementors the freedom to use octet holes if
> >that is how they would like to support UTF8String.
> >
> >At most there should be a comment:
> >
> >  --        UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
> >  
> >Doing so does not break the 1988 and 1997 standards which both forbid
> >the use of UNIVERSAL tags in type definitions in ASN.1 modules, it
> >makes it clear how this type is formally defined for those people who
> >don't know that the tag is UNIVERSAL 12, and it is convenient for
> >anyone whose tool does not support UTF8String to simply remove the
> >"--" if doing so helps their tool to properly handle UTF8String.
> >
> >
> >
> >Christian
> >
> >---
> >
> >Christian Rinderknecht       Alcatel Alsthom Corporate Research
> Center
> >Object Architectures Unit    Tel : +33 (0) 1 69 63 17 60
> >Route de Nozay               Fax : +33 (0) 1 69 63 17 69
> >91460 Marcoussis, France     
> >mailto:[email-masked]
> > 

From: "Phillip M. Hallam-Baker" <[email-masked]>
To: <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: S/MIME Index?
Date: Wed, 4 Mar 1998 12:48:59 -0500
Sender: [email-masked]

The HTTP index was created using Microsoft Word...

        Phill

-----Original Message-----
From: Russ Housley <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Wednesday, February 25, 1998 2:54 PM
Subject: Re: S/MIME Index?

>You are right that this is a big burden on the editor ....
>
>Russ
>
>
>At 02:04 PM 2/25/98 -0500, Phillip H. Griffin wrote:
>>Just pulled down the latest HTTP draft and noticed that 
>>it has a wonderful index at the end of the document. Is
>>it possible that S/MIME could do the same? Big impact
>>on the editors, but it could really add a lot to the 
>>value of the final published works.
>>
>>Phil
>>-- 
>>Phillip H. Griffin         Griffin Consulting
>>[email-masked]        ASN.1-SET-Java-Security
>>919.828.7114               1625 Glenwood Avenue
>>919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
>>------------------------------------------------------------
>>          Visit  http://www.fivepointsfestival.com
>>                 http://www.five-points.com
>>------------------------------------------------------------
>> 
>

Date: Wed, 4 Mar 1998 12:45:36 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Tolerance on Message Digest Attribute
Sender: [email-masked]

> All,
> 
> I agree with Eric that the proposals to omit the message digest attribute
> from the transmitted signedData object do not enhance security and do create
> a needless incompatibility between S/MIME v3 and v2 implementations.
> 
> - John Pawling

I'm willing to accept either outcome; I just want to achieve closure,
and give potential non-S/MIME users of CMS (in particular Tim Dean and
the European community) one last chance to weigh in on the issue.

Date: Wed, 4 Mar 1998 12:38:16 -0500
To: EKR <[email-masked]>, [email-masked] (David P. Kemp)
From: [email-masked] (John Pawling)
Subject: Re: Tolerance on Message Digest Attribute
Cc: [email-masked]
Sender: [email-masked]

All,

I agree with Eric that the proposals to omit the message digest attribute
from the transmitted signedData object do not enhance security and do create
a needless incompatibility between S/MIME v3 and v2 implementations.

- John Pawling

To: [email-masked] (David P. Kemp)
Cc: [email-masked]
Subject: Re: Tolerance on Message Digest Attribute
From: EKR <[email-masked]>
Date: 04 Mar 1998 06:59:14 -0800
Lines: 93
Sender: [email-masked]

[email-masked] (David P. Kemp) writes:

> I don't believe we ever reached closure on Chris Bonnatti's suggestion
> from January 15.  To recap:
> 
> >   What I would propose is simple.  We modify the CMS spec to allow a
> >   variation in the processing of the authenticatedAttributes in the
> >   SignedData such that:
> >
> >   1.  It allows originating implementations to OPTIONALLY delete this
> >   attribute from the attribute set AFTER the calculation of the
> >   signature value is complete.
> >
> >   2.  If the authenticatedAttributes are present but the MessageDigest
> >   attribute is absent on reception, the recipient implementation
> >   will recreate the attribute using it's local calculation of the hash
> >   value.  The signature validation can then proceed normally.
> >
> >   3.  The procedure should remain as it is now if the attribute is
> >   present.
> >
> >   4.  Add a note that to achieve backward compatibility with
> >   an existing implementation this attribute should be present.
> 
> 
> I agree with Chris' proposal, but in the interest of guaranteeing
> backward compatibility with S/MIME v2, here is another somewhat less
> elegant suggestion:
> 
>  1. AFTER the originator computes the signature value, the value
>     of the Message Digest attribute is deleted.  The Message Digest
>     attribute, with the empty value, is transmitted on the wire.
> 
> This has the disadvantage of including a few unnecessary bytes on
> the wire, but it ensures that S/MIME v2 implementations which expect
> to receive that attribute will get it.
> 
This doesn't guarantee backwards compatibility.

PKCS-7 implies (nay, requires the following algorithm)

Extract the attributes encoding into a structure
Recompute the message digest.
Compare the computed message digest to the digest attribute.
Reencode the attributes.
Check the signature.

This is a safe procedure, but it will be broken by your change.
>      Even if no changes are made in messageDigest handling in CMS, this
>      requirement to check the received and computed values is unnecessary.
>      The computed value is used in signature validation; the received value
>      should be ignored.
But the computed value isn't used DIRECTLY in the signature computation.
It's used as a field in an ASN.1 structure which is itself
signed. That's what protects the rest of the authenticated
attributes. To check YOUR version, you have to do:

Imagine the following algorithm:
Extract the attributes encoding into a structure
Recompute the message digest.
*** Insert the computed message digest into the attributes structure
Reencode the attributes.
Check the signature.

>   3) just for redundancy's sake, add the following after the first
>      paragraph of section 11.2:
>      "Although the complete message-digest attribute is included in the
>       signature generation and validation computations, the transmitted
>       value of this attribute is always a zero-length OCTET STRING.
>       Non-empty values of this attribute received from earlier versions
>       of this specification are accepted and must be ignored."
> 
> 
> Eric and everyone else: are there any objections to including either
> Chris' original proposal or my more-backwards-compatible version
> into CMS? 
Yes. I object to both of these. This is of negligible security
value, and it creates a needless incompatibility.

> Which proposal is preferred?
They're both equally objectionable.

>  If there are no objections
> can we declare consensus and incorporate the changes into the next
> draft?
There are objections.

-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

Date: Wed, 4 Mar 1998 08:58:09 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Tolerance on Message Digest Attribute
Sender: [email-masked]

I don't believe we ever reached closure on Chris Bonnatti's suggestion
from January 15.  To recap:

>   What I would propose is simple.  We modify the CMS spec to allow a
>   variation in the processing of the authenticatedAttributes in the
>   SignedData such that:
>
>   1.  It allows originating implementations to OPTIONALLY delete this
>   attribute from the attribute set AFTER the calculation of the
>   signature value is complete.
>
>   2.  If the authenticatedAttributes are present but the MessageDigest
>   attribute is absent on reception, the recipient implementation
>   will recreate the attribute using it's local calculation of the hash
>   value.  The signature validation can then proceed normally.
>
>   3.  The procedure should remain as it is now if the attribute is
>   present.
>
>   4.  Add a note that to achieve backward compatibility with
>   an existing implementation this attribute should be present.

I agree with Chris' proposal, but in the interest of guaranteeing
backward compatibility with S/MIME v2, here is another somewhat less
elegant suggestion:

 1. AFTER the originator computes the signature value, the value
    of the Message Digest attribute is deleted.  The Message Digest
    attribute, with the empty value, is transmitted on the wire.

This has the disadvantage of including a few unnecessary bytes on
the wire, but it ensures that S/MIME v2 implementations which expect
to receive that attribute will get it.

> Date: Tue, 27 Jan 1998 12:18:32 -0500
> From: Russ Housley <[email-masked]>
> 
> Dave & Eric:
> 
> I understand the security issue.  The recipient must recompute the message
> digest.  However, vendors have been very clear that they want CMS to be
> backward compatible with PKCS#7v1.5.  So, in the last version of CMS, I
> included text requiring the recipinet to recompute the message digest.
> 
> Russ

Since the recipient is incorrect and cryptographically vulnerable if it
does not recompute the message digest, all correct S/MIME v2 / PKCS#7
v1.5 implementations will compute the digest from the content, and will
not be adversely affected if the digest value is not included in the
transmitted messageDigest attribute.  In other words, if receiving an
empty messageDigest causes an application to fail to verify signatures,
then that is an indication that the application may have the very
implementation bug we are trying to protect against.

I propose modifying CMS as follows:

  1) add the following after the second paragraph of section 5.3:
     "After the signature has been generated, the value of the
      messageDigest authenticatedAttribute is deleted, i.e. the
      transmitted value of the messageDigest attribute is always
      a zero-length OCTET STRING."

  2) delete the last sentence of section 5.5:
     "For the signature to be valid, the message digest value calculated
      by the recipient must be the same as the value of the messageDigest
      attribute included in the authenticatedAttributes of the signedData
      signerInfo."

     Even if no changes are made in messageDigest handling in CMS, this
     requirement to check the received and computed values is unnecessary.
     The computed value is used in signature validation; the received value
     should be ignored.

  3) just for redundancy's sake, add the following after the first
     paragraph of section 11.2:
     "Although the complete message-digest attribute is included in the
      signature generation and validation computations, the transmitted
      value of this attribute is always a zero-length OCTET STRING.
      Non-empty values of this attribute received from earlier versions
      of this specification are accepted and must be ignored."

Eric and everyone else: are there any objections to including either
Chris' original proposal or my more-backwards-compatible version
into CMS?  Which proposal is preferred?  If there are no objections
can we declare consensus and incorporate the changes into the next
draft?

Regards,
Dave Kemp

Date: Wed, 4 Mar 1998 08:28:24 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: ESS-01 issues not finished
Sender: [email-masked]

All,

I agree with Russ.  I can't think of any scenarios in which Russ' proposed
rule would not apply.

- John Pawling

At 11:56 PM 3/2/98 -0500, Russ Housley wrote:
>Jim:
>
>I would prefer a stronger statement.  I would like to say that if any of
>the SignerInfos includes a security label authenticated attribute, then all
>of the SignerInfos MUST include the security label authenticated attribute,
>and the value of each MUST be identical.
>
>Russ
>
>
>At 09:16 PM 2/28/98 -0800, Jim Schaad (Exchange) wrote:
>>The following items from my comments for ESS-01 did not make it into
>>ESS-02 so here it is again.  Hopefully this time it will get some
>>discussion.
>>
>>1.  Section 3.1.1 paragraph 5.  I disagree that some SignerInfos within
>>a SignedData object may be permitted to be missing security labels
>>without any restrictions.  I propose the following replacement paragraph
>>(new last sentence).
>>
>>"There can be multiple SignerInfos within a SignedData object, and each
>>SignerInfo may include authenticatedAttributes. Therefore, a single
>>SignedData object may include multiple security labels, each SignerInfo
>>having an eSSSecurityLabel attribute. For example, an originator can
>>send a
>>signed message with two SignerInfos, one containing a DSS signature, the
>>other containing an RSA signature. Not all of the SignerInfos need to
>>include security labels, but in all of the SignerInfos that do contain
>>security labels, the security labels MUST be identical.  Additionally, a
>>client
>>SHOULD NOT allow access to the mail if it cannot verify atleast one of
>>the 
>>SignerInfos which contains the security label."
>>
>>
>>Jim
>> 
>

Date: Wed, 4 Mar 1998 08:28:32 -0500
To: Bancroft Scott <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Comment on ESS and Privacy Marks
Cc: [email-masked]
Sender: [email-masked]

All,

I agree with Bancroft Scott that ESSPrivacyMark should be:

ESSPrivacyMark ::= CHOICE {
    pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
    utf8String   [0] IMPLICIT UTF8String (SIZE (1..ub-privacy-mark-length))
 }

- John Pawling

Date: Wed, 4 Mar 1998 09:23:55 +0100
From: Christian Rinderknecht <[email-masked]>
To: Russ Housley <[email-masked]>
Cc: [email-masked]
Subject: Re: Comment on ESS and Privacy Marks
Sender: [email-masked]

Russ Housley <[email-masked]> wrote:

> Since S/MIME and PKIX are using the 1988 ASN.1, we need to use the
> [UNIVERSAL xx] trick to support any types that have been defined in the
> subsequent releases of ASN.1.  Several implementations of 1988 ASN.1
> support the use of [UNIVERSAL xx].
  
If your tool needs to use the [UNIVERSAL xx] trick then by all means
change your local copy of S/MIME to use it.  However, this syntax should 
not be part of ASN.1 for it is illegal.  Illegal in 1988
ASN.1. Illegal in 1997 ASN.1.  Illegal in the (illegal) mix of 1988
and 1997.
  
Christian

-- 
Christian Rinderknecht       Alcatel Alsthom Corporate Research Center
Object Architectures Unit    Tel : +33 (0) 1 69 63 17 60
Route de Nozay               Fax : +33 (0) 1 69 63 17 69
91460 Marcoussis, France     
mailto:[email-masked]

Date: Tue, 03 Mar 1998 18:46:29 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Missing mail for ietf-smime
Sender: [email-masked]

Greetings, all. If you sent mail to this list Tuesday afternoon and didn't
see it, please send it again. IMC upgraded its server and majordomo had an
error, which seems to be fixed now. 

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 3 Mar 1998 11:28:30 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Comment on ESS and Privacy Marks
Sender: [email-masked]

All,

Having worked with a 1988-constrained ASN.1 ToolKit for several years, we
(VDA) can verify that both Paul Hoffman's and Bancroft Scott's "UTF8String"
strategies will work.  We have played similar tricks using both strategies.

It seems that Paul Hoffman's strategy (see below) is cleaner because a
context-specific tag is not required for UTF8String if the ASN.1 software
recognizes UTF8String:

ESSPrivacyMark ::= CHOICE {
    pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
    utf8String   UTF8String
}

ub-privacy-mark-length INTEGER ::= 128

I believe that we should add "SIZE (1..ub-utf8-privacy-mark-length)" to the
UTFString component above where ub-utf8-privacy-mark-length is defined as
"ub-utf8-privacy-mark-length INTEGER ::= 768".

Why 768?  It seems that the SIZE constraint on UTF8String should be 6 times
that of the printableString based on Bancroft's statement as follows:

"For almost all purposes UTF8String characters are three bytes max,
but in theory can range to 6 bytes per character.  Only when carrying
characters that lie outside the range of those carried by BMPString
does it exceed three characters per byte.  You may want to look at: 
ftp://ftp.informatik.uni-erlangen.de/pub/doc/ISO/charsets/ISO-10646-UTF-8.html"

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

Date: Tue, 3 Mar 1998 09:02:05 -0500
To: "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Criticality of Authenticated Attributes
Sender: [email-masked]

All,

Jim makes a good point, but I still believe that the essSecurityLabel
authenticatedAttribute must always be critical.  The basis of my opinion is
that when the signer decides to include an essSecurityLabel
authenticatedAttribute in a signedData object, then the signer has made a
deliberate decision that the data must be labeled with specific security
classification and security category values.  By populating the
essSecurityLabel attribute, the signer is stating a requirement that the
recipient must honor that essSecurityLabel by processing it and by
performing access controls checks based on the included values.  If ESS is
written to allow the essSecurityLabel to be non-critical, then the receiving
software could legally ignore the essSecurityLabel and continue processing
the signedData without acting on the essSecurityLabel and without indicating
that condition to the recipient.  I believe that is not acceptable because
it is not consistent with the signer's requirements implied by the signer
populating the essSecurityLabel in the first place.

If the WG agrees that the essSecurityLabel must always be critical, then I
agree with Jim's comment that the intro to ESS should reflect the fact that
essSecurityLabels are not interoperable with legacy S/MIME v2 implementations.

- John Pawling 

At 01:34 PM 2/27/98 -0800, Jim Schaad (Exchange) wrote:
>There is a problem with making essSecurityLabel critical.  This means
>that it cannot be used in S/MIME v2 clients and they will not understand
>the signed message which comes in.  The version on the signedData object
>would be 3.  With this change we have now moved to the point where no
>items in ESS (except for mlExpansionHistory which is a server side
>"feature") can be done with S/MIME v2.  If we accept this then we need
>to re-write the intro to ESS.
>
>jim
>

Date: Tue, 3 Mar 1998 08:44:37 -0500
To: "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: ESS-01 issues not finished
Sender: [email-masked]

All,

I agree with Jim's recommendation.

- John Pawling

At 09:16 PM 2/28/98 -0800, Jim Schaad (Exchange) wrote:
>The following items from my comments for ESS-01 did not make it into
>ESS-02 so here it is again.  Hopefully this time it will get some
>discussion.
>
>1.  Section 3.1.1 paragraph 5.  I disagree that some SignerInfos within
>a SignedData object may be permitted to be missing security labels
>without any restrictions.  I propose the following replacement paragraph
>(new last sentence).
>
>"There can be multiple SignerInfos within a SignedData object, and each
>SignerInfo may include authenticatedAttributes. Therefore, a single
>SignedData object may include multiple security labels, each SignerInfo
>having an eSSSecurityLabel attribute. For example, an originator can
>send a
>signed message with two SignerInfos, one containing a DSS signature, the
>other containing an RSA signature. Not all of the SignerInfos need to
>include security labels, but in all of the SignerInfos that do contain
>security labels, the security labels MUST be identical.  Additionally, a
>client
>SHOULD NOT allow access to the mail if it cannot verify atleast one of
>the 
>SignerInfos which contains the security label."
>
>
>Jim
>

Date: Tue, 3 Mar 1998 08:38:35 -0500
To: "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: ESS-02 Comments part 2
Sender: [email-masked]

All,

I agree with all of Jim's responses included in his 27 Feb 98 message which
responded to my comments to his comments to ESS-02.

- John Pawling

Date: Mon, 2 Mar 1998 16:27:48 -0500 (EST)
From: Bancroft Scott <[email-masked]>
Reply-To: Bancroft Scott <[email-masked]>
To: "David P. Kemp" <[email-masked]>
Cc: [email-masked]
Subject: Re: Comment on ESS and Privacy Marks
Sender: [email-masked]

On Mon, 2 Mar 1998, David P. Kemp wrote:

> > From: Paul Hoffman / IMC <[email-masked]>
> >  
> > I made the opposite choice: the above goes in without the "--" and people
> > who have compilers that already know UTF8String can comment it out.
> 
> This is not a big issue, but I lean with those who would have the
> module as published be a valid ASN.1 specification, requiring that
> the "--" comment chars be removed to allow it to be compiled with the
> tools currently in use.
> 
> Yes, nearly everyone will have to uncomment the definition.  But I
> believe that is preferable to publishing something known to be incorrect.

I too am supportive of the S/MIME having at most the commented definition

	-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING

and requiring that this be removed by anyone using a compiler that
benefits from its removal.  Without the comment the ASN.1 is NOT legal
1988 syntax; nor is it legal 1997 syntax; nor is it legal in a union of
1988 and 1997 syntax.  It is not.  While individual tools are free to use
such syntax as a means of supporting UTF8String, that should be an
individual tool matter, and such illegal syntax that violates every
version of ASN.1 that has ever been has no place in S/MIME.

Further, I recommend the following definition for the likes of
ESEPrivacyMark:

 ESEPrivacyMark ::= CHOICE {
    pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
    utf8String   [0] IMPLICIT UTF8String (SIZE (1..ub-privacy-mark-length))
 }

It DOES NOT introduce an octet hole, fully aligns us with correct
implementations of UTF8String in the future, while at the same time making
it possible for ASN.1 tools that do not support the above illegal
reference to [UNIVERSAL 12] to change the "UTF8String" to OCTET STRING and
thus function until such a time as native support for UTF8String is added
to the tool. 

--------------------------------------------------------------------------
Bancroft Scott                                Toll Free    :1-888-OSS-ASN1
Open Systems Solutions, Inc.                  International:1-609-987-9073
[email-masked]                                  Tech Support :1-732-249-5107
http://www.oss.com                            Fax          :1-732-249-4636

Date: Mon, 2 Mar 1998 14:49:52 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Comment on ESS and Privacy Marks
Sender: [email-masked]

> From: Paul Hoffman / IMC <[email-masked]>
>  
> I made the opposite choice: the above goes in without the "--" and people
> who have compilers that already know UTF8String can comment it out.

This is not a big issue, but I lean with those who would have the
module as published be a valid ASN.1 specification, requiring that
the "--" comment chars be removed to allow it to be compiled with the
tools currently in use.

Yes, nearly everyone will have to uncomment the definition.  But I
believe that is preferable to publishing something known to be incorrect.

Date: Mon, 02 Mar 1998 11:23:34 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Comment on ESS and Privacy Marks
Sender: [email-masked]

Greetings, all. The next round of the ESS document has been turned in to
the I-D editor, and we should see it here soon. Feel free to hold you
comments for a few days until it appears. :-)

>At most there should be a comment:
>
>  --        UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
>  
>Doing so does not break the 1988 and 1997 standards which both forbid
>the use of UNIVERSAL tags in type definitions in ASN.1 modules, it
>makes it clear how this type is formally defined for those people who
>don't know that the tag is UNIVERSAL 12, and it is convenient for
>anyone whose tool does not support UTF8String to simply remove the
>"--" if doing so helps their tool to properly handle UTF8String.
 
I made the opposite choice: the above goes in without the "--" and people
who have compilers that already know UTF8String can comment it out. I based
this on two factors:
- We're still using ASN.1 1988 as the base, and *no* 1988 compilers should
have UTF8String defined
- Few people using more modern compilers have UTF8String today since it was
just finalized a few months ago

Either way, it's up near the top of the module, and should be easy for
people to deal with one way or the other.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 2 Mar 1998 11:50:00 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: ESS-01 issues not finished
Sender: [email-masked]

> From: "Jim Schaad (Exchange)" <[email-masked]>
>
> "Additionally, a client
> SHOULD NOT allow access to the mail if it cannot verify at least one of
> the SignerInfos which contains the security label."

Looks like a necessary restriction to me.  Good catch.

Date: Mon, 2 Mar 1998 10:55:31 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: ESS EncapsulatedContentType
Sender: [email-masked]

> From: Russ Housley <[email-masked]>
> 
> I support John on this one.  I have an additional reason.  The content type
> helps ensure the proper binding.  The content identifier may be defined in
> a content-specific manner.  o, two messages with different content types
> could be assigned the same content identifier by the plug-ins that deal
> with those content types.  In this case, content type and content
> identifier may be necessary to uniquely identify the message that
> corresponds to the receipt.

Russ,

I'm sorry to be a pest, but I am still finding it difficult to
understand this requirement.

ESS says: "A signedContentIdentifier MUST be created by the message
originator when creating a receipt request. To ensure global
uniqueness, the minimal signedContentIdentifier SHOULD contain a
concatenation of user-specific identification information (...), a
GeneralizedTime string, and a random number." Thus the
ContentIdentifier included in Receipt and ReceiptRequest uniquely
identifies the specific signed data without requiring the use of
ContentType.

Perhaps the plug-in assigned field you are discussing above is
"content hints", rather than "content identifier"?

> At 01:40 PM 2/26/98 -0500, John Pawling wrote:
> >
> >IMHO, the Receipt contentType does serve a purpose and I believe that it
> >should be retained.  It indicates the contentType of the message that
> >requested the signed receipt.  If the app is managing multiple flavors of
> >contents, then this field will point the app in the right direction to find
> >the message that matches the Receipt signedContentIdentifier.  
> >
> >For example, lets say that CMS/ESS was being used in conjunction with X.400.
> >The content types could be P2, P22, P772, etc.  The Receipt contentType
> >field will indicate which flavor of message that it needs to locate to
> >validate the signed receipt.
> >
> >In summary, I believe that it would be short-sighted to remove the Receipt
> >contentType.

What resource is being saved by "pointing the app in the right direction"?

If you have a pile of messages with different types (P2, P22, P772,
...) laying around when a receipt comes in, you need to scan each
message to determine whether it matches the receipt.  You could match
the content type of the receipt against each message and only compare
ContentIdentifiers if the ContentType matched, or you could always
compare ContentIdentifier and ignore ContentType.  How much disk I/O
and how many CPU cycles are you saving by doing a two stage compare
instead of just comparing a single field?  Is the miniscule savings
worth the extra complexity?

A more clever UA would just maintain a table mapping ContentIdentifiers
to messages, and would just search incoming receipts against the table
to find the message to which the receipt refers.  Including ContentType
in the Receipt is of no benefit here, it just takes up extra space.

Dave Kemp

Date: Mon, 2 Mar 1998 09:30:47 -0500
To: Russ Housley <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: ESS MLA Attributes Comment
Cc: [email-masked]
Sender: [email-masked]

Russ,

I completely agree with your argument when it is applied to the inner
security label (i.e. securityLabel authenticated attribute included in inner
signedData layer).  

However, I disagree with your argument when applied to the outer security
label (i.e. securityLabel authenticated attribute included in outer
signedData layer).  The outer layer is intended to provide security services
between intermediate entities in addition to involving end entities.  When
an intermediate entity creates an outer signedData object, it signs the data
included in that object.  IMHO, it is OK for the MLA to compose a new
securityLabel based on the MLA's local policies.  The bottom line is that
the MLA signs the securityLabel that it constructs.  If ESS included a rule
limiting the values that an intermediate entity can place in the
securityLabel that it creates in the outer signedData, then it is impossible
for the recipient to cryptographically verify that the intermediate entity
actually followed the securilyLabel-related rule because the recipient
verifies the intermediate entity's signature of the outer signedData
(including authenticated attributes including the securityLabel).

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
===============================

At 06:07 PM 2/28/98 -0500, Russ Housley wrote:
>John:
>
>I understnad your point, and I mostly agree.  I am concerned with label
>translation.  Translation is never perfect.  Translating from domain A to
>domain B will loose informations (or worse), and then translation back to
>domain A will result in a different label.  For this reason, I think it is
>prudent to maintain a label throughout the delivery path (perhaps multiple
>MLAs), and then translate only once at the final recipient.
>
>Russ
>
>
>At 06:17 PM 2/19/98 -0500, John Pawling wrote:
>>Russ,
>>
>>I agree that the MLA MUST NEVER change the original signer's securityLabel
>>authenticated attribute contained in the innermost signedData.  Because
>>CMS/ESS binds the securityLabel authenticatedAttribute with the signature of
>>the data, intermediate entities can't change the securityLabel without
>>breaking the original signer's signature.  That is an excellent feature of
>>CMS/ESS.
>>
>>However, I respectfully disagree with your proposal that the MLA must be
>>restricted from defining the securityLabel values in the outermost
>>signedData envelope that it creates and signs.  When an MLA-expanded message
>>is received by the ultimate recipient, the receiving software will process
>>the securityLabel defined by the MLA when it validates the MLA-generated
>>outermost signedData layer and will separately process the securityLabel
>>defined by the original signer when it validates the innermost signedData
>>layer.  IMHO, the policy defining how an MLA derives the values for the
>>securityLabel included in the outermost signedData that it signs should be a
>>matter of local customer policy, not mandated by the ESS spec.  Your
>>proposal would unnecessarily (IMHO) limit the flexibility of the CMS/ESS
>>spec, so I oppose it.  
>> 
>>================================
>>John Pawling   
>>[email-masked]                             
>>J.G. Van Dyke & Associates, Inc.           
>>===============================
>>
>>
>>At 03:44 PM 2/19/98 -0500, Russ Housley wrote:
>>>John:
>>>
>>>I disagree with your handling of security label.  MLAs should not modify an
>>>existing security label attribute.  This action would encourage label
>>>translation.
>>>
>>>I suggest that we permit the addition of a security label if it is absent,
>>>but otherwise the MLA should preserve the outter security label.
>>>
>>>Russ
>>>
>> 
>

Date: Mon, 2 Mar 1998 15:22:30 +0100
From: Christian Rinderknecht <[email-masked]>
To: Russ Housley <[email-masked]>
Cc: [email-masked], John Pawling <[email-masked]>
Subject: Re: Comment on ESS and Privacy Marks
Sender: [email-masked]

On Mon, 2 Mar 1998, Russ Housley wrote:

>>I agree with Bancroft Scott that ESSPrivacyMark should be re-defined
+as follows:
>>
>>> ESSPrivacyMark ::= CHOICE {
>>>    pString      PrintableString (SIZE
+(1..ub-privacy-mark-length)),
>>>    utf8String   [0] IMPLICIT UTF8String (SIZE
+(1..ub-privacy-mark-length))
>>> }
>>
>>
>>Note Bancroft's point as follows:
>>
>>Another
>>benefit is that if someone is using a tool that does not support
>>UTF8String they can simply change it to "[0] OCTET STRING" and get
+the
>>same encoding.
>
> I do not agree. I think we should use the UNIVERSAL tag.  This will
> align us with the correct implementation of UTF8 in the future,
+rather 
> than creating an octet hole to carry a UTF8.

An "octet hole" is use of an OCTET STRING type to carry data of some
other type, so [0] IMPLICIT UTF8String is not an octet hole for the
type of the value is clearly specified as UTF8String.  The suggestion
below to define the utf8String component with an IMPLICIT tag is a
good idea, for it does not put an octet hole in the standard, while at
the same time gives implementors the freedom to use octet holes if
that is how they would like to support UTF8String.

At most there should be a comment:

  --        UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
  
Doing so does not break the 1988 and 1997 standards which both forbid
the use of UNIVERSAL tags in type definitions in ASN.1 modules, it
makes it clear how this type is formally defined for those people who
don't know that the tag is UNIVERSAL 12, and it is convenient for
anyone whose tool does not support UTF8String to simply remove the
"--" if doing so helps their tool to properly handle UTF8String.

Christian

---

Christian Rinderknecht       Alcatel Alsthom Corporate Research Center
Object Architectures Unit    Tel : +33 (0) 1 69 63 17 60
Route de Nozay               Fax : +33 (0) 1 69 63 17 69
91460 Marcoussis, France     
mailto:[email-masked]

From: Scott Hollenbeck <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RE: ESS-02 MLA Receipt Policies
Date: Mon, 2 Mar 1998 05:57:15 PST
Sender: [email-masked]

OK, let me suggest a small addition to the end of section 4.3.
The last paragraph currently reads:

"The interesting cases are combining insteadOf with inAddtionTo. The rest of
the cases either substitute in B's policy or propagate forward A's policy."

(First note another misspelling in the above sentence.  "inAddtionTo"
should be "inAdditionTo").

I suggest:

"The interesting cases are combining insteadOf(A) and inAdditionTo(A) with
inAdditionTo(B).  Note that the union of insteadOf(A) and inAdditionTo(B),
listed in the table as insteadOf(A+B), is more specifically defined as
insteadOf(insteadOf(A) + inAdditionTo(B)).  The rest of the cases either
substitute in B's policy or propagate forward A's policy."

Scott

-----Original Message-----
From:	Russ Housley [SMTP:[email-masked]]
Sent:	Saturday, February 28, 1998 5:51 PM
To:	Scott Hollenbeck
Cc:	[email-masked]
Subject:	Re: ESS-02 MLA Receipt Policies

Yes, Scott you have it correct.  If this is not clear in the document,
please suggest wording changes to make it clear.

Russ

At 07:55 AM 2/20/98 -0800, Scott Hollenbeck wrote:
>First, two minor typos in the table in section 4.3:
>
>The entry for "A's policy is missing" and "B's policy is inAdditionTo"
>is misspelled.  "inAddtionTo(B)" should be "inAdditionTo(B)".
>
>The entry for "B's policy is missing" and "A's policy is inAdditionTo"
>is misspelled.  "inAditionTo" should be "inAdditionTo".
>
>Now I need to understand something about the intended union of the
>policies.  Consider this case:
>
>A's policy is insteadOf, and B's policy is inAdditionTo.  The table
>says the union is insteadOf(A+B).  Does this mean the effective policy
>is the union of A's insteadOf names and B's inAdditionTo names to yield
>insteadOf(insteadOf(A) + inAdditionTo(B))?  I know there aren't any other
>names available, but the table entry makes it look like there should be
>insteadOf names for B.
>
>----->
>Scott Hollenbeck (mailto:[email-masked])
>Xerox Special Information Systems
>Arlington, Virginia, USA

Date: Sat, 28 Feb 1998 17:50:51 -0500
To: Scott Hollenbeck <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: ESS-02 MLA Receipt Policies
Cc: [email-masked]
Sender: [email-masked]

Yes, Scott you have it correct.  If this is not clear in the document,
please suggest wording changes to make it clear.

Russ

At 07:55 AM 2/20/98 -0800, Scott Hollenbeck wrote:
>First, two minor typos in the table in section 4.3:
>
>The entry for "A's policy is missing" and "B's policy is inAdditionTo"
>is misspelled.  "inAddtionTo(B)" should be "inAdditionTo(B)".
>
>The entry for "B's policy is missing" and "A's policy is inAdditionTo"
>is misspelled.  "inAditionTo" should be "inAdditionTo".
>
>Now I need to understand something about the intended union of the
>policies.  Consider this case:
>
>A's policy is insteadOf, and B's policy is inAdditionTo.  The table
>says the union is insteadOf(A+B).  Does this mean the effective policy
>is the union of A's insteadOf names and B's inAdditionTo names to yield
>insteadOf(insteadOf(A) + inAdditionTo(B))?  I know there aren't any other
>names available, but the table entry makes it look like there should be
>insteadOf names for B.
>
>----->
>Scott Hollenbeck (mailto:[email-masked])
>Xerox Special Information Systems
>Arlington, Virginia, USA
> 

Date: Sat, 28 Feb 1998 18:36:00 -0500
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: RE: Comment on ESS and Privacy Marks
Cc: [email-masked]
Sender: [email-masked]

I do not agree. I think we should use the UNIVERSAL tag.  This will align
us with the correct implementation of UTF8 in the future, rather than
creating an octet hole to carry a UTF8.

Russ

At 08:32 AM 2/19/98 -0500, John Pawling wrote:
>All,
>
>I agree with Bancroft Scott that ESSPrivacyMark should be re-defined as
follows:
>
>> ESSPrivacyMark ::= CHOICE {
>>    pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
>>    utf8String   [0] IMPLICIT UTF8String (SIZE (1..ub-privacy-mark-length))
>> }
>
>
>Note Bancroft's point as follows:
>
>>Another
>>benefit is that if someone is using a tool that does not support
>>UTF8String they can simply change it to "[0] OCTET STRING" and get the
>>same encoding. 
>
>================================
>John Pawling   
>[email-masked]                             
>J.G. Van Dyke & Associates, Inc.           
>================================
> 

Date: Sat, 28 Feb 1998 18:07:30 -0500
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: Re: ESS MLA Attributes Comment
Cc: [email-masked]
Sender: [email-masked]

John:

I understnad your point, and I mostly agree.  I am concerned with label
translation.  Translation is never perfect.  Translating from domain A to
domain B will loose informations (or worse), and then translation back to
domain A will result in a different label.  For this reason, I think it is
prudent to maintain a label throughout the delivery path (perhaps multiple
MLAs), and then translate only once at the final recipient.

Russ

At 06:17 PM 2/19/98 -0500, John Pawling wrote:
>Russ,
>
>I agree that the MLA MUST NEVER change the original signer's securityLabel
>authenticated attribute contained in the innermost signedData.  Because
>CMS/ESS binds the securityLabel authenticatedAttribute with the signature of
>the data, intermediate entities can't change the securityLabel without
>breaking the original signer's signature.  That is an excellent feature of
>CMS/ESS.
>
>However, I respectfully disagree with your proposal that the MLA must be
>restricted from defining the securityLabel values in the outermost
>signedData envelope that it creates and signs.  When an MLA-expanded message
>is received by the ultimate recipient, the receiving software will process
>the securityLabel defined by the MLA when it validates the MLA-generated
>outermost signedData layer and will separately process the securityLabel
>defined by the original signer when it validates the innermost signedData
>layer.  IMHO, the policy defining how an MLA derives the values for the
>securityLabel included in the outermost signedData that it signs should be a
>matter of local customer policy, not mandated by the ESS spec.  Your
>proposal would unnecessarily (IMHO) limit the flexibility of the CMS/ESS
>spec, so I oppose it.  
> 
>================================
>John Pawling   
>[email-masked]                             
>J.G. Van Dyke & Associates, Inc.           
>===============================
>
>
>At 03:44 PM 2/19/98 -0500, Russ Housley wrote:
>>John:
>>
>>I disagree with your handling of security label.  MLAs should not modify an
>>existing security label attribute.  This action would encourage label
>>translation.
>>
>>I suggest that we permit the addition of a security label if it is absent,
>>but otherwise the MLA should preserve the outter security label.
>>
>>Russ
>>
> 

Date: Sat, 28 Feb 1998 12:18:31 -0500
To: Carlisle Adams <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Inclusion of the issuer and serial number in authenticated information
Cc: [email-masked]
Sender: [email-masked]

Carlisle:

I prefer the inclusion of the issuer and serial number as an authenticated
attribute.  The signature certificate is likely to be included already.
This does require that the issuer have distinguished name (not an empty
name and an alt name).

Do you prefer the addition of the new attribute in ESS or CMS?  I see
advantages to both choices.

Russ

At 01:57 PM 2/25/98 -0500, Carlisle Adams wrote:
>Hi Jim,
>
>>----------
>>From: 	Jim Schaad (Exchange)[SMTP:[email-masked]]
>>Sent: 	Wednesday, February 25, 1998 1:25 AM
>>To: 	Ietf-Smime (E-mail)
>>Subject: 	Inclusion of the issuer and serial number in authenticated
>>information
>>
>>In discussions with other people here at Microsoft about the questions
>>of building certificate chains and what you sign with (a certificate or
>>a key), we came up with an interesting security hole from a legal
>>standpoint.  If a person gets more than one certificate for a given key,
>>a person could switch certificates in the signed data object to the
>>other certificate thus potentially changing the legal liability of the
>>signature.
>
>Denis Pinkas has been talking about this for a long time now (see, for
>example, some of his postings to the PKIX list some time back, where the
>context of the discussion was proof-of-possession in operational
>protocols).  Ultimately, what you want (from both a security and a legal
>standpoint) is that a signature is computed not only over some data, but
>also over the certificate (or cert. identifier) containing the public
>key to be used to verify the signature.
>
>Within something like CMS there are two very simple solutions.  The
>first is what you suggested:
>
>>To address this problem, I strongly suggest we do the following:
>>
>>1.  In CMS we define an authenticated attribute which contains the
>>issuer and serial number of the certificate which was used to sign the
>>message.
>
>The other is to put the certificate itself (rather than the issuer &
>serial number) in an authenticated attribute.  This might be attractive
>if the certificate is not carried elsewhere in the envelope or if it is
>desirable to have the relevant information (e.g., the verification key
>to check the signature) right there at your fingertips.  In any case,
>either solution is probably fine (though for CMS I suspect the former is
>preferable...).
>
>>2.  We require this new attribute to be included in the
>>authenticatedAttributes section of the message if one exists.  (We can't
>>do anything about the problem if it does not exists.)
>
>I suppose you could also say that an authenticateAttributes section
>SHOULD exist, for this very reason.
>
>>If the list thinks this is a problem which needs to be addressed, I will
>>come up with a detailed proposal to fix this and submit it to the list.
>>
>>jim schaad
>
>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked]
>--------------------------------------------
> 

Date: Sat, 28 Feb 1998 11:57:40 -0500
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: Re: ESS EncapsulatedContentType
Cc: [email-masked]
Sender: [email-masked]

I support John on this one.  I have an additional reason.  The content type
helps ensure the proper binding.  The content identifier may be defined in
a content-specific manner.  o, two messages with different content types
could be assigned the same content identifier by the plug-ins that deal
with those content types.  In this case, content type and content
identifier may be necessary to uniquely identify the message that
corresponds to the receipt.

Russ

At 01:40 PM 2/26/98 -0500, John Pawling wrote:
>All,
>
>IMHO, the Receipt contentType does serve a purpose and I believe that it
>should be retained.  It indicates the contentType of the message that
>requested the signed receipt.  If the app is managing multiple flavors of
>contents, then this field will point the app in the right direction to find
>the message that matches the Receipt signedContentIdentifier.  
>
>For example, lets say that CMS/ESS was being used in conjunction with X.400.
>The content types could be P2, P22, P772, etc.  The Receipt contentType
>field will indicate which flavor of message that it needs to locate to
>validate the signed receipt.
>
>In summary, I believe that it would be short-sighted to remove the Receipt
>contentType.
>
>- John Pawling
>
>
>At 11:08 AM 2/26/98 -0500, David P. Kemp wrote:
>>> From: [email-masked] (John Pawling)
>>> 
>>> I respectfully disagree with Dave that contentType should be removed from
>>> the Receipt content syntax.  It is included in the signed receipt to
assist
>>> the application that must validate the signed receipt with the process of
>>> identifying the original message (or hash of the message) that
requested the
>>> signed receipt.  The original message (or hash of the message) is required
>>> to validate the signed receipt.  The Receipt contentType will
especially be
>>> valuable to apps that must manage contents of multiple types.
Therefore, I
>>> believe that contentType should be retained and that it should be
changed to
>>> a mandatory field which will always contain the value copied from the
>>> signedData encapContentInfo eContentType field of the message
requesting the
>>> signed receipt.
>>
>>
>>I don't object to keeping contentType in Receipt if it serves a purpose.
>>However, I still don't understand what the purpose is.  Currently, the
>>eContentType field of the innermost signed data will *always* contain
>>id-data, no?  If Russ' proposal to define 4 additional OIDs for X.411
>>builtin message types, or my (as yet unproposed) proposal to define
>>a single id-data-x411 OID for X.411 messages is adopted, there will
>>be at most a few eContentType values.  In practice, a single user
>>is not likely to have both S/MIME and X.411 original messages awaiting
>>receipts, so the contentType field in the Receipt will be totally
>>useless in distinguishing which message the receipt applies to.
>>At best, it could only help distinguish between S/MIME and X.411 messages.
>>
>>Even then (if there were multiple content types), what is the purpose
>>of including contentType in the Receipt?  The Receipt
>>signedContentIdentifier uniquely identifies the message to which the
>>receipt applies, so the UA only needs to validate the receipt against
>>that single message.
>>
>>What am I missing?
>>
>>
> 

Date: Sat, 28 Feb 1998 11:50:03 -0500
To: [email-masked], [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: ESS-02 Comments
Cc: [email-masked]
Sender: [email-masked]

Paul and I talked about this on the phone.  We decided to place the OIDs in
each document.  The rationale is simple.  If a particular document need a
new OID, then corresponding text on the use of the OID should be added at
the same time.  Putting the OID definition and the descriptive text in the
same place ensure synchronizations.

Russ

At 01:59 PM 2/26/98 -0500, John Pawling wrote:
>Russ,
>
>Whatever you want to do is fine with me.  I thought that the S/MIME OIDs was
>a part of the document tree, but if it is easier to divvy up these OIDs in
>the various docs, then that is fine with me.
>
>- John Pawling
>
>
>At 01:44 PM 2/26/98 -0500, Russ Housley wrote:
>>John:
>>
>>If we take that approack, then the OID module must be added to our document
>>tree.
>>
>>Russ
>>
>>
>>At 12:06 PM 2/26/98 -0500, John Pawling wrote:
>>>Russ,
>>>
>>>The CMS and ESS modules could import the OIDs from the S/MIME OIDs module.
>>>Defining the OIDs in multiple modules invites inconsistencies.
>>>
>>>- John Pawling
>>>
>>>
>>>At 09:40 AM 2/26/98 -0500, Russ Housley wrote:
>>>>Paul:
>>>>
>>>>The OID in the registry is not sufficient.  Please look at CMS Appendix A,
>>>>and you will see that the OIDs needed to implement CMS are part of the CMS
>>>>module.
>>>>
>>>>Russ
>>> 
>>
> 

Date: Sat, 28 Feb 1998 11:46:27 -0500
To: [email-masked], [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: ESS-02 Comments part 2
Cc: [email-masked]
Sender: [email-masked]

Two comments below.  I refixed them with RH:

Russ

At 01:33 PM 2/26/98 -0500, John Pawling wrote:
>All,
>
>I agree with all of Jim's comments except that I have a few comments
>regarding his comments:
>
>At 06:40 PM 2/25/98 -0800, Jim Schaad (Exchange) wrote:
>>1.  Section 1 pargraph #2:  Since as time goes by it becomes harder for
>>me to understand what sections of this document require SMIME3 and what
>>can be implemented using SMIME2, I would like to be explicit here.
>>Replace with the following paragraph: "The services described here are
>>extensions to S/MIME version 2 [SMIME2] and S/MIME version 3 [SMIME3].
>>The Security Label and Mail List Agent services can be added to S/MIME
>>version 2, but the Secure Reciepts service requires [CMS] and can only
>>be added to S/MIME version 3."  then contue with the last sentence.
>
>[JSP:  Why do you think that signed receipts can't be added to an S/MIME v2
>product?  It seems like support for the receiptRequest attribute could be
>added.  Similarly, the S/MIME v2 product could be enhanced to support the
>Receipt content.  I understand that these are noon-trivial enhancements, but
>I don't see why they couldn't be implemented.]

RH: John, some S/MIME v2 implementations only support id-data.  As you
point out, non-trivila changes will be needed to support receipts.  These
chages will surely include API modifications.

>>5.  Section 2.10 -- Please insert a section describing the
>>msgDigestAttribute here:
>>2.10  Message Digest Attribute
>>
>>This attribute is used only in a Secure Receipt authenticated attributes
>>section.  It contains the message digest of the SignedData object for
>>which a receipt is being created.  Only one msgDigestAttribute can
>>appear in an authenteicated attributes set.
>>
>>ASN goes here...\
>
>[JSP: Did you mean "Message Signature Digest".  If so, then I recommend the
>following re-wording of your proposed para:
>
>"2.10  Message Signature Digest Attribute
>
>This attribute can only be used in the authenticated attributes of a signed
>receipt.  It contains the digest of the ASN.1 DER encoded
>authenticatedAttributes included in the original signedData that requested
>the signed receipt.  Only one msgSigDigest attribute can appear in an
>authenticated attributes set.  Section 2 provides more details regarding the
>use of the msgSigDigest authenticated attribute.  It is defined as follows:
>
>msgSigDigest ::= OCTET STRING."]
>
>
>>9.  Section 4.1, paragraph 5.  Please as the following sentence.  "An
>>MLA SHOULD NOT expand and redistribute a message if it cannot validate
>>one or more outer signatures."
>
>[JSP: I respectfully disagree with this comment.  A user could send a
>double-wrapped message (i.e. envelopedData encapsulating signedData) to an
>MLA in which there is not an outer signedData.  Furthermore, a user may send
>a single-wrapped signedData or envelopedData message to an MLA in which
>there is not an outer signedData.] 

RH:  I agree with John.  Given a signed-encrypted-signed message, the MLA
should only operate on the outer two wrappers.

>>10.  Section 4.2.1, Bullet 2.
>>This is along the lines of a question,  Should the new RecipientInfos be
>>unioned with the existing set or replaced.  There are no security
>>reasons why it cannot be replacement but this seems odd to me.
>
>[JSP:  The MLA deletes the existing recipientInfos and builds a new
>recipientInfo for each member of the ML.  The recipientInfos in the original
>message are not needed in the MLA-expanded message because those users can

>decrypt the original message.  For example, user 1 sends a message
>containing recipientInfos for: ML1, Tom and Dick.  ML1, Tom and Dick each
>receive their copy of the message and decrypt it using their copy of
>recipientInfo.  The MLA representing ML1 will expand the copy of the message
>that it received.  The recipientInfos for ML1, Tom and Dick are not required
>in the MLA-expanded message, because the message is not being sent to ML1,
>Tom and Dick.  It is being sent to the ML recipients.]
>
>
>>13.  Section 1.4 and Appendix A.  We should not be refering to the imc
>>URL for the oids anymore or saying we intend to move to IANA to keep the
>>registry.   Recommend deletion of section 1.4 and the inclusion of the
>>OIDs used by this draft in Appendix A.
>
>[JSP: Why can't we refer to the S/MIME OIDs document?  It includes an ASN.1
>module that includes all of the OIDs.  The ESS and CMS modules can immport
>this module.]
>