Subject: (3) Re: New versions of the -msg and -cert documents
From: "Phillip H. Griffin" <[email-masked]>
To: Blake Ramsdell <[email-masked]>
Cc: "'Paul Hoffman / IMC'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Date: Fri, 30 Jan 1998 21:03:32 -0500

Blake Ramsdell wrote:
> 
snip
> If you have specific changes that surround things other than
snip

In the message specification, type 

   SMIMECapability ::= SEQUENCE {
      capabilityID OBJECT IDENTIFIER,
      parameters OPTIONAL ANY DEFINED BY capabilityID }

should have the OPTIONAL moved to just before "}"
to be correct.

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
------------------------------------------------------------

From: Brian Korver <[email-masked]>
Subject: Re: Critical Attributes
To: [email-masked] (Russ Housley)
Date: Fri, 30 Jan 1998 17:49:49 -0800 (PST)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Russ Housley writes:
> 
> All:
> 
> The current ASN.1 syntax of attribute is actually a bit of a problem.  If
> an attribute is encountered that is unknown, the ASN.1 decoder might die.
> To avoid this problem, X.509v3 extensions all have a type of OCTET STRING.
> These extensions require a second decode pass to extract the extension
> value from the OCTET STRING.
> 
> Can some folks with real life implemntation experience of ANY offer
> suggestions?
> 
> Russ

Russ,

In practice, the second decode pass isn't because of the OCTET STRING.
Rather, because the sequence can have arbitrary values in arbitrary 
order, the obvious data structure you would parse the values into
would be a union of all the possible value types.  Unfortunately,
that is rarely the more desirable data structure to parse the data
into.  So instead, the sequence is parsed to obtain the OIDs, and then
each value is parsed individually (when convenient to do so).
 
That is, the OCTET STRING by itself does not negate single pass decoding.
In fact, you can convert any OCTET STRING to an ANY by replacing 
"OCTET STRING" in the ASN.1 with "[UNIVERSAL 4] IMPLICIT ANY"
(notwithstanding the howling from ASN.1 purists :).  Most tools support
this, and in practice this sort of ASN.1 mangling is employed with
great success to provide implementation flexibility.  Thus, from the
standpoint of implementation, I often prefer OCTET STRING to ANY
because I--as an implementor--can choose which way I want to treat the
data.  
 
That said, I would vote for backward compatability: that AttributeValue
continue to be an ANY.  

brian
[email-masked]

Date: Fri, 30 Jan 1998 20:00:28 -0500
To: ross <[email-masked]>, [email-masked], Russ Housley <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Critical Attributes
Sender: [email-masked]

All,

I agree with Russ and Ross that the critical Boolean option is the way to go.

- John Pawling

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>
Cc: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Hashing of CMS signedData objects
Date: Fri, 30 Jan 1998 16:08:42 -0800
Sender: [email-masked]

Yes all of the objects have their own OIDs so that they are
recognizable.  I would not however wish to enumerate the list and
special case in that way.

jim

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Friday, January 30, 1998 5:40 AM
To: Jim Schaad (Exchange)
Cc: Ietf-Smime (E-mail)
Subject: Re: Hashing of CMS signedData objects

Jim:

I need more information.  Do these objects have their own OIDs?  If so,
there may be a straightforward way to support them. 

Russ

At 01:20 PM 1/28/98 -0800, Jim Schaad (Exchange) wrote:
>When we had the discussions in San Fransico at the RSA conference, one
>of the questions that was raised about changing the what data and how
>the data was encoded was if there was any material currently out in the
>real world which was signed in the PKCS #7 way rather than the new
>proposed CMS way.  At the time I said that I know of none.  I have
since
>been informed that MIcrosoft actually does have some objects signed and
>encoded in this manner, and they have actually been released into the
>real world.
>
>This gives a problem to me because it means that I need to have atleast
>some backwards compatable language put into the CMS draft.  Thus I
>propose the following:
>
>We add an appendix to the CMS draft to explain the following items:
>1.  The difference and reasons for the change in the way that the data
>is encoded.
>2.  A general way of doing recognition of the two different ways of
>encoding and how to correctly verify each way
>3.  A statemtent that one MAY implement the compatibilty mode of
>signature verification and one SHOULD NOT implement the compatability
>mode of signature creation unless required to do so by backwards
>compatability issues.
>
>How to do both signature verifications:
>
>Look at the type of the data enclosed.  
>-  If it is octet string then strip the type and length encoding bytes,
>allowing for the possilbity that it may be indefinite lenght encoded,
>and hash the remaining data.  The data actually hashed is then returned
>as the data block of signedData object.
>-  If it is not octet string, then strip the type and length encoding
>bytes (can't be indefinite length encoded) and hash the remaining data.
>The data returned as the data block of the signedData object is the
>type, length and hashed data.
>

Date: Fri, 30 Jan 1998 18:53:15 -0500
To: "Jim Schaad (Exchange)" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Hashing of CMS signedData objects
Sender: [email-masked]

All,

I believe that CMS should mandate the strategy that was agreed to at San
Francisco as follows:

"Proposal #2: Change the CMS SignedData contentInfo field to be
signedContentInfo defined as follows:

SignedContentInfo ::=  SEQUENCE {
    sigContentType       ContentType,
    sigContent      [0]  EXPLICIT  OCTET STRING  OPTIONAL}

It is proposed that the CMS Section 5.3 will be changed so that the
digesting rules are consistent for all types of data that is signed (i.e.
the rules for digesting the Data content type will be extended to all types
of data)."

- John Pawling

Date: Fri, 30 Jan 1998 18:42:54 -0500
To: Russ Housley <[email-masked]>, "Bonatti, Chris" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Content Type Attribute Question
Cc: [email-masked]
Sender: [email-masked]

Russ,

ESS, Sec 1.3.4 already lists encapsulatedContentType as a separate
attribute.  This is needed to provide equivalent services as the ACP120
encapsulatedContentType.  

Please note that the ESS Open Issues (Appendix D) states that OIDs still
need to be defined for the contentType and encapsulatedContentType attributes.

- John Pawling

Date: Fri, 30 Jan 1998 18:08:44 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: Blake Ramsdell <[email-masked]>
CC: "'Russ Housley'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Hashing of CMS signedData objects
Sender: [email-masked]

Blake Ramsdell wrote:
> 
snip
> 
> Jim has brought up a good point that since they use PKCS #7 for
> Authenticode (I think) as well as potentially for other stuff, he
> doesn't want to cart around code for both CMS and PKCS #7.
> 
snip

If I'm not mistaken, that will be necessary anyway. PKCS #7,
we were told when we used it in the design of SET, assumes
EXPLICIT tags, but I believe that S/MIME assumes IMPLICIT.
I haven't looked closely enough at the two and run test 
cases, but I would expect that there are some differences.
But maybe not.

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
------------------------------------------------------------

From: "Blake Ramsdell" <[email-masked]>
To: "'Elliott N Ginsburg'" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-cert-01.txt
Date: Fri, 30 Jan 1998 14:42:48 -0800
Sender: [email-masked]

<internet-drafts recipients trimmed>

On Friday, January 30, 1998 11:05 AM, Elliott N Ginsburg
[SMTP:[email-masked]] wrote:
> We've had well over a month of discussions about the requirement for
> email
> address in end-entity certs, and the requirement for the MUA to check the
> From field against the email addresses in the cert. Yet this latest draft
> is virtually the same as the previous draft on these issues.
> 
> I thought that it had been settled that neither of these requirements
> would
> remain. Wasn't that the concensus from the meeting in San Francisco?

I screwed up.  The word MUST will be replaced with MAY in the following
sentence from section 3.1:

> End-entity certificates MUST contain an Internet mail address as
> described in [RFC-822].

I read the first half of the paragraph from John's notes, but not the
last half.

Boy, it's getting hot in here.  I should learn how to edit.

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, 30 Jan 1998 17:44:17 -0500
To: Russ Housley <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Comments to CMS-02
Cc: [email-masked]
Sender: [email-masked]

Russ,

I agree with all of your responses to my comments except for the following:

I originally stated:
>>3) Sec 6.2, RecipientInfo originatorCert description:  Please add "This
>>field should be included when the recipientInfo keyEncryptionAlgorithm field
>>indicates a key agreement algorithm and the originator's certificate is
>>omitted from the envelopedData originatorInfo field (i.e. the originator's
>>public key material is required as part of the process to decrypt the
>>encryptedKey, but the originator's certificate is not included in the
>>envelopedData object)." 

You responded:
>I do not understand this one.  In the bag-of-certificates, the originator
>may have more than one with the specified key management algorithm.  In
>this case, the originator tells the recipient which one to use.  The
>certificate itself is not carried here, rather an EntityIdentifier is carried:
>
>  EntityIdentifier ::= CHOICE {
>    issuerAndSerialNumber IssuerAndSerialNumber,
>    subjectKeyIdentifier SubjectKeyIdentifier }
>
>So, I do not see the change that is needed....

[JSP: Consider this example: I receive an envelopedData that includes a
recipientInfo for my D-H certificate, but the envelopedData does not include
originatorInfo and my recipientInfo does not include originatorCert.  (This
is currently allowed by CMS).  How do I identify the originator's D-H cert
from which the public D-H key must be obtained to be used to form the
pairwise key to be used to decrypt the encrypted session key???  I can't.

My point was to ensure that CMS clearly states that the originator's cert
must be present in originatorInfo or must be identified in recipientInfo
originatorCert.  I believe that my comment should be included.]

- John Pawling

From: "Blake Ramsdell" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: RE: Hashing of CMS signedData objects
Date: Fri, 30 Jan 1998 14:41:48 -0800
Sender: [email-masked]

On Friday, January 30, 1998 5:42 AM, Russ Housley
[SMTP:[email-masked]] wrote:
> No.  It will be a concern when the content encapsulated in a signed data
> does not use the data content type.  In this case, the PKCS#7v1.5
> language
> says that the encapsulated content should be DER encoded.

My point was the only incompatibility should come as a result of PKCS #7
1.5 coexisting in the same environment as CMS, which is only in S/MIME
right now.  I understand the technical reason of the incompatibility (I
suggested the OCTET STRING wrapping, I think :)).

Jim has brought up a good point that since they use PKCS #7 for
Authenticode (I think) as well as potentially for other stuff, he
doesn't want to cart around code for both CMS and PKCS #7.

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, 30 Jan 1998 16:58:38 -0500
To: Russ Housley <[email-masked]>, ross <[email-masked]>
From: John Lowry <[email-masked]>
Subject: Re: Critical Attributes
Cc: [email-masked]
Sender: [email-masked]

Russ,

Not all ASN.1 compilers "die" when encountering an unknown OID.
It is up to the compiler writer to provide a way of handling this
issue.  I would argue that a good compiler would handle the syntax
correctly provided it is properly encoded and provide an exception
handler for unrecognized semantics (values).

I guess it is obvious that I don't have a problem with this...

John

At 02:54 PM 1/30/98 -0500, Russ Housley wrote:
>All:
>
>The current ASN.1 syntax of attribute is actually a bit of a problem.  If
>an attribute is encountered that is unknown, the ASN.1 decoder might die.
>To avoid this problem, X.509v3 extensions all have a type of OCTET STRING.
>These extensions require a second decode pass to extract the extension
>value from the OCTET STRING.
>
>Can some folks with real life implemntation experience of ANY offer
>suggestions?
>
>Russ
>
>
>>-----Original Message-----
>>From: Russ Housley <[email-masked]>
>>To: [email-masked] <[email-masked]>
>>Date: Thursday, January 29, 1998 9:53 AM
>>Subject: Critical Attributes
>>
>>
>>>All:
>>>
>>>There has benn much discussion of attribute criticality.  It is my view
>>>that there is concensus that the feature is needed.  Two mecanisms for the
>>>addition of this feature have been offered.
>>>
>>>First alternative: include a BOOLEAN in the attribute definition that
>>>states the criticality of the the attribute.  If the attribute is marked
>>>critical and an implementation does not know how to process the attribute,
>>>then the message must be rejected.
>>>
>>>Second alternative: include a new attribute that lists the OIDs of all
>>>critical attributes.
>>>
>>>In terms of backward compatibility with S/MIME 2, these two mechanisms have
>>>very different implications.
>>>
>>>By defining a DEFAULT value for the BOOLEAN, all non-critical attributes
>>>will be backward compatible.  Also, we can use the S/MIME 3 version to
>>>indicate that critical attributes are present.  This use of version should
>>>keep an S/MIME 2 implementation from having an ASN.1 decode error.  The
>>>ASN.1 would be:
>>>
>>>   Attribute ::= SEQUENCE {
>>>     attributeType   OBJECT IDENTIFIER,
>>>     critical        BOOLEAN DEFAULT FALSE,
>>>     attributeValues SET OF AttributeValue }
>>>
>>>   AttributeValue ::= ANY
>>>
>>>On the other hand, the critical attribute list makes no change to the
>>>syntax.  However, an S/MIME 2 implementation would simply ignore this
>>>attribute as it would any other unsupported attribute.  So, the criticality
>>>of the attributes would not really be imposed.
>>>
>>>This breifi analysis leads to to the coluclusion that the critical boolean
>>>is a better path.  Is there concensus on this point?
>>>
>>>Russ
>>
>
>

Date: Fri, 30 Jan 1998 16:42:30 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: Critical Attributes
Sender: [email-masked]

David P. Kemp wrote:
> 
> > From: Russ Housley <[email-masked]>
> >
> > All:
> >
> > The current ASN.1 syntax of attribute is actually a bit of a problem.  If
> > an attribute is encountered that is unknown, the ASN.1 decoder might die.
> > To avoid this problem, X.509v3 extensions all have a type of OCTET STRING.
> > These extensions require a second decode pass to extract the extension
> > value from the OCTET STRING.
> >
> > Can some folks with real life implemntation experience of ANY offer
> > suggestions?
> >
> > Russ
> 
> This might be a problem for some implementations, but it doesn't have
> to be.
>

Amen. Folks have been handling ANY (TYPE-IDENTIFIER.&Type in 1994, 
almost) for some time. Folks using 1988 Tools that are implementing
the ASN.1:1994 SET protocol implement TYPE-IDENTIFIER.&Type using
the same code they use for ANY. Such toolkits then augment this code, 
or have the using application do so, with a little code to verify
that the hex blob that follows the ANY is a valid ASN.1 type. Simple. 

> X.509 has three extensible object classes: certificate extensions,
> algorithms (as used in algorithmIdentifier), and RDN attributes.  Only
> certificate extensions are encapsulated in an OCTET STRING hole.
> If one wants a robust certificate decoder, one must be prepared to find
> unrecognized data in the other two classes.

Yes. My understanding is that the Cert Extensions class used OCTET 
STRING only for backwards compatibility with deployed X.400 systems.

> 
> At one point my certificate decoder was not robust :-).  But I believe
> it can handle anything now without croaking.  At least it deals
> correctly with all instances of unsupported data types that have been
> thrown at it so far.

This is correct behavior for any decent ASN.1 tool. As versions of this
standard evolve, such tools are supposed to expect new types: BMPString
in 1994, UTF8String in 1998. The obvious way to handle such events is 
to simply treat them like an open type (ANY). That is the same thing as 
saying, merely step over the tag and length octets and leave the thing
undecoded. This is precisely how SET MsgExtensions, a derivative of
X.509 Extensions work. The sequence is decoded, and an OID inside and
a BOOLEAN criticality flag are fully decode. The associated type is 
not fully decoded, but carried as an open type (ANY - a struct with an
integer length and a pointer to a character string).

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
------------------------------------------------------------

From: "Charles Moore" <[email-masked]>
To: "ross" <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Critical Attributes
Date: Sat, 31 Jan 1998 07:26:53 +1000
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0082_01BD2E19.9ACD5550
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

-----Original Message-----
From: Russ Housley <[email-masked]>
To: ross <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Saturday, 31 January 1998 6:41
Subject: Re: Critical Attributes

:All:
:
:The current ASN.1 syntax of attribute is actually a bit of a problem.  If
:an attribute is encountered that is unknown, the ASN.1 decoder might die.
:To avoid this problem, X.509v3 extensions all have a type of OCTET STRING.
This just pushes the problem up one level.
This problem is common with any OID anydefined by construction.
Unknown syntax is a common issue that all implementor have to address in
many other places today.
Once done its not a problem, so I would not worry about fixing a non
existant problem.

:These extensions require a second decode pass to extract the extension
:value from the OCTET STRING.
I prefer to handle in a single pass, unknow syntax should be handled in the
first pass, the OCTET STRING
just complicates the problem for NO gain.
General solution dont mess with the syntax to fix broken parsers, fix the
broken parsers, keep it simple.

:
:Can some folks with real life implemntation experience of ANY offer
:suggestions?
:
:Russ
:
:
:>-----Original Message-----
:>From: Russ Housley <[email-masked]>
:>To: [email-masked] <[email-masked]>
:>Date: Thursday, January 29, 1998 9:53 AM
:>Subject: Critical Attributes
:>
:>
:>>All:
:>>
:>>There has benn much discussion of attribute criticality.  It is my view
:>>that there is concensus that the feature is needed.  Two mecanisms for
the
:>>addition of this feature have been offered.
:>>
:>>First alternative: include a BOOLEAN in the attribute definition that
:>>states the criticality of the the attribute.  If the attribute is marked
:>>critical and an implementation does not know how to process the
attribute,
:>>then the message must be rejected.
:>>
:>>Second alternative: include a new attribute that lists the OIDs of all
:>>critical attributes.
:>>
:>>In terms of backward compatibility with S/MIME 2, these two mechanisms
have
:>>very different implications.
:>>
:>>By defining a DEFAULT value for the BOOLEAN, all non-critical attributes
:>>will be backward compatible.  Also, we can use the S/MIME 3 version to
:>>indicate that critical attributes are present.  This use of version
should
:>>keep an S/MIME 2 implementation from having an ASN.1 decode error.  The
:>>ASN.1 would be:
:>>
:>>   Attribute ::= SEQUENCE {
:>>     attributeType   OBJECT IDENTIFIER,
:>>     critical        BOOLEAN DEFAULT FALSE,
:>>     attributeValues SET OF AttributeValue }
:>>
:>>   AttributeValue ::= ANY
:>>
:>>On the other hand, the critical attribute list makes no change to the
:>>syntax.  However, an S/MIME 2 implementation would simply ignore this
:>>attribute as it would any other unsupported attribute.  So, the
criticality
:>>of the attributes would not really be imposed.
:>>
:>>This breifi analysis leads to to the coluclusion that the critical
boolean
:>>is a better path.  Is there concensus on this point?
:>>
:>>Russ
:>

------=_NextPart_000_0082_01BD2E19.9ACD5550
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0082_01BD2E19.9ACD5550--

Date: Fri, 30 Jan 1998 15:26:17 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: MSP and ACP 120 Documents
Cc: [email-masked], [email-masked]
Sender: [email-masked]

All:

The MSP and ACP 120 documents are available from the SPYRUS web site for
download.  They are Microsoft Word97 documents.

	MSP:		http://www.spyrus.com/support/s701-4a.doc
	ACP 120:	http://www.spyrus.com/support/acp120.doc

Enjoy,
  Russ

Date: Fri, 30 Jan 1998 15:26:21 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Critical Attributes
Sender: [email-masked]

> From: Russ Housley <[email-masked]>
> 
> All:
> 
> The current ASN.1 syntax of attribute is actually a bit of a problem.  If
> an attribute is encountered that is unknown, the ASN.1 decoder might die.
> To avoid this problem, X.509v3 extensions all have a type of OCTET STRING.
> These extensions require a second decode pass to extract the extension
> value from the OCTET STRING.
> 
> Can some folks with real life implemntation experience of ANY offer
> suggestions?
> 
> Russ

This might be a problem for some implementations, but it doesn't have
to be.

X.509 has three extensible object classes: certificate extensions,
algorithms (as used in algorithmIdentifier), and RDN attributes.  Only
certificate extensions are encapsulated in an OCTET STRING hole.
If one wants a robust certificate decoder, one must be prepared to find
unrecognized data in the other two classes.

At one point my certificate decoder was not robust :-).  But I believe
it can handle anything now without croaking.  At least it deals
correctly with all instances of unsupported data types that have been
thrown at it so far.

Date: Fri, 30 Jan 1998 14:54:46 -0500
To: ross <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Critical Attributes
Cc: [email-masked]
Sender: [email-masked]

All:

The current ASN.1 syntax of attribute is actually a bit of a problem.  If
an attribute is encountered that is unknown, the ASN.1 decoder might die.
To avoid this problem, X.509v3 extensions all have a type of OCTET STRING.
These extensions require a second decode pass to extract the extension
value from the OCTET STRING.

Can some folks with real life implemntation experience of ANY offer
suggestions?

Russ

>-----Original Message-----
>From: Russ Housley <[email-masked]>
>To: [email-masked] <[email-masked]>
>Date: Thursday, January 29, 1998 9:53 AM
>Subject: Critical Attributes
>
>
>>All:
>>
>>There has benn much discussion of attribute criticality.  It is my view
>>that there is concensus that the feature is needed.  Two mecanisms for the
>>addition of this feature have been offered.
>>
>>First alternative: include a BOOLEAN in the attribute definition that
>>states the criticality of the the attribute.  If the attribute is marked
>>critical and an implementation does not know how to process the attribute,
>>then the message must be rejected.
>>
>>Second alternative: include a new attribute that lists the OIDs of all
>>critical attributes.
>>
>>In terms of backward compatibility with S/MIME 2, these two mechanisms have
>>very different implications.
>>
>>By defining a DEFAULT value for the BOOLEAN, all non-critical attributes
>>will be backward compatible.  Also, we can use the S/MIME 3 version to
>>indicate that critical attributes are present.  This use of version should
>>keep an S/MIME 2 implementation from having an ASN.1 decode error.  The
>>ASN.1 would be:
>>
>>   Attribute ::= SEQUENCE {
>>     attributeType   OBJECT IDENTIFIER,
>>     critical        BOOLEAN DEFAULT FALSE,
>>     attributeValues SET OF AttributeValue }
>>
>>   AttributeValue ::= ANY
>>
>>On the other hand, the critical attribute list makes no change to the
>>syntax.  However, an S/MIME 2 implementation would simply ignore this
>>attribute as it would any other unsupported attribute.  So, the criticality
>>of the attributes would not really be imposed.
>>
>>This breifi analysis leads to to the coluclusion that the critical boolean
>>is a better path.  Is there concensus on this point?
>>
>>Russ
>

Date: Fri, 30 Jan 1998 08:39:44 -0500
To: "Jim Schaad (Exchange)" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Hashing of CMS signedData objects
Cc: "Ietf-Smime (E-mail)" <[email-masked]>
Sender: [email-masked]

Jim:

I need more information.  Do these objects have their own OIDs?  If so,
there may be a straightforward way to support them. 

Russ

At 01:20 PM 1/28/98 -0800, Jim Schaad (Exchange) wrote:
>When we had the discussions in San Fransico at the RSA conference, one
>of the questions that was raised about changing the what data and how
>the data was encoded was if there was any material currently out in the
>real world which was signed in the PKCS #7 way rather than the new
>proposed CMS way.  At the time I said that I know of none.  I have since
>been informed that MIcrosoft actually does have some objects signed and
>encoded in this manner, and they have actually been released into the
>real world.
>
>This gives a problem to me because it means that I need to have atleast
>some backwards compatable language put into the CMS draft.  Thus I
>propose the following:
>
>We add an appendix to the CMS draft to explain the following items:
>1.  The difference and reasons for the change in the way that the data
>is encoded.
>2.  A general way of doing recognition of the two different ways of
>encoding and how to correctly verify each way
>3.  A statemtent that one MAY implement the compatibilty mode of
>signature verification and one SHOULD NOT implement the compatability
>mode of signature creation unless required to do so by backwards
>compatability issues.
>
>How to do both signature verifications:
>
>Look at the type of the data enclosed.  
>-  If it is octet string then strip the type and length encoding bytes,
>allowing for the possilbity that it may be indefinite lenght encoded,
>and hash the remaining data.  The data actually hashed is then returned
>as the data block of signedData object.
>-  If it is not octet string, then strip the type and length encoding
>bytes (can't be indefinite length encoded) and hash the remaining data.
>The data returned as the data block of the signedData object is the
>type, length and hashed data.
>

Date: Fri, 30 Jan 1998 08:42:20 -0500
To: "Blake Ramsdell" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Hashing of CMS signedData objects
Cc: [email-masked]
Sender: [email-masked]

Blake:

No.  It will be a concern when the content encapsulated in a signed data
does not use the data content type.  In this case, the PKCS#7v1.5 language
says that the encapsulated content should be DER encoded.

Russ

At 08:34 PM 1/28/98 -0800, Blake Ramsdell wrote:
>On Wednesday, January 28, 1998 1:21 PM, Jim Schaad (Exchange)
>[SMTP:[email-masked]] wrote:
>> When we had the discussions in San Fransico at the RSA conference, one
>> of the questions that was raised about changing the what data and how
>> the data was encoded was if there was any material currently out in the
>> real world which was signed in the PKCS #7 way rather than the new
>> proposed CMS way.  At the time I said that I know of none.  I have since
>> been informed that MIcrosoft actually does have some objects signed and
>> encoded in this manner, and they have actually been released into the
>> real world.
>
>Isn't this only a concern if the PKCS #7 SignedData use in question is
>being used in an S/MIME context?
>
>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, 30 Jan 1998 14:04:52 -0500
To: [email-masked], [email-masked]
From: Elliott N Ginsburg <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-cert-01.txt
Cc: [email-masked]
Sender: [email-masked]

We've had well over a month of discussions about the requirement for email
address in end-entity certs, and the requirement for the MUA to check the
>From field against the email addresses in the cert. Yet this latest draft
is virtually the same as the previous draft on these issues.

I thought that it had been settled that neither of these requirements would
remain. Wasn't that the concensus from the meeting in San Francisco?

Can somebody help me here? Did I hallucinate all this?

elliott ginsburg

At 09:40 AM 1/30/98 -0500, [email-masked] wrote:
>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-01.txt
>	Pages		: 17
>	Date		: 29-Jan-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.
> 
>This specification is compatible with the Cryptographic Message Syntax
>[CMS] in that it uses the data types defined by CMS. It also inherits
>all the varieties of architectures for certificate-based key
>management supported by CMS. Note that the method S/MIME messages make
>certificate requests is defined in [SMIME-MSG].
> 
>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].
> - ''PKCS #10: Certification Request Syntax'', [PKCS-10].
>
>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-01.txt".
>A URL for the Internet-Draft is:
>ftp://ds.internic.net/internet-drafts/draft-ietf-smime-cert-01.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-01.txt".
>	
>NOTE:	The mail server at ds.internic.net 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.
>
><ftp://ds.internic.net/internet-drafts/draft-ietf-smime-cert-01.txt>
>

Elliott N Ginsburg

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-msg-01.txt
Date: Fri, 30 Jan 1998 09:40:54 -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-01.txt
	Pages		: 26
	Date		: 29-Jan-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).
 
S/MIME can be used by traditional mail user agents (MUAs) to add
cryptographic security services to mail that is sent, and to interpret
cryptographic security services in mail that is received. However,
S/MIME is not restricted to mail; it can be used with any transport
mechanism that transports MIME data, such as HTTP. As such, S/MIME
takes advantage of the object-based features of MIME and allows secure
messages to be exchanged in mixed-transport systems.
 
Further, S/MIME can be used in automated message transfer agents that
use cryptographic security services that do not require any human
intervention, such as the signing of software-generated documents and
the encryption of FAX messages sent over the Internet.

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-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-smime-msg-01.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-01.txt".
	
NOTE:	The mail server at ds.internic.net 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-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-msg-01.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cert-01.txt
Date: Fri, 30 Jan 1998 09:40:58 -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-01.txt
	Pages		: 17
	Date		: 29-Jan-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.
 
This specification is compatible with the Cryptographic Message Syntax
[CMS] in that it uses the data types defined by CMS. It also inherits
all the varieties of architectures for certificate-based key
management supported by CMS. Note that the method S/MIME messages make
certificate requests is defined in [SMIME-MSG].
 
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].
 - ''PKCS #10: Certification Request Syntax'', [PKCS-10].

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-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-smime-cert-01.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-01.txt".
	
NOTE:	The mail server at ds.internic.net 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-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-cert-01.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Fri, 30 Jan 1998 08:57:30 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: Blake Ramsdell <[email-masked]>
CC: "'Paul Hoffman / IMC'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: (2) Re: New versions of the -msg and -cert documents
Sender: [email-masked]

Blake Ramsdell wrote:
> 
snip
> 
> If you have specific changes that surround things other than
> capitalization of OIDs (the ChallengePassword CHOICE is a good one) then
snip

X.208 does not require identifiers for the two choice alternatives
provided in the following definition, neither does it prohibit 
their use. 

   -- 5.2.1 Challenge Password

   ChallengePassword ::= CHOICE {
     PrintableString, T61String }

So this could be rewritten as something like...

   ChallengePassword ::= CHOICE {
      printableString  PrintableString, 
      t61String        T61String 
   }

and a little bit of ambiguity would be eliminated from the 
definition. This would only be of use to implementors that 
wished to use automatic tools and the ASN.1 value notation 
to generate challenge password values, perhaps to use in 
their application or for test purposes. 

Some tools support the automatic generation of encodings 
of such values described using the value notation. Not of
any use at all for hand coders, or folks that still use 
1980s-based tools. And in this particular case, where the
types are quite simple, being able to generate encodings
using value notation has little advantage, since it is 
fairly easy to do by hand.

But when such types are embedded in more complex structures
the advantages of using the value notation can be quite 
dramatic. For example, to generate an encoding of a complex 
message like an unsigned certificate body, I need only write 
something like...

myCert UnsignedCertificate ::= {
   version 2,
   serialNumber 1,
   signature { 
      algorithm   { 2 23 42 9 11 4 1 10 },     -- ECDSA 131 -- 
      parameters  NULL 
   },
   issuer rdnSequence : {
      {{ type  { joint-iso-itu-t(2) ds(5) 4 3 },     -- commonName --   
         value printableString : "Phil Griffin" }},
      {{ type  { joint-iso-itu-t(2) ds(5) 4 6 },    -- countryName --
         value printableString : "US" }},
      {{ type  { joint-iso-itu-t(2) ds(5) 4 10 },      -- org.Name --
         value bmpString : "Self Certification Authority" }},
      {{ type  { joint-iso-itu-t(2) ds(5) 4 11 },  -- org.UnitName --
         value printableString : "Root Certificate" }}
   },
   validity { notBefore utcTime : "970808070000Z", 
              notAfter  utcTime : "990807070000Z" 
   },
   subject rdnSequence : {
      {{ type  { joint-iso-itu-t(2) ds(5) 4 3 },     -- commonName
--     
         value printableString : "Phil Griffin" }},
      {{ type  { joint-iso-itu-t(2) ds(5) 4 6 },    -- countryName --
         value printableString : "CA" }},
      {{ type  { joint-iso-itu-t(2) ds(5) 4 10 },      -- org.Name --
         value bmpString : "Self Certification Authority" }},
      {{ type  { joint-iso-itu-t(2) ds(5) 4 11 },  -- org.UnitName --
         value printableString : "Root Certificate" }}
   },
   subjectPublicKeyInfo {
      algorithm { 
         algorithm   { 2 23 42 9 11 4 1 10 },  -- ECDSA 131 --
         parameters  NULL 
      },
      subjectPublicKey '30480241 ...and so on... C58D4FB0011A761C'H
   },
   extensions {
      { extnId { 2 5 29 5 }, -- privateKeyUsagePeriod (pkup) --
        extnValue
'3022800F31393937313133303037303030305A810F31393938313133303037303030305A'H 
      },
      { extnId { 2 5 29 19 }, -- basicConstraints (isCA) --
        critical  TRUE,
        extnValue '30030101FF'H 
      },                                    
      { extnId { 2 5 29 15 }, -- keyUsage --
        critical  TRUE,
        extnValue '03020182'H -- digitalSignature , cRLSign --
      },                                    
      { extnId { 2 5 29 17 }, -- subjectAltName --
        extnValue
'301882165375626A65637420416C7465726E617465204E616D65'H
      },-- Encoded GeneralNames, dNSName, "Subject Alternate Name" --
      { extnId { 2 5 29 18 }, -- issuerAltName --
        extnValue '3017821549737375657220416C7465726E617465204E616D65'H
      } -- Encoded GeneralNames, dNSName, "Issuer Alternate Name" --
   }
}

and throw it in a tool, which will generate a C++ program to test
the notation by encoding and decoding the message, and displaying
the encoded results. And as shown above, the value notaion is not
bad for demonstrating the structure of complex messages. 

But back to ChallengePassword. I believe that better choices can
be made for the alternatives presented here. PrintableString is
not such a good choice for users, since it does not allow them to
select characters from the full ASCII set that they see on their
keyboards. Since users are likely to attempt to select characters
that are not supported by this type, and since hand coders would
seem not so likely to implement ASN.1 permitted alphabet constraints, 
I would argue that type VisibleString, which contains all of the
ASCII set minus the control characters, to be a better choice. I
believe that using VisibleString here might improve the chances of
applications, at least in the US, successfully interoperating.

Type T61String is from way back, the 80s I believe, and is another
name for type TeletexString, a restricted character string type. It
is/was popular in Europe, and I suppose has use for anyone that still
uses such a device. Its characters come from ISO/IEC 10646-1, but
contains the DELETE character among other goodies, may cause some
implementors problems, and does not provide a very usefull level of
national language support.

The ASN.1:1994 type BMPString is also based on ISO/IEC 10646-1, but
is mapped to the same characters described as Unicode. It supports
most if not all of the worlds written languages. A new type defined
in ASN.1:1998, UTF8String, provides all of the capabilities of type
BMPString and more. Unlike BMPString, which contains only double-
byte characters, UTF8String contains variable-width characters, and
I believe is favored by IESG. The first 'n' characters of the 
UTF8String are the same as VisibleString, the visible ASCII set,
and are encoded more efficiently than BMPString, as single octets.

UTF8String would be a best choice for national language support,
and if you don't mind violating the ASN.1 standards by mixing 
versions of ASN.1 together (kludges) that will break some folks
tools, I would prefer seeing UTF8String used over BMPString. Type
UTFString has its own distinct UNIVERSAL tag, so no further tagging
is required on the choice alternatives in the following

   ChallengePassword ::= CHOICE {
      printableString  PrintableString, 
      t61String        T61String,
      visibleString    VisibleString,
      utf8String       UTF8String
   }

which might be desirable for backwards compatibility with previous
versions of ChallengePassword.

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
------------------------------------------------------------

Date: Fri, 30 Jan 1998 06:43:21 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: Blake Ramsdell <[email-masked]>
CC: "'Paul Hoffman / IMC'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: (1) Re: New versions of the -msg and -cert documents
Sender: [email-masked]

Blake Ramsdell wrote:
> 
> On Thursday, January 29, 1998 4:42 PM, Phillip H. Griffin
> [SMTP:[email-masked]] wrote:
> > Perhaps the wrong version of S/MIME Version 3 Certificate
> > Handling was placed on the site. The one that I fetched had
> > a date of November 20, 1997, and contained several errors in
> > the ASN.1 definitions, as well as valid imperfections of some
> > note.
> 
> As far as ASN.1 syntax, I have a "work needed" in the message draft
> about needing to fix things (we still refer to CCITT, I believe).  This
> disclaimer needs to be extended to the cert draft also, apparently.
> 
> If you have specific changes that surround things other than
> capitalization of OIDs (the ChallengePassword CHOICE is a good one) then
> we need to address these specifically, consistent with the ASN.1 goals
> that Russ has set -- 1984 syntax plus a couple of kludges to define
> universal tags, if I understand it right.  Of course, I could have the
> wrong year.
> 
> The X.501 OIDs I can research and use the exact syntax from X.501, since
> I have paid my money and I am now privy to the wealth of knowledge that
> it contains.  Or something.
> 

You'll find that these are defined in X.520. The names that you used
are actually the names used in X.520 as attribute information objects,
which have the function in ASN.1:1994 of tightly binding an OBJECT
IDENTIFIER to some type, in a way that can be enforced by modern,
automated tools. No such mechanism is provided in X.208, which must
rely on ordinary text and the good behavior of implementors.

The convention in X.520, is to prefix OBJECT IDENTIFIER values with
the letters "id-", so the following names are provided:

Note that "id-at" is merely an alias for "joint-iso-ccitt(2) ds(5)
attributeType(4)" below.

-- Attributes --

id-at-countryName             OBJECT IDENTIFIER ::= {id-at  6}
id-at-stateOrProvinceName     OBJECT IDENTIFIER ::= {id-at  8}
id-at-commonName              OBJECT IDENTIFIER ::= {id-at  3}
id-at-title                   OBJECT IDENTIFIER ::= {id-at 12}
id-at-organizationName        OBJECT IDENTIFIER ::= {id-at 10}
id-at-organizationalUnitName  OBJECT IDENTIFIER ::= {id-at 11}
id-at-streetAddress           OBJECT IDENTIFIER ::= {id-at  9}
id-at-postalCode              OBJECT IDENTIFIER ::= {id-at 17}
id-at-telephoneNumber         OBJECT IDENTIFIER ::= {id-at 20}

> 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

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
------------------------------------------------------------

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Paul Hoffman / IMC'" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: RE: New versions of the -msg and -cert documents
Date: Thu, 29 Jan 1998 17:30:12 -0800
Sender: [email-masked]

On Thursday, January 29, 1998 4:42 PM, Phillip H. Griffin
[SMTP:[email-masked]] wrote:
> Perhaps the wrong version of S/MIME Version 3 Certificate 
> Handling was placed on the site. The one that I fetched had 
> a date of November 20, 1997, and contained several errors in 
> the ASN.1 definitions, as well as valid imperfections of some
> note.

As far as ASN.1 syntax, I have a "work needed" in the message draft
about needing to fix things (we still refer to CCITT, I believe).  This
disclaimer needs to be extended to the cert draft also, apparently.

If you have specific changes that surround things other than
capitalization of OIDs (the ChallengePassword CHOICE is a good one) then
we need to address these specifically, consistent with the ASN.1 goals
that Russ has set -- 1984 syntax plus a couple of kludges to define
universal tags, if I understand it right.  Of course, I could have the
wrong year.

The X.501 OIDs I can research and use the exact syntax from X.501, since
I have paid my money and I am now privy to the wealth of knowledge that
it contains.  Or something.

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, 29 Jan 1998 16:51:59 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: New versions of the -msg and -cert documents
Sender: [email-masked]

At 07:42 PM 1/29/98 -0500, Phillip H. Griffin wrote:
>Perhaps the wrong version of S/MIME Version 3 Certificate 
>Handling was placed on the site.

Flush your Web cache and try again. Both drafts are -01 and dated yesterday.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 29 Jan 1998 19:42:28 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: Paul Hoffman / IMC <[email-masked]>
CC: [email-masked]
Subject: Re: New versions of the -msg and -cert documents
Sender: [email-masked]

Paul Hoffman / IMC wrote:
> 
> New versions of the -msg and-cert documents are now available.
> 
> S/MIME Version 3 Message Specification:
> <http://www.imc.org/draft-ietf-smime-msg>
> S/MIME Version 3 Certificate Handling:
> <http://www.imc.org/draft-ietf-smime-cert>
> 
> As always, you can see links to the most recent documents at
> <http://www.imc.org/ietf-smime/>.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium

Paul,

Perhaps the wrong version of S/MIME Version 3 Certificate 
Handling was placed on the site. The one that I fetched had 
a date of November 20, 1997, and contained several errors in 
the ASN.1 definitions, as well as valid imperfections of some
note.

   5.2.1 Challenge Password

   ChallengePassword ::= CHOICE {
     PrintableString, T61String }

While this is valid under X.208, the lack of an identifier
on component type PrintableString causes ambiguity for those
who may wish to use the value notation to create test data.
Consider...

  testString ChallengePassword ::= "Which string type is it?"

demonstrates a problem corrected in the 1994 standard by
requiring that identifiers be used to name choice alternatives.
A better definition might be

   ChallengePassword ::= CHOICE {
     p PrintableString, t T61String }

The second definition has never been correct, since when it
was origionally written, type UniversalString did not yet 
exist. The authors apparently guessed that the naming convention
for OCTET STRING and BIT STRING would be followed. So,

   ChallengePassword ::= CHOICE {
       PrintableString, T61String, UNIVERSAL STRING }

is not valid ASN.1 for any version of that standard. For
section 5.2.2 Unstructured Address, the same is true.

   A.5 Name Attributes

   emailAddress OBJECT IDENTIFIER ::=
     {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1}

   CountryName OBJECT IDENTIFIER ::=
       {joint-iso-ccitt(2) ds(5) attributeType(4) 6}

   StateOrProvinceName OBJECT IDENTIFIER ::=
       {joint-iso-ccitt(2) ds(5) attributeType(4) 8}

   CommonName OBJECT IDENTIFIER ::=
     {joint-iso-ccitt(2) ds(5) attributeType(4) 3}

   Title OBJECT IDENTIFIER ::=
     {joint-iso-ccitt(2) ds(5) attributeType(4) 12}

   Organization OBJECT IDENTIFIER ::=
     {joint-iso-ccitt(2) ds(5) attributeType(4) 10}

   OrganizationalUnit OBJECT IDENTIFIER ::=
     {joint-iso-ccitt(2) ds(5) attributeType(4) 11}

   StreetAddress OBJECT IDENTIFIER ::=
     {joint-iso-ccitt(2) ds(5) attributeType(4) 9}

   Postal Code OBJECT IDENTIFIER ::=
     {joint-iso-ccitt(2) ds(5) attributeType(4) 17}

   Phone Number OBJECT IDENTIFIER ::=
     {joint-iso-ccitt(2) ds(5) attributeType(4) 20}

The identifiers US, CountryName, and StateOrProvinceName 
CommonName, Title, Organization, OrganizationalUnit, 
StreetAddress, "Postal Code", "Phone Number" are not 
valid ASN.1 identifiers.

   A.7 X.509 V3 Certificate Extensions

   basicConstraints basicConstraints EXTENSION ::= {
       SYNTAX  BasicConstraintsSyntax
       IDENTIFIED BY { id-ce 19 } }

   keyUsage EXTENSION ::= {
       SYNTAX  KeyUsage
       IDENTIFIED BY { id-ce 15 }}

The use of the EXTENSION class definition, and the WITH
SYNTAX notation to define an ASN.1:1994 extension object 
is not valid for X.208.

Note that S/MIME Version 3 Message Specification, also dated
11/20/97, also has several ASN.1 errors. I had thought that both
of these documents had been corrected.

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
------------------------------------------------------------

From: "Blake Ramsdell" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, "'Mark Vandenwauver'" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: RE: Question about signing attachments separately
Date: Thu, 29 Jan 1998 16:20:43 -0800
Sender: [email-masked]

On Thursday, January 29, 1998 9:10 AM, Russ Housley
[SMTP:[email-masked]] wrote:
> I have a preference for signing the whole message.  The cover note can
> greatly change the meaning or actions expected.

I agree with this also -- Andrew pointed out a good Ned message from a
past thread dealing with this issue and the possible problems.  We can
discuss anything that wasn't covered back then, or revisit those
arguments in light of new information, but I think we covered it pretty
well.

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, 29 Jan 1998 15:34:29 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: New versions of the -msg and -cert documents
Sender: [email-masked]

New versions of the -msg and-cert documents are now available.

S/MIME Version 3 Message Specification:
<http://www.imc.org/draft-ietf-smime-msg>
S/MIME Version 3 Certificate Handling:
<http://www.imc.org/draft-ietf-smime-cert>

As always, you can see links to the most recent documents at
<http://www.imc.org/ietf-smime/>.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 29 Jan 1998 14:01:35 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Critical Attributes
Sender: [email-masked]

> From: Russ Housley <[email-masked]>
> 
> By defining a DEFAULT value for the BOOLEAN, all non-critical attributes
> will be backward compatible.  Also, we can use the S/MIME 3 version to
> indicate that critical attributes are present.  This use of version should
> keep an S/MIME 2 implementation from having an ASN.1 decode error.  The
> ASN.1 would be:
> 
>    Attribute ::= SEQUENCE {
>      attributeType   OBJECT IDENTIFIER,
>      critical        BOOLEAN DEFAULT FALSE,
>      attributeValues SET OF AttributeValue }
> 
>    AttributeValue ::= ANY
> 
> On the other hand, the critical attribute list makes no change to the
> syntax.  However, an S/MIME 2 implementation would simply ignore this
> attribute as it would any other unsupported attribute.  So, the criticality
> of the attributes would not really be imposed.
> 
> This breifi analysis leads to to the coluclusion that the critical boolean
> is a better path.  Is there concensus on this point?
> 
> Russ

What is the behavior of an S/MIME v2 implementation on receiving a
message with version=3 ?

If this behavior (I assume it is to refuse to decode or display the
message at all) is an acceptable outcome for a message containing
a critical authenticated attribute, then I agree that the boolean
flag is better. 

But if the goal is to maximize backward compatibility of v3-generated
messages to v2 implementations, acknowledging that S/MIME v2
implementations have *no* support for criticality processing, then
the OID list approach is better.

I guess it is up to those who have some application for critical
attributes in mind to decide whether the preferred v2 UA behavior is to
reject the message or to process/display it (perhaps with an indication
that an unrecognized attribute was attached).

From: ross <[email-masked]>
To: [email-masked], Russ Housley <[email-masked]>
MMDF-Warning:  Parse error in original version of preceding line at post.mail.demon.net
Subject: Re: Critical Attributes
Date: Thu, 29 Jan 1998 18:18:11 -0800
Sender: [email-masked]

I agree with Russ, the critical Boolean is a better path. It is backward
compatible and offers the capability to flag criticality per occurrence of
each attribute.   This may be important when an attribute occurs more than
once, an attribute may have critical implications on one occurrence but not
on the other.

JR
-----Original Message-----
From: Russ Housley <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Thursday, January 29, 1998 9:53 AM
Subject: Critical Attributes

>All:
>
>There has benn much discussion of attribute criticality.  It is my view
>that there is concensus that the feature is needed.  Two mecanisms for the
>addition of this feature have been offered.
>
>First alternative: include a BOOLEAN in the attribute definition that
>states the criticality of the the attribute.  If the attribute is marked
>critical and an implementation does not know how to process the attribute,
>then the message must be rejected.
>
>Second alternative: include a new attribute that lists the OIDs of all
>critical attributes.
>
>In terms of backward compatibility with S/MIME 2, these two mechanisms have
>very different implications.
>
>By defining a DEFAULT value for the BOOLEAN, all non-critical attributes
>will be backward compatible.  Also, we can use the S/MIME 3 version to
>indicate that critical attributes are present.  This use of version should
>keep an S/MIME 2 implementation from having an ASN.1 decode error.  The
>ASN.1 would be:
>
>   Attribute ::= SEQUENCE {
>     attributeType   OBJECT IDENTIFIER,
>     critical        BOOLEAN DEFAULT FALSE,
>     attributeValues SET OF AttributeValue }
>
>   AttributeValue ::= ANY
>
>On the other hand, the critical attribute list makes no change to the
>syntax.  However, an S/MIME 2 implementation would simply ignore this
>attribute as it would any other unsupported attribute.  So, the criticality
>of the attributes would not really be imposed.
>
>This breifi analysis leads to to the coluclusion that the critical boolean
>is a better path.  Is there concensus on this point?
>
>Russ

Date: Thu, 29 Jan 1998 10:18:32 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Critical Attributes
Sender: [email-masked]

At 12:51 PM 1/29/98 -0500, Russ Housley wrote:
>On the other hand, the critical attribute list makes no change to the
>syntax.=A0 However, an S/MIME 2 implementation would simply ignore this
>attribute as it would any other unsupported attribute.=A0 So, the critic=
ality
>of the attributes would not really be imposed.

In fact, it would not be imposed at all. Because someone writing a messag=
e
with
a critical attribute cannot know the version of S/MIME used by the recipi=
ent,
they don't know if the recipient will reject the message if they don't
understand the attribute. This is a terrible situation, I think. We would=
 be
creating "critical for v3 clients only" attributes.

>This breifi analysis leads to to the coluclusion that the critical boole=
an
>is a better path.=A0 Is there concensus on this point?

That sounds right to me.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 29 Jan 1998 12:51:25 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Critical Attributes
Sender: [email-masked]

All:

There has benn much discussion of attribute criticality.  It is my view
that there is concensus that the feature is needed.  Two mecanisms for the
addition of this feature have been offered.

First alternative: include a BOOLEAN in the attribute definition that
states the criticality of the the attribute.  If the attribute is marked
critical and an implementation does not know how to process the attribute,
then the message must be rejected.

Second alternative: include a new attribute that lists the OIDs of all
critical attributes.

In terms of backward compatibility with S/MIME 2, these two mechanisms have
very different implications.

By defining a DEFAULT value for the BOOLEAN, all non-critical attributes
will be backward compatible.  Also, we can use the S/MIME 3 version to
indicate that critical attributes are present.  This use of version should
keep an S/MIME 2 implementation from having an ASN.1 decode error.  The
ASN.1 would be:

   Attribute ::= SEQUENCE {
     attributeType   OBJECT IDENTIFIER,
     critical        BOOLEAN DEFAULT FALSE,
     attributeValues SET OF AttributeValue }

   AttributeValue ::= ANY

On the other hand, the critical attribute list makes no change to the
syntax.  However, an S/MIME 2 implementation would simply ignore this
attribute as it would any other unsupported attribute.  So, the criticality
of the attributes would not really be imposed.

This breifi analysis leads to to the coluclusion that the critical boolean
is a better path.  Is there concensus on this point?

Russ

Date: Thu, 29 Jan 1998 12:10:24 -0500
To: Mark Vandenwauver <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Question about signing attachments separately
Cc: [email-masked]
Sender: [email-masked]

I have a preference for signing the whole message.  The cover note can
greatly change the meaning or actions expected.

Russ

At 11:22 AM 1/28/98 +0100, Mark Vandenwauver wrote:
>Hi all,
>
>We are in the process of implementing S/MIME and me and my colleagues are
>having a debate whether we will allow the software to sign and/or encrypt
>attachments separately vs. signing/encrypting the whole mail message. Do
>the S/MIME experts have any input on this matter ? What do you see as the
>biggest advantages to each approach ?
>
>Thanks in advance,
>
>Mark
>
>-----------------------------------------------------------------------
>
>Mark Vandenwauver 	email : [email-masked]
>Assistant 		www   : http://www.esat.kuleuven.ac.be/~vdwauver
>K.U.Leuven ESAT-COSIC	phone : 32-16-321134
>Kard. Mercierlaan 94	        32-16-321050 (Secr.)
>3001 Heverlee 		fax   : 32-16-321986
>BELGIUM
>

Date: Thu, 29 Jan 1998 09:36:30 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: 41st IETF-LOS ANGELES: SMIME Meeting Time
Sender: [email-masked]

All:

We have a time slot for the S/MIME working group in LA.  We get to go
first.  Our working group will meet on Monday, March 30 at 0930-1130
(opposite udlr, adsl).

Please send me a message if you want time on the agenda.

Russ

Date: Wed, 28 Jan 1998 10:35:11 -0500
To: "Bonatti, Chris" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Content Type Attribute Question
Cc: [email-masked]
Sender: [email-masked]

Chris:

Please look at the Content Hints attribue defined in ESS.  Would it be
useful to add the EncapsulatedContentType structure to this attribute? 
Would this meet your requirements?

Russ

At 09:37 PM 1/14/98 -0500, Bonatti, Chris wrote: 

>>>>

<excerpt>    I'd like to pose the question of why (besides backward
compatibility, which I understand) the ContentType attribute is limited
to only an object identifier?  Object IDs certainly work for S/MIME
content types carrying other S/MIME content types, but there are a bunch
of other likely types of content that aren't identified in that manner. 
X.400, for example, relies on integer encoding for backward
compatibility.  MIME itself uses an ASCII string identifier for the
content, and we don't support this either.  While I think that object IDs
are probably the BEST way to identify the content type, it is unrealistic
to expect the whole world to change its ways.  Even our own S/MIME ESS
document has a more flexible definition of content type. 

    I would like to propose that we define a new attribute to accommodate
more flexible content typing.  The definition I would propose as a
starting point for this new attribute is as follows: 

    ContentTypeExtended ::= CHOICE { 

        built-in               BuiltInContentType, 

        external               ExternalContentType, 

        externalWithSubtype    ExternalContentWithSubtype, 

        other                  OtherContentType } 

    BuiltinContentType ::= [APPLICATION 6] INTEGER { 

        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 ::= 32767 

    ExternalContentType ::= OBJECT IDENTIFIER 

    ExternalContentWithSubtype ::= SEQUENCE { 

        external       ExternalContentType, 

        subtype        INTEGER } 

    OtherContentType :: = SEQUENCE { 

        type    [0] OBJECT IDENTIFIER, 

        value   [1] OCTET STRING } 

    other-content-type-ia5-mime-subtype OBJECT IDENTIFIER ::= { TBD } 

        -- When used in the "type" field of the OtherContentType, 

        -- this value indicates the presence of MIME content type 

        -- indications within the octet string.  When this value 

        -- is used the content of the octet string must be a string 

        -- of ASCII characters. 

This syntax is the same as that in ESS, except that I have added an
additional choice that allows any value to be carried.  My intention here
is that we could effectively convey an ASN.1 constrained ANY, but
restricting the encoding to an octet string for ease of implementation. 
This additional field could be used to convey MIME types.  However,
structured the way it is, it leaves could easily support alternate
character sets or other creative uses in the future. 

    I think that such a new attribute would add a lot of flexibility to
S/MIME.  The proposed attribute does nothing to break backward
compatibility, because the old definition will still be valid and
protected messages could actually carry both attributes through some
transition period. 

    I look forward to hearing your opinions on this. 

  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  | 

 |  PGP public key available from
"<<http://www.ieca.com/>http://www.ieca.com/"       | 

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

</excerpt><<<<<<<<

Organization: ESAT, K.U.Leuven, Belgium
Date: Thu, 29 Jan 1998 13:20:10 +0100 (MET)
From: Mark Vandenwauver <[email-masked]>
To: Andrew Farrell <[email-masked]>
cc: [email-masked], Jonathan Penn <[email-masked]>
Subject: Re: Question about signing attachments separately 
Sender: [email-masked]

> The problem with signatures is far worse. The standard example is the
> three part message with a first that says, "The first attachment is the
> version of the contract to use, the second is the crappy one that should
> never have seen the light of day." The parts can be swapped without
> detection if they are signed separately. Enough said.
>

This is however the case we would like to support. I send the contract to
party B with my signature on the attachment. B then signs the attachment
and forwards it to C. C can check that I and B have signed the contract 
and can deposit it. This multi-signature contract question looks like an
advocate for the system and not the opposite.

Mark

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

                           '''
                          (o o)
             .------oOOO---(_)-----------.
             |                           |
             |                           |
             | This is me in real size   |
             |                           |
             `-------------------oOOO----'
                         |__|__|
                          || ||
                         ooO Ooo

Mark Vandenwauver 	email : [email-masked]
Assistant 		www   : http://www.esat.kuleuven.ac.be/~vdwauver
K.U.Leuven ESAT-COSIC	phone : 32-16-321134
Kard. Mercierlaan 94	        32-16-321050 (Secr.)
3001 Heverlee 		fax   : 32-16-321986
BELGIUM

To: [email-masked]
Cc: Jonathan Penn <[email-masked]>
Subject: Re: Question about signing attachments separately 
Date: Thu, 29 Jan 1998 10:53:54 +0000
From: Andrew Farrell <[email-masked]>
Sender: [email-masked]

In message <v04003a0bb0f55a766a11@[38.168.136.14]>you write:

>i would like some clarification on this as well, including, but not
>limited to, whether this is relevant to the following circumstance:
>person A receives a message & attachment signed by person B (perhaps
>from a previous email) and forwards this along to person C. of course,
>person A wants to put his own signature on the entire email, so person C
>is sure where the forwarding message came from.

>in general, how does a user forward a message such that the recipient
>can prove that (a) the original message came from the purported original
>sender, and (b) that this forwarded message and any additional
>text/attachments are from the purported forwarder/intermediary.

There's a mime-type called message/rfc822 for embedding messages in
other messages. This is available in Exchange through the
Insert->Message option, and presumably in Messenger by some means that I
can't immediately find, and it is for this purpose. If you attach a
signed message your own and secure your message, then whatever
processing activates when the recipient opened your message should
activate when they open the attachment. The obvious issues about
forwarding encrypted mail apply.

As regards securing individual attachments, I'd have reservations about
expecting users to correctly interpret a message with differently
secured sections. They have enough trouble understanding that a message
encrypted to them hasn't neccesarily come from the claimed sender.
Getting them to deal with a message whose component parts, though
secured, may have an insecure relation to each other seems more trouble
than it's worth. Certainly, no-one's ever asked us for this.

After a bit of searching, I found some email on this, from Ned Freed, on
4th February 1996:

----

> In a subsequest offline discussion, it was suggested that we promote
>the model where each body part in a multipart message is encrypted
>separately thereby creating a separate S/MIME body part for each
>original body part. Although this increases the overhead in the
>replication of the key management information, it has the advantage in
>remote access situations (eg. IMAP) that each resulting S/MIME body part
>is self-contained and can  be downloaded and processed independently.

Sigh. How many times do we have to go over this?

This is pretty marginal in the case of encryption and absolutely
unacceptable in the case of signatures. The problem in the encryption
case is that internal message headers and structure are exposed. This
can be a very significant exposure in some situations.

The problem with signatures is far worse. The standard example is the
three part message with a first that says, "The first attachment is the
version of the contract to use, the second is the crappy one that should
never have seen the light of day." The parts can be swapped without
detection if they are signed separately. Enough said.

                                Ned
----

Andrew.

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Blake Ramsdell'" <[email-masked]>, "'Ietf-Smime (E-mail)'" <[email-masked]>
Subject: RE: Hashing of CMS signedData objects
Date: Wed, 28 Jan 1998 20:38:52 -0800
Sender: [email-masked]

Yes that is true, however what we have is a set of common code in our
CryptoAPI.  The code to decode a signed data object is one of these
common code functions.  Thus we use the same code for both S/MIME
messages and other structures which are wrapped up in signedData code.
It does not make any sense internally for us to try and force users to
decide if they are using PKCS #7 signedData or CMS signedData objects.
This is even more true as we go forward and CMS gets adopted by even
more of the IETF standards.  (We can hope.)

jim

-----Original Message-----
From: Blake Ramsdell [mailto:[email-masked]]
Sent: Wednesday, January 28, 1998 8:35 PM
To: Jim Schaad (Exchange); 'Ietf-Smime (E-mail)'
Subject: RE: Hashing of CMS signedData objects

On Wednesday, January 28, 1998 1:21 PM, Jim Schaad (Exchange)
[SMTP:[email-masked]] wrote:
> When we had the discussions in San Fransico at the RSA conference, one
> of the questions that was raised about changing the what data and how
> the data was encoded was if there was any material currently out in
the
> real world which was signed in the PKCS #7 way rather than the new
> proposed CMS way.  At the time I said that I know of none.  I have
since
> been informed that MIcrosoft actually does have some objects signed
and
> encoded in this manner, and they have actually been released into the
> real world.

Isn't this only a concern if the PKCS #7 SignedData use in question is
being used in an S/MIME context?

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

From: "Blake Ramsdell" <[email-masked]>
To: "'Jim Schaad (Exchange)'" <[email-masked]>, "'Ietf-Smime (E-mail)'" <[email-masked]>
Subject: RE: Hashing of CMS signedData objects
Date: Wed, 28 Jan 1998 20:34:42 -0800
Sender: [email-masked]

On Wednesday, January 28, 1998 1:21 PM, Jim Schaad (Exchange)
[SMTP:[email-masked]] wrote:
> When we had the discussions in San Fransico at the RSA conference, one
> of the questions that was raised about changing the what data and how
> the data was encoded was if there was any material currently out in the
> real world which was signed in the PKCS #7 way rather than the new
> proposed CMS way.  At the time I said that I know of none.  I have since
> been informed that MIcrosoft actually does have some objects signed and
> encoded in this manner, and they have actually been released into the
> real world.

Isn't this only a concern if the PKCS #7 SignedData use in question is
being used in an S/MIME context?

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, 28 Jan 1998 14:15:25 -0800
To: [email-masked]
From: Jonathan Penn <[email-masked]>
Subject: RE: Question about signing attachments separately
Sender: [email-masked]

the question asked was "what are the advantages/disadvantages of each approach?"  the answer that came back only sheds light on what the majority of vendors implement (or, more precisely, don't implement).

i would like some clarification on this as well, including, but not limited to, whether this is relevant to the following circumstance:
person A receives a message & attachment signed by person B (perhaps from a previous email) and forwards this along to person C. of course, person A wants to put his own signature on the entire email, so person C is sure where the forwarding message came from.

in general, how does a user forward a message such that the recipient can prove that (a) the original message came from the purported original sender, and (b) that this forwarded message and any additional text/attachments are from the purported forwarder/intermediary.

From: Karen Rosenthal <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RE: Question about signing attachments separately
Date: Wed, 28 Jan 1998 14:02:08 -0800
Organization: Premenos, a Harbinger Corporation
Sender: [email-masked]

It may also be worth noting, that prior to V3's inclusion of receipts, that 
some existing receipt implementations (i.e. based on Message Disposition 
Notification, and EDIINTs implementation thereof) are message level.

Regards,
-------------------------------------------
Karen Rosenthal
Premenos, a Harbinger Corporation
1000 Burnett Ave
Concord, CA  94520

Email:	[email-masked]
Tel#:	1-510-688-2928
Fax#:	1-510-602-2133
Visit:	http://www.harbinger.com

-----Original Message-----
From:	Jim Schaad (Exchange) [SMTP:[email-masked]]
Sent:	Wednesday, January 28, 1998 12:59 PM
To:	'Paul Hoffman / IMC'; [email-masked]
Subject:	RE: Question about signing attachments separately

I don't remember if this was changed in the S/MIME V2 spec or not,
however there was a general agreement among the S/MIME developers at the
last RSA workshop that we would restrict ourselfs to the case where the
security was applyed only once and only as the top level object.

This should change with people starting to implement the V3 spec, we
should handle security at any level and to any depth in the mime stream.
However don't be suprised if some clients only handle the restricted
case.

Jim Schaad
Microsoft

-----Original Message-----
From: Paul Hoffman / IMC [mailto:[email-masked]]
Sent: Wednesday, January 28, 1998 9:52 AM
To: [email-masked]
Subject: Re: Question about signing attachments separately

Karen missed Mark's point. If you have a MIME entity such as a
multipart/mixed,
you have the option of treating that as a single entity and signing it,
or
signing each sub-entity. I believe the current S/MIME spec is silent on
this
choice, but I suspect that some implementations may not handle
signatures on
non-nested subentities very well.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: Hashing of CMS signedData objects
Date: Wed, 28 Jan 1998 13:20:37 -0800
Sender: [email-masked]

When we had the discussions in San Fransico at the RSA conference, one
of the questions that was raised about changing the what data and how
the data was encoded was if there was any material currently out in the
real world which was signed in the PKCS #7 way rather than the new
proposed CMS way.  At the time I said that I know of none.  I have since
been informed that MIcrosoft actually does have some objects signed and
encoded in this manner, and they have actually been released into the
real world.

This gives a problem to me because it means that I need to have atleast
some backwards compatable language put into the CMS draft.  Thus I
propose the following:

We add an appendix to the CMS draft to explain the following items:
1.  The difference and reasons for the change in the way that the data
is encoded.
2.  A general way of doing recognition of the two different ways of
encoding and how to correctly verify each way
3.  A statemtent that one MAY implement the compatibilty mode of
signature verification and one SHOULD NOT implement the compatability
mode of signature creation unless required to do so by backwards
compatability issues.

How to do both signature verifications:

Look at the type of the data enclosed.  
-  If it is octet string then strip the type and length encoding bytes,
allowing for the possilbity that it may be indefinite lenght encoded,
and hash the remaining data.  The data actually hashed is then returned
as the data block of signedData object.
-  If it is not octet string, then strip the type and length encoding
bytes (can't be indefinite length encoded) and hash the remaining data.
The data returned as the data block of the signedData object is the
type, length and hashed data.

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, [email-masked]
Subject: RE: Question about signing attachments separately
Date: Wed, 28 Jan 1998 12:58:30 -0800
Sender: [email-masked]

I don't remember if this was changed in the S/MIME V2 spec or not,
however there was a general agreement among the S/MIME developers at the
last RSA workshop that we would restrict ourselfs to the case where the
security was applyed only once and only as the top level object. 

This should change with people starting to implement the V3 spec, we
should handle security at any level and to any depth in the mime stream.
However don't be suprised if some clients only handle the restricted
case.

Jim Schaad
Microsoft

-----Original Message-----
From: Paul Hoffman / IMC [mailto:[email-masked]]
Sent: Wednesday, January 28, 1998 9:52 AM
To: [email-masked]
Subject: Re: Question about signing attachments separately

Karen missed Mark's point. If you have a MIME entity such as a
multipart/mixed,
you have the option of treating that as a single entity and signing it,
or
signing each sub-entity. I believe the current S/MIME spec is silent on
this
choice, but I suspect that some implementations may not handle
signatures on
non-nested subentities very well.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Wed, 28 Jan 1998 09:51:37 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Question about signing attachments separately
Sender: [email-masked]

Karen missed Mark's point. If you have a MIME entity such as a
multipart/mixed,
you have the option of treating that as a single entity and signing it, or
signing each sub-entity. I believe the current S/MIME spec is silent on this
choice, but I suspect that some implementations may not handle signatures on
non-nested subentities very well.

--Paul Hoffman, Director
--Internet Mail Consortium

From: Karen Rosenthal <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To: "'Mark Vandenwauver'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: Question about signing attachments separately
Date: Wed, 28 Jan 1998 09:11:07 -0800
Organization: Premenos, a Harbinger Corporation
Sender: [email-masked]

Mark,

Using S/MIME, if you wish to both sign and encrypt a message, you sign, 
then encrypt the message as a single PKCS#7 body part.  The application 
first signs the message, using either the PKCS#7 SignedData construct, or 
RFC1847 multipart/signed (EDIINT currently supports the latter).  You then 
take either the SignedData or multipart/signed as the data input to 
encrypt, to be placed in the PKCS#7 EnvelopedData construct.  This is 
deemed as advantageous, as the signer of the document is not exposed.

Regards,
Karen

-------------------------------------------
Karen Rosenthal
Premenos, a Harbinger Corporation
1000 Burnett Ave
Concord, CA  94520

Email:	[email-masked]
Tel#:	1-510-688-2928
Fax#:	1-510-602-2133
Visit:	http://www.harbinger.com

-----Original Message-----
From:	Mark Vandenwauver [SMTP:[email-masked]]
Sent:	Wednesday, January 28, 1998 2:23 AM
To:	[email-masked]
Subject:	Question about signing attachments separately

Hi all,

We are in the process of implementing S/MIME and me and my colleagues are
having a debate whether we will allow the software to sign and/or encrypt
attachments separately vs. signing/encrypting the whole mail message. Do
the S/MIME experts have any input on this matter ? What do you see as the
biggest advantages to each approach ?

Thanks in advance,

Mark

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

Mark Vandenwauver 	email : [email-masked]
Assistant 		www   : http://www.esat.kuleuven.ac.be/~vdwauver
K.U.Leuven ESAT-COSIC	phone : 32-16-321134
Kard. Mercierlaan 94	        32-16-321050 (Secr.)
3001 Heverlee 		fax   : 32-16-321986
BELGIUM

Organization: ESAT, K.U.Leuven, Belgium
Date: Wed, 28 Jan 1998 11:22:35 +0100 (MET)
From: Mark Vandenwauver <[email-masked]>
To: [email-masked]
Subject: Question about signing attachments separately
Sender: [email-masked]

Hi all,

We are in the process of implementing S/MIME and me and my colleagues are
having a debate whether we will allow the software to sign and/or encrypt
attachments separately vs. signing/encrypting the whole mail message. Do
the S/MIME experts have any input on this matter ? What do you see as the
biggest advantages to each approach ?

Thanks in advance,

Mark

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

Mark Vandenwauver 	email : [email-masked]
Assistant 		www   : http://www.esat.kuleuven.ac.be/~vdwauver
K.U.Leuven ESAT-COSIC	phone : 32-16-321134
Kard. Mercierlaan 94	        32-16-321050 (Secr.)
3001 Heverlee 		fax   : 32-16-321986
BELGIUM

Date: Tue, 27 Jan 1998 17:08:55 -0500
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: Re: Comments to CMS-02
Cc: [email-masked]
Sender: [email-masked]

John:

>1) Sec 3, last para: I believe that this paragraph describing "external
>signatures" should be moved to Sec 5.1, SignedData contentInfo description.
>That is the only use of ContentInfo to which the "external signatures"
>paragraph applies.

I noticed this too.  I was a carry over from the PKCS#7 document.  I will
make the change in the next document.

>2) Sec 6, bullet 3: Please delete "the originator and" from the following:
>"3. For the originator and each recipient, the encrypted content-encryption
>key and other recipient-specific information are collected into a
>RecipientInfo value, defined in Section 6.2."  The 10 Dec 97 S/MIME WG
>decided that the requirement for the inclusion of a copy of the
>content encryption key encrypted for the originator in an envelopedData
>object must not be included in the CMS I-D, but that it must be included in
>the S/MIME v3 Message Specification as a SHOULD requirement.

Agree.  I will remove the words.

>3) Sec 6.2, RecipientInfo originatorCert description:  Please add "This
>field should be included when the recipientInfo keyEncryptionAlgorithm field
>indicates a key agreement algorithm and the originator's certificate is
>omitted from the envelopedData originatorInfo field (i.e. the originator's
>public key material is required as part of the process to decrypt the
>encryptedKey, but the originator's certificate is not included in the
>envelopedData object)." 

I do not understand this one.  In the bag-of-certificates, the originator
may have more than one with the specified key management algorithm.  In
this case, the originator tells the recipient which one to use.  The
certificate itself is not carried here, rather an EntityIdentifier is carried:

  EntityIdentifier ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    subjectKeyIdentifier SubjectKeyIdentifier }

So, I do not see the change that is needed....

>4) Sec 9.7, IssuerAndSerialNumber. The PKIX X.509 Cert and CRL Profile
>allows X.509 Certs to include an empty sequence as the Issuer Name and a
>IssuerAltName extension which may (or may not) contain a Name form.  The
>current CMS IssuerAndSerialNumber does not include sufficient flexibility to
>uniquely identify X.509 certs that use non-Name IssuerAltName forms instead
>of the Issuer Name.  If the S/MIME v3 Certificate Handling spec allows empty
>Issuer Names and non-Name IssuerAltName forms, then I believe that
>IssuerAndSerialNumber should be changed as follows:
>
>IssuerAndSerialNumber ::= SEQUENCE {
>  issuer        Name,
>  serialNumber  SerialNumber
>  issuerAltName [0] IMPLICIT GeneralNames OPTIONAL}
>
>This would be backwards compatible with PKCS #7, v1.5.

I talked to Blake about this issue.  The next draft of the certs draft will
mandate the population of the issuer name.  I think this is a much simplier
solution to the issue that you raise.

>5) If comment 4 is accepted, then the signedData signerInfo version
>description should be changed to state that the version shall be 1 if the
>issuer Name is used and issuerAltName is absent.  If the issuerAltName is
>present, then the version shall be 2.  Similar changes would be needed for
>the recipientInfo version and originatorCert descriptions.

Actually, this is the reason that I prefer the mandatory issuer name
solution.  I am personally more concerned with backward compatibility of
signed messages than encrypted messages.

>6) References: Please delete the references to PKCS #6 and PKCS #9.

I disagree.  I have pulled stuff into CMS from both of these documents, so
they deserve the reference.

>7) References: Please change PKCS #7 to match that in the ESS I-D.

I included both forms of reference.

Thanks for the review,
  Russ

Date: Tue, 27 Jan 1998 14:35:57 -0500
To: "Bonatti, Chris" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Question:  DSA and S/MIME v2?  v3?
Cc: Stephen Klump <[email-masked]>, [email-masked]
Sender: [email-masked]

Chris:

No.  Use of DSA does not determine wheteher or not authenticated attributes
are used.  DSA may be used with authenticated attributes, and DSA may be
used without authenticated attributes.

As far as I know, DSA is always used with SHA-1.  The DSA requires a
160-bit message digest input.  SHA-1 is the only message digest that I know
of that generates a 160-bit value.

Russ

At 02:04 PM 1/23/98 -0500, Bonatti, Chris wrote:
>Russ,
>
>    Is the converse of this statement true?  If using DSA, does that
>essentially mean that authenticated attributes cannot be used?
>
>    I would assume that you could specify DSA as the signature algorithm, and
>specify an arbitrary hash algorithm to address the messageDigest attribute.
>
>Chris
>
>
>___________________
>
>Russ Housley wrote:
>
>> Stephen:
>>
>> >I understand that S/MIME v1 can't support DSA keys because it requires
>> >the messageDigest, which DSA does not provide.  And if authenticated
>> >attributes are present, the messageDigest attribute (among others) MUST
>> >be present.
>>
>> This is not correct.  If you look at the signed-data syntax in PKCS#7
>> version 1.5, you can see that encryptedDigest can easily carry a DSA
>> signature value.  The syntax works fine, although the english desciption of
>> the process is RSA specific.  I do not think that any implementation would
>> be confused is the appropriate OIDs are used.
>>
>> DSA is not one of the algorithms supported by any S/MIME v2 implementation
>> that I know about.  I am sure that someone on the list will correct me if I
>> am unaware of one.
>
>
>
>
>

Date: Tue, 27 Jan 1998 12:18:32 -0500
To: [email-masked] (David P. Kemp)
From: Russ Housley <[email-masked]>
Subject: Re: Tolerance on Message Digest Attribute
Cc: [email-masked]
Sender: [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

At 03:28 PM 1/23/98 -0500, David P. Kemp wrote:
>
>> From EKR:
>> Since the digest can be independently computed from the
>> message data, it's hard to understand why removing it from the
>> authenticatedAttributes on the wire adds any security.
>
>
>I have to agree strongly with Chris.  Since the digest can be
>independently computed from the message data, it *should* be so
>computed, and not transmitted on the wire.
>
>Including a redundant copy of the hash is not only, .. well .., redundant,
>it also is an invitation for implementors to make a mistake and not
>compute the hash from the message.  That is an operational security
>problem, even if no case can be demonstrated for which it introduces
>a cryptographic vulnerability.
>
>As Chris said, "motive and opportunity".  I'm always in favor of
>removing an opportunity for error.
>
>Dave Kemp
>

Date: Mon, 26 Jan 1998 17:25:09 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: RE: Corporate Key mechanism
Sender: [email-masked]

ALL:

I would like to bring this thread to a close.

In my view, S/MIME 3 already support three key/message recovery schemes.
First, the CA can keep a copy of any key management private key (e.g.,
Entrust).  Second, the originator can include a a recovery agent in the CC
list for every message.  Third, a session key recovery scheme can be used
with the necessary fields carried as algorithm parameters (e.g., TIS).
None of these approaches requires a change to the protocol specification.
And, I am strongly opposed to requiring the use of any particular scheme.

Please, on resolution of the open issues.

Thanks,
  Russ Housley
  S/MIME WG Chair

From: "Blake Ramsdell" <[email-masked]>
To: "'Bruce Greenblatt'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Jim Schaad (Exchange)'" <[email-masked]>, "'phil'" <[email-masked]>, "'Steve Russell'" <[email-masked]>, "'IETF-SMIME'" <[email-masked]>
Subject: RE: Corporate Key mechanism
Date: Mon, 26 Jan 1998 12:20:45 -0800
Sender: [email-masked]

On Monday, January 26, 1998 12:16 PM, Bruce Greenblatt
[SMTP:[email-masked]] wrote:
> Why can't this corporate key/key escrow stuff be done in a separate
> document (ala the ESS document), and those people that really believe
> that it is an important thing can work on it.  The S/MIME core documents
> (if there is such a thing) should be allowed to progress independent of
> this work.  It isn't even clear to me that the core documents even need
> to mention this topic.

I think that we have already come to this consensus.  See my previous
message that explains the creation of a new draft.

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: Bruce Greenblatt <[email-masked]>
To: [email-masked], "Jim Schaad (Exchange)" <[email-masked]>, "'Blake Ramsdell'" <[email-masked]>, "'phil'" <[email-masked]>, "'Steve Russell'" <[email-masked]>, IETF-SMIME <[email-masked]>
Subject: RE: Corporate Key mechanism
Date: Mon, 26 Jan 1998 12:15:42 -0800
Sender: [email-masked]

Why can't this corporate key/key escrow stuff be done in a separate
document (ala the ESS document), and those people that really believe
that it is an important thing can work on it.  The S/MIME core documents
(if there is such a thing) should be allowed to progress independent of
this work.  It isn't even clear to me that the core documents even need
to mention this topic.

Bruce

Date: Mon, 26 Jan 1998 14:57:46 -0500
To: "Jim Schaad (Exchange)" <[email-masked]>, "'Blake Ramsdell'" <[email-masked]>, "'phil'" <[email-masked]>, "'Steve Russell'" <[email-masked]>, "'SMIME -IETF'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Corporate Key mechanism
Sender: [email-masked]

Jim,

I am not sure that I understand your proposal.  Are you saying the
following?:  User1 sends a signedData object to User2 which includes
authenticated attributes in the signerInfo identifying User1's key
management (KM) cert and the "corporate key" KM cert associated with User1's
KM cert.  The signerInfo signature binds the authenticated attributes with
the signer's identity.  Based on the authenticated attributes in the
signedData object, User2 then builds an envelopedData object that includes
receipientInfos for User1's KM cert and the "corporate key" KM cert
associated with User1's KM cert.   

I agree that this is a valid alternative to the proposal to include a
"corporate key" cert identifier extension in each user's KM cert (that
requires the "corporate key" feature).  I believe that the extension
solution is more secure because the CA's signature of the cert tightly binds
the identity of the "corporate key" cert with the user's key material and
identity.  The authenticatedAttribute method is less tightly linked and
presents opportunities for attackers to spoof the originator into creating
recipientInfos for entities' certs other than the intended recipient's cert
and (if required) the intended recipient's "corporate key" cert.

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

>Return-Path: <[email-masked]>
>From: "Jim Schaad (Exchange)" <[email-masked]>
>To: "'Blake Ramsdell'" <[email-masked]>,
>        "[email-masked]'"
>	 <[email-masked]>,
>        "'phil'" <[email-masked]>,
>        "'Steve Russell'"
>	 <[email-masked]>,
>        "'SMIME -IETF'" <[email-masked]>
>Subject: RE: Corporate Key mechanism
>Date: Fri, 23 Jan 1998 15:21:20 -0800
>
>It would seem to me that the the best syntax to use for the extension
>would be exactly the same one as is used for the two-key this is my
>encryption certificate.   In the case of the gateway exploder this could
>easily be done just by saying that I have a two key system and my
>encryption cert is the corperate certificate.
>
>jim

Date: Mon, 26 Jan 1998 14:32:46 -0500
To: [email-masked], [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Corporate Key mechanism
Sender: [email-masked]

Peter,

The major issue seems to be whether the "corporate key" feature is a valid
S/MIME requirement.  I believe that issue needs to be debated further on the
list.  The WorldTalk folks believe that this is a valid requirement.  Does
anybody else believe that it is?

If the S/MIME WG agrees that this is a valid requirement, then I believe
that it should be implemented via an extension in each user's cert.  This is
the most secure method because the CA's signature of the cert tightly binds
the identity of the "corporate key" cert with the user's key material and
identity.  Any other method is less tightly linked and presents
opportunities for attackers to spoof the originator into creating
recipientInfos for entities' certs other than the intended recipient's cert
and (if required) the intended recipient's "corporate key" cert.

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

Date: Mon, 26 Jan 1998 14:10:32 -0500
To: Chen Wang <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
From: [email-masked] (John Pawling)
Subject: RE: Corporate Key mechanism
Sender: [email-masked]

Chen,

I don't believe that we need all of the complexity of KeyID to identify an
X.509 cert.  IMHO, the IssuerAndSerialNumber syntax is sufficient (assuming
that every cert has an Issuer DN which has been proposed as a MUST
requirement for certs used for S/MIME).  IssuerAndSerialNumber is used to
identify the signer's cert in SignerInfo and I believe that it is also
sufficient in the case of the "corporate key" cert.  

- John Pawling

>
>How about the PKCS#7 keyID? 
>
>KeyID ::= CHOICE {
>    x509IssuerAndSerialNumber
>                    [ 0 ] EXPLICIT IssuerAndSerialNumber,
>                                    -- X.509 cert.issuer and cert.serial no.
>    x509KeyID       [ 1 ] EXPLICIT X509KeyID,
>    publicKeyInfo   [ 2 ] EXPLICIT SubjectPublicKeyInfo,
>                                    -- Raw public key info,
>    internalID      [ 3 ] EXPLICIT INTEGER, -- Internal ref.used by this PDU
>    otherID         [ 4 ] EXPLICIT OtherID,
>}
>
>To shamelessly cut and paste a message as sent by Peter Gutmann (on an
>entirely different issue) ...
>
>	-- Chen Wang, NetDox
>
>

From: ross <[email-masked]>
To: Blake Ramsdell <[email-masked]>
Cc: s-mime list <[email-masked]>
Subject: Re: CMS Critical flag for signed attributes?
Date: Mon, 26 Jan 1998 13:21:03 -0800
Sender: [email-masked]

Has anything happened on the CMS critical flag issue since our last
discussion?  I was intending to discuss the issue on the s/mime list, but
somehow I do not think our discussion went onto the list.

I still think the best answer is define an ASN.1 attribute type that has the
capability to include a criticality flag per attribute.  I understand that
such a solution would not be acceptable for attributes already defined by
s/mime v1 and v2, but  would it be acceptable for new attributes with new
OIDs in v3?  There could be a default rule that indicates absence of the
criticality flag means non-critical.  If existing attributes definitions
need to be critical then a new OID could be allocated for them with include
the optional criticality flag indication as part of the attribute
definition.

I am forwarding some of our previous discussion for information to list
subscribers.

On Tuesday, January 06, 1998 6:15 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> This would have no mandatory effect on v2 user agents, but does enable
> the enforcement of criticality in v3, and appears to be the simplest
> fully compatible method of doing so.
I agree that this is fully compatible -- the question is whether or not
v2 user agents ignoring it is acceptable.  If there aren't any
complaints about v2 clients ignoring it, then we can go ahead and draft
syntax for it:
CriticalAttribute ::= OBJECT IDENTIFIER
CriticalAttributes ::= SEQUENCE OF CriticalAttribute
Or more simply:
CriticalAttributes ::= SEQUENCE OF OBJECT IDENTIFIER
And the OID:
id-aa-criticalAttributes OBJECT IDENTIFIER ::= { id-aa 5 }
The proposed use that Phill had is interesting, but I wonder if there
are implications in the event that an authenticated attribute in a
message is in conflict with the capabilities of the signing certificate,
both of which may be marked critical.  For instance:
Certificate has a critical extension that says "This certificate cannot
be used to sign contracts"
Message has a critical attribute that says "This is a signed contract"
Is this something to be concerned about?
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

On Thursday, January 08, 1998 4:51 PM, Ross
[SMTP:[email-masked]] wrote:
> Providing the sequence of CriticalAttributes can be used to point to the
> object IDs of the critical attributes.  But can there be more than one
> occurrence of an attribute in the signature sequence?  If so,  can one
> occurrence be critical and the other occurrence not?
That's a very good observation.  I will think about this.
Perhaps another way we can do this is by partitioning the OIDs so that
all critical ones are under a particular arc?  If there is a noncritical
version of the same attribute, it can go under the noncritical arc
also...
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
-----Original Message-----
From: Blake Ramsdell <[email-masked]>
To: 'Ross' <[email-masked]>
Date: Friday, January 09, 1998 12:23 PM
Subject: RE: CMS Critical flag for signed attributes?

>On Friday, January 09, 1998 8:16 AM, Ross [SMTP:[email-masked]]
>wrote:
>> That solution would work, although it would mean that many attributes
>> would
>> have two OIDs.
>
>You're right, and there may be some confusion as to which is the "right"
>one to use.  This needs some more thought.
>
>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: [email-masked]
DATE: 23 Jan 98 12:21:27 AM
TO: [email-masked]
SUBJECT: Are You Happy!
Sender: [email-masked]

There is brilliant information available to you,  
that will enable you to fully understand yourself 
and everybody else. This knowledge can benefit
you tremendously in many ways.

It can help you to get the very best out of your 
career, or discover your most suitable new career, 
and of course being happy at work, really
improves the finances.
 
It can also really enhance your love life. If you're 
in a relationship, it works great, because you are 
able to fully understand your own and your partner's 
emotions and motivations. If you're not, you will know 
exactly what you want from your perfect mate and what 
they will find attractive about you. 

Another big advantage to becoming balanced and happy 
is that good health runs hand in hand.

Take a closer look two free pages of information at:
http://www.po9.com

From: "Blake Ramsdell" <[email-masked]>
To: "'Steve Russell'" <[email-masked]>, "'SMIME -IETF'" <[email-masked]>
Subject: RE: Corporate Key mechanism
Date: Fri, 23 Jan 1998 19:11:27 -0800
Sender: [email-masked]

On Friday, January 23, 1998 12:07 PM, Steve Russell
[SMTP:[email-masked]] wrote:
> A new and somewhat radical thread....

That we will now discuss amongst ourselves.  The players have let
themselves be known, and the warning has been given that this rathole
was explored on OpenPGP.

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: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Corporate Key mechanism
Reply-To: [email-masked]
Date: Sat, 24 Jan 1998 15:33:05 (NZDT)
Sender: [email-masked]

[email-masked] (John Pawling) writes:
 
>If the S/MIME WG agree that this is a valid requirement, then I recommend 
>that the S/MIME v3 Certificate Handling spec could be changed so that it 
>includes a section defining a certificate extension that identifies the 
>"corporate key" cert.  The ASN.1 syntax could be a SEQUENCE of issuer 
>GeneralNames and serialNumber (to uniquely identify the cert).  The text 
>would state that the extension would be non-critical so that non-S/MIME apps 
>could share the use of the cert.  
 
I think this is a really bad move, it's basically an X.509 analog of PGP
5.x's greatly-criticised CMR/GAK feature (as was pointed out in an earlier 
message).  What makes this much more dangerous though is that it's being done 
as an X.509 extension, which means that any CA can add a GAK key to the certs 
it signs.  Australia is currently considering making it illegal to run a 
non-government-approved CA.  The UK has been thinking about the issues of 
government-controlled CA's for some time now.  Surprisingly the US hasn't 
looked at this yet, but I suspect that's only because it's not (currently) 
possible to do GAK with X.509.  If this facility is added then it's only a 
matter of time before governments start requiring CA's to include GAK keys in 
every cert they sign.  It's almost trivial to do, once a proper PKI is 
established you require that CA's change the GAK extension from non-critical 
to critical and always include it in certificates.  Since it won't be possible 
to do business electronically without a cert from some recognised CA, everyone 
will be forced into using GAK.
 
I consider the inclusion of GAK-ready features a really bad move which is just 
asking for trouble in the future.  Having something like this in S/MIME is bad 
enough, building it into something which will become as pervasive as X.509 
would be a disaster.
 
Peter.

Date: Fri, 23 Jan 1998 18:14:10 -0600 (CST)
From: Chen Wang <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: Corporate Key mechanism
Sender: [email-masked]

> From [email-masked] Fri Jan 23 17:09:37 1998
> 
> I really do see your point John, and I agree about the bloat and
> additional storage requirements, which is why I suggested the choice
> between the identifier and the certificate itself.  The most important
> thing to me is to make sure that in the event that this (potentially
> critical) extension is present, that there is a way to make sure that
> the certificate to which it refers is present also.
> 
> I will say that your comments have me leaning towards not having the
> entire cert inside.
> 
> Blake

How about the PKCS#7 keyID? 

KeyID ::= CHOICE {
    x509IssuerAndSerialNumber
                    [ 0 ] EXPLICIT IssuerAndSerialNumber,
                                    -- X.509 cert.issuer and cert.serial no.
    x509KeyID       [ 1 ] EXPLICIT X509KeyID,
    publicKeyInfo   [ 2 ] EXPLICIT SubjectPublicKeyInfo,
                                    -- Raw public key info,
    internalID      [ 3 ] EXPLICIT INTEGER, -- Internal ref.used by this PDU
    otherID         [ 4 ] EXPLICIT OtherID,
}

To shamelessly cut and paste a message as sent by Peter Gutmann (on an
entirely different issue) ...

	-- Chen Wang, NetDox

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Blake Ramsdell'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'phil'" <[email-masked]>, "'Steve Russell'" <[email-masked]>, "'SMIME -IETF'" <[email-masked]>
Subject: RE: Corporate Key mechanism
Date: Fri, 23 Jan 1998 15:21:20 -0800
Sender: [email-masked]

It would seem to me that the the best syntax to use for the extension
would be exactly the same one as is used for the two-key this is my
encryption certificate.   In the case of the gateway exploder this could
easily be done just by saying that I have a two key system and my
encryption cert is the corperate certificate.

jim

-----Original Message-----
From: Blake Ramsdell [mailto:[email-masked]]
Sent: Friday, January 23, 1998 3:05 PM
To: [email-masked]'; 'phil'; 'Steve Russell'; 'SMIME -IETF'
Subject: RE: Corporate Key mechanism

On Friday, January 23, 1998 2:57 PM, [email-masked]
[SMTP:[email-masked]] wrote:
> I respectfully disagree that the proposed "corporate key" extension in
> the
> user's cert should have the capability to contain the entire
"corporate
> key"
> cert because this would be extremely inefficient.  I believe that the
> extension only needs to identify the "corporate key" cert (Issuer
> GeneralNames and SerialNumber).  There are many ways that the
"corporate
> key" cert can be distributed such as: CMS SignedData certificates
field,
> CMS
> EnvelopedData originatorInfo field, LDAP, X.500, HTTP, etc.  Once the
app
> has obtained the "corporate key" cert, then it will probably want to
> store
> only a single copy of the "corporate key" cert in its local database
of
> certs.  If the entire "corporate key" cert was stored in every user's
> cert,
> then the app would have many redundant copies of the cert in its
database
> (within each user's cert).

I really do see your point John, and I agree about the bloat and
additional storage requirements, which is why I suggested the choice
between the identifier and the certificate itself.  The most important
thing to me is to make sure that in the event that this (potentially
critical) extension is present, that there is a way to make sure that
the certificate to which it refers is present also.

I will say that your comments have me leaning towards not having the
entire cert inside.

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

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'phil'" <[email-masked]>, "'Steve Russell'" <[email-masked]>, "'SMIME -IETF'" <[email-masked]>
Subject: RE: Corporate Key mechanism
Date: Fri, 23 Jan 1998 15:05:30 -0800
Sender: [email-masked]

On Friday, January 23, 1998 2:57 PM, [email-masked]
[SMTP:[email-masked]] wrote:
> I respectfully disagree that the proposed "corporate key" extension in
> the
> user's cert should have the capability to contain the entire "corporate
> key"
> cert because this would be extremely inefficient.  I believe that the
> extension only needs to identify the "corporate key" cert (Issuer
> GeneralNames and SerialNumber).  There are many ways that the "corporate
> key" cert can be distributed such as: CMS SignedData certificates field,
> CMS
> EnvelopedData originatorInfo field, LDAP, X.500, HTTP, etc.  Once the app
> has obtained the "corporate key" cert, then it will probably want to
> store
> only a single copy of the "corporate key" cert in its local database of
> certs.  If the entire "corporate key" cert was stored in every user's
> cert,
> then the app would have many redundant copies of the cert in its database
> (within each user's cert).

I really do see your point John, and I agree about the bloat and
additional storage requirements, which is why I suggested the choice
between the identifier and the certificate itself.  The most important
thing to me is to make sure that in the event that this (potentially
critical) extension is present, that there is a way to make sure that
the certificate to which it refers is present also.

I will say that your comments have me leaning towards not having the
entire cert inside.

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, 23 Jan 1998 17:57:06 -0500
To: "Blake Ramsdell" <[email-masked]>, "'phil'" <[email-masked]>, "'Steve Russell'" <[email-masked]>, "'SMIME -IETF'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Corporate Key mechanism
Sender: [email-masked]

Blake,

I respectfully disagree that the proposed "corporate key" extension in the
user's cert should have the capability to contain the entire "corporate key"
cert because this would be extremely inefficient.  I believe that the
extension only needs to identify the "corporate key" cert (Issuer
GeneralNames and SerialNumber).  There are many ways that the "corporate
key" cert can be distributed such as: CMS SignedData certificates field, CMS
EnvelopedData originatorInfo field, LDAP, X.500, HTTP, etc.  Once the app
has obtained the "corporate key" cert, then it will probably want to store
only a single copy of the "corporate key" cert in its local database of
certs.  If the entire "corporate key" cert was stored in every user's cert,
then the app would have many redundant copies of the cert in its database
(within each user's cert).

Have a Great Weekend!
John Pawling  

From: Larry Layten <[email-masked]>
To: Steve Russell <[email-masked]>, phil <[email-masked]>, SMIME -IETF <[email-masked]>, "'John Pawling'" <[email-masked]>
Subject: RE: Corporate Key mechanism
Date: Fri, 23 Jan 1998 16:40:09 -0600
Sender: [email-masked]

Steve,

I would not agree to this proposal unless the following wording 
was added:     "The sending user MUST have the
option to be notified when an encrypted message is also being 
sent to a 'corporate key' prior to the sending of the message."

There are other ways that entities that require this feature (such
as brokerage firms). One method is that they only publish certificates
for encryption that contain the "corporate key". Then they use
their mail gateway to explode to a users certificate (behind their
firewall) that contains the real users public key. This is a "natural" 
feature for an email gateway company to develop and offer :-).

Larry

----------
From: 	John Pawling[SMTP:[email-masked]]
Sent: 	Friday, January 23, 1998 4:04 PM
To: 	Steve Russell; phil; SMIME -IETF
Subject: 	RE: Corporate Key mechanism

Steve,

OK, I see your point.  If the S/MIME WG agree that this is a valid
requirement, then I recommend that the S/MIME v3 Certificate Handling spec
could be changed so that it includes a section defining a certificate
extension that identifies the "corporate key" cert.  The ASN.1 syntax could
... [snip]

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'phil'" <[email-masked]>, "'Steve Russell'" <[email-masked]>, "'SMIME -IETF'" <[email-masked]>
Subject: RE: Corporate Key mechanism
Date: Fri, 23 Jan 1998 14:33:56 -0800
Sender: [email-masked]

On Friday, January 23, 1998 2:09 PM, [email-masked]
[SMTP:[email-masked]] wrote:
> Please see my message that crossed paths with yours.  I agree with the
> majority of your message except that I believe that the extension only
> needs
> to identify the "corporate key" cert (not include the complete cert).
>  The
> issuer's GeneralNames and the cert serialNumber is enough info to
> uniquely
> identify the cert.

...But not enough to guarantee that the recipient has the corporate
certificate.  Perhaps it can be an option to include the cert or simply
a reference to it.

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, 23 Jan 1998 17:08:41 -0500
To: "Blake Ramsdell" <[email-masked]>, "'phil'" <[email-masked]>, "'Steve Russell'" <[email-masked]>, "'SMIME -IETF'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Corporate Key mechanism
Sender: [email-masked]

Blake,

Please see my message that crossed paths with yours.  I agree with the
majority of your message except that I believe that the extension only needs
to identify the "corporate key" cert (not include the complete cert).  The
issuer's GeneralNames and the cert serialNumber is enough info to uniquely
identify the cert.

- John Pawling

Date: Fri, 23 Jan 1998 17:04:50 -0500
To: "Steve Russell" <[email-masked]>, "phil" <[email-masked]>, "SMIME -IETF" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Corporate Key mechanism
Sender: [email-masked]

Steve,

OK, I see your point.  If the S/MIME WG agree that this is a valid
requirement, then I recommend that the S/MIME v3 Certificate Handling spec
could be changed so that it includes a section defining a certificate
extension that identifies the "corporate key" cert.  The ASN.1 syntax could
be a SEQUENCE of issuer GeneralNames and serialNumber (to uniquely identify
the cert).  The text would state that the extension would be non-critical so
that non-S/MIME apps could share the use of the cert.  The text would state
that a compliant S/MIME v3 agent MUST implement this extension (i.e.
recognize the OID and be able to decode the syntax) and MUST implement the
following rules: "When the application builds a CMS envelopedData for the
recipient, then the app MUST search for the "corporate key" extension in the
recipient's certificate.  If the "corporate key" extension is present, then
the application MUST build a recipientInfo for the identified "corporate
key" certificate in addition to building a recipientInfo for the recipient's
certificate.  Furthermore, the application MUST search for the "corporate
key" extension in the originator's cert.  If the "corporate key" extension
is present, then the application MUST build a recipientInfo for the
identified "corporate key" cert."  The text would also state that the
"corporate key" extension MAY be present in a cert.  The "MAY" allows those
who want this feature to use it, but those that don't want the feature
implemented for their users can omit the extension from their users' certs
(but they still have to implement the feature to meet the MUST requirements
and so that they can honor the wishes of others that do populate the
extension in their users' certs).  

- John Pawling

At 02:36 PM 1/23/98 -0700, Steve Russell wrote:
>IMHO, the problem with someone using an extension is that generally
speaking, they will only be able to recover half of the mail (i.e. the mail
that the modified client sent).  If the methodology for using corporate keys
(differentiated from key recovery which I agree shouldn't be in the spec) is
not included in the spec then from an customer implementation point of view,
the solution is not practical.  Unless a customer can say that in order to
send me an S/MIME message you must also encrypt to this key, then the
majority of clients will not perform that encryption.  If multiple client
vendors are going to be pushed for this type of solution (which we and at
least one other that may choose to identify themselves are), then it will
make everyone's life easier to agree of a methodology in a standard based way.
>
>Steve
>
>

Date: Fri, 23 Jan 1998 13:58:12 -0800
To: <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Corporate Key mechanism
Sender: [email-masked]

At 01:46 PM 1/23/98 -0800, Blake Ramsdell wrote:
>I agree completely -- the only point that Steve was making is that this
>is a useful thing in some communities, and we should try to standardize
>it so that different products will interoperate.  The best way that this
>can happen is to have a draft that either lives in the S/MIME or PKIX WG
>that explains how it should be implemented.

I agree, as long as it is kept out of the mainline S/MIME specs. In fact, it
seems likely that this should be in PKIX because it affects much more than
S/MIME use. A separate I-D that is what Blake says should suffice.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 23 Jan 1998 19:56:42 -0200 (EDT)
From: Ed Gerck <[email-masked]>
Reply-To: Ed Gerck <[email-masked]>
To: phil <[email-masked]>
cc: Steve Russell <[email-masked]>, SMIME -IETF <[email-masked]>
Subject: Re: Corporate Key mechanism
Sender: [email-masked]

On Fri, 23 Jan 1998, phil wrote:

-> I would word it differently, I would instread say that what we wish to do is
-> to define an attribute which defines a KEY, not a certificate to which the
-> message SHOULD also be encrypted.
-> 
-> The reason for prefering a key over a certificate is that all the
-> information is provided in a single package. The purpose of the certificate
-> is to perform identity binding to the key. I would like a direct binding to
-> what our PGP friends would call a 'mobby key'.

... which could be the competitor's key! Or, a bogus key that has a small
"mistake" and will turn out to unseful or outdated when needed. How can
someone trust a key without trusted information on the key, as provided by
a cert which is signed by a trusted issuer or as provided by an "insider"
mechanism also trusted? Mind you, the trusted cert can be a self-signed
cert very well because trust on that cert is out-of-band ("Towards a
real-world model of trust" http://mcg.org.br/trustdef.txt). 

The mistake was in the reasoning that a key is all you need. A key is only
data with almost zero syntax (yes, you can guess it is a RSA-key but there
is no clue on the message digest used) and zero semantics. Of course, if
you think about implict certs, where the value of the key itself is a
pointer to the cert as known by a restricted community, then to that
restricted community the key is the DN to the one and only cert -- which
again unfolds the rest of the syntax and all the semantics you need in
order to trust that implict key.

In other words and taking my pick at an old joke, the important thing is
not what language God used when He computed the world, but what was His
makefile! The hidden dependencies in Nature are the hidden semantics which
we would need in order to understand it -- and the same goes for keys
where the certificates they are imbedded in (even implicit certs) carry
information which is essential to their use (even knowing it has no
semantics is useful). 

Maybe what you need is just a proper .forward or aliases file and S/MIME
as it is.

Cheers,

Ed

______________________________________________________________________
Dr.rer.nat. E. Gerck                     [email-masked]
http://novaware.cps.softex.br
    --- Visit the Meta-Certificate Group at http://mcg.org.br ---

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'phil'" <[email-masked]>, "'Steve Russell'" <[email-masked]>, "'SMIME -IETF'" <[email-masked]>
Subject: RE: Corporate Key mechanism
Date: Fri, 23 Jan 1998 13:46:03 -0800
Sender: [email-masked]

On Friday, January 23, 1998 1:30 PM, [email-masked]
[SMTP:[email-masked]] wrote:
> I respectfully disagree that we should add complexity to the S/MIME specs
> to
> support key recovery.  If a user community desires to support key
> recovery,
> then they can populate a private extension in each of their subscriber's
> certs that specifies the "corporate key" cert.  When the application
> builds
> a CMS envelopedData for the recipient, then the app examines the private
> extension in the recipient's cert to detemine the "corporate key" cert.
> Then the app can build a recipientInfo for the "corporate key" cert in
> addition to the recipient's recipientInfo.  This strategy can be
> implemented
> without mentioning it in the S/MIME specs at all.

I agree completely -- the only point that Steve was making is that this
is a useful thing in some communities, and we should try to standardize
it so that different products will interoperate.  The best way that this
can happen is to have a draft that either lives in the S/MIME or PKIX WG
that explains how it should be implemented.

It seems to me that a draft that explains this can be relatively short:

1. Define an X.509 v3 extension OID
2. Define a syntax for this extension (in this case, a complete X.509
certificate)
3. Define semantics for using this extension (create another
recipientInfo for that certificate)
4. Explain the political implications, when the criticality flag should
be set, etc.

Putting on my "I'm a capitalist scumbag with a fiduciary responsibility
to my shareholders, blah, blah" hat for a second, this is an issue that
we would like to investigate due to large customer demand.  The question
is whether or not this is useful to the S/MIME community at large, the
X.509 community at large, or it's just an issue for us.

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, 23 Jan 1998 14:36:36 -0700
From: "Steve Russell" <[email-masked]>
Subject: RE: Corporate Key mechanism
To: "[email-masked]@inetgw" <[email-masked]>, "phil" <[email-masked]>, "SMIME -IETF" <[email-masked]>
Sender: [email-masked]

IMHO, the problem with someone using an extension is that generally speaking, they will only be able to recover half of the mail (i.e. the mail that the modified client sent).  If the methodology for using corporate keys (differentiated from key recovery which I agree shouldn't be in the spec) is not included in the spec then from an customer implementation point of view, the solution is not practical.  Unless a customer can say that in order to send me an S/MIME message you must also encrypt to this key, then the majority of clients will not perform that encryption.  If multiple client vendors are going to be pushed for this type of solution (which we and at least one other that may choose to identify themselves are), then it will make everyone's life easier to agree of a methodology in a standard based way.

Steve

Date: Fri, 23 Jan 1998 16:29:57 -0500
To: "phil" <[email-masked]>, "Steve Russell" <[email-masked]>, "SMIME -IETF" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Corporate Key mechanism
Sender: [email-masked]

Phill and Steve,

I respectfully disagree that we should add complexity to the S/MIME specs to
support key recovery.  If a user community desires to support key recovery,
then they can populate a private extension in each of their subscriber's
certs that specifies the "corporate key" cert.  When the application builds
a CMS envelopedData for the recipient, then the app examines the private
extension in the recipient's cert to detemine the "corporate key" cert.
Then the app can build a recipientInfo for the "corporate key" cert in
addition to the recipient's recipientInfo.  This strategy can be implemented
without mentioning it in the S/MIME specs at all.

- John Pawling

At 04:18 PM 1/23/98 -0800, phil wrote:
>
>>Basically, what is involved is changing the user certificate format to
>designate a field for a second certificate which represents the corporate
>public key appropriate for that user.  An application intending to encrypt
>mail to that user MUST then encrypt the message to both the user key and the
>corporate key.
>
>
>
>I would word it differently, I would instread say that what we wish to do is
>to define an attribute which defines a KEY, not a certificate to which the
>message SHOULD also be encrypted.
>
>The reason for prefering a key over a certificate is that all the
>information is provided in a single package. The purpose of the certificate
>is to perform identity binding to the key. I would like a direct binding to
>what our PGP friends would call a 'mobby key'.
>
>If it was desirable to achieve binding to a certificate to leverage key
>revocation systems than I would suggest an OID with a required key
>specificateion and an optional certificate serial number attribute.
>
>
>The reasons I would specify SHOULD is simple, first we have to be backwards
>compatible with the deployed base if possible, second I think you will find
>that there is much more pushback on making a key recovery system mandatory
>than optional.
>
>In practice support for recovery will be optional for users since they can
>always use an older mail client.
>
>
>            Phill
>
>
>

To: "Bonatti, Chris" <[email-masked]>
Cc: [email-masked]
Subject: Re: Tolerance on Message Digest Attribute
From: EKR <[email-masked]>
Date: 23 Jan 1998 13:18:41 -0800
Lines: 56
Sender: [email-masked]

"Bonatti, Chris" <[email-masked]> writes:

> On 98-01-15, EKR wrote:
> 
> > "Bonatti, Chris" <[email-masked]> writes:
> > >     One concern I have is that the presence of the clear hash
> > > value may lead some vendors to inappropriately reuse it in their
> > > recipient side calculations rather than independently calculate
> > > it.  Clause 5 of the CMS spec says that we're not supposed to do
> > > this.  However, criminologists will tell you that motive and
> > > opportunity identify possible suspects in a crime.  I will leave
> > > motive to your imagination.  Leaving the message digest value
> > > available is an opportunity that I think should be denied.
> > There are lots of ways to go wrong in writing a CMS verifier,
> > many of them simpler than this. I don't see the virtue in going
> > out of our way to prevent this particular one constitutes much
> > of an improvement.
> 
> Eric,
> 
>     Your thinking presupposes a value judgement with which I don't
> agree.  With non-reversible signature algorithms, the hash is not
> available in transit.
Provided that the hash algorithm is ALSO unknown. (Or private).

>     I also don't see this as "going out of our way".  It's just
> relaxing a constraint that isn't necessary in the first place.
But it is going out of our way, since it introduces a gratuitous
incompatibility.

> > Since the digest can be independently computed from the
> > message data, it's hard to understand why removing it from the
> > authenticatedAttributes on the wire adds any security.
> 
>     As I stated above, if a private set of algorithms are used then
> your statement is not correct.  That is the case I am concerned about.
> High-security applications are unlikely to use the run of the mill
> algorithms for signature and/or hash.  However, there is no reason that
> we shouldn't be able to build them based on our existing S/MIME
> products.
I'm not sure what it is you're worried about here. Any hash for
which you can learn very much merely from analysis of plaintext/digest 
pairs isn't much of a hash. This seems like a particularly weak
rationale considering that this hypothetical attacker has
available to him plaintext/ciphertext pairs for the cryptosystem
and the signature/digest system considered as a whole. (Incidentally,
if you DO think that this constitutes a problem, you should insist
that signedData always be encrypted, in which case this problem goes
away.)

-Ekr

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

From: "phil" <[email-masked]>
To: "Steve Russell" <[email-masked]>, "SMIME -IETF" <[email-masked]>
Subject: Re: Corporate Key mechanism
Date: Fri, 23 Jan 1998 16:18:13 -0800
Sender: [email-masked]

>Basically, what is involved is changing the user certificate format to
designate a field for a second certificate which represents the corporate
public key appropriate for that user.  An application intending to encrypt
mail to that user MUST then encrypt the message to both the user key and the
corporate key.

I would word it differently, I would instread say that what we wish to do is
to define an attribute which defines a KEY, not a certificate to which the
message SHOULD also be encrypted.

The reason for prefering a key over a certificate is that all the
information is provided in a single package. The purpose of the certificate
is to perform identity binding to the key. I would like a direct binding to
what our PGP friends would call a 'mobby key'.

If it was desirable to achieve binding to a certificate to leverage key
revocation systems than I would suggest an OID with a required key
specificateion and an optional certificate serial number attribute.

The reasons I would specify SHOULD is simple, first we have to be backwards
compatible with the deployed base if possible, second I think you will find
that there is much more pushback on making a key recovery system mandatory
than optional.

In practice support for recovery will be optional for users since they can
always use an older mail client.

            Phill

Date: Fri, 23 Jan 1998 16:00:26 -0500
To: "Steve Russell" <[email-masked]>, "SMIME -IETF" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Corporate Key mechanism
Sender: [email-masked]

Steve,

IMHO, there is no need to change the CMS spec (or any of the S/MIME specs)
to support your requirement.  When constructing a CMS envelopedData object,
your software would build a recipientInfo SEQUENCE for the recipient and
another recipientInfo SEQUENCE for the "corporate key". 

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

Date: Fri, 23 Jan 1998 15:28:00 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Tolerance on Message Digest Attribute
Sender: [email-masked]

> From EKR:
> Since the digest can be independently computed from the
> message data, it's hard to understand why removing it from the
> authenticatedAttributes on the wire adds any security.

I have to agree strongly with Chris.  Since the digest can be
independently computed from the message data, it *should* be so
computed, and not transmitted on the wire.

Including a redundant copy of the hash is not only, .. well .., redundant,
it also is an invitation for implementors to make a mistake and not
compute the hash from the message.  That is an operational security
problem, even if no case can be demonstrated for which it introduces
a cryptographic vulnerability.

As Chris said, "motive and opportunity".  I'm always in favor of
removing an opportunity for error.

Dave Kemp

Date: Fri, 23 Jan 1998 13:07:01 -0700
From: "Steve Russell" <[email-masked]>
Subject: Corporate Key mechanism
To: "SMIME -IETF" <[email-masked]>
Sender: [email-masked]

A new and somewhat radical thread....

Because I believe the following to be true:
 
- Requiring key recovery is a bad thing (complexity, cost, implementation, etc.)
- Companies do have a need to access mail encrypted to or encrypted by their employees (lost keys, legal investigations, etc)
- We are all working on methods of satisfying US export requirements so that we can export a cryptographically useful product
- The is a middle step between full key recovery and no hope of recovery which involves encrypting messages to a 'corporate key' in addition to a individual public key when sending a message.
 
Basically, what is involved is changing the user certificate format to designate a field for a second certificate which represents the corporate public key appropriate for that user.  An application intending to encrypt mail to that user MUST then encrypt the message to both the user key and the corporate key.  
 
By no means am I implying that everyone that implements S/MIME leave a back door into all of their messages.  However, since most companies that are implementing secure messaging are setting up their own CA (Entrust, OnSite, Netscape, etc.) and they have control over what fields are populated and with what information, they are able to choose whether or not they need visibility into their own data.  
 
As a side note, this is not a radically new concept as something very similar has already been proposed and implemented by PGP.
 
Flames welcome.
 
Steve

Date: Fri, 23 Jan 1998 14:22:04 -0500
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: EKR <[email-masked]>
CC: [email-masked]
Subject: Re: Tolerance on Message Digest Attribute
Sender: [email-masked]

On 98-01-15, EKR wrote:

> "Bonatti, Chris" <[email-masked]> writes:
> >     One concern I have is that the presence of the clear hash
> > value may lead some vendors to inappropriately reuse it in their
> > recipient side calculations rather than independently calculate
> > it.  Clause 5 of the CMS spec says that we're not supposed to do
> > this.  However, criminologists will tell you that motive and
> > opportunity identify possible suspects in a crime.  I will leave
> > motive to your imagination.  Leaving the message digest value
> > available is an opportunity that I think should be denied.
> There are lots of ways to go wrong in writing a CMS verifier,
> many of them simpler than this. I don't see the virtue in going
> out of our way to prevent this particular one constitutes much
> of an improvement.

Eric,

    Your thinking presupposes a value judgement with which I don't
agree.  With non-reversible signature algorithms, the hash is not
available in transit.  With the run of the mill hash algorithms, this
is no big deal.  However, if a privately defined algorithm is selected
(selected by the originator and supported by all recipients) then the
presence of the messageDigest attribute can subject the algorithm to
attack by parties that do not have the hash algorithm.

    I also don't see this as "going out of our way".  It's just
relaxing a constraint that isn't necessary in the first place.

> >     My other concern relates to the overall strength of the
> > protocol in terms of INFOSEC practices.  It is a *bad* idea to
> > expose intermediate values from end system security processes on
> > the communications channel.  Okay, so maybe there isn't an
> > obvious problem if we're assuming RSA algorithms, but it's still
> > violating a design premise for no tangible benefit.  Suppose some
> > creative soul works out a way to exploit the hash value on
> > signed-only messages.  Again, removing it doesn't buy you much
> > with reversible algorithms, but we're now supposed to be
> > designing for a multi-algorithm environment.  I would hate to see
> > something like this be a barrier to acceptance of S/MIME products
> > for use in high-security cryptographic applications.
> Since the digest can be independently computed from the
> message data, it's hard to understand why removing it from the
> authenticatedAttributes on the wire adds any security.

    As I stated above, if a private set of algorithms are used then
your statement is not correct.  That is the case I am concerned about.
High-security applications are unlikely to use the run of the mill
algorithms for signature and/or hash.  However, there is no reason that
we shouldn't be able to build them based on our existing S/MIME
products.

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

    Does anybody else have any views on this?

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  |
 |  PGP public key available from "http://www.ieca.com/"       |
 ---------------------------------------------------------------

Date: Fri, 23 Jan 1998 15:00:56 -0500
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: Michael Warner <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Proposal: Re: 'Signature Purpose' attribute?
Sender: [email-masked]

    After congitating over all the recent negative message on this topic,=
 I
think you guys are missing some of the point here based on interpretation=
 of
"signer".  (Tim, please feel free to slap me about if I'm misrepresenting=
 you
ideas, but this is what I see signature purpose as being good for.)

    I don't see the signature purpose as necessarily something for human
consumption, but rather an aid in automated processing by recipient
implementations.  For instance, a trusted third party time stamp is clear=
ly
something that would be processed automatically by the recipient system, =
and
possibly handled differently (i.e., the time stamp used to mark objects d=
erived
from that message.)  Now consider that the signingTime attribute is a som=
ewhat
likely attribute to be included in any signature.  Isn't it a bit haphaza=
rd
then to expect a receiving implementation to locate a trusted third party=
 time
stamp signature based on the presence of signingTime?  This is not an iss=
ue of
helping the receiving user know which signature is which.  It is an issue=
 of
enabling products to perform automatic actions based on commonly understo=
od
signature semantics.

    Similar examples could, no doubt, be constructed for authorizing
signatures, sensitivity labeling, and other things from Rich's list.

    It seems to me that expecting the receiving implementation to GUESS t=
he
sematics meaning of each signature based on the set of attributes used is=
 at
its BEST a bad design that unduly restricts the usability of digital
signatures.   I think Tim's idea is a useful improvement that can potenti=
ally
stimulate a many uses of S/MIME that are not commonplace today.

Chris Bonatti
IECA, Inc.

____________________

Michael Warner wrote:

> > From: Tim Dean <[email-masked]>
> >
> > Having no way to determine that one is the intended recipient of an
> > S/MIME signed message is just one of a number of obvious limitations
> > which have been discussed on the list, but not fully resolved in my
> > view.
>
> Surely the objective for S/MIME is to provide data origin authenticatio=
n,
> data integrity and data confidentiality.   Anything more than that - su=
ch
> as who a particular message is intended for and what it means - is
> application specific.   S/MIME cannot understand all the semantics of a=
ll
> applications.   The applications themselves must ensure that their mess=
ages
> are meaningful and unambiguous.
>
> > Simply saying =91just hope that a recipient can guess that a signed
> > =93thing=94 was intended for him/her from the content=92 is not a sat=
isfactory
> > answer, particularly when the protocol fix is so simple.  To reinforc=
e
> > this point, the message to which I am responding contained no indicat=
ion
> > it was for me.  The SMTP =91To=92 field gave a clue, but it is intere=
sting
> > that if we were using S/MIME, relying on these unauthenticated fields=
 is
> > (rightly) discouraged.  Some implementations may not even display the=
m.
> >
>
> And so a mail application which implements S/MIME can duplicate some of=
 the
> SMTP header fields within the body of the message, or the user of the m=
ail
> package can insert such fields if he/she thinks its important.   But S/=
MIME
> which is more generic than just E-mail shouldn't have to understand cer=
tain
> fields which are specific to a particular application.
>
> Cheers,
>
> Michael Warner
> Telstra Research Labs

Date: Fri, 23 Jan 1998 14:31:27 -0500
To: "Bonatti, Chris" <[email-masked]>, Russ Housley <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Question:  DSA and S/MIME v2?  v3?
Cc: Stephen Klump <[email-masked]>, [email-masked]
Sender: [email-masked]

Chris,

SHA-1 and DSA can be used with authenticated attributes.  A SHA-1 hash can
be calculated for the content.  The resulting SHA-1 hash value is then
included in the messageDigest authenticated attributes.  A SHA-1 hash is
then calculated for the ASN.1 encoded authenticatedAttributes.  The
resulting SHA-1 hash value is input to the DSA algorithm which outputs the
digital signature value.

- John Pawling

At 02:04 PM 1/23/98 -0500, Bonatti, Chris wrote:
>Russ,
>
>    Is the converse of this statement true?  If using DSA, does that
>essentially mean that authenticated attributes cannot be used?
>
>    I would assume that you could specify DSA as the signature algorithm, and
>specify an arbitrary hash algorithm to address the messageDigest attribute.
>
>Chris
>
>
>___________________
>
>Russ Housley wrote:
>
>> Stephen:
>>
>> >I understand that S/MIME v1 can't support DSA keys because it requires
>> >the messageDigest, which DSA does not provide.  And if authenticated
>> >attributes are present, the messageDigest attribute (among others) MUST
>> >be present.
>>
>> This is not correct.  If you look at the signed-data syntax in PKCS#7
>> version 1.5, you can see that encryptedDigest can easily carry a DSA
>> signature value.  The syntax works fine, although the english desciption of
>> the process is RSA specific.  I do not think that any implementation would
>> be confused is the appropriate OIDs are used.
>>
>> DSA is not one of the algorithms supported by any S/MIME v2 implementation
>> that I know about.  I am sure that someone on the list will correct me if I
>> am unaware of one.
>
>
>
>
>
>

Date: Fri, 23 Jan 1998 14:04:47 -0500
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: Russ Housley <[email-masked]>
CC: Stephen Klump <[email-masked]>, [email-masked]
Subject: Re: Question:  DSA and S/MIME v2?  v3?
Sender: [email-masked]

Russ,

    Is the converse of this statement true?  If using DSA, does that
essentially mean that authenticated attributes cannot be used?

    I would assume that you could specify DSA as the signature algorithm, and
specify an arbitrary hash algorithm to address the messageDigest attribute.

Chris

___________________

Russ Housley wrote:

> Stephen:
>
> >I understand that S/MIME v1 can't support DSA keys because it requires
> >the messageDigest, which DSA does not provide.  And if authenticated
> >attributes are present, the messageDigest attribute (among others) MUST
> >be present.
>
> This is not correct.  If you look at the signed-data syntax in PKCS#7
> version 1.5, you can see that encryptedDigest can easily carry a DSA
> signature value.  The syntax works fine, although the english desciption of
> the process is RSA specific.  I do not think that any implementation would
> be confused is the appropriate OIDs are used.
>
> DSA is not one of the algorithms supported by any S/MIME v2 implementation
> that I know about.  I am sure that someone on the list will correct me if I
> am unaware of one.

Date: Fri, 23 Jan 1998 13:42:34 -0500
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: John Pawling <[email-masked]>
CC: Darren Harter <[email-masked]>, [email-masked]
Subject: Re: Content Type Attribute Question
Sender: [email-masked]

John,

    I think I agree with your points.  To wit, you wrote:

> IMHO, we should not add context-specific tags unless they are absolutely
> required.  As you correctly pointed out, the addition of context-specific
> tags will interfere with backwards compatibility in some cases.

<SNIP>

> I don't believe that it causes any extra work to add a context-specific tag
> once it has become absolutely necessary.  For example, if one or more of the
> BuiltInContentType, ExternalContentType or ExternalContentWithSubtype
> definitions syntaxes are changed such that they are no longer unique, then
> the implementor can change her ASN.1 software to implement the new
> content-specific tag in conjunction with implementing the changed syntax.
> In other words, the ASN.1 software must be changed anyway, so adding support
> for the context-specific tag is a trivial amount of work.

    In nearly all cases, the encoding of the ASN.1 tag amounts to a trivial
change.  I don't have a really strong view on unnecessary tagging.  They do no
harm, but they also do no good.  Extra tags can really make the syntax UGLY from
a maintenance point of view, but I don't know whether we can count that as a
valid engineering rationale.

    I this case, compatibility clearly argues for leaving the tagging the way it
is.

> I do not object to Chris' recommendation.  If his recommendation is
>     approved, then a context-specific tag needs to be added to the
>     "ContentTypeExtended other OtherContentType" choice (to distinguish it
> from
>     the ExternalContentWithSubtype choice) and the context-specific tags can
> be
>     deleted from the OtherContentType syntax (because they are not needed).
>     This results in the following:
>
>         ContentTypeExtended ::= CHOICE {
>             built-in                 BuiltInContentType,
>             external                 ExternalContentType,
>             externalWithSubtype      ExternalContentWithSubtype,
>             other                [0] OtherContentType }
>
>         OtherContentType :: = SEQUENCE {
>             type    OBJECT IDENTIFIER,
>             value   OCTET STRING }

    I agree with this modification.  The tags on "type" and "value" were
inadvertant artifacts of the way I initially wrote the syntax (using
TYPE-IDENTIFIER, which I thought better of) in which they were necessary.  The
missing tag on "other" was simply an oversight.

Chris

Date: Fri, 23 Jan 1998 10:55:46 -0500
To: Scott Hollenbeck <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: ESS-01 msgSigDigest Attribute
Cc: [email-masked]
Sender: [email-masked]

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

All:

I have assigned the OID requested by Scott.  Attached is the latest S/MIME
OID registry.

Russ

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

-- S/MIME Object Identifier Registry
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 
            rsadsi(113549) pkcs(1) pkcs-9(9) 16 }

-- S/MIME Arcs
id-mod  OBJECT IDENTIFIER ::= { id-smime 0 }   -- modules
id-ct   OBJECT IDENTIFIER ::= { id-smime 1 }   -- content types
id-aa   OBJECT IDENTIFIER ::= { id-smime 2 }   -- auth attributes

-- Modules
id-mod-cms             OBJECT IDENTIFIER ::= { id-mod 1 }
id-mod-ess             OBJECT IDENTIFIER ::= { id-mod 2 }

-- Content Types
id-ct-receipt          OBJECT IDENTIFIER ::= { id-ct 1 }

-- Authenticated Attributes
id-aa-receiptRequest   OBJECT IDENTIFIER ::= { id-aa 1 }
id-aa-securityLabel    OBJECT IDENTIFIER ::= { id-aa 2 }
id-aa-mlExpandHistory  OBJECT IDENTIFIER ::= { id-aa 3 }
id-aa-contentHint      OBJECT IDENTIFIER ::= { id-aa 4 }
id-aa-msgSigDigest     OBJECT IDENTIFIER ::= { id-aa 5 }

--=====================_885588946==_--

Date: Fri, 23 Jan 1998 08:50:20 -0500
To: Stephen Klump <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Question:  DSA and S/MIME v2?  v3?
Cc: [email-masked]
Sender: [email-masked]

Stephen:

>I understand that S/MIME v1 can't support DSA keys because it requires
>the messageDigest, which DSA does not provide.  And if authenticated
>attributes are present, the messageDigest attribute (among others) MUST
>be present.

This is not correct.  If you look at the signed-data syntax in PKCS#7
version 1.5, you can see that encryptedDigest can easily carry a DSA
signature value.  The syntax works fine, although the english desciption of
the process is RSA specific.  I do not think that any implementation would
be confused is the appropriate OIDs are used.

DSA is not one of the algorithms supported by any S/MIME v2 implementation
that I know about.  I am sure that someone on the list will correct me if I
am unaware of one.

>Would some kind soul please tell me if S/MIME v2 gets away from this
>somehow and therefore allows DSA keys, or do we have to wait for S/MIME
>v3?

The CMS specification fixes the wording so that any signature algorithm can
be used.  The syntax does not change.

>I can't really tell much difference between S/MIME v1 and v2 in terms of
>ASN.1 except for the application/mime types.  Do I have this right
>[broad strokes]:
>
>v1 - RSA developed this
>v2 - continuation of v1, only under IETF
>v3 - DSA, signed receipts, security clearance, MLA's

No.  S/MIME v2 was developed by RSA.  It is in the process of being
documented in Informational RFCs.  S/MIME v3 is being developed in the
IETF.  S/MIME v3 is building on S/MIME v2, and it adds additional features
(including key management algorithm independence, signed receipts, security
labels, and support for mail lists).

>Mainly what I'm jonesin' for is DSA; the other stuff can wait for my
>purposes, for the moment.

Enjoy,
  Russ

From: Stephen Klump <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Question:  DSA and S/MIME v2?  v3?
Date: Thu, 22 Jan 1998 20:37:40 -0500
Sender: [email-masked]

Hi Folks,

Please forgive me if this question is a little thick.

I understand that S/MIME v1 can't support DSA keys because it requires
the messageDigest, which DSA does not provide.  And if authenticated
attributes are present, the messageDigest attribute (among others) MUST
be present.

Would some kind soul please tell me if S/MIME v2 gets away from this
somehow and therefore allows DSA keys, or do we have to wait for S/MIME
v3?

I can't really tell much difference between S/MIME v1 and v2 in terms of
ASN.1 except for the application/mime types.  Do I have this right
[broad strokes]:

v1 - RSA developed this
v2 - continuation of v1, only under IETF
v3 - DSA, signed receipts, security clearance, MLA's

Mainly what I'm jonesin' for is DSA; the other stuff can wait for my
purposes, for the moment.

Thanks in advance,
Stephen - Entrust Technologies

From: Scott Hollenbeck <[email-masked]>
To: "'IETF S/MIME'" <[email-masked]>
Subject: ESS-01 msgSigDigest Attribute
Date: Thu, 22 Jan 1998 07:23:43 PST
Sender: [email-masked]

Section 2.4, steps 1 and 5 describe an authenticated attribute
called "msgSigDigest".  Looking at Russ' OID web page, I don't
yet see an OID assigned for this attribute.  That needs to be
done.

I propose the following:

id-aa-msgSigDigest  OBJECT IDENTIFIER ::= { id-aa 5 }

so that it is simply added to the end of the existing authenticated
attribute arc.

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

Date: Thu, 22 Jan 1998 08:25:37 +1100
From: Michael Warner <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: Proposal: Re: 'Signature Purpose' attribute?
Cc: [email-masked]
Sender: [email-masked]

> From: Tim Dean <[email-masked]>
>
> Having no way to determine that one is the intended recipient of an
> S/MIME signed message is just one of a number of obvious limitations
> which have been discussed on the list, but not fully resolved in my
> view.

Surely the objective for S/MIME is to provide data origin authentication,
data integrity and data confidentiality.   Anything more than that - such
as who a particular message is intended for and what it means - is 
application specific.   S/MIME cannot understand all the semantics of all 
applications.   The applications themselves must ensure that their messages 
are meaningful and unambiguous.

> Simply saying ‘just hope that a recipient can guess that a signed
> “thing” was intended for him/her from the content’ is not a satisfactory
> answer, particularly when the protocol fix is so simple.  To reinforce
> this point, the message to which I am responding contained no indication
> it was for me.  The SMTP ‘To’ field gave a clue, but it is interesting
> that if we were using S/MIME, relying on these unauthenticated fields is
> (rightly) discouraged.  Some implementations may not even display them.
> 

And so a mail application which implements S/MIME can duplicate some of the
SMTP header fields within the body of the message, or the user of the mail
package can insert such fields if he/she thinks its important.   But S/MIME
which is more generic than just E-mail shouldn't have to understand certain
fields which are specific to a particular application.

Cheers,

Michael Warner
Telstra Research Labs

Date: Wed, 21 Jan 1998 14:35:10 -0600
To: [email-masked]
From: Paul Robichaux <[email-masked]>
Subject: Solved (was: Re: OID registry?)
Sender: [email-masked]

>There's probably a very simple answer to this question: is there a central
>registry of interesting S/MIME-related OIDs? In particular, I'm looking for
>the arc under 1.2.840.1015, which doesn't appear in any of the drafts or
>the registry at domen.uninett.no.

The 1.2.840.1015 OIDs appeared because I had an obsolete version of our
ASN.1 parser that didn't properly handle id_PKCS9*. Now all the OIDs I see,
and generate, are defined according to the PKCS definitions at the
<http://www.imc.org/ietf-smime/oids.html> site John pointed out. Thanks to
all who responded.

Cheers,
-Pau

--
Paul Robichaux <[email-masked]>  |  LJL Enterprises, Inc. | <http://www.ljl.com>
Author,	_Jazz Up Your Web Site In A Weekend_ (ISBN 0761511377)
	 _Windows NT Server 4 Administrator's Guide_ (ISBN 0761507515)
On the way: _Managing the Windows NT Registry_ (O'Reilly; Feb 98)

Date: Wed, 21 Jan 1998 14:54:05 -0500
To: Paul Robichaux <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: OID registry?
Cc: [email-masked]
Sender: [email-masked]

Paul:

If you think there are additional OIDs that need to be assigned, then I am
the registrar.  Otherwise, the www.imc.org site has a page that lists
previously assigned OIDs.

Russ

At 11:26 AM 1/21/98 -0600, Paul Robichaux wrote:
>There's probably a very simple answer to this question: is there a central
>registry of interesting S/MIME-related OIDs? In particular, I'm looking for
>the arc under 1.2.840.1015, which doesn't appear in any of the drafts or
>the registry at domen.uninett.no.
>
>TIA,
>-Paul
>
>--
>Paul Robichaux <[email-masked]>  |  LJL Enterprises, Inc. |
<http://www.ljl.com>
>Author,	_Jazz Up Your Web Site In A Weekend_ (ISBN 0761511377)
>	 _Windows NT Server 4 Administrator's Guide_ (ISBN 0761507515)
>On the way: _Managing the Windows NT Registry_ (O'Reilly; Feb 98)
>
>

Date: Wed, 21 Jan 1998 15:01:36 -0500
To: "Darren Harter" <[email-masked]>, <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Content Type Attribute Question
Sender: [email-masked]

Darren,

IMHO, we should not add context-specific tags unless they are absolutely
required.  As you correctly pointed out, the addition of context-specific
tags will interfere with backwards compatibility in some cases.  

You stated:
>That way we would not have to rely of the definition of BuiltInContentType,
>ExternalContentType and ExternalContentWithSubtype being unique from a tag
>perspective, and if they ever changed we would not have to worry about
>amending this definition retrospectively.

I don't believe that it causes any extra work to add a context-specific tag
once it has become absolutely necessary.  For example, if one or more of the
BuiltInContentType, ExternalContentType or ExternalContentWithSubtype
definitions syntaxes are changed such that they are no longer unique, then
the implementor can change her ASN.1 software to implement the new
content-specific tag in conjunction with implementing the changed syntax.
In other words, the ASN.1 software must be changed anyway, so adding support
for the context-specific tag is a trivial amount of work.

- John

From: Trevor Freeman <[email-masked]>
To: "'Tim Dean'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Proposal: Re: 'Signature Purpose' attribute?
Date: Wed, 21 Jan 1998 11:53:43 -0800
Sender: [email-masked]

Tim,
I agree with John's point, if you want to control the distribution of a
message, encryption is the solution. Even so, we have to accept that once I
have given a document to someone, even if we have encrypted it, it is no
longer in your control and could be forwarded. Some key exchange protocols
in this instance would be of value since if you use Diffie-Hellman(an
algorithm close to you hart Tim), you will have (or be able to find) the
certificate of the person who constructed the encryption layer. Anyone
forwarding a message, cannot use the originators D-H certificate. If you
have a signature on the inside layer of a message which matches the
certificate used to generate the encryption layer, it has come the
originator. If the encryption and signature layers do not match, then it has
been forwarded.
I strongly disagree with the sentiment that machines will be able to
unambiguously determine the purpose intended by the signer from any message
that passes by, and that the purpose is still valid.
As for time stamping, there are other w/g working on this. I do not believe
it was the intent of this w/g to reinvent the wheel. Having the signing time
is a useful attribute in an S\MIME signature, but is does not constitute a
time stamp protocol in itself.
Trevor

From: Bruce Greenblatt <[email-masked]>
To: [email-masked], Paul Robichaux <[email-masked]>, [email-masked]
Subject: RE: OID registry?
Date: Wed, 21 Jan 1998 11:25:08 -0800
Sender: [email-masked]

Paul,

Where did you find 1.2.840.1015?

Bruce

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Wednesday, January 21, 1998 10:29 AM
> To:	Paul Robichaux; [email-masked]
> Subject:	Re: OID registry?
> 
> Paul,
> 
> Check out http://www.imc.org/ietf-smime/oids.html.
> 
> 
> ================================
> John Pawling   
> [email-masked]                             
> J.G. Van Dyke & Associates, Inc.           
> ================================
> 
> 
> At 11:26 AM 1/21/98 -0600, Paul Robichaux wrote:
> >There's probably a very simple answer to this question: is there a
> central
> >registry of interesting S/MIME-related OIDs? In particular, I'm
> looking for
> >the arc under 1.2.840.1015, which doesn't appear in any of the drafts
> or
> >the registry at domen.uninett.no.
> >
> >TIA,
> >-Paul
> >
> >--
> >Paul Robichaux <[email-masked]>  |  LJL Enterprises, Inc. |
> <http://www.ljl.com>
> >Author,	_Jazz Up Your Web Site In A Weekend_ (ISBN 0761511377)
> >	 _Windows NT Server 4 Administrator's Guide_ (ISBN 0761507515)
> >On the way: _Managing the Windows NT Registry_ (O'Reilly; Feb 98)
> >
> >
> >

From: "Darren Harter" <[email-masked]>
To: <[email-masked]>, "John Pawling" <[email-masked]>
Subject: Re: Content Type Attribute Question
Date: Wed, 21 Jan 1998 18:45:49 -0000
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0016_01BD269C.CCAD3920
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

John et al,

See below.

-----Original Message-----
From: John Pawling <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Tuesday, January 20, 1998 07:53
Subject: Re: Content Type Attribute Question

>This results in the following:
>
>    ContentTypeExtended ::= CHOICE {
>        built-in                 BuiltInContentType,
>        external                 ExternalContentType,
>        externalWithSubtype      ExternalContentWithSubtype,
>        other                [0] OtherContentType }
>

I would like to raise a general concern with definition of structures based
on ASN.1 CHOICE.  I personally prefer it if definitions like this had
context-specific tags of every field.

e.g. This definition would be as follows:

    ContentTypeExtended ::= CHOICE {
        built-in                           [0]  BuiltInContentType,
        external                         [1]  ExternalContentType,
        externalWithSubtype   [2]  ExternalContentWithSubtype,
        other                              [3] OtherContentType }

That way we would not have to rely of the definition of BuiltInContentType,
ExternalContentType and ExternalContentWithSubtype being unique from a tag
perspective, and if they ever changed we would not have to worry about
amending this definition retrospectively.

This is a general case "rule" that I believe we should follow for future
definitions that use CHOICE.  I am NOT proposing that we change this
particular structure now as it would not be backwards compatible, and
backwards compatability is an issue (on this list at least).

All things considered, I agree with John's  changes.

Darren

------=_NextPart_000_0016_01BD269C.CCAD3920
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0016_01BD269C.CCAD3920--

Date: Wed, 21 Jan 1998 13:28:43 -0500
To: Paul Robichaux <[email-masked]>, [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: OID registry?
Sender: [email-masked]

Paul,

Check out http://www.imc.org/ietf-smime/oids.html.

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

At 11:26 AM 1/21/98 -0600, Paul Robichaux wrote:
>There's probably a very simple answer to this question: is there a central
>registry of interesting S/MIME-related OIDs? In particular, I'm looking for
>the arc under 1.2.840.1015, which doesn't appear in any of the drafts or
>the registry at domen.uninett.no.
>
>TIA,
>-Paul
>
>--
>Paul Robichaux <[email-masked]>  |  LJL Enterprises, Inc. | <http://www.ljl.com>
>Author,	_Jazz Up Your Web Site In A Weekend_ (ISBN 0761511377)
>	 _Windows NT Server 4 Administrator's Guide_ (ISBN 0761507515)
>On the way: _Managing the Windows NT Registry_ (O'Reilly; Feb 98)
>
>
>

Date: Wed, 21 Jan 1998 11:26:27 -0600
To: [email-masked]
From: Paul Robichaux <[email-masked]>
Subject: OID registry?
Sender: [email-masked]

There's probably a very simple answer to this question: is there a central
registry of interesting S/MIME-related OIDs? In particular, I'm looking for
the arc under 1.2.840.1015, which doesn't appear in any of the drafts or
the registry at domen.uninett.no.

TIA,
-Paul

--
Paul Robichaux <[email-masked]>  |  LJL Enterprises, Inc. | <http://www.ljl.com>
Author,	_Jazz Up Your Web Site In A Weekend_ (ISBN 0761511377)
	 _Windows NT Server 4 Administrator's Guide_ (ISBN 0761507515)
On the way: _Managing the Windows NT Registry_ (O'Reilly; Feb 98)

Date: Wed, 21 Jan 1998 11:13:23 -0500
To: Tim Dean <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Proposal: Re: 'Signature Purpose' attribute?
Cc: [email-masked]
Sender: [email-masked]

Tim,

You stated:
>Having no way to determine that one is the intended recipient of an
>S/MIME signed message is just one of a number of obvious limitations
>which have been discussed on the list, 

I disagree with this statement and with your other arguments regarding the
determination that one is the intended recipient of an S/MIME signed
message.  If the originator wishes to protect the data such that only
specified people can access the plaintext data, then the originator must
protect the data within a signedData object which is then encrypted within
an envelopedData object.  This ensures that only the intended recipients can
access the data and identifies to the recipient that she is one of the
intended recipients.

If the originator chooses to send a signed-only message, then the originator
has made the decision that she doesn't care who accesses the data.  In that
case, I don't know why the recipient would need to determine that she is one
of the intended recipients.

Note that if an originator wishes to send a signed-only message and that
only specified recipients should return a signed receipt, then that
capability is provided in the receiptRequest authenticated attribute.

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

Date: Wed, 21 Jan 1998 14:19:25 +0000
From: Tim Dean <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: RE: Proposal: Re: 'Signature Purpose' attribute?
Sender: [email-masked]

Trevor,

Having no way to determine that one is the intended recipient of an
S/MIME signed message is just one of a number of obvious limitations
which have been discussed on the list, but not fully resolved in my
view.  Simply saying ‘just hope that a recipient can guess that a signed
“thing” was intended for him/her from the content’ is not a satisfactory
answer, particularly when the protocol fix is so simple.  To reinforce
this point, the message to which I am responding contained no indication
it was for me.  The SMTP ‘To’ field gave a clue, but it is interesting
that if we were using S/MIME, relying on these unauthenticated fields is
(rightly) discouraged.  Some implementations may not even display them.

>It is at the end of the
>day people using these systems, not ASN.1 experts.

Yes but it is machines which are going to be generating and processing
signatures.   Many of those will have little or no direct human
interaction: timestamping facilities, CAs, firewalls, virus scanners,
Web servers, to name but a few.  Machines are capable of understanding
ASN.1, and they know the context of an application.  They are capable of
spotting something which has been taken from one application and (mis-)
used in another.

>Other examples such as time stamping do not seem ambiguous.

I do not understand given the current spec how an implementation is
going to detect the difference between an originator’s signature and one
created for time-stamping purposes.  How is a time-stamping agency going
to protect itself against the lawsuit from someone who thought it
originated the content of the message?

>This seams to me
>inherent feature of using a hostile infrastructure. I certainly do not
trust
>the document any the less because of its uncertain means of
>transportation(email or http), since I trust the signature.

In our experience, the main threat is not coming from the hostile
infrastructure, but from hostile end systems.  As I’m sure you know,
writing software which takes local files and sends them off through a
messaging API without the user knowing about it is worryingly easy to
do.

I am well aware that the signature purpose attribute cannot fix all
known security problems on its own.  But with careful implementation, I
suggest it contributes to a solution to some of them.  To take the
example in the previous paragraph, a firewall could detect and block
outgoing messages which do not have the ‘message originator’ purpose
code set.  There are many organizations (like ours) where that would be
a definite advantage.   As a refinement to this, an S/MIME module could
check a user’s capabilities before allowing them to use a particular
purpose code.  This would stop ‘naughty’ software from calling the
module for inappropriate purposes.  An obvious place to store user
capabilities is in the certificate.

Determining that you are the intended recipient of a signed message is
also easy to fix: just include the recipient’s distinguished name (or
certificate) in the signature block.  That plus sig-purpose protects you
from another class of attacks.

I am guessing that the main counter-arguments are coming from
implementers who claim this breaks ‘layering’ and S/MIME’s claimed
application-independence.  IMHO these features make for bad security,
and it is part of our responsibility to attempt to fix them.  Ergo,
vivat sig purpose!

Tim

Trevor Freeman [SMTP:[email-masked]] wrote:

>I am having real difficulty in seeing any value from including a
signature >purpose attribute. Some of the examples given are trying to
authenticate >the context or the transport of the signed document. Other
examples such >as time stamping do not seem ambiguous.
>If Bob receives a document signed by Alice, he does not and cannot
>know it was sent by Alice, only that Alice signed the document. This
>seams to me inherent feature of using a hostile infrastructure. I
certainly >do not trust the document any the less because of its
uncertain means of >transportation(email or http), since I trust the
signature. If Alice >constructs a document solely intended for Bob, but
addresses it “to >whom it may concern” then she has opened the door
herself for Bob to >forward the document. Any document Carol receives
signed by Alice and >beginning “Dear Bob” must be understood by Carol
for what it is. I >cannot see any technological add-on will help Carol
at this point. It is at >the end of the day people using these systems,
not ASN.1 experts.
>Signature Purpose - R.I.P.
>Trevor

Date: Tue, 20 Jan 1998 16:07:48 -0800
From: [email-masked]
Reply-To: [email-masked]
Subject: Mark leaving Netscape
To: [email-masked]
Sender: [email-masked]

(This is a maximum-distribution email. Please forward to whomever may be 
 interested. My apologies if you are sent more than one copy of this 
 message; I am sending to both individuals and mailing lists.)

As of the close of business today, I am no longer working for Netscape.

If you are on this list because you have worked with me, and if you want
to contact someone regarding S/MIME, PKCS7, or other security or mail
related issues, please contact Bob Relyea <[email-masked]>.

If you would like to contact me personally, here is my contact information:

	Mark Welch
	10194 Parkwood Drive, Apt. 6
	Cupertino, CA 95014
	Voice: (408) 257-3699
	Fax/Data: (408) 257-3879
	Email: [email-masked] or [email-masked]

I leave Netscape with no ill feelings, and no regrets. I wish everyone well.

Sincerely,
Mark Welch

Date: Tue, 20 Jan 1998 15:53:55 -0500
To: Makoto Tomoeda <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Question on <draft-ietf-smime-msg-00.txt>
Cc: [email-masked]
Sender: [email-masked]

Makoto:

The indicated paragraph must be revised!  RSA should be implemented for
backward compatibility with S/MIME 2.  Diffie-Hellman (the X9.42 variant)
will be required for S/MIME 3.

Russ

At 05:00 PM 1/20/98 +0900, Makoto Tomoeda wrote:
>
>Hi All
>
>   I have a question regarding to MUST implement algorithms.
>   In <draft-ietf-smime-msg-00.txt> section 2.3 says....
>
>>2.3 KeyEncryptionAlgorithmIdentifier
>>
>> Sending and receiving agents MUST support Diffie-Hellman defined in[DH].
>>
>> Receiving agents SHOULD support rsaEncryption. Incoming encrypted
>> messages contain symmetric keys which are to be decrypted with a
>> user's private key. The size of the private key is determined during
>> key generation.Sending agents SHOULD support rsaEncryption. 
>>
>> Sending agents MUST support encryption of symmetric keys with RSA
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> public keys at key sizes from 512 bits to 1024 bits.   
> ~~~~~~~~~~~~~
>
>   Is that mean Sending agents MUST support RSA algorithm?
>   Sorry if I misunderstood the sentence.
>   
>                                  Thanks in advance.
>   
>---------------------------------------------------------------
>  Makoto Tomoeda
>
>  NTT Multimedia Communication Promotion Dept.
>  Security Service Project Group
>  E-mail : [email-masked]
>---------------------------------------------------------------
>

Date: Tue, 20 Jan 1998 14:13:38 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Content Type Attribute Question
Sender: [email-masked]

All,

I do not object to Chris' recommendation.  If his recommendation is
approved, then a context-specific tag needs to be added to the
"ContentTypeExtended other OtherContentType" choice (to distinguish it from
the ExternalContentWithSubtype choice) and the context-specific tags can be
deleted from the OtherContentType syntax (because they are not needed).
This results in the following:

    ContentTypeExtended ::= CHOICE {
        built-in                 BuiltInContentType,
        external                 ExternalContentType,
        externalWithSubtype      ExternalContentWithSubtype,
        other                [0] OtherContentType }

    OtherContentType :: = SEQUENCE {
        type    OBJECT IDENTIFIER,
        value   OCTET STRING }

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

Date: Tue, 20 Jan 1998 09:52:03 -0800
To: <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Question on <draft-ietf-smime-msg-00.txt>
Sender: [email-masked]

>"If the agent
>supports rsaEncryption, then it MUST support encryption of symmetric keys
>with RSA public keys at key sizes from 512 bits to 1024 bits."

This is exactly right. It is good that that a careful reader caught this.
Hopefully Blake fixes that in the next draft, which is due really soon now,
isn't it Blake?

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 20 Jan 1998 08:45:10 -0500
To: <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Question on <draft-ietf-smime-msg-00.txt>
Sender: [email-masked]

Makoto,

I agree that the wording is confusing.  The intent was to say "If the agent
supports rsaEncryption, then it MUST support encryption of symmetric keys
with RSA public keys at key sizes from 512 bits to 1024 bits."

At the 10 Dec 97 Washington D.C. IETF S/MIME WG, the following decisions
were made: 
"CMS 02 Proposal 6:  The WG agreed that the "MUST implement" algorithms are
SHA-1, DSA, Diffie-Hellman (D-H) and 3DES as specified in MSG3.  The D-H
will be one of the X9.42 variants.  The 3DES will use three independent keys
and CBC mode.  Russ stated that CMS 02 will include placeholders for the
algorithm specifications that will include details regarding the use of the
"MUST implement" cryptographic algorithms with CMS.  After a brief debate
regarding which I-D should include the "MUST implement" cryptographic
algorithms, it was agreed that the CMS I-D will specify the "MUST implement"
algorithms and that the MSG3 I-D will refer to the CMS I-D for the
specification of the "MUST implement" algorithms."

In summary, the text regarding crypto algorithms will be moved from the
S/MIME v3 Message Specification I-D to the CMS I-D.  Hopefully, the text
will be clarified when it is moved into CMS.  Furthermore, I believe that
the gory details regarding the RSA algorithms (such as key size info) should
be documented in an appendix documenting how the RSA algorithms are used
with CMS rather than in the CMS base document itself.

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

At 05:00 PM 1/20/98 +0900, Makoto Tomoeda wrote:
>
>Hi All
>
>   I have a question regarding to MUST implement algorithms.
>   In <draft-ietf-smime-msg-00.txt> section 2.3 says....
>
>>2.3 KeyEncryptionAlgorithmIdentifier
>>
>> Sending and receiving agents MUST support Diffie-Hellman defined in[DH].
>>
>> Receiving agents SHOULD support rsaEncryption. Incoming encrypted
>> messages contain symmetric keys which are to be decrypted with a
>> user's private key. The size of the private key is determined during
>> key generation.Sending agents SHOULD support rsaEncryption. 
>>
>> Sending agents MUST support encryption of symmetric keys with RSA
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> public keys at key sizes from 512 bits to 1024 bits.   
> ~~~~~~~~~~~~~
>
>   Is that mean Sending agents MUST support RSA algorithm?
>   Sorry if I misunderstood the sentence.
>   
>                                  Thanks in advance.
>   
>---------------------------------------------------------------
>  Makoto Tomoeda
>
>  NTT Multimedia Communication Promotion Dept.
>  Security Service Project Group
>  E-mail : [email-masked]
>---------------------------------------------------------------
>
>

Date: Tue, 20 Jan 1998 17:00:26 +0900 (JST)
To: <[email-masked]>
From: Makoto Tomoeda <[email-masked]>
Subject: Question on <draft-ietf-smime-msg-00.txt>
Sender: [email-masked]

Hi All

   I have a question regarding to MUST implement algorithms.
   In <draft-ietf-smime-msg-00.txt> section 2.3 says....

>2.3 KeyEncryptionAlgorithmIdentifier
>
> Sending and receiving agents MUST support Diffie-Hellman defined in[DH].
>
> Receiving agents SHOULD support rsaEncryption. Incoming encrypted
> messages contain symmetric keys which are to be decrypted with a
> user's private key. The size of the private key is determined during
> key generation.Sending agents SHOULD support rsaEncryption. 
>
> Sending agents MUST support encryption of symmetric keys with RSA
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> public keys at key sizes from 512 bits to 1024 bits.   
 ~~~~~~~~~~~~~

   Is that mean Sending agents MUST support RSA algorithm?
   Sorry if I misunderstood the sentence.
   
                                  Thanks in advance.
   
---------------------------------------------------------------
  Makoto Tomoeda

  NTT Multimedia Communication Promotion Dept.
  Security Service Project Group
  E-mail : [email-masked]
---------------------------------------------------------------

Date: Mon, 19 Jan 1998 18:26:09 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: 1/14/98 S/MIME Proposals
Sender: [email-masked]

All,

I believe that ALL of the checks that Chen lists MUST always be performed.
IMHO, the order of performing the checks is up to the implementor. 

- John Pawling 

At 05:04 PM 1/19/98 -0600, Chen Wang wrote:
>> From [email-masked] Mon Jan 19 13:53:42 1998
>
>[ snip ]
>
>> 3) Two Key Systems
>...
>
>> 
>> Proposal #4: The following rule is also proposed for addition to CMS: "If
>> the new authenticated attribute is absent, then the signature and KM
>> certificates must include the same subject DN."  If the new attribute is
>> absent, then the sending agent would examine the OID in the
>> subjectPublicKeyInfo field of each cert to determine if the OID indicates
>> the purpose (ex: id-dsa indicates that a DSS key is included in the cert).
>> The agent should also examine the keyUsage extension to determine the
>> intended usage of the public key included in the cert.
>> 
>
>[ snip ]
>
>It would seem that the agent should check the keyUsage extension *first*,
>before checking the subjectPublicKeyInfo field ... doesn't that match more
>closely the intent of the keyUsage extension?
>
>So a simple flow would be like:
>
>1) Does the CMS exist an authenticated attribute, if so, then DONE
>2) if not, MUST (Carlisle's comments, which I completely agree with) check 
>   the keyUsage extensions (if so exist), for the same subject DN certificates,
>   if one of such is clearly marked for KM purposes, then DONE
>3) if the Key Usage extensions doesn't exist, then look into 
>   subjectPublicKeyInfo
>
>Just a thought,
>
>	-- Chen Wang, NetDox
>
>

Date: Mon, 19 Jan 1998 17:04:18 -0600 (CST)
From: Chen Wang <[email-masked]>
To: [email-masked]
Subject: Re: 1/14/98 S/MIME Proposals
Sender: [email-masked]

> From [email-masked] Mon Jan 19 13:53:42 1998

[ snip ]

> 3) Two Key Systems
...

> 
> Proposal #4: The following rule is also proposed for addition to CMS: "If
> the new authenticated attribute is absent, then the signature and KM
> certificates must include the same subject DN."  If the new attribute is
> absent, then the sending agent would examine the OID in the
> subjectPublicKeyInfo field of each cert to determine if the OID indicates
> the purpose (ex: id-dsa indicates that a DSS key is included in the cert).
> The agent should also examine the keyUsage extension to determine the
> intended usage of the public key included in the cert.
> 

[ snip ]

It would seem that the agent should check the keyUsage extension *first*,
before checking the subjectPublicKeyInfo field ... doesn't that match more
closely the intent of the keyUsage extension?

So a simple flow would be like:

1) Does the CMS exist an authenticated attribute, if so, then DONE
2) if not, MUST (Carlisle's comments, which I completely agree with) check 
   the keyUsage extensions (if so exist), for the same subject DN certificates,
   if one of such is clearly marked for KM purposes, then DONE
3) if the Key Usage extensions doesn't exist, then look into 
   subjectPublicKeyInfo

Just a thought,

	-- Chen Wang, NetDox

Date: Mon, 19 Jan 1998 17:47:32 -0500
To: "[email-masked]'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: 1/14/98 S/MIME Proposals
Sender: [email-masked]

All,

I agree with all of Carlisle's comments.

- John Pawling

At 05:29 PM 1/19/98 -0500, Carlisle Adams wrote:
>Hi John,
>
>Great minutes, as always.
>
>>----------
>>From: 	[email-masked][SMTP:[email-masked]]
>>Sent: 	Monday, January 19, 1998 2:44 PM
>>To: 	[email-masked]
>>Subject: 	1/14/98 S/MIME Proposals
>>
>>All,
>>
>>The following individuals met on 14 Jan 98 in San Francisco to discuss
>>S/MIME-related issues: Russ Housley, Spyrus; Paul Hoffman, IMC; Blake
>>Ramsdell, WorldTalk; Jim Schaad, Microsoft; Jon Callas, PGP; Dave Solo,
>>Citicorp; Pat Cain, GTE: Bob Dickinson, WorldTalk; Ron ?, WorldTalk; Clark
>>Wagner, DoD; John Pawling, VDA.  As requested by Paul Hoffman, this message
>>includes notes from the meeting including proposals for changes to the
>>S/MIME v3 set of I-Ds.  All are welcome to provide comments, if any.
>
>A couple of small comments...
>
>>3) Two Key Systems
>>
>>There was a discussion regarding some perceived problems with two key
>>systems (i.e. separate keys used for signing and for KM). 
>>
>>Proposal #4: The following rule is also proposed for addition to CMS: "If
>>the new authenticated attribute is absent, then the signature and KM
>>certificates must include the same subject DN."  
>
>I might suggest that the last couple of words above get modified
>slightly.  You say elsewhere in these minutes that the DN might be NULL
>(essentially directing parsers to the (critical) subjectAltName
>extension).  Therefore, the rule might be worded:  "If the new
>authenticated attribute is absent, then the signature and KM
>certificates must include the same subject identifying information
>(i.e., DN and/or subjectAltName)."  Or something to that effect...
>
>>If the new attribute is
>>absent, then the sending agent would examine the OID in the
>>subjectPublicKeyInfo field of each cert to determine if the OID indicates
>>the purpose (ex: id-dsa indicates that a DSS key is included in the cert).
>>The agent should also examine the keyUsage extension to determine the
>>intended usage of the public key included in the cert.
>
>You say elsewhere in these minutes that if a keyUsage extension is
>included then it must be critical.  Therefore, the final sentence above
>might be worded:  "The agent MUST also examine the keyUsage extension
>(if present) to determine the intended usage of the public key included
>in the cert."  [That is, I think that your use of the word "should" is
>too soft here...]
>
>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked]
>--------------------------------------------
>
>
>

From: Trevor Freeman <[email-masked]>
To: Tim Dean <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Proposal: Re: 'Signature Purpose' attribute?
Date: Mon, 19 Jan 1998 14:30:50 -0800
Sender: [email-masked]

I am having real difficulty in seeing any value from including a signature
purpose attribute. Some of the examples given are trying to authenticate the
context or the transport of the signed document. Other examples such as time
stamping do not seem ambiguous. 
If Bob receives a document signed by Alice, he does not and cannot know it
was sent by Alice, only that Alice signed the document. This seams to me
inherent feature of using a hostile infrastructure. I certainly do not trust
the document any the less because of its uncertain means of
transportation(email or http), since I trust the signature. If Alice
constructs a document solely intended for Bob, but addresses it "to whom it
may concern" then she has opened the door herself for Bob to forward the
document. Any document Carol receives signed by Alice and beginning "Dear
Bob" must be understood by Carol for what it is. I cannot see any
technological add-on will help Carol at this point. It is at the end of the
day people using these systems, not ASN.1 experts.
Signature Purpose - R.I.P.
Trevor

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: 1/14/98 S/MIME Proposals
Date: Mon, 19 Jan 1998 17:29:38 -0500
Sender: [email-masked]

Hi John,

Great minutes, as always.

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	Monday, January 19, 1998 2:44 PM
>To: 	[email-masked]
>Subject: 	1/14/98 S/MIME Proposals
>
>All,
>
>The following individuals met on 14 Jan 98 in San Francisco to discuss
>S/MIME-related issues: Russ Housley, Spyrus; Paul Hoffman, IMC; Blake
>Ramsdell, WorldTalk; Jim Schaad, Microsoft; Jon Callas, PGP; Dave Solo,
>Citicorp; Pat Cain, GTE: Bob Dickinson, WorldTalk; Ron ?, WorldTalk; Clark
>Wagner, DoD; John Pawling, VDA.  As requested by Paul Hoffman, this message
>includes notes from the meeting including proposals for changes to the
>S/MIME v3 set of I-Ds.  All are welcome to provide comments, if any.

A couple of small comments...

>3) Two Key Systems
>
>There was a discussion regarding some perceived problems with two key
>systems (i.e. separate keys used for signing and for KM). 
>
>Proposal #4: The following rule is also proposed for addition to CMS: "If
>the new authenticated attribute is absent, then the signature and KM
>certificates must include the same subject DN."  

I might suggest that the last couple of words above get modified
slightly.  You say elsewhere in these minutes that the DN might be NULL
(essentially directing parsers to the (critical) subjectAltName
extension).  Therefore, the rule might be worded:  "If the new
authenticated attribute is absent, then the signature and KM
certificates must include the same subject identifying information
(i.e., DN and/or subjectAltName)."  Or something to that effect...

>If the new attribute is
>absent, then the sending agent would examine the OID in the
>subjectPublicKeyInfo field of each cert to determine if the OID indicates
>the purpose (ex: id-dsa indicates that a DSS key is included in the cert).
>The agent should also examine the keyUsage extension to determine the
>intended usage of the public key included in the cert.

You say elsewhere in these minutes that if a keyUsage extension is
included then it must be critical.  Therefore, the final sentence above
might be worded:  "The agent MUST also examine the keyUsage extension
(if present) to determine the intended usage of the public key included
in the cert."  [That is, I think that your use of the word "should" is
too soft here...]

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date: Mon, 19 Jan 1998 14:44:06 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: 1/14/98 S/MIME Proposals
Sender: [email-masked]

All,

The following individuals met on 14 Jan 98 in San Francisco to discuss
S/MIME-related issues: Russ Housley, Spyrus; Paul Hoffman, IMC; Blake
Ramsdell, WorldTalk; Jim Schaad, Microsoft; Jon Callas, PGP; Dave Solo,
Citicorp; Pat Cain, GTE: Bob Dickinson, WorldTalk; Ron ?, WorldTalk; Clark
Wagner, DoD; John Pawling, VDA.  As requested by Paul Hoffman, this message
includes notes from the meeting including proposals for changes to the
S/MIME v3 set of I-Ds.  All are welcome to provide comments, if any.

++++++++++++++++++++++++++++++++++++++++++++++++++++++

1) PGP Commonality:

The IETF S/MIME WG Charter states: "The S/MIME Working Group will attempt to
coordinate its efforts with the OpenPGP Working Group in areas where the
work of the two groups overlap, particularly in specification of
cryptographic algorithms and MIME 
structure."  The group agreed that the S/MIME v3 and Open PGP I-Ds would
continue to differ in their use of certificates and security heading
formats.  A goal is for the CMS and OpenPGP I-Ds to require a common set of
cryptographic algorithms.  The following table documents the CMS mandatory
algorithm requirements and closest equivalent in the PGP environment:

                    |     CMS                 PGP    
====================|=====================================
Digest		    |    SHA-1	            SHA-1
Signature	    |     DSS	            DSS
Content Encryption  |  3DES (CBC)     3DES (Eccentric CFB)
Key Management (KM) |  D-H (X9.42)    D-H (ElGamal variant)

Note that the SHA-1 and DSS (a.k.a. DSA) algorithms are common between the
two environments, but the D-H and 3DES variants are not interoperable.
Note: CBC = Cipher Block Chaining mode and CFB = Cipher Feedback mode.

The MIME structure was discussed.  Blake stated that it would be most
excellent if the MIME heading could include separate PGP and CMS signatures
in addition to the data that was signed.  Another attendee stated that the
1847 spec should be enhanced to include a multipart format so that the PGP
and CMS signatures can be included in separate parts of the MIME heading.
Blake noted that the existing 1847 spec would work because the PGP and CMS
signatures can be included in a single multipart portion of a MIME header.

Proposal #1: Paul Hoffman proposes to create a  separate mail list on which
S/MIME-PGP convergence issues will be discussed.  He will announce the new
mail list on both the IETF OpenPGP and S/MIME WG mail lists.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++

2) SignedData Digesting Rules:

The Dec 97 CMS I-D, Section 5.3 includes rules for digesting the content of
a SignedData object as part of the signature generation and verification
processes.  The rules are different for the Data content type (digest the
Data OCTET STRING value field which can be any random data) than for other
content types (digest the DER encoding of the content).  After a long
debate, the group decided to make the following proposal:

Proposal #2: Change the CMS SignedData contentInfo field to be
signedContentInfo defined as follows:

SignedContentInfo ::=  SEQUENCE {
    sigContentType       ContentType,
    sigContent      [0]  EXPLICIT  OCTET STRING  OPTIONAL}

It is proposed that the CMS Section 5.3 will be changed so that the
digesting rules are consistent for all types of data that is signed (i.e.
the rules for digesting the Data content type will be extended to all types
of data). 

Note that this change is backwards compatible with PKCS #7 v1.5.  The
sigContent OCTET STRING is equivalent to the PKCS #7 v1.5 Data content OCTET
STRING.  Also note that no changes are proposed to the ContentInfo SEQUENCE
encapsulating the outer CMS object.

++++++++++++++++++++++++++++++++++++++++++++++++++++

3) Two Key Systems

There was a discussion regarding some perceived problems with two key
systems (i.e. separate keys used for signing and for KM). 

Proposal #3:  One issue discussed was the process by which an agent
determines which of a remote user's certificates should be used for KM
purposes to support the encryption of a CMS EnvelopedData object.  It is
proposed that a new authenticated attribute will be defined in CMS that will
identify which of a user's X.509 certificates (usually communicated in the
SignedData certificates field) is to be used for key management purposes.
For example, User 1 sends a SignedData object including his KM and DS
Certificates in the SignedData certificates field and the authenticated
attribute indicating which of the certs is his KM cert.  The remote user
would then know which cert to use for KM purposes when sending an
envelopedData object to User 1.  (Note that the EnvelopedData recipientInfo
originatorCert field is used to indicate which of the originator's certs (if
required by the KM algorithm (such as D-H)) is to be used for KM purposes to
support the decryption of an envelopedData object.) 

Proposal #4: The following rule is also proposed for addition to CMS: "If
the new authenticated attribute is absent, then the signature and KM
certificates must include the same subject DN."  If the new attribute is
absent, then the sending agent would examine the OID in the
subjectPublicKeyInfo field of each cert to determine if the OID indicates
the purpose (ex: id-dsa indicates that a DSS key is included in the cert).
The agent should also examine the keyUsage extension to determine the
intended usage of the public key included in the cert.

Proposal #5: The following rule is also proposed for addition to the S/MIME
v3 Certificate Handling I-D: "If a keyUsage extension is included in a v3
X.509 Certificate, then it MUST be marked as critical."  This will ensure
that the S/MIME application uses the public key included in the X.509
Certificate as it was intended by the certificate issuer.  

+++++++++++++++++++++++++++++++++++++++++++++++++++

4) DNs in Certs

There was much debate regarding the inclusion of subject and issuer names
(i.e. DNs) in X.509 Certificates.  The PKIX X.509 Certificate and CRL
Profile states that issuer and subject DNs may be NULL.  

Proposal #6: It is proposed that the S/MIME v3 Certificate 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.

+++++++++++++++++++++++++++++++++++++++++++++++++++

5) E-Mail Addresses in Certs

There was much debate regarding the inclusion of E-Mail addresses in X.509
Certificates.  The current S/MIME v3 Certificate Handling I-D states that
all end-entity certs MUST contain an RFC-822 address. 

The general consensus was that the e-mail address, if present, should be
included in the subjectAltName extension rather than in a component of the
subject DN.  The vast majority of the group agreed that the inclusion of
RFC-822 addresses in X.509 Certificates should not be a mandatory
requirement in the S/MIME v3 Cert Handling I-D.  Further message traffic
will include specific proposals regarding this issue.

++++++++++++++++++++++++++++++++++++++++++++++++++++

6) Certificate Request Message Format (CRMF)
 
Background:  See "12/10/97 IETF S/MIME WG Minutes" Certificate Request
Syntax (CRS) discussion.

The PKIX CRS (based on PKCS-10) and PKIX Certificate Management Protocol
authors and other interested parties have developed a compromise solution
that will soon be documented in the PKIX Certificate Request Message Format
(CRMF) I-D.  The CMP and CRS I-Ds will be changed to replace their redundant
certificate request protocols with pointers to the CRMF I-D.  The CRS I-D
will define the use of CMS for protecting CRMF messages (and other related
certificate management messages to be determined).  The S/MIME v3
Certificate Handling I-D will define how the CRS objects are communicated
using MIME.  The CRMF will only include the harmonized certificate request
format.  A separate I-D will include other harmonized certificate management
message formats such as the certificate response message format.  Note that
the 10 Dec 97 IETF S/MIME WG agreed with this course of action.  The only
new information is the name of the "harmonized" format (i.e. CRMF) and that
significant work has been accomplished toward the development of the CRMF I-D.

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

Date: Fri, 16 Jan 1998 14:27:51 +0000
From: Tim Dean <[email-masked]>
To: [email-masked], [email-masked]
Subject: Resend of earlier message
Sender: [email-masked]

Apologies to all for the fact that I still haven't managed to figure out
how to get my E-mail editor to line-wrap properly... (I've looked all
through the options, and there is seemingly no way of setting line
lengths - despite it being supposedly modern software.)

Here's a re-send of a message I sent earlier, this time using a
different editor.  Hopefully this should fix it...

Tim

----------------------------
Phil Griffin [[email-masked]] said:

>>different set of purpose codes.  The signature pur

>Note: The last line above was snipped by my mailer.

The last bit of this paragraph said “The signature purpose attribute
applies only to the signature in SignerInfo which contains it.  It does
not apply to any other signature.”
The actual text associated with each code could be defined by this
standard as ordinary text. These meanings could be translated into
whatever national languages needed by an implementation for display
purposes. The use of the BIT STRING would allow a set of basic
purposes to be transmitted more efficiently and processed more
easily than using a set of sigPurposeId object identifiers.

Your suggestion about making the basic purpose codes a bit string and
application specific ones OIDs looks sensible to me.  However, if I’ve
understood your suggested ASN.1 correctly, the purpose qualifier can now
only be added to app-specific codes.  Is that correct?  If so, the
original intent was also to allow qualifying text for basic codes as
well. As an example, for the content review code, someone may wish to
further qualify why he/she/it has signed content in human-readable form:
“I’m virus scanner ABC running in domain XYZ. I’ve checked and reviewed
this content before it got to you.”.  Do you have a suggestion of how to
tweak the ASN.1 to support this?  I’m also told SEQUENCE OF generates
slightly more efficient encoding than SET OF.  If this is the case then
this would make sig purpose more efficient too.

>I
>would think type VisibleString (all ASCII with no control chars.)
>more useful, but would prefer either...

>PurposeQualifier ::= CHOICE {
>visASCII  VisibleString (SIZE (1..maxPurposeQualifierSize)),
>unicode   BMPString     (SIZE (1..maxPurposeQualifierSize))
>}

>if valid ASN.1:1994 were supported, and

>SignaturePurposeCode ::= UTF8String
>(SIZE(1..maxPurposeQualifierSize))
>if ASN.1:1998 were used. This would allow alternative definitions
>for these types:

The consensus at the last meeting was to use the 1988 ASN.1 definition
- see the minutes for the discussion and conclusions. Is it possible to
re-express the above in 1988 ASN.1?
Regards,
Tim

Date: Fri, 16 Jan 1998 09:24:05 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: Tim Dean <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Proposal: Re: 'Signature Purpose' attribute?
Sender: [email-masked]

Tim Dean wrote:
> 
> Phil,
> 
> >> different set of purpose codes.  The signature pur
> >>
> 
> >Note: The last line above was snipped by my mailer.
> 
> The last bit of this paragraph said "The signature purpose attribute applies only to the signature in SignerInfo which contains it.  It does not apply to any other signature."
> 
> >The actual text associated with each code could be defined by this
> >standard as ordinary text. These meanings could be translated into
> >whatever national languages needed by an implementation for display
> >purposes. The use of the BIT STRING would allow a set of basic
> >purposes to be transmitted more efficiently and processed more
> >easily than using a set of sigPurposeId object identifiers.
> 
> > Your suggestion about making the basic purpose codes a bit string 
> > and application specific ones OIDs looks sensible to me.  However, 
> > if I've understood your suggested ASN.1 correctly, the purpose 
> > qualifier can now only be added to app-specific codes.  Is that correct?  
> > 

Yes.

> > If so, the original intent was also to allow qualifying text for 
> > basic codes as well. As an example, for the content review code, 
> > someone may wish to further qualify why he/she/it has signed content 
> > in human-readable form: "I'm virus scanner ABC running in domain XYZ. 
> > I've checked and reviewed this content before it got to you.".  Do you 
> > have a suggestion of how to tweak the ASN.1 to support this?  

I noted this difference in capability in my post, and I believe that 
it could be viewed as either a bonus or a negative in the design. It
is possible that the qualifier text might contradict text assumed for
the basic purpose codes, and lead to ambiguity. If qualifier text is
not allowed for the basic purpose codes, I thought that they might
be more useful for applications, and easier to implement.

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'.
 
> > 
> > I'm also told SEQUENCE OF generates slightly more efficient encoding 
> > than SET OF.  If this is the case then this would make sig purpose more 
> > efficient too.

Under DER, SET OF components require sorting, but SEQUENCE OF does not.
I would prefer always using SEQUENCE OF, but SET OF is commonly used in
SMIME, since it relies on an old version (1.5) of PKCS #7, so I assumed
that sorting was not an important consideration. It *is* important in
the modified SignaturePurpose type component 'basicQuals' shown above.

> 
> >I
> >would think type VisibleString (all ASCII with no control chars.)
> >more useful, but would prefer either...
> 
> >   PurposeQualifier ::= CHOICE {
> >      visASCII  VisibleString (SIZE (1..maxPurposeQualifierSize)),
> >      unicode   BMPString     (SIZE (1..maxPurposeQualifierSize))
> >   }
> 
> >if valid ASN.1:1994 were supported, and
> 
> >   SignaturePurposeCode ::= UTF8String
> >(SIZE(1..maxPurposeQualifierSize))
> >if ASN.1:1998 were used. This would allow alternative definitions
> >for these types:
> 
> The consensus at the last meeting was to use the 1988 ASN.1 definition  
> - see the minutes for the discussion and conclusions. Is it possible to 
> re-express the above in 1988 ASN.1?
>

My mistake. Neither BMPString(1994-8) nor UTF8String(1998) should be 
used in standards defined to adhere to ASN.1:1988, though the 'rules'
for what is and what is not valid ASN.1 escape me. I confess that I
have no experience with mixing ASN.1 versions. Sorry for the flux. 
Still, you may wish to consider VisibleString over PrintableString,
though neither of these types supports national languages.
 
> Regards,
> Tim
> 
> ----------
> From:  Phillip H. Griffin [SMTP:[email-masked]]
> Sent:  Wednesday, January 14, 1998 7:06 PM
> To:  Tim Dean
> Cc:  [email-masked]'
> Subject:  Re: Proposal: Re: 'Signature Purpose' attribute?
> 
> Tim Dean wrote:
> >
> > 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
> >
> > 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 pur
> >
> 
> Note: The last line above was snipped by my mailer.
> 
> >
> > 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.
> 
> It strikes me that a set of basic purpose codes could be provided
> as a named bit list instead of by using object identifiers as the
> ASN.1 above describes. For example,
> 
>    BasicPurposeCodes ::= BIT STRING {
>       messageOriginator  (0),
>       messageForwarder   (1),
>       contentOriginator  (2),
>       hTTPOriginator     (3),
>       contentReviewer    (4),
>       securityLabe       (5),
>       timeStamp          (6)
>    }
> 
> The actual text associated with each code could be defined by this
> standard as ordinary text. These meanings could be translated into
> whatever national languages needed by an implementation for display
> purposes. The use of the BIT STRING would allow a set of basic
> purposes to be transmitted more efficiently and processed more
> easily than using a set of sigPurposeId object identifiers.
> 
> The component of SignaturePurposeCode, purposeQualifier, is ASN.1
> type PrintableString, which does not support national languages,
> and does not even support all of the visible ASCII characters. I
> would think type VisibleString (all ASCII with no control chars.)
> more useful, but would prefer either...
> 
>    PurposeQualifier ::= CHOICE {
>       visASCII  VisibleString (SIZE (1..maxPurposeQualifierSize)),
>       unicode   BMPString     (SIZE (1..maxPurposeQualifierSize))
>    }
> 
> if valid ASN.1:1994 were supported, and
> 
>    SignaturePurposeCode ::= UTF8String
> (SIZE(1..maxPurposeQualifierSize))
> 
> if ASN.1:1998 were used. This would allow alternative definitions
> for these types:
> 
>   SignaturePurpose ::= SEQUENCE {
>      basics   BasicPurposeCodes,
>      others   SigPurposeCodes  OPTIONAL
>   }
> 
>   SigPurposeCodes ::= SET OF SignaturePurposeCode
> 
>   SignaturePurposeCode ::= SEQUENCE {
>     sigPurposeId     OBJECT IDENTIFIER,
>     purposeQualifier PurposeQualifier
>   }
> 
> The above definitions support national languages, and allow
> efficient coding when only basic purpose codes are used. The
> use of additional application-specific purpose codes is also
> supported. Note, however, that this scheme doe not provide a
> mechanism for specifying augmenting text with the basic purpose
> codes, which may be viewed as either a bonus or a negative.
> 
> >
> > 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.
> 

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
------------------------------------------------------------

From: Tim Dean <[email-masked]>
To: Tim Dean <[email-masked]>, "'Phillip H. Griffin'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Proposal: Re: 'Signature Purpose' attribute?
Date: Fri, 16 Jan 1998 12:58:52 -0000
Sender: [email-masked]

Phil,

>> different set of purpose codes.  The signature pur
>>

>Note: The last line above was snipped by my mailer.

The last bit of this paragraph said "The signature purpose attribute =
applies only to the signature in SignerInfo which contains it.  It does =
not apply to any other signature."

>The actual text associated with each code could be defined by this
>standard as ordinary text. These meanings could be translated into
>whatever national languages needed by an implementation for display
>purposes. The use of the BIT STRING would allow a set of basic
>purposes to be transmitted more efficiently and processed more
>easily than using a set of sigPurposeId object identifiers.=20

Your suggestion about making the basic purpose codes a bit string and =
application specific ones OIDs looks sensible to me.  However, if I've =
understood your suggested ASN.1 correctly, the purpose qualifier can now =
only be added to app-specific codes.  Is that correct?  If so, the =
original intent was also to allow qualifying text for basic codes as =
well. As an example, for the content review code, someone may wish to =
further qualify why he/she/it has signed content in human-readable form: =
"I'm virus scanner ABC running in domain XYZ. I've checked and reviewed =
this content before it got to you.".  Do you have a suggestion of how to =
tweak the ASN.1 to support this?  I'm also told SEQUENCE OF generates =
slightly more efficient encoding than SET OF.  If this is the case then =
this would make sig purpose more efficient too.

>I
>would think type VisibleString (all ASCII with no control chars.)
>more useful, but would prefer either...

>   PurposeQualifier ::=3D CHOICE {
>      visASCII  VisibleString (SIZE (1..maxPurposeQualifierSize)), =20
>      unicode   BMPString     (SIZE (1..maxPurposeQualifierSize))
>   }

>if valid ASN.1:1994 were supported, and

>   SignaturePurposeCode ::=3D UTF8String
>(SIZE(1..maxPurposeQualifierSize))
>if ASN.1:1998 were used. This would allow alternative definitions
>for these types:

The consensus at the last meeting was to use the 1988 ASN.1 definition  =
- see the minutes for the discussion and conclusions. Is it possible to =
re-express the above in 1988 ASN.1?=20

Regards,
Tim

----------
From:  Phillip H. Griffin [SMTP:[email-masked]]
Sent:  Wednesday, January 14, 1998 7:06 PM
To:  Tim Dean
Cc:  [email-masked]'
Subject:  Re: Proposal: Re: 'Signature Purpose' attribute?

Tim Dean wrote:
>=20
> After discussion with one or two people I have put together some=20
> suggested text for the signature purpose attribute.  This is now=20
> offered to the list for comment.  The intent would be to add this=20
> text as part of section 10 of CMS, providing there is WG consensus.
>=20
> Comments welcome!
> Tim Dean
> ------------------- cut here ---------------------------------
>=20
> 10.x Signature Purpose
>=20
> The signature purpose attribute specifies the purpose for which the=20
> signature was created.  It is intended to be used in circumstances=20
> where there may otherwise be ambiguity in the intention of the signer. =

> For example, it assists in preventing signed content created in one=20
> application (e.g. a signed file or HTTP transaction) being=20
> unintentionally or maliciously mis-used by another (e.g. to=20
> authenticate a message originator).  It can also be used to protect=20
> an entity wishing to sign and forward
>=20
> The signature purpose attribute is identified by the following object
> identifier:
>
> id-sigPurpose OBJECT IDENTIFIER ::=3D { iso(1) member-body(2)
>           us(840) rsadsi(113549) pkcs(1) pkcs9(9) xxx }
>=20
> Signature purpose attribute values have ASN.1 type SignaturePurpose:
>=20
> SignaturePurpose ::=3D SET OF SignaturePurposeCode
>=20
> SignaturePurposeCode ::=3D SEQUENCE {
>   sigPurposeId OBJECT IDENTIFIER,
>   purposeQualifier PrintableString (SIZE =
(1..maxPurposeQualifierSize))}
>=20
>   maxPurposeQualifierSize INTEGER ::=3D 1024
>=20
> The signature purpose attribute MUST be an authenticated attribute;=20
> it MUST NOT be included as part of authenticated attributes.  When=20
> signing content an S/MIME application SHOULD include at least one=20
> purpose code, taken either from the list below or an=20
> application-specific purpose code.  An S/MIME application may include
> more than one purpose code. There can be multiple SignerInfos=20
> associated with a SignedData object, and each one may include a=20
> different set of purpose codes.  The signature pur
>

Note: The last line above was snipped by my mailer.

>=20
> A number of basic purpose codes are defined here for use by S/MIME=20
> applications.  Further purpose codes may be defined on an=20
> application-specific basis. An implementation may choose to populate=20
> the purposeQualifier field with text which further describes the=20
> purpose.

It strikes me that a set of basic purpose codes could be provided
as a named bit list instead of by using object identifiers as the
ASN.1 above describes. For example,

   BasicPurposeCodes ::=3D BIT STRING {
      messageOriginator  (0),
      messageForwarder   (1),
      contentOriginator  (2),
      hTTPOriginator     (3),
      contentReviewer    (4),
      securityLabe       (5),=20
      timeStamp          (6) =20
   }

The actual text associated with each code could be defined by this
standard as ordinary text. These meanings could be translated into
whatever national languages needed by an implementation for display
purposes. The use of the BIT STRING would allow a set of basic
purposes to be transmitted more efficiently and processed more
easily than using a set of sigPurposeId object identifiers.=20

The component of SignaturePurposeCode, purposeQualifier, is ASN.1
type PrintableString, which does not support national languages,
and does not even support all of the visible ASCII characters. I
would think type VisibleString (all ASCII with no control chars.)
more useful, but would prefer either...

   PurposeQualifier ::=3D CHOICE {
      visASCII  VisibleString (SIZE (1..maxPurposeQualifierSize)), =20
      unicode   BMPString     (SIZE (1..maxPurposeQualifierSize))
   }

if valid ASN.1:1994 were supported, and

   SignaturePurposeCode ::=3D UTF8String
(SIZE(1..maxPurposeQualifierSize))

if ASN.1:1998 were used. This would allow alternative definitions
for these types:

  SignaturePurpose ::=3D SEQUENCE {
     basics   BasicPurposeCodes,
     others   SigPurposeCodes  OPTIONAL
  }
=20
  SigPurposeCodes ::=3D SET OF SignaturePurposeCode

  SignaturePurposeCode ::=3D SEQUENCE {
    sigPurposeId     OBJECT IDENTIFIER,
    purposeQualifier PurposeQualifier=20
  }

The above definitions support national languages, and allow
efficient coding when only basic purpose codes are used. The
use of additional application-specific purpose codes is also
supported. Note, however, that this scheme doe not provide a
mechanism for specifying augmenting text with the basic purpose
codes, which may be viewed as either a bonus or a negative.

>=20
> The following basic S/MIME purpose codes are defined:
>
> * Message originator - the signer originated the message together=20
>   with the content of the message.  Signature purpose code=20
>   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.
>=20
> * 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=20
>   typical use of this purpose code is to add an S/MIME signature to=20
>   local files and documents inside a system.

> * HTTP originator - the signer originated the HTTP content.=20
>   Signature purpose code id-SigPurposeHTTPOriginator is used for=20
>   this purpose.
>
> * Content review and approval - the signer reviewed and approved the=20
>   content but did not originate it. Signature purpose code=20
>   id-SigPurposeContentReviewer is used for this purpose. A possible=20
>   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. =20
>   In both cases, further qualifying text could be added in the=20
>   purposeQualifier field.
>
> * Security label - the signer added the signed security label but=20
>   did not originate the content. Signature purpose code=20
>   id-SigPurposeSecurityLabel is used for this purpose.
>
> * Timestamp - the signer added a signed timestamp but did not=20
>   originate the content. Signature purpose code id-SigPurposeTimestamp
>   is used for this purpose.
>=20
> 'Message Originator', 'Content Originator', and 'HTTP originator',=20
> may be used in a SignerInfo on content but SHOULD NOT be used in a=20
> countersignature.  All the other codes listed may be used in either=20
> a SignerInfo on content or in a countersignature.  An implementation=20
> may choose to compare the signature purpose field with fields in
> the certificate before deciding whether the signature is valid.

Phil
--=20
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
------------------------------------------------------------

To: [email-masked]
Subject: Re: Tolerance on Message Digest Attribute
From: EKR <[email-masked]>
Date: 15 Jan 1998 14:53:15 -0800
Lines: 35
Sender: [email-masked]

"Bonatti, Chris" <[email-masked]> writes:
>     One concern I have is that the presence of the clear hash
> value may lead some vendors to inappropriately reuse it in their
> recipient side calculations rather than independently calculate
> it.  Clause 5 of the CMS spec says that we're not supposed to do
> this.  However, criminologists will tell you that motive and
> opportunity identify possible suspects in a crime.  I will leave
> motive to your imagination.  Leaving the message digest value
> available is an opportunity that I think should be denied.
There are lots of ways to go wrong in writing a CMS verifier,
many of them simpler than this. I don't see the virtue in going
out of our way to prevent this particular one constitutes much
of an improvement.

>     My other concern relates to the overall strength of the
> protocol in terms of INFOSEC practices.  It is a *bad* idea to
> expose intermediate values from end system security processes on
> the communications channel.  Okay, so maybe there isn't an
> obvious problem if we're assuming RSA algorithms, but it's still
> violating a design premise for no tangible benefit.  Suppose some
> creative soul works out a way to exploit the hash value on
> signed-only messages.  Again, removing it doesn't buy you much
> with reversible algorithms, but we're now supposed to be
> designing for a multi-algorithm environment.  I would hate to see
> something like this be a barrier to acceptance of S/MIME products
> for use in high-security cryptographic applications.
Since the digest can be independently computed from the
message data, it's hard to understand why removing it from the
authenticatedAttributes on the wire adds any security.

-Ekr

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

From: [email-masked] (John Pawling)
Subject: RE: Issues with Enhanced Security Services for S/MIME (ESS-01)  
To: [email-masked]
Date: Thu, 15 Jan 1998 16:47:50 -0500 (EST)
Sender: [email-masked]

All,

I agree with everything that Jim stated in his message.

- John Pawling

Return-Path: <[email-masked]>
To: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Issues with Enhanced Security Services for S/MIME (ESS-01)
Date: Wed, 14 Jan 1998 20:11:51 -0800
Sender: [email-masked]
Precedence: bulk

I had a conversation with John Pawling and we have agreed on the
following changes to my original proposal.

From: [email-masked]
DATE: 14 Jan 98 4:17:10 PM
TO: [email-masked]
SUBJECT: CyberNews
Sender: [email-masked]

      LET US DO YOUR BULK MAILINGS!!!

..$350 PER MILLION ADDRESSES SENT
..$250 PER 1/2 MILLION ADDRESSES SENT

THE WAY OF THE FUTURE FOR SUCCESS IN YOUR BUSINESS!

Our company will do bulk emailing for your product/service.

Addresses are extracted daily by six of our computers,
which run 24 hours a day 7 days a week, scanning the net
for new addresses.  Estimated 60-80,000 addresses extracted 
daily.  They are fresh!  Over 40 million addresses on file.

No more than 2 pages (50 lines), no porn and no foul 
language.  $50 per page/25 lines per page beyond 2 pages.  
We do not do targeted mailings at this price.

Targeted mailings: 
$150 per 50,000 addresses extracted or less.
We can extract by country, occupation, organizations, 
associations, product, etc.  If we can not 
search and extract what you need, then nobody can.

There are no lower prices on the net.  Your mailing 
can be done in a matter of hours.  We have 6 computers 
extracting addresses 24/7.

For the fastest service, cheapest prices and cleanest
mailings call our processing and new accounts office
at 904-282-0945, Monday - Friday 9 - 5 EST.  If the line is
busy, please keep trying, as bulk mailing is growing fast.  
We do want to work with you to advertise your product.

To have your name removed, call our processing office.
Any negative responses will be dealt with accordingly.

Date: Thu, 15 Jan 1998 16:11:15 -0500
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: [email-masked]
Subject: Tolerance on Message Digest Attribute
Sender: [email-masked]

    I would like to suggest a more flexible and tolerant approach
be adopted for binding the authenticated attributes to the
content in the SignedData content type.  The current procedure
requires (among other things) that if the authenticatedAttributes
are present then the  MessageDigest attribute also be present.
When this occurs the unsigned hash value is present in the
attribute set, making an intermediate value available to the
recipient system and possibly in the transmission channel.  I
have two concerns with this status quo.

    One concern I have is that the presence of the clear hash
value may lead some vendors to inappropriately reuse it in their
recipient side calculations rather than independently calculate
it.  Clause 5 of the CMS spec says that we're not supposed to do
this.  However, criminologists will tell you that motive and
opportunity identify possible suspects in a crime.  I will leave
motive to your imagination.  Leaving the message digest value
available is an opportunity that I think should be denied.

    My other concern relates to the overall strength of the
protocol in terms of INFOSEC practices.  It is a *bad* idea to
expose intermediate values from end system security processes on
the communications channel.  Okay, so maybe there isn't an
obvious problem if we're assuming RSA algorithms, but it's still
violating a design premise for no tangible benefit.  Suppose some
creative soul works out a way to exploit the hash value on
signed-only messages.  Again, removing it doesn't buy you much
with reversible algorithms, but we're now supposed to be
designing for a multi-algorithm environment.  I would hate to see
something like this be a barrier to acceptance of S/MIME products
for use in high-security cryptographic applications.

    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.

This would allow the originating implementation to weigh how must
risk and benefit is entailed in retaining the hash value in the
attributes and decide accordingly; an ideal condition in my
view.  The modified procedures should place little additional
burden on the receiving implementation since it is supposed to
repeat the hash calculation anyway according to
clause 5.

    I look forward to hearing your opinions on this.

  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  |
 |  PGP public key available from "http://www.ieca.com/"       |
 ---------------------------------------------------------------

From: Yolaine Legare <[email-masked]>
Date: Thu, 15 Jan 1998 11:16:11 -0500 (EST)
To: [email-masked]
Subject: A little question!
Content-MD5: 85mAeWwZkF5QhbKW76ym2Q==
Sender: [email-masked]

Hi,

I have been reading info about PGP and S/MIME for four days now but I found 
nowhere where I could have a response to my little but I guess not so simple 
question,

Why a cie would actually use S/MIME instead of PGP?

I would very appreciate if someone could give me an answer or a reference to it.

Yolaine.

Date: Wed, 14 Jan 1998 21:37:26 -0500
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: [email-masked]
Subject: Content Type Attribute Question
Sender: [email-masked]

--------------C31A5B1F424FE72EEB0862BC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

    I'd like to pose the question of why (besides backward
compatibility, which I understand) the ContentType attribute is
limited to only an object identifier?  Object IDs certainly work
for S/MIME content types carrying other S/MIME content types, but
there are a bunch of other likely types of content that aren't
identified in that manner.  X.400, for example, relies on integer
encoding for backward compatibility.  MIME itself uses an ASCII
string identifier for the content, and we don't support this
either.  While I think that object IDs are probably the BEST way
to identify the content type, it is unrealistic to expect the
whole world to change its ways.  Even our own S/MIME ESS document
has a more flexible definition of content type.

    I would like to propose that we define a new attribute to
accommodate more flexible content typing.  The definition I would
propose as a starting point for this new attribute is as follows:

    ContentTypeExtended ::= CHOICE {
        built-in               BuiltInContentType,
        external               ExternalContentType,
        externalWithSubtype    ExternalContentWithSubtype,
        other                  OtherContentType }

    BuiltinContentType ::= [APPLICATION 6] INTEGER {
        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 ::= 32767

    ExternalContentType ::= OBJECT IDENTIFIER

    ExternalContentWithSubtype ::= SEQUENCE {
        external       ExternalContentType,
        subtype        INTEGER }

    OtherContentType :: = SEQUENCE {
        type    [0] OBJECT IDENTIFIER,
        value   [1] OCTET STRING }

    other-content-type-ia5-mime-subtype OBJECT IDENTIFIER ::= {
TBD }
        -- When used in the "type" field of the OtherContentType,

        -- this value indicates the presence of MIME content type

        -- indications within the octet string.  When this value
        -- is used the content of the octet string must be a
string
        -- of ASCII characters.

This syntax is the same as that in ESS, except that I have added
an additional choice that allows any value to be carried.  My
intention here is that we could effectively convey an ASN.1
constrained ANY, but restricting the encoding to an octet string
for ease of implementation.  This additional field could be used
to convey MIME types.  However, structured the way it is, it
leaves could easily support alternate character sets or other
creative uses in the future.

    I think that such a new attribute would add a lot of
flexibility to S/MIME.  The proposed attribute does nothing to
break backward compatibility, because the old definition will
still be valid and protected messages could actually carry both
attributes through some transition period.

    I look forward to hearing your opinions on this.

  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  |
 |  PGP public key available from "http://www.ieca.com/"       |
 ---------------------------------------------------------------

--------------C31A5B1F424FE72EEB0862BC
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<HTML>
&nbsp;&nbsp;&nbsp; I'd like to pose the question of why (besides backward
compatibility, which I understand) the ContentType attribute is limited
to only an object identifier?&nbsp; Object IDs certainly work for S/MIME
content types carrying other S/MIME content types, but there are a bunch
of other likely types of content that aren't identified in that manner.&nbsp;
X.400, for example, relies on integer encoding for backward compatibility.&nbsp;
MIME itself uses an ASCII string identifier for the content, and we don't
support this either.&nbsp; While I think that object IDs are probably the
BEST way to identify the content type, it is unrealistic to expect the
whole world to change its ways.&nbsp; Even our own S/MIME ESS document
has a more flexible definition of content type.

<P>&nbsp;&nbsp;&nbsp; I would like to propose that we define a new attribute
to accommodate more flexible content typing.&nbsp; The definition I would
propose as a starting point for this new attribute is as follows:

<P><TT>&nbsp;&nbsp;&nbsp; ContentTypeExtended ::= CHOICE {</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; built-in&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
BuiltInContentType,</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; external&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ExternalContentType,</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; externalWithSubtype&nbsp;&nbsp;&nbsp;
ExternalContentWithSubtype,</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; other&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OtherContentType }</TT>

<P><TT>&nbsp;&nbsp;&nbsp; BuiltinContentType ::= [APPLICATION 6] INTEGER
{</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; unidentified&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(0),</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; external&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(1),</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; interpersonal-messaging-1984&nbsp;&nbsp;&nbsp;
(2),</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; interpersonal-messaging-1988&nbsp;&nbsp;&nbsp;
(22),</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; edi-messaging&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(35),</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; voice-messaging&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(40) }</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(0..ub-built-in-content-type)</TT>

<P><TT>&nbsp;&nbsp;&nbsp; ub-built-in-content-type INTEGER ::= 32767</TT>

<P><TT>&nbsp;&nbsp;&nbsp; ExternalContentType ::= OBJECT IDENTIFIER</TT>

<P><TT>&nbsp;&nbsp;&nbsp; ExternalContentWithSubtype ::= SEQUENCE {</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; external&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ExternalContentType,</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; subtype&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
INTEGER }</TT>

<P><TT>&nbsp;&nbsp;&nbsp; OtherContentType :: = SEQUENCE {</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; type&nbsp;&nbsp;&nbsp;
[0] OBJECT IDENTIFIER,</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; value&nbsp;&nbsp; [1]
OCTET STRING }</TT>

<P><TT>&nbsp;&nbsp;&nbsp; other-content-type-ia5-mime-subtype OBJECT IDENTIFIER
::= { TBD }</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- When used in the
"type" field of the OtherContentType,</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- this value indicates
the presence of MIME content type</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- indications within
the octet string.&nbsp; When this value</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- is used the content
of the octet string must be a string</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- of ASCII characters.</TT>

<P>This syntax is the same as that in ESS, except that I have added an
additional choice that allows any value to be carried.&nbsp; My intention
here is that we could effectively convey an ASN.1 constrained ANY, but
restricting the encoding to an octet string for ease of implementation.&nbsp;
This additional field could be used to convey MIME types.&nbsp; However,
structured the way it is, it leaves could easily support alternate character
sets or other creative uses in the future.

<P>&nbsp;&nbsp;&nbsp; I think that such a new attribute would add a lot
of flexibility to S/MIME.&nbsp; The proposed attribute does nothing to
break backward compatibility, because the old definition will still be
valid and protected messages could actually carry both attributes through
some transition period.

<P>&nbsp;&nbsp;&nbsp; I look forward to hearing your opinions on this.

<P>&nbsp; Chris
<BR>&nbsp;
<BR>&nbsp;

<P><TT>&nbsp;---------------------------------------------------------------</TT>
<BR><TT>&nbsp;|&nbsp; International Electronic Communication Analysts,
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT>
<BR><TT>&nbsp;|&nbsp; Christopher D. Bonatti&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
9010 Edgepark Road&nbsp; |</TT>
<BR><TT>&nbsp;|&nbsp; Vice-president&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Vienna, Virginia 22182&nbsp; |</TT>
<BR><TT>&nbsp;|&nbsp; [email-masked]&nbsp;&nbsp; Tel: 301-212-9428&nbsp;&nbsp;
Fax: 703-506-8377&nbsp; |</TT>
<BR><TT>&nbsp;|&nbsp; PGP public key available from "<A HREF="http://www.ieca.com/">http://www.ieca.com/</A>"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</TT>
<BR><TT>&nbsp;---------------------------------------------------------------</TT>
<BR>&nbsp;</HTML>

--------------C31A5B1F424FE72EEB0862BC--

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Issues with Enhanced Security Services for S/MIME (ESS-01)
Date: Wed, 14 Jan 1998 20:11:51 -0800
Sender: [email-masked]

I had a conversation with John Pawling and we have agreed on the
following changes to my original proposal.

> -----Original Message-----
> From: Jim Schaad (Exchange) 
> 
> 5.  Section 1.3.4. - Last paragraph :  Change the last sentence to
> "These attributes are required and must be in the authenticated
> attribute section if a receiptRequest attribute is present."

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

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

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

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

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

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

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

Add the following paragraph to section 2.7

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

New item:

Insert a new pargraph 3 in section 4.2

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

jim

Date: Wed, 14 Jan 1998 14:06:00 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: Tim Dean <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Proposal: Re: 'Signature Purpose' attribute?
Sender: [email-masked]

Tim Dean wrote:
> 
> 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
> 
> 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 pur
>

Note: The last line above was snipped by my mailer.

> 
> 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.

It strikes me that a set of basic purpose codes could be provided
as a named bit list instead of by using object identifiers as the
ASN.1 above describes. For example,

   BasicPurposeCodes ::= BIT STRING {
      messageOriginator  (0),
      messageForwarder   (1),
      contentOriginator  (2),
      hTTPOriginator     (3),
      contentReviewer    (4),
      securityLabe       (5), 
      timeStamp          (6)  
   }

The actual text associated with each code could be defined by this
standard as ordinary text. These meanings could be translated into
whatever national languages needed by an implementation for display
purposes. The use of the BIT STRING would allow a set of basic
purposes to be transmitted more efficiently and processed more
easily than using a set of sigPurposeId object identifiers. 

The component of SignaturePurposeCode, purposeQualifier, is ASN.1
type PrintableString, which does not support national languages,
and does not even support all of the visible ASCII characters. I
would think type VisibleString (all ASCII with no control chars.)
more useful, but would prefer either...

   PurposeQualifier ::= CHOICE {
      visASCII  VisibleString (SIZE (1..maxPurposeQualifierSize)),  
      unicode   BMPString     (SIZE (1..maxPurposeQualifierSize))
   }

if valid ASN.1:1994 were supported, and

   SignaturePurposeCode ::= UTF8String
(SIZE(1..maxPurposeQualifierSize))

if ASN.1:1998 were used. This would allow alternative definitions
for these types:

  SignaturePurpose ::= SEQUENCE {
     basics   BasicPurposeCodes,
     others   SigPurposeCodes  OPTIONAL
  }
 
  SigPurposeCodes ::= SET OF SignaturePurposeCode

  SignaturePurposeCode ::= SEQUENCE {
    sigPurposeId     OBJECT IDENTIFIER,
    purposeQualifier PurposeQualifier 
  }

The above definitions support national languages, and allow
efficient coding when only basic purpose codes are used. The
use of additional application-specific purpose codes is also
supported. Note, however, that this scheme doe not provide a
mechanism for specifying augmenting text with the basic purpose
codes, which may be viewed as either a bonus or a negative.

> 
> 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.

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
------------------------------------------------------------

From: Tim Dean <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Proposal: Re: 'Signature Purpose' attribute?
Date: Tue, 13 Jan 1998 10:36:39 -0000
Sender: [email-masked]

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 ::=3D { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs9(9) xxx }

Signature purpose attribute values have ASN.1 type SignaturePurpose:

      SignaturePurpose ::=3D SET OF SignaturePurposeCode

      SignaturePurposeCode ::=3D SEQUENCE {
            sigPurposeId OBJECT IDENTIFIER,
            purposeQualifier PrintableString (SIZE =
(1..maxPurposeQualifierSize))}

      maxPurposeQualifierSize INTEGER ::=3D 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.

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: Issues with Enhanced Security Services for S/MIME (ESS-01)
Date: Sun, 11 Jan 1998 23:58:26 -0800
Sender: [email-masked]

After reviewing the latest draft, I have a few issues and corrections I
would like to see in it.

1.  Section 1.1.2 -  I would like to see this document become agnostic
on the application/signed-data vs. multipart/signed issue.  This is the
policy in the new S/MIME V3 documents and I don't think that this
document should attempt to address the issue.  There are possible
reasons why the inner signature should be multipart/signed if you have a
gateway that is striping the encryption.  And the use of two signedData
and one encryptedData object with base64 encoding leads to a doubling of
the message body size.

2.  Section 1.1.3 - There are no longer eight layers of wrapping on the
original message listed.  I count 11 items listed.  Either we need to
adjust the count in the text, or describe which items in the list are
not really encapsulations.

3.  Section 1.3.2 - Change : "attributes of a SignedData object." to
"attributes of any SignedData object" in paragraph 1.

4.  Section 1.3.4 -  Change contentType to be "MUST BE authenticated"
this is called for in the CMS and PKCS 1.7 specifications if any
attributes are present.  The purpose of this attribute unauthenticated
makes no sense and is required authenticated.

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

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

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

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

9. Section 3.1.1 - Security labels and multiple SignerInfos -- I
disagree with the next to last paragraph.  IMHO if any SignedInfo has a
security label, every SignedInfo in the same SignedData object MUST have
the same label.  I do not want a security label ignored simply because
somebody else signed the message and did not include a security label.

10. Section 4.1 paragraph 4.  I don't know that I agree that it makes
any sense to allow for multiple SignerInfos within the outer SignedData
object which DO NOT have the mlExpansionHistory in the event that any
SignerInfo contains the mlExpansionHistory attribute.  The reason that I
worry about this is that there may be loops which will not be detected.
If a MLA understands the ONE SignerInfo which does not contain the
mlExpansionHistory attribute -- it just may go ahead and send the
message with a NEW mlExchangeHistory starting with it and just deleting
the other SignerInfos it was unable to validate.  If we are going to
keep this then we need to see some type of justification for it.

11.  Section 4.4 paragraph 1 -- Spelling error "ub-ml-expansion-hsitory"

12.  Please add a section to Appendix A which contains all of the OIDs
referenced in this document.

Regards

Jim Schaad

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: CMS Critical flag for signed attributes?
Date: Wed, 7 Jan 1998 11:57:44 -0800
Sender: [email-masked]

On Tuesday, January 06, 1998 6:15 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> This would have no mandatory effect on v2 user agents, but does enable
> the enforcement of criticality in v3, and appears to be the simplest
> fully compatible method of doing so.

I agree that this is fully compatible -- the question is whether or not
v2 user agents ignoring it is acceptable.  If there aren't any
complaints about v2 clients ignoring it, then we can go ahead and draft
syntax for it:

CriticalAttribute ::= OBJECT IDENTIFIER
CriticalAttributes ::= SEQUENCE OF CriticalAttribute

Or more simply:

CriticalAttributes ::= SEQUENCE OF OBJECT IDENTIFIER

And the OID:

id-aa-criticalAttributes OBJECT IDENTIFIER ::= { id-aa 5 }

The proposed use that Phill had is interesting, but I wonder if there
are implications in the event that an authenticated attribute in a
message is in conflict with the capabilities of the signing certificate,
both of which may be marked critical.  For instance:

Certificate has a critical extension that says "This certificate cannot
be used to sign contracts"
Message has a critical attribute that says "This is a signed contract"

Is this something to be concerned about?

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, 7 Jan 1998 13:17:24 -0600 (CST)
From: Chen Wang <[email-masked]>
To: [email-masked]
Subject: Re: The address-in-certs issue
Sender: [email-masked]

Boy, a lot of things have been bounced around when I was off for the holidays,
doesn't everybody take a vacation to some non e-mail reachable place? 

> From [email-masked] Wed Jan  7 10:05:49 1998
> 
> > The mandatory identifier syntax requirements for Internet Mail should be
> > that the CA is required to include at least one RFC 822 name and the UA
> > is required to be able to interpret and display RFC 822 names in an
> > intelligible manner.
> 
> *** <blink> Disagree </blink> ***
> 
> This is ISSUE3.  The minimum S/MIME compliance requirement for CAs
> should be that they populate the subject identifier in a form that can
> be displayed by S/MIME-compliant UAs.

Agreed ...

> If the resolution of ISSUE3 is that identifiers in a cert have no
> S/MIME-mandated relationship to From:/To: addresses, then the form of
> the identifier in a cert is not constrained except that it must be
> displayable.

Well, the identifier in a cert, IMHO, must *not* have a *mandated* 
relationship to From:/To: addresses. It is common-place to have the
certificate containing a RFC822 address as "[email-masked]" and
the From:/To: address as something like "[email-masked]". 
 
> > Well, we have multiple issues with dependencies between them.  Can we
> > get agreement on JGM1 through JGM3 before tackling ISSUE2?
> 
> I agree with JGM1 - JGM3.
> I think we all agree that the answer to ISSUE1 is "yes".
> And the answer to ISSUE2 falls out once ISSUE3 is resolved.
> 
> 
> ISSUE3 is the core.  You and Jim Schaad have said essentially,
> (quoting Jim):
> 
> > 1.  It is my firm belief that all certificates should contain a name,
> > either as the subject name or as an alternate subject name that is in
> > the domain which is being dealt with application under question.  As
> > S/MIME is specified primarily as an Internet Mail system, this would
> > imply that RFC 822 e-mail names should be present in a subjectAltName
> > extension.  
> 
> That position sounds plausible on the surface, but when you examine the
> premise on which it is based (ISSUE3), it falls apart.  If you are not
> prepared to mandate a relationship between identities and delivery
> addresses, then there is no reason for S/MIME to require that the
> domain of identities which are displayed to and understood by users
> be identical to the domain of addresses to which Internet Mail can be
> delivered.
> 
> Most of the contributors to this thread have demonstrated why it is
> undesirable to mandate that 1) certs contain delivery addresses, or
> 2) there be any mandatory To:/From: checking requirements for UAs.
> 
> *If* a cert contains an identity that uses the same syntax as an
> Internet Mail To:/From: address, and *if* the identity doesn't match
> the address, then an S/MIME UA MAY take some unspecified action.  As a
> matter of good user interface design, not S/MIME-compliance, that
> action should be configurable by the end user.

Agreed ... however, since S/MIME messages maybe transported over non
Internet Mail venues (such as HTTP), in which case To/From address 
will not exist when the UA get to process the package. I would recommend
that the default action to be not enforced verification.   
 
> So again, what UA address-check-failure action are you prepared to
> mandate in the S/MIME specification?

Since the S/MIME message specification does not explicitly stipulate the
mechanism over which the S/MIME packages are transported (such as SMTP
versus HTTP), I don't believe the S/MIME specification should mandate
any type of check failure action.

On a slightly different note, since S/MIME messages maybe transported
over alternative transport mechanisms, shouldn't the certificate also
potentially contain other types of addressing mechanisms? For instance,
if a S/MIME is to be delivered HTTP, then potentially the certificate
may contain a HTTP URL (following the argument that S/MIME certs *must*
contain a RFC822 name)? I am aware that this maybe outside the boundary
of this WG. 

	-- Chen Wang

Date: Wed, 7 Jan 1998 10:51:44 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: The address-in-certs issue
Sender: [email-masked]

> From: John Gardiner Myers <[email-masked]>
> 
> ISSUE1) Does S/MIME need mandatory minimum identifier syntax
> requirements?
> 
> ISSUE2) Assuming yes to ISSUE1, what are the requirements for Internet
> Mail?
> 
> ISSUE3) What relation, if any, do identifiers in the cert have with an
> address in the From: header?
> 
>     [and]
>
> JGM1) In order to interoperate, each application of S/MIME must specify
> mandatory minimum idenitfier syntax requirements on CAs and receiving
> UAs, such that every conforming cert has identifiers interperable
> (subject to policy) by every conforming UA.

Agree.

> JGM2) The mandatory identifier syntax requirements of Internet mail
> should be specified in a base S/MIME document.

Agree.

> JGM3) Applications other than Internet mail may profile S/MIME to change
> these identifier syntax requirements as necessary.

I agree with this statement, but it is not relevant to the question of
what this working group should produce.

> The mandatory identifier syntax requirements for Internet Mail should be
> that the CA is required to include at least one RFC 822 name and the UA
> is required to be able to interpret and display RFC 822 names in an
> intelligible manner.

*** <blink> Disagree </blink> ***

This is ISSUE3.  The minimum S/MIME compliance requirement for CAs
should be that they populate the subject identifier in a form that can
be displayed by S/MIME-compliant UAs.

If the resolution of ISSUE3 is that identifiers in a cert have no
S/MIME-mandated relationship to From:/To: addresses, then the form of
the identifier in a cert is not constrained except that it must be
displayable.

> Well, we have multiple issues with dependencies between them.  Can we
> get agreement on JGM1 through JGM3 before tackling ISSUE2?

I agree with JGM1 - JGM3.
I think we all agree that the answer to ISSUE1 is "yes".
And the answer to ISSUE2 falls out once ISSUE3 is resolved.

ISSUE3 is the core.  You and Jim Schaad have said essentially,
(quoting Jim):

> 1.  It is my firm belief that all certificates should contain a name,
> either as the subject name or as an alternate subject name that is in
> the domain which is being dealt with application under question.  As
> S/MIME is specified primarily as an Internet Mail system, this would
> imply that RFC 822 e-mail names should be present in a subjectAltName
> extension.  

That position sounds plausible on the surface, but when you examine the
premise on which it is based (ISSUE3), it falls apart.  If you are not
prepared to mandate a relationship between identities and delivery
addresses, then there is no reason for S/MIME to require that the
domain of identities which are displayed to and understood by users
be identical to the domain of addresses to which Internet Mail can be
delivered.

Most of the contributors to this thread have demonstrated why it is
undesirable to mandate that 1) certs contain delivery addresses, or
2) there be any mandatory To:/From: checking requirements for UAs.

*If* a cert contains an identity that uses the same syntax as an
Internet Mail To:/From: address, and *if* the identity doesn't match
the address, then an S/MIME UA MAY take some unspecified action.  As a
matter of good user interface design, not S/MIME-compliance, that
action should be configurable by the end user.

So again, what UA address-check-failure action are you prepared to
mandate in the S/MIME specification?

From: "Rich Ankney" <[email-masked]>
To: "Tim Dean" <[email-masked]>, <[email-masked]>
Subject: Re: 'Signature Purpose' attribute?
Date: Wed, 7 Jan 1998 09:50:41 -0500
Sender: [email-masked]

I'm in Boston today, but when I get home tomorrow I'll pull together a list
of current signature purpose values.  X9.45 defines some "genic" ones,
and there's an ASTM standard that defines some values specific to
medical records applications.  No sense in duplicating what's already
been done...

Regards,
Rich

----------
From: Tim Dean <[email-masked]>
To: [email-masked]
Subject: 'Signature Purpose' attribute?
Date: Wednesday, January 07, 1998 7:37 AM

The topic of 'signature purpose' began to be discussed towards the end but
didn't quite seem to reach closure (hols got in the way I think.) I'm
re-raising it here to see if there is any kind of consensus for including
it as a signed attribute in S/MIME.

Brief summary of previous discussion: it was pointed out that due to the
multi-purpose nature of S/MIME, a signature created in one application for
one purpose could be used by another application for another purpose which
the signer did not intend.  This could happen accidentally or maliciously. 
E.g. I sign a local file or an HTML transaction and someone sends it off to
a third party as an e-mail in my name.  So far as I can tell given the
current protocol the recipient will not be able to detect that I hadn't
intended to send the signed content as an authenticated E-mail.  This
'feature' seems to reduce the usefulness of signatures, particularly for
anything  with a legal flavour, I suspect.

The suggested fix to this problem was to define a 'signature purpose'
attribute which could be optionally included as an authenticated attribute.
 Rich Ankney suggested the value of the attribute could be an OID in line
with prior precedent (including ANSI X9.45).  Purposes could include:

* Authenticate Message originator
* Authenticate file ownership (distinct from previous - 'I want to claim
ownership of this file but am not sending it out as an e-mail')
* Authenticate HTML originator
* Authenticate content reviewer
* Authenticate release authority (to get message through firewall)
* Authenticate Checked by virus scanner
* Authenticate Time stamp
* Etc. - define your own application specific ones.

So different signers could sign a file using different purpose codes using
S/MIME's multiple signature capability.  This could be done without fear of
the purpose being misunderstood.  E.g. I'm signing the content to say I
have virus scanned it or timestamped it, but I deny originating it. 
Several signature purposes could be used together - e.g. I'm originating
this e-mail and I have virus scanned it.

This seems to me to be a simple fix to a potentially awkward problem. 
Thoughts of others?

Tim

----------

Date: Wed, 07 Jan 1998 08:22:00 -0500
To: John Gardiner Myers <[email-masked]>, [email-masked]
From: Elliott N Ginsburg <[email-masked]>
Subject: Re: The address-in-certs issue
Sender: [email-masked]

Issue 1: identifiers in certs

1) Addresses are not identities. The phone number I give is where I can be
reached, not who I am. Ditto for a postal address. My RFC822 address on a
message is determined by a combination of which account I'm using, and
possibly where I want a reply to go, but it's not my identity.

2) Contrary to a previous comment, I WILL be the one (or my organization)
to decide how my identity is presented to the world, subject to the proof
of identtity procedures set-up.

3) I am perfectly capable of deciding whether email addresses or DNs are
more stable in my organization; I don't need someone else to tell me the
"right" way to do this. I am also perfectly capable of choosing a DN which
is understandable, although I may not be able to do the same for my email
address; I don't need someone else to tell me the "right" way to do
thiseither.  The point is, its MY responsibility to give useful information
to my recipients, so that they can decide whether to trust the content of
the message.

4) There will be organizations which will have no use for DNs, and they may
choose RFC822 identifiers; there will be other organizations which will
want to use DNs, and tie them to a directory of some kind.

5) It takes a special UA to process signatures and inform the recipient of
the result; surely this UA can be made to understand all of a small set of
identifier forms.

6) I think the implication that every user will have a bank of certs
containing all possible email addresses he/she may need is completely
unacceptable for a large organization trying to manage this process. My
organization is trying to minimize the number of certs a user will need.

7) Suppose my ISP or organization does not issue RFC822 addresses which are
very useful for identification purposes. Am I supposed to just make-up an
address, then have it bound into a certificate? If its not really an
address, then its actually another form of DN. The point is we need an
identifier which is not an address, which conveys different kind of
information than does an address.

Issue 2: Should the UA verify the From address against identifiers in a cert

1) Because addresses are not identifiers, I believe this SHOULD NOT be
done. Let the user make the comparison based on whatever information is in
the cert. This validation does not need to be automated by the UA, and
there is more flexibility letting a user do it.

2) Of course, if email addresses are not required in certs, this cannot be
required.

3) This question has only been posed for the case of checking a signature
and a cert used for signatures; what about a recipient cert used for
encryption, is there some kind of checking required for this? Would a key
exchange cert, separate from a signature cert, have to contain an email
address?

At 01:00 PM 1/6/98 -0800, John Gardiner Myers wrote:
>David P. Kemp wrote:
>> 
>> > From: John Gardiner Myers <[email-masked]>
>> > Date: Fri, 19 Dec 1997 14:50:07 -0800
>> >
>> > David P. Kemp wrote:
>> > > Reasons include 1) the more information that goes into a cert, the
shorter
>> > > the expected lifetime,
>> >
>> > Then take out other information.  RFC822 identities are what are used in
>> > Internet Mail, and if you're securing Internet Mail objects, those are
>> > the identities you need to certify.
>> 
>>   --- and ---
>> 
>> > From: John Gardiner Myers <[email-masked]>
>> > Date: Mon, 22 Dec 1997 18:09:51 -0800
>> >
>> > Even simpler, I could have a certificate with both
>> > 12345,[email-masked] and "John Gardiner Myers"@netscape.com.
>> 
>> Is it too much to ask that your arguments at least be self-consistent?
>> You can't simultaneously take extra information out of and put extra
>> information into a certificate.
>
>I don't see any inconsistency.  In the second quote, I transformed an
>example that you posed that had two pieces of information into an
>example that had two pieces of information.  No extra information was
>put into the certificate, I merely changed the syntax of one piece of
>information.
>
>> If we agree that relatively long-lived stable identities are a goal,
>> and that accommodating environments where mail can reach a given user
>> by multiple and occasionally or frequently changing addresses is also
>> a goal, then we can't reach both goals by putting all the delivery
>> addresses into a cert.
>
>Then don't put all the delivery addresses into the cert.
>
>You seem to have an assumption that DN-syntax identifiers are inherently
>more "stable" than all RFC822-syntax identifiers.  This is not the
>case.  Some RFC822-syntax identifiers are temporary.  Some are not. 
>Some RFC822-syntax addresses are more stable than some DN-syntax
>identifiers.
>
>> > Paul needs to send you an important, private message.  Paul is a busy
>> > person.  He's the co-founder of an industry consortium for Internet
>> > mail.  Having much familiarity with Internet mail, he uses the same,
>> > simple, interface he has always used for informing his UA to whom the
>> > mail is intended: he types "[email-masked]" into the To: field of
>> > his compose window.
>> 
>> Paul is a busy person, so he types "kemp" into his compose window.  His
>> MUA has a database of certificates, each of which has a subject name
>> bound to a public key.  The list of subjects matching "kemp" pops up,
>> and Paul clicks on the correct one.  If there is only one match, the
>> MUA displays the full name and either asks for confirmation if Paul has
>> previously checked the "always ask" option, or proceeds if the option is
>> unchecked.
>
>The attacker happens to have a legal name of "David P. Kemp".  In
>addition to associating the attacker's identity with the
>[email-masked] entry in Paul's address book, he also removes your
>certificate from the MUA's database.  When the MUA finds only one match,
>the MUA displays the full name and asks for confirmation.  Paul seeing a
>common name matching yours checks "ok".  The message is encrypted with
>the attacker's public key.
>
>Proponents of DN's seem to have an inexplicable fascination with using
>common names for identifiers.  This besides the fact that common names
>fail two requirements of identifiers: common names are neither unique
>nor unchanging.
>
>> > That is because Paul, being a busy person, doesn't have the time to
>> > parse the DN for every message he receives.  Being an Internet mail kind
>> > of person, he thinks in terms of RFC822 syntax.
>> >   [...]
>> > Most Internet mail users can't distinguish a DN from base64-encoded
>> > line noise.
>> 
>> That is a remarkably insulting statement - I'm glad you said it about
>> Paul and not me :-).  I give even computer-using mothers-in-law* credit
>> for being able to recognize "O=imc.org, CN=Paul Hoffman" as easily as
>> they would "Paul Hoffman / IMC <[email-masked]>".
>
>I don't see why you consider it insulting.  Heck, I don't even have time
>to do the mental gear-switching needed to parse two different syntaxes
>for every message I read.
>
>You must have a remarkably technically inclined mother-in-law.  Never
>mind the fact that you give her an atypically simplistic DN.
>
>> And I give credit to MUA designers to be able to present "Paul Hoffman"
>> to the user given either form as input, and allow the curious to
>> explicitly seek further details.
>
>If the UA only presents "Paul Hoffman", tossing the information needed
>to distinguish that particular "Paul Hoffman" from other things with a
>legal name of "Paul Hoffman", then there is a security problem--some
>other "Paul Hoffman" could masquerade as [email-masked].
>
>
>

Elliott N Ginsburg

From: Tim Dean <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: 'Signature Purpose' attribute?
Date: Wed, 7 Jan 1998 12:37:05 -0000
Sender: [email-masked]

The topic of 'signature purpose' began to be discussed towards the end =
but didn't quite seem to reach closure (hols got in the way I think.) =
I'm re-raising it here to see if there is any kind of consensus for =
including it as a signed attribute in S/MIME.

Brief summary of previous discussion: it was pointed out that due to the =
multi-purpose nature of S/MIME, a signature created in one application =
for one purpose could be used by another application for another purpose =
which the signer did not intend.  This could happen accidentally or =
maliciously.  E.g. I sign a local file or an HTML transaction and =
someone sends it off to a third party as an e-mail in my name.  So far =
as I can tell given the current protocol the recipient will not be able =
to detect that I hadn't intended to send the signed content as an =
authenticated E-mail.  This 'feature' seems to reduce the usefulness of =
signatures, particularly for anything  with a legal flavour, I suspect.

The suggested fix to this problem was to define a 'signature purpose' =
attribute which could be optionally included as an authenticated =
attribute.  Rich Ankney suggested the value of the attribute could be an =
OID in line with prior precedent (including ANSI X9.45).  Purposes could =
include:

* Authenticate Message originator
* Authenticate file ownership (distinct from previous - 'I want to claim =
ownership of this file but am not sending it out as an e-mail')
* Authenticate HTML originator
* Authenticate content reviewer
* Authenticate release authority (to get message through firewall)
* Authenticate Checked by virus scanner
* Authenticate Time stamp
* Etc. - define your own application specific ones.

So different signers could sign a file using different purpose codes =
using S/MIME's multiple signature capability.  This could be done =
without fear of the purpose being misunderstood.  E.g. I'm signing the =
content to say I have virus scanned it or timestamped it, but I deny =
originating it.  Several signature purposes could be used together - =
e.g. I'm originating this e-mail and I have virus scanned it.

This seems to me to be a simple fix to a potentially awkward problem.  =
Thoughts of others?

Tim

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Re: The address-in-certs issue
Date: Tue, 06 Jan 1998 19:18:32 -0800
Organization: Netscape Communications Corporation
Lines: 149
NNTP-Posting-Host: 205.217.229.208
Sender: [email-masked]

Paul Hoffman / IMC wrote:
> 
> Nice to see you back from vacation, John.
> 
> At 02:33 PM 1/6/98 -0800, John Gardiner Myers wrote:
> >In the message to which I was replying, Paul Hoffman was disagreeing
> >with this very point.  He was espousing a position that it was OK for
> >the S/MIME specification to allow a conforming CA to issue certs
> >containing only DN's, yet allow UA's to only recognize RFC822 addresses.
> 
> I never said that. What I said was, unless we specify that this part of the
> cert spec relates specifically to Internet mail, requiring RFC 822
> addresses with no semantics is no more useful than requiring any old string
> with no semantics.

For the record, you stated in your message of 22 Dec 97 16:40:42 PST
that the failure resulting from the abovementioned situation "is due to
the presentation problem, not to the protocol".  In your followup
message at 21:32 you said of the noninteroperation: "That's out of
scope."

> John, your argument has changed over the thread, and where you are now is
> much clearer than when you started off.

I've read over my old posts and don't think I've changed position. 
What's probably confusing things is that there are three separate issues
being argued:

ISSUE1) Does S/MIME need mandatory minimum identifier syntax
requirements?

ISSUE2) Assuming yes to ISSUE1, what are the requirements for Internet
Mail?

ISSUE3) What relation, if any, do identifiers in the cert have with an
address in the From: header?

I've unfortunately been arguing both ISSUE1 and ISSUE2 in the same
messages.

> At the risk of pissing you off even
> further, let me try to summarize what I believe you are now saying:
> - We should define the cert contents for certs passed in S/MIME messages
> over Internet mail

Close.  To break this down more precisely, from my message of 12/22/97
18:09 PST:

JGM1) In order to interoperate, each application of S/MIME must specify
mandatory minimum idenitfier syntax requirements on CAs and receiving
UAs, such that every conforming cert has identifiers interperable
(subject to policy) by every conforming UA.

JGM2) The mandatory identifier syntax requirements of Internet mail
should be specified in a base S/MIME document.

JGM3) Applications other than Internet mail may profile S/MIME to change
these identifier syntax requirements as necessary.

> - In these certs, the identifier must be an RFC 822 name, and cannot be a
> DN (subject name null, subjectAltName must have at least an RFC 822
> identifier in it)

The mandatory identifier syntax requirements for Internet Mail should be
that the CA is required to include at least one RFC 822 name and the UA
is required to be able to interpret and display RFC 822 names in an
intelligible manner.

CA's may include additional identifiers of other syntaxes, be they DN's,
Credit card accounts, IP addresses, Wampums, Foma, or Pantaloons.  UAs
may interpret and/or display such additional identifier syntaxes.

> - That identifier has some semantics. Someone creating a cert must follow
> certain rules about the parts of the RFC 822 name. Someone receiving the
> cert can be sure of certain things about the RFC 822 name and use that
> information to make further inferences about the signer.

The above statement is true for ANY identifier, regardless of syntax.
 
> I'd like to request that you (John) write these out as a specific wording
> changes for the certs draft so that we can talk about a specific, static
> proposal.

Well, we have multiple issues with dependencies between them.  Can we
get agreement on JGM1 through JGM3 before tackling ISSUE2?

> I'd especially like the wording on the semantics of the RFC 822
> addresses, since this was a point of concern from other people on the list
> and one that was not clear in your early posts.

An addr-spec is a specific Internet identifier that contains both a
locally
interpreted string followed by the at-sign character ("@", ASCII value
64)
followed by an Internet domain. The locally interpreted string is either
a
quoted-string or a dot-atom. If the string can be represented as a
dot-atom
(that is, it contains no characters other than atext characters or "."
surrounded by atext characters), then the dot-atom form SHOULD be used
and the
quoted-string form SHOULD NOT be used. Comments and folding whitespace
SHOULD
NOT be used around the "@" in the addr-spec.

addr-spec       =       local-part "@" domain

local-part      =       dot-atom / quoted-string / obs-local-part

domain          =       dot-atom / domain-literal / obs-domain

domain-literal  =       [CFWS]
                        "[" *([FWS] (dtext / quoted-pair)) [FWS] "]"
                        [CFWS]

dtext           =       NO-WS-CTL /     ; Non-white-space controls

                        %d33-90 /       ; The rest of the US-ASCII
                        %d94-127        ;  characters not including "[",
                                        ;  "]", or "\"

The domain portion is a fully qualified identifier for an Internet host.
For
example, in a mailbox address, it is the host on which the particular
mailbox
resides. In the dot-atom form, this is interpreted as an Internet domain
name
(either a host name or a mail exchanger name) as described in [DNS]. In
the
domain-literal form, the domain is interpreted as the literal Internet
address
of the particular host. In both cases, how addressing is used and how
messages
are transported to a particular host is covered in the mail transport
document
[SMTP]. These mechanisms are outside of the scope of this document.

The local-part portion is a domain dependent string. In addresses, it is
simply
interpreted on the particular host as a name of a particular mailbox. In
a
message identifier (described in section 3.6.4), it is an identifying
string
that is unique to a message generated on a particular host. It is
otherwise
uninterpreted in this standard.

[The reference to section 3.6.4 is to the document
draft-ietf-drums-msg-fmt-03.txt]

Date: Tue, 06 Jan 1998 16:03:53 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: The address-in-certs issue
Sender: [email-masked]

Nice to see you back from vacation, John.

At 02:33 PM 1/6/98 -0800, John Gardiner Myers wrote:
>In the message to which I was replying, Paul Hoffman was disagreeing
>with this very point.  He was espousing a position that it was OK for
>the S/MIME specification to allow a conforming CA to issue certs
>containing only DN's, yet allow UA's to only recognize RFC822 addresses.

I never said that. What I said was, unless we specify that this part of the
cert spec relates specifically to Internet mail, requiring RFC 822
addresses with no semantics is no more useful than requiring any old string
with no semantics.

John, your argument has changed over the thread, and where you are now is
much clearer than when you started off. At the risk of pissing you off even
further, let me try to summarize what I believe you are now saying:
- We should define the cert contents for certs passed in S/MIME messages
over Internet mail
- In these certs, the identifier must be an RFC 822 name, and cannot be a
DN (subject name null, subjectAltName must have at least an RFC 822
identifier in it)
- That identifier has some semantics. Someone creating a cert must follow
certain rules about the parts of the RFC 822 name. Someone receiving the
cert can be sure of certain things about the RFC 822 name and use that
information to make further inferences about the signer.

I'd like to request that you (John) write these out as a specific wording
changes for the certs draft so that we can talk about a specific, static
proposal. I'd especially like the wording on the semantics of the RFC 822
addresses, since this was a point of concern from other people on the list
and one that was not clear in your early posts.

In general, I would prefer the S/MIME spec to have as little mail-specific
text in it as possible, but am happy if we go the other way as long as we
do it carefully. 

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Darren Harter" <[email-masked]>
To: "Darren Harter" <[email-masked]>, <[email-masked]>, "John Pawling" <[email-masked]>
Subject: Re: S/MIME v2 Compatibility - was CMS Critical flag for signedattributes? -Reply
Date: Tue, 6 Jan 1998 19:27:14 -0000
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0031_01BD1AD9.180D6B80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

John,

Sounds to me like we need a WG that will look at true secure messaging -
i.e. that which does not rely, depend or dictate any existing carrier or
encapsulation mechanism, and does consider interoperability issues like
those presented by Tim Dean at the Washington meeting.

Darren

-----Original Message-----
From: John Pawling <[email-masked]>
To: Darren Harter <[email-masked]>; [email-masked]
<[email-masked]>; [email-masked] <[email-masked]>
Date: Tuesday, January 06, 1998 06:52
Subject: Re: S/MIME v2 Compatibility - was CMS Critical flag for
signedattributes? -Reply

>Darren wrote:
>>The reliance on MIME encodings that a meant, was the fact that data
>>has to be MIME encoded before it is protected using S/MIME, not that
>>the form that gets finally sent out is dependant in MIME - or am I
>>reading the specs incorrectly?
>
>You are reading the S/MIME v3 Message Spec and ESS spec correctly.  Note
>that specs could be written for another application environment (such as
>X.400) that could use the CMS objects without MIME encapsulation (but that
>is the topic for a work group other than the S/MIME WG).
>

------=_NextPart_000_0031_01BD1AD9.180D6B80
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0031_01BD1AD9.180D6B80--

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Re: The address-in-certs issue
Date: Tue, 06 Jan 1998 14:33:11 -0800
Organization: Netscape Communications Corporation
Lines: 38
NNTP-Posting-Host: 205.217.229.208
Sender: [email-masked]

David P. Kemp wrote:
> 
> > From: John Gardiner Myers <[email-masked]>
> > So, we have clearly demonstrated a need to explicitly define a set of
> > mandatory minimum identifier syntaxes.
> 
> or, the equally meaningful "we have clearly demonstrated that
> the sun rises every day".

In the message to which I was replying, Paul Hoffman was disagreeing
with this very point.  He was espousing a position that it was OK for
the S/MIME specification to allow a conforming CA to issue certs
containing only DN's, yet allow UA's to only recognize RFC822 addresses.

> Does anyone disagree that the mandatory-to-support identifier syntax
> for S/MIME user agents includes { Name, rfc822Name }?   (That is, an
> S/MIME-compliant MUA must be capable of displaying, at a minimum, the
> subject distinguished name, as well as two of the nine defined forms of
> GeneralName.)

Yes, I disagree.  First, it is necessary to constrain CA's such that
each cert they issue must contain at least one identifier with a syntax
in the mandatory minimum set.  Otherwise, certs they issue may not
interoperate with UA's conforming to the mandatory-to-support identifier
syntax requirement.

(This "mandatory minimum" requirement could be more complex than
CA-must-include-one, UA-must-support-all, but we'll simplify for now.)

I agree that for the Internet Mail domain, the set contains no more
elements than { Name, rfc822Name }, but I further believe that in this
domain the set contains exactly { rfc822Name }.  This position appears
to be shared by Jim Schaad, and I know it to be shared by other mail
vendors.

In domains other than Internet Mail, the set may well be completely
disjoint from { Name, rfc822Name }.  Such domains would need to profile
the S/MIME specification.

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Re: The address-in-certs issue
Date: Tue, 06 Jan 1998 14:08:15 -0800
Organization: Netscape Communications Corporation
Lines: 27
NNTP-Posting-Host: 205.217.229.208
Sender: [email-masked]

Bill Barry wrote:
> Sorting out the above statement I get (and agree with) these goals:
> 
> Goal 1 - Long lived stable identities/certs (i.e. like a S.S. number)

I certainly don't want to advertise my S.S. number or anything as stable
as my S.S. number on the net, for privacy reasons.

> IMHO the dichotomy is clear; we cannot achieve all goals at the same time.
> It is the issue of adding and/or editing addresses that would result in
> an unstable certificate. I add my voice to those proposing that the
> certificate not contain any address.

If you put anything that can change, such as a common name, into a cert,
you get an "unstable" certificate.
 
> If we had some other form of permanent ID in our cyber world then I
> would vote that we put it in the cert.  Ideally, a recipient would
> only need one certificate for their entire life.

What would you suggest?  Employers change relatively frequently. 
Residence addresses change frequently.  State/country of residence
changes occasionally.  Even common names change occasionally, especially
for women.

Anything that is hard to change intentionally, such as a S.S. number, is
problemetic for privacy reasons.

Date: Tue, 6 Jan 1998 16:21:26 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: The address-in-certs issue
Sender: [email-masked]

> From: John Gardiner Myers <[email-masked]>
>
>    [Three pages of mixed undisputed fact, irrelevancy, and
>      unmeasurable and unsubstantiated assertion, leading up to ..]
>
> So, we have clearly demonstrated a need to explicitly define a set of
> mandatory minimum identifier syntaxes. 

or, the equally meaningful "we have clearly demonstrated that
the sun rises every day".

Does anyone disagree that the mandatory-to-support identifier syntax
for S/MIME user agents includes { Name, rfc822Name }?   (That is, an
S/MIME-compliant MUA must be capable of displaying, at a minimum, the
subject distinguished name, as well as two of the nine defined forms of
GeneralName.)

All the rest is policy, not interoperability.

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Re: The address-in-certs issue
Date: Tue, 06 Jan 1998 13:00:31 -0800
Organization: Netscape Communications Corporation
Lines: 100
NNTP-Posting-Host: 205.217.229.208
Sender: [email-masked]

David P. Kemp wrote:
> 
> > From: John Gardiner Myers <[email-masked]>
> > Date: Fri, 19 Dec 1997 14:50:07 -0800
> >
> > David P. Kemp wrote:
> > > Reasons include 1) the more information that goes into a cert, the shorter
> > > the expected lifetime,
> >
> > Then take out other information.  RFC822 identities are what are used in
> > Internet Mail, and if you're securing Internet Mail objects, those are
> > the identities you need to certify.
> 
>   --- and ---
> 
> > From: John Gardiner Myers <[email-masked]>
> > Date: Mon, 22 Dec 1997 18:09:51 -0800
> >
> > Even simpler, I could have a certificate with both
> > 12345,[email-masked] and "John Gardiner Myers"@netscape.com.
> 
> Is it too much to ask that your arguments at least be self-consistent?
> You can't simultaneously take extra information out of and put extra
> information into a certificate.

I don't see any inconsistency.  In the second quote, I transformed an
example that you posed that had two pieces of information into an
example that had two pieces of information.  No extra information was
put into the certificate, I merely changed the syntax of one piece of
information.

> If we agree that relatively long-lived stable identities are a goal,
> and that accommodating environments where mail can reach a given user
> by multiple and occasionally or frequently changing addresses is also
> a goal, then we can't reach both goals by putting all the delivery
> addresses into a cert.

Then don't put all the delivery addresses into the cert.

You seem to have an assumption that DN-syntax identifiers are inherently
more "stable" than all RFC822-syntax identifiers.  This is not the
case.  Some RFC822-syntax identifiers are temporary.  Some are not. 
Some RFC822-syntax addresses are more stable than some DN-syntax
identifiers.

> > Paul needs to send you an important, private message.  Paul is a busy
> > person.  He's the co-founder of an industry consortium for Internet
> > mail.  Having much familiarity with Internet mail, he uses the same,
> > simple, interface he has always used for informing his UA to whom the
> > mail is intended: he types "[email-masked]" into the To: field of
> > his compose window.
> 
> Paul is a busy person, so he types "kemp" into his compose window.  His
> MUA has a database of certificates, each of which has a subject name
> bound to a public key.  The list of subjects matching "kemp" pops up,
> and Paul clicks on the correct one.  If there is only one match, the
> MUA displays the full name and either asks for confirmation if Paul has
> previously checked the "always ask" option, or proceeds if the option is
> unchecked.

The attacker happens to have a legal name of "David P. Kemp".  In
addition to associating the attacker's identity with the
[email-masked] entry in Paul's address book, he also removes your
certificate from the MUA's database.  When the MUA finds only one match,
the MUA displays the full name and asks for confirmation.  Paul seeing a
common name matching yours checks "ok".  The message is encrypted with
the attacker's public key.

Proponents of DN's seem to have an inexplicable fascination with using
common names for identifiers.  This besides the fact that common names
fail two requirements of identifiers: common names are neither unique
nor unchanging.

> > That is because Paul, being a busy person, doesn't have the time to
> > parse the DN for every message he receives.  Being an Internet mail kind
> > of person, he thinks in terms of RFC822 syntax.
> >   [...]
> > Most Internet mail users can't distinguish a DN from base64-encoded
> > line noise.
> 
> That is a remarkably insulting statement - I'm glad you said it about
> Paul and not me :-).  I give even computer-using mothers-in-law* credit
> for being able to recognize "O=imc.org, CN=Paul Hoffman" as easily as
> they would "Paul Hoffman / IMC <[email-masked]>".

I don't see why you consider it insulting.  Heck, I don't even have time
to do the mental gear-switching needed to parse two different syntaxes
for every message I read.

You must have a remarkably technically inclined mother-in-law.  Never
mind the fact that you give her an atypically simplistic DN.

> And I give credit to MUA designers to be able to present "Paul Hoffman"
> to the user given either form as input, and allow the curious to
> explicitly seek further details.

If the UA only presents "Paul Hoffman", tossing the information needed
to distinguish that particular "Paul Hoffman" from other things with a
legal name of "Paul Hoffman", then there is a security problem--some
other "Paul Hoffman" could masquerade as [email-masked].

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Re: The address-in-certs issue
Date: Tue, 06 Jan 1998 12:27:35 -0800
Organization: Netscape Communications Corporation
Lines: 102
NNTP-Posting-Host: 205.217.229.208
Sender: [email-masked]

Elliott N Ginsburg wrote:
> First of all, all identifers are strings; there should be no problem
> presenting them.

This is not the case.  In PKIX, each identifier type has its own
arbitrary ASN.1 syntax.  A UA cannot display an identifier without
knowing how to parse the ASN.1 and convert it into something that is
presentable.

> Secondly, I want to choose my identity, how I am
> represented to the world for purposes of trust.

Well, heck, I'd like to choose my identity as being "the Bill Gates who
founded Microsoft" and represent that to a couple of banks for purposes
of trust.

Sorry, but interoperability requires that there be constraints on the
identities that you represent to the world.

> One of my email accounts is
> "[email-masked]", and this conveys nothing to recipients about who sent
> this message. I also have mail forwarder accounts with yet other cryptic
> addresses.

So pick a RFC822 identity which conveys some real information and get
that put into your cert.  Even better, put that in your From: address.

> I suggest again that we allow, or even encourage the use of RFC822
> identifiers, but don't require them or force the UA to validate them
> against the From address. When I receive a signed message, and am informed
> that the signature is valid, I want to see whatever info I can about who
> the signer was.

Any UI which normally states only that "the signature is valid" without
either displaying or checking the identity is misleading.  Users will
not normally take extra action to inquire about the signature, the
information needs to always be displayed in a simple, obvious way or it
is useless.

> 
> Elliott Ginsburg
> 
> At 03:52 PM 12/22/97 -0800, John Gardiner Myers wrote:
> >Paul Hoffman / IMC wrote:
> >>
> >> At 12:58 PM 12/22/97 -0800, John Gardiner Myers wrote:
> >> >Just like S/MIME needs a mandatory-to-implement cipher suite, it needs
> >> >some sort of mandatory identity syntax.  Otherwise it is likely that
> >> >conforming implementations will fail to interoperate.
> >>
> >> I'm not sure if I agree here (and I really mean "not sure"). When checking
> >> the validity of a signature in S/MIME, the receiving agent looks at a
> >> certificate from a mutually-trusted CA. I think that there is an assumption
> >> that maybe we need to state more clearly in the document: If you trust the
> >> CA, you also trust the CA's method(s) of identifying users. A CA might use
> >> RFC822 addressess, might use DNs, or might use both (or others).
> >
> >If a CA only uses DNs and the receiving UA is only able to present
> >RFC822 addresses in a way that is comprehensible to the receiving
> >end-user, then the CA and the UA have failed to interoperate.  If both
> >conform to the S/MIME specification, then the S/MIME specification has
> >failed.
> >
> >Having a user indicate to a UA that a given CA is trusted does not
> >magically give that UA the ability to present whatever identity syntaxes
> >that CA chooses to put in its certificaes.   Different identity syntaxes
> >require different code.
> >
> >> Putting it a different way, you must accept whatever your CA gives you for
> >> an identifier when validating a signature. If you are an RFC822 kind of
> >> program, you can still use a CA that uses other blobs for the identifiers.
> >
> >In such an appplication, a CA that does not use RFC822-syntax
> >identifiers is not appropriate, and the standard for such an application
> >needs to state that such CAs do not conform.
> >
> >> However, you won't be able to do much with those blobs after validating a
> >> signature other than storing them for future reference.
> >
> >Then what's the point of having a CA involved in the first place?
> >
> >> [...] but I don't see a need to force
> >> everyone to use a single identifier if any identifier will work as long as
> >> you have a mutual agreement with your CA as to what the identifiers mean.
> >
> >Likewise, any cipher suite will work as long as you have a mutual
> >agreement between the sender and recipient as to which to use.  Such an
> >approach does not lead to interoperability.
> >
> >> However, elevating it to a MUST seems to stymie some potential uses of
> >> S/MIME without adding value that isn't already added in the inherent trust
> >> model between users and their CAs.
> >
> >Those uses can profile S/MIME to fit their needs.  For example, a
> >commerce application could replace the RFC822 identity requirement with
> >a credit card identity for a purchase request.  Such an application
> >doesn't have to interoperate with Internet mail--the only useful sender
> >CAs and recipient UA's are those which understand credit cards.
> >
> >
> >

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Re: The address-in-certs issue
Date: Tue, 06 Jan 1998 12:06:46 -0800
Organization: Netscape Communications Corporation
Lines: 207
NNTP-Posting-Host: 205.217.229.208
Sender: [email-masked]

Paul Hoffman / IMC wrote:
> At 08:01 PM 12/22/97 -0800, John Gardiner Myers wrote:
> >> >If a CA only uses DNs and the receiving UA is only able to present
> >> >RFC822 addresses in a way that is comprehensible to the receiving
> >> >end-user, then the CA and the UA have failed to interoperate.
> >>
> >> True, but I assert that that failure is due to the presentation problem,
> >> not to the protocol.
> >
> >Huh?  If the CA and receiving UA fail to interoperate, at least one of
> >the following has occurred:
> >
> >A) The CA is non-conforming
> >B) The UA is non-conforming
> >C) Something in the path between the CA and UA is broken.
> >D) The S/MIME standard is broken.
> >
> >For purposes of my statement above, we can rule out (C).  Which of the
> >remaining is it?
> 
> OK, I misworded my answer. Instead of saying "True", I should have said
> "False". The UA and CA can interoperate even if the UA can't present RFC822
> addresses in a way that is comprehensible to the receiving end-user. It's
> the UA and the end user that are not interoperating. That's out of scope.

That is hardly out of scope.  If the standard failed to give the UA
enough information/constraints on its input to allow the UA to present
intelligible information to the user, then the standard has failed. 
UA's are not magic, they cannot make silk out of a pig's ear.

> >The format of the identifier controls how the UA has to
> >present it, and it controls how humans are able to interpret it.
> 
> Yes to the former, no to the latter. Humans interpret it as we damn well
> please. Saying one kind of opaque string is more understandable than
> another, particularly when you are guaranteed that an intelligent piece of
> software will be displaying it, is silly.

RFC addr-specs are not opaque in the sense that binary blobs are
opaque.  And in an e-mail context, they are far more intelligible to
humans than DN's.

If the software does not have knowledge of what a thing is, it cannot be
intelligent about displaying it.

> >If you can't do anything with the identity, what's the point in having
> >it assured?
> 
> You have already said you can't do anything reliable with
> "[email-masked]". It may not be a recipient for a future message, so
> putting it in an address book is wrong. Comparing it to unauthenticated
> information that came with the signed message is unsafe so should not be
> done. What else were you planning on doing with it?

I have described in detail what one can do with something like
"[email-masked]".

> >It tells a user that the identity is something at "blobbo.com", and that
> >the user can apply some external knowledge concerning the identifier
> >policies of "blobbo.com" to get further knowledge of the identity.
> 
> Ah, I see where we are differing here. You are assuming that some
> infrastructure will exist to aid users in getting further knowledge. You
> hadn't said this before. Such an infrastructure could give further
> knowledge about identifier policies for names in any format.

Information exists from external context.  This is the case for ANY
identifier syntax, not just RFC822 identifier syntax.  This external
context is in general social, not electronic.

> >An RFC822 name means exactly what the entity that controls the domain
> >part wants it to mean, no more, no less.  The domain can choose to make
> >the name usable as a delivery address or it could not.
> 
> ...if the domain even exists. You're making lots of hidden assumptions
> here, given that you already said that the identifier didn't have to be a
> deliverable address. You are now saying that the right hand side (RHS) of
> the identifier must be an existing domain name, not just a syntactically
> correct one.

The RHS must be a registered domain.  This is a semantic constraint the
standards place on the RFC822 syntax.

> I think you're also saying that it can somehow possibly
> respond to queries about LHS names at that domain.

No.  I'm saying there is typically some external context which allows
the recipient to know something about the allocation policies of the
RHS.

> Your repsonses leads to a lot of thorny questions.
> - Does the RHS need to exist? If the RHS doesn't need to exist, the user
> can't apply any external knowledge.

Yes.

> - If the RHS needs to exist, how does a disconnected user validate this? If
> he can't validate it, what should he do with the signature?

Through external knowledge.

> - Does a domain named in the RHS have to be part of some policy-emitting
> infrastructure? If not, what "external knowlege" does the user get from
> knowing only that the RHS exists?

The user may have knowledge of the RHS through some sequence of
bilateral agreements.  The user may know about the domain allocation
policies of the higher-level domains that the RHS is in.

> - If a domain named in the RHS has to be part of some policy-emitting
> infrastructure, who at the domain named in the RHS controls the policy
> emitter? Using what protocol? I admit I haven't followed all the other
> security work as closely as I would like, but I've never heard of any such
> protocol or the semantics associated with it.

Have you heard of the DNS and subdomains?  The immediate parent domain
of the RHS controls everything contained one level directly below it, so
it controls who gets that RHS.  Whoever gets that RHS controls the
policy of that RHS.

> - If the site in the RHS doesn't emit a policy, what should a user do with
> a signature that has that RHS?

Without such external information about what the identity means, the
identity is worthless.

This is basic stuff and applies to ANY identifier syntax.  If you get
something signed by "Joe Isuzu", you have gained absolutely no
information of value unless you have some external information about
what the identity "Joe Isuzu" means.

Take the identity "c=US, o=Netscape Communications, cn=John Gardiner
Myers".  Without having external knowledge of the identity-allocation
policies of "c=US" and "c=US, o=Netscape Communmications" you have no
worthwhile information about the first identity.  If you think the above
identity is equivalent to the identity of a certain carbon-based life
form you have met at various IETFs, you are simply wrong.  If that
particular carbon-based life form gets its brains splattered all over US
101, the entity "c=US, o=Netscape Communications" will ensure that some
other carbon-based life form assumes the credentials and identity of
"..., cn=John Gardiner Myers" in order to retrieve assets belonging to
that identity.

> As you can see, I'm skeptical of all of this. I think a better protocol is
> to say "UAs that trust a CA to validate signatures also must trust whatever
> identifier the CA gives it". 

Trusting the identifier and interpreting the identifier are two
different things.

> Anything else, including side-validation and
> policy finding, is way outside the scope of the document.

Certainly it is outside the scope of the document.  I'm describing the
semantics of various identifier syntaxes, so we can discuss their
applicability to our problem space.

> Telling the user "you might recognize the format of the identifier and you
> can make lots of possibly-wrong guesses based on that format" is OK, but I
> wouldn't force it on every S/MIME implementation. I'd say that instead, we
> could use RFC822 addresses as a SHOULD, and make it real clear in the spec
> exactly what semantics they *don't* convey.

All S/MIME UA's have to do is display RFC822 identifiers.  Humans have
the resources and social structures to be able to interpret them.

Is it your position to make it correspondingly clear in the spec exactly
what semantics DN's don't convey?  Frankly, I don't find it particularly
useful to spend time specifying exactly what identifiers do and don't
mean.  I find it better to specify the technical procedures for how
their assignment is delegated, and let the meanings derive from that.

> >Is it your position that other applications do not need to have
> >restrictions on identifier syntaxes?  If not, what exactly is your
> >position on mandatory minimum identifier syntaxes?
> 
> My position is that the "restrictions" on identifier syntaxes can be
> something as general as "a UTF-8 string". UAs and CAs can interoperate with
> this. UAs can display this to their human users.

You appear to be putting forward a position that interoperability
requires that all identifier syntaxes have a restriction that they be
displayable by interpreting their contents as a UTF-8 string.  If this
is so, we have gotten somewhere--you have granted that interoperability
requires at least some restriction on identifier syntaxes.

As to your particular proposal for restricting identifier syntaxes to
"displayable as a UTF-8 string", we only need to look at page 27 of
draft-ietf-pkix-ipki-part1-06.txt to dismiss it as unworkable.  One of
the identifier syntaxes defined therein is "iPAddress" whose contents
are clearly not displayable by interpreting as a UTF-8 string.  Even the
directoryName identifier syntax does not conform to your proposed
restriction.  PKIX allows an identifier type to define its own arbitrary
syntax--without knowledge of the specific name type, a UA has no chance
of being able to display the value.

So, we have clearly demonstrated a need to explicitly define a set of
mandatory minimum identifier syntaxes. 

> Making the humans
> "understand" it is difficult, but as you can see from above, it is also
> difficult for supposedly "simple" formats as well.

The process by which humans "understand" RFC822 identifiers may be
difficult to explain, but it is easy for humans to do.  Similarly, it is
difficult to explain (or replicate) how humans understand speech, but it
is easy for humans to do.

Date: Tue, 6 Jan 1998 13:53:50 -0500
To: Darren Harter <[email-masked]>, [email-masked], [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: S/MIME v2 Compatibility - was CMS Critical flag for signedattributes? -Reply
Sender: [email-masked]

All,

Darren wrote:
>I agree it does meet the requirement, as would redefining Attribute
>as Attribute ::= SEQUENCE {
>    type  ...snip...
>    critical BOOLEAN DEFAULT FALSE,
>    values   ...snip... }
>
>This would also be backwards compatible, and closer to X.509's
>way of expressing criticality ;-)

This solution does not maximize backwards compatibility because if the
attribute is critical, then the Attribute critical field would be present
(and TRUE).  This would break the S/MIME v2 agents because they are not
designed to process the critical field.  I like Phill's "list of OIDs"
solution proposed in Dave K's earlier message.

Darren wrote:
>The reliance on MIME encodings that a meant, was the fact that data
>has to be MIME encoded before it is protected using S/MIME, not that
>the form that gets finally sent out is dependant in MIME - or am I
>reading the specs incorrectly?

You are reading the S/MIME v3 Message Spec and ESS spec correctly.  Note
that specs could be written for another application environment (such as
X.400) that could use the CMS objects without MIME encapsulation (but that
is the topic for a work group other than the S/MIME WG).

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

Date: Tue, 06 Jan 1998 18:18:24 +0000
From: Darren Harter <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Comments to CMS-02 -Reply
Sender: [email-masked]

John,

>>>> John Pawling <[email-masked]> 01/06 1:09 pm >>>
>The 1997 X.509 Recommendation defines issuerAltName as
>GeneralNames, not GeneralName.

Sorry John.  Perhaps that will teach me to check the spec
before replying ;-)

Darren

Date: Tue, 06 Jan 1998 18:11:24 +0000
From: Darren Harter <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: S/MIME v2 Compatibility - was CMS Critical flag for signed attributes? -Reply
Sender: [email-masked]

John,

>>> John Pawling <[email-masked]> 01/06 1:33 pm >>>
>I use the term "backwards compatibility" to mean that
>it is possible to select the options and algorithms when
>constructing an S/MIME v3 message such that S/MIME v2 agents can
>successfully process that message, and vice versa.  I did not mean
>to imply in my previous message that "backwards compatibility" is
>a silver bullet to shoot down any new proposal.  However, when we
>debate new proposals, I believe that we must consider the
>backwards compatibility issue and design the specs to accommodate
>that feature when possible.  I believe that we have done an
>excellent job so far of adding new features without breaking
>backward compatibility.

I agree completely with you on this.  So long as we keep the "when
possible" in mind, and don't get blinked we will get specs that
will be acceptable in all our environments.

>Darren wrote:
>>For example,  why is there no extension mechanism, like X.509s, in
>>SignedData?  

>IMHO, Phillip's proposal to define an attribute consisting of a
>SEQUENCE of attribute-like structures each of which includes a
>crticality flag meets that requirement.

I agree it does meet the requirement, as would redefining Attribute
as Attribute ::= SEQUENCE {
    type  ...snip...
    critical BOOLEAN DEFAULT FALSE,
    values   ...snip... }

This would also be backwards compatible, and closer to X.509's
way of expressing criticality ;-)

>Darren wrote:
>>Let's change the name to SIM (Secure Internet Mail) and get rid
> of the reliance on MIME encodings and allow the passing of
> arbitrary binary data.
>
>That contradicts the S/MIME WG charter which states that the WG
>will "define MIME encapsulation of digitally signed and encrypted
>objects whose format is based on PKCS #7".

The reliance on MIME encodings that a meant, was the fact that data
has to be MIME encoded before it is protected using S/MIME, not that
the form that gets finally sent out is dependant in MIME - or am I
reading the specs incorrectly?

Darren

Date: Tue, 6 Jan 1998 10:11:19 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: CMS Critical flag for signed attributes?
Sender: [email-masked]

All,

That sounds good to me.

- John Pawling

At 09:14 AM 1/6/98 -0500, David P. Kemp wrote:
>
>After some private discussions with Phill, I agree with his proposal
>to create a single S/MIME attribute which v3 clients must always treat
>as critical.  That attribute would have syntax SEQUENCE OF OBJECT IDENTIFIER
>and would be a list of other attributes which are to be treated as
>critical (must be understood/supported or the message signature is
>not considered valid) for that message.
>
>This would have no mandatory effect on v2 user agents, but does enable
>the enforcement of criticality in v3, and appears to be the simplest
>fully compatible method of doing so.
>
>Dave K.
>
>
>
>> From: [email-masked] (John Pawling)
>> 
>> All,
>> 
>> I agree with Phillip's proposal:
>> 
>> >One entirely backwards compatible method of doing this would be to
>> >create
>> >an OID whose attributes would simply be a list of critical extensions.
>> >S/MIME v3 clients would be required to understand the OID semantics.
>

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-ess-01.txt
Date: Tue, 06 Jan 1998 09:35:49 -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-01.txt
	Pages		: 25
	Date		: 05-Jan-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 2 [SMIME2] and
S/MIME version 3 [SMIME3]. Most of this document can be used with S/MIME
version 2, which relies on PKCS #7 version 1.5 [PKCS7-1.5]. A small number
of the services require mechanisms described in Cryptographic Message
Syntax [CMS]. The format of the messages are described in ASN.1:1988
[ASN1-1988] with the modification that BMPString and UniversalString
types from ASN.1:1994 [ASN1-1994] are 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-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-smime-ess-01.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-01.txt".
	
NOTE:	The mail server at ds.internic.net 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-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-ess-01.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 6 Jan 1998 09:14:45 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: CMS Critical flag for signed attributes?
Sender: [email-masked]

After some private discussions with Phill, I agree with his proposal
to create a single S/MIME attribute which v3 clients must always treat
as critical.  That attribute would have syntax SEQUENCE OF OBJECT IDENTIFIER
and would be a list of other attributes which are to be treated as
critical (must be understood/supported or the message signature is
not considered valid) for that message.

This would have no mandatory effect on v2 user agents, but does enable
the enforcement of criticality in v3, and appears to be the simplest
fully compatible method of doing so.

Dave K.

> From: [email-masked] (John Pawling)
> 
> All,
> 
> I agree with Phillip's proposal:
> 
> >One entirely backwards compatible method of doing this would be to
> >create
> >an OID whose attributes would simply be a list of critical extensions.
> >S/MIME v3 clients would be required to understand the OID semantics.

Date: Tue, 6 Jan 1998 08:33:26 -0500
To: "Darren Harter" <[email-masked]>, "ietf-smime" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: S/MIME v2 Compatibility - was CMS Critical flag for signed attributes?
Sender: [email-masked]

Darren,

The goal of the S/MIME WG is to design the S/MIME v3 set of specs such that
they meet the secure e-mail messaging requirements validated by the WG while
maximizing backwards compatibility with the significant installed base of
S/MIME v2 products.  I use the term "backwards compatibility" to mean that
it is possible to select the options and algorithms when constructing an
S/MIME v3 message such that S/MIME v2 agents can successfully process that
message, and vice versa.  I did not mean to imply in my previous message
that "backwards compatibility" is a silver bullet to shoot down any new
proposal.  However, when we debate new proposals, I believe that we must
consider the backwards compatibility issue and design the specs to
accommodate that feature when possible.  I believe that we have done an
excellent job so far of adding new features without breaking backward
compatibility.

Darren wrote:
>For example,  why is there no extension mechanism, like X.509s, in
>SignedData?  

IMHO, Phillip's proposal to define an attribute consisting of a SEQUENCE of
attribute-like structures each of which includes a crticality flag meets
that requirement.

Darren wrote:
>Let's change the name to SIM (Secure Internet Mail) and get rid of the
reliance on
>MIME encodings and allow the passing of arbitrary binary data.

That contradicts the S/MIME WG charter which states that the WG will "define
MIME encapsulation of digitally signed and encrypted objects whose format is
based on PKCS #7".

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

Date: Tue, 6 Jan 1998 08:09:25 -0500
To: "Darren Harter" <[email-masked]>, <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Comments to CMS-02
Sender: [email-masked]

Darren,

The 1997 X.509 Recommendation defines issuerAltName as GeneralNames, not
GeneralName.  GeneralNames is a SEQUENCE of GeneralName.  Therefore, I stand
by my original proposal to change IssuerAndSerialNumber as follows:

IssuerAndSerialNumber ::= SEQUENCE {
  issuer        Name,
  serialNumber  SerialNumber
  issuerAltName [0] IMPLICIT GeneralNames OPTIONAL}

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

From: "Darren Harter" <[email-masked]>
To: <[email-masked]>, "John Pawling" <[email-masked]>
Subject: Re: Comments to CMS-02
Date: Tue, 6 Jan 1998 08:19:58 -0000
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0008_01BD1A7B.E2434180
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

-----Original Message-----
From: John Pawling <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Monday, January 05, 1998 07:24
Subject: Comments to CMS-02

>IssuerAndSerialNumber should be changed as follows:
>
>IssuerAndSerialNumber ::= SEQUENCE {
>  issuer        Name,
>  serialNumber  SerialNumber
>  issuerAltName [0] IMPLICIT GeneralNames OPTIONAL}
>
>This would be backwards compatible with PKCS #7, v1.5.
>

John,

Excellent point, but please bear in mind the following...

The issuerAltName extension is defined as a GeneralName not GeneralNames -
i.e. there is only one of them.  Unfortunately, if we simply change the
GeneralNames to a GeneralName, the IMPLICIT key word in the above would be
ignored by the ASN.1 compiler because of the following:

The GeneralName structure is a CHOICE, and under BER and DER all CHOICE
constructs that have additional tagging are tagged as EXPLICIT regardless of
any explicit IMPLICIT or EXPLICIT key word. (As in X.509's
AuthorityKeyIdentifier extension)

IMHO, I believe the following would make matching against issuerAltName
easier to implement:

IssuerAndSerialNumber ::= SEQUENCE {
  issuer        Name,
  serialNumber  SerialNumber
  issuerAltName [0] EXPLICIT GeneralName OPTIONAL}
                        -- EXPLICIT keyword is informational as GeneralName
is always
                        -- encoded explicitly.

Darren

------=_NextPart_000_0008_01BD1A7B.E2434180
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0008_01BD1A7B.E2434180--

From: "Darren Harter" <[email-masked]>
To: "ietf-smime" <[email-masked]>, "John Pawling" <[email-masked]>
Subject: S/MIME v2 Compatibility - was CMS Critical flag for signed attributes?
Date: Mon, 5 Jan 1998 19:13:26 -0000
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0021_01BD1A0E.01E9B640
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

-----Original Message-----
From: John Pawling <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>; ietf-smime
<[email-masked]>
Date: Monday, January 05, 1998 05:36
Subject: Re: CMS Critical flag for signed attributes?

>All,
>
>One of the primary requirements of the S/MIME v3 set of specs is to
maintain
>backwards compatibility with the S/MIME v2 set of specs
>
> snip....

John,

Let me stick my head above the parapet and be shot at ........

Why is a primary requirement of S/MIME v3 to be backwards compatible with
S/MIME v2?  Surely the remit is to design a secure messaging protocol that
meets the majority of users requirements. This may or may not mean backwards
compatibility with S/MIME v2

If a firm requirement exists that results in a proposed enhancement to the
existing
specs that would make them incompatible with S/MIME v2, then that
enhancement must
never be thrown out just because its not backwards compatible.  Surely this
is the whole
point of making S/MIME an IETF standard.  If we find that we have
requirements that the
original S/MIME designers didn't foresee, we should not be constrained by a
design that
did not consider the requirement in the first place.

For example,  why is there no extension mechanism, like X.509s, in
SignedData?  Let's
change the name to SIM (Secure Internet Mail) and get rid of the reliance on
MIME
encodings and allow the passing of arbitrary binary data.

Time to duck I think ........

Darren

------=_NextPart_000_0021_01BD1A0E.01E9B640
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0021_01BD1A0E.01E9B640--

Date: Mon, 05 Jan 1998 16:49:44 -0500
To: Phillip Hallam-Baker <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: CMS Critical flag for signed attributes?
Cc: ietf-smime <[email-masked]>
Sender: [email-masked]

Phill:

By your definition, I do not think that any of the attributes that have
been defined would be marked critical.

Russ

At 12:25 PM 12/31/97 -0800, Phillip Hallam-Baker wrote:
>Should there be a criticallity flag for signed attributes?
>
>The application I am thiniking of is limiting an employees signing
>authority inside a company. An obvious way to do this would be to have
>an OID for the signed attribute 'this message does not constitute an
>offer or acceptance of a contract'.
>
>The problem is forcing the client to bring this (or a like) OID to the
>attention of the reader.
>
>It seems to me we may just need a critical flag just like there is in
>the X.509v3 certificate. If the critical bit is set and the client does
>not understand the semantics of the attribute a client is required to
>inform the user of the fact.
>
>Alternatively one could suggest making all extensions critical in which
>case I am sure I can think up an example of a need to flag something
>non-critical!
>
>
>		Phill
>

Date: Mon, 05 Jan 1998 14:52:52 -0500
From: Phillip Hallam-Baker <[email-masked]>
Organization: VeriSign Inc.
To: ietf-smime <[email-masked]>
Subject: Re: CMS Critical flag for signed attributes?
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msD89AE23FEE583A45214770F2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> The other problem is that it does not address the four corners issue.
> The reason certificate policies were largely abandoned as a means of
> specifying the criteria for issuing a certificate was that they
> might not be binding in court. As Michael Baum points out, a court
> might decide that they are not even admissible. Courts are likely
> to decide to restrict their debate to the 'four corners' of the
> document in dispute.

As Warwick Ford just pointed out to me. The 'certificate policies'
I am referring to here are the old style PEM/RFC 1442 scheme of
Policy Certificates. This is not the same as X.509v3 Certificate
Policies which *are* a good idea but unfortunately happen to have
a confusingly similar name :-(

		Phill
--------------msD89AE23FEE583A45214770F2
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------msD89AE23FEE583A45214770F2--

Date: Mon, 5 Jan 1998 13:54:47 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Comments to CMS-02
Sender: [email-masked]

All,

IMHO, Russ has done a wonderful job of updating the CMS I-D based on the
decisions of the group.  I have a few comments to the CMS-02 I-D:

1) Sec 3, last para: I believe that this paragraph describing "external
signatures" should be moved to Sec 5.1, SignedData contentInfo description.
That is the only use of ContentInfo to which the "external signatures"
paragraph applies.

2) Sec 6, bullet 3: Please delete "the originator and" from the following:
"3. For the originator and each recipient, the encrypted content-encryption
key and other recipient-specific information are collected into a
RecipientInfo value, defined in Section 6.2."  The 10 Dec 97 S/MIME WG
decided that the requirement for the inclusion of a copy of the
content encryption key encrypted for the originator in an envelopedData
object must not be included in the CMS I-D, but that it must be included in
the S/MIME v3 Message Specification as a SHOULD requirement.

3) Sec 6.2, RecipientInfo originatorCert description:  Please add "This
field should be included when the recipientInfo keyEncryptionAlgorithm field
indicates a key agreement algorithm and the originator's certificate is
omitted from the envelopedData originatorInfo field (i.e. the originator's
public key material is required as part of the process to decrypt the
encryptedKey, but the originator's certificate is not included in the
envelopedData object)." 

4) Sec 9.7, IssuerAndSerialNumber. The PKIX X.509 Cert and CRL Profile
allows X.509 Certs to include an empty sequence as the Issuer Name and a
IssuerAltName extension which may (or may not) contain a Name form.  The
current CMS IssuerAndSerialNumber does not include sufficient flexibility to
uniquely identify X.509 certs that use non-Name IssuerAltName forms instead
of the Issuer Name.  If the S/MIME v3 Certificate Handling spec allows empty
Issuer Names and non-Name IssuerAltName forms, then I believe that
IssuerAndSerialNumber should be changed as follows:

IssuerAndSerialNumber ::= SEQUENCE {
  issuer        Name,
  serialNumber  SerialNumber
  issuerAltName [0] IMPLICIT GeneralNames OPTIONAL}

This would be backwards compatible with PKCS #7, v1.5.

5) If comment 4 is accepted, then the signedData signerInfo version
description should be changed to state that the version shall be 1 if the
issuer Name is used and issuerAltName is absent.  If the issuerAltName is
present, then the version shall be 2.  Similar changes would be needed for
the recipientInfo version and originatorCert descriptions.

6) References: Please delete the references to PKCS #6 and PKCS #9.

7) References: Please change PKCS #7 to match that in the ESS I-D.

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

Date: Mon, 5 Jan 1998 12:51:06 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: CMS Critical flag for signed attributes?
Sender: [email-masked]

----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 67

> From: Phillip Hallam-Baker <[email-masked]>
> 
> Jim Schaad (Exchange) wrote:
> 
> > I would strongly disagree that the place to put this is in the CMS or
> > S/MIME specifications.  This is the type of statement which belongs in
> > the Certificate Policy statment for the certificate itself and not on
> > individual signatures.  I don't see a case where you would have some
> > signatures from a person being binding and some not binding.  (What
> > happens if the signer forgets to set the bit, does it then become
> > binding on the corperation?)
> 
> The problem with this approach is that it means a person must have
> a different certificate for each privillege level they have.
> 
> I am anticipating disclaimers of the form 'the value of any contract
> agreement entered into under this message is less than $1000'. I 
> would expect an automated 'contract box' to accept input in the
> form of signed S/MIME messages, consult some corporate database of
> project budgets and possibly authorize some small value contracts
> automatically. Doing this requires either that we solve the AI
> problem and parse the contract or we find some other method of
> limiting the exposure due to such a device.

If we accept that the AI problem of general message parsing has not
been solved (and I believe we all do), then you are correct: we must
use some other method of representing such disclaimers in a structured,
machine-parsable format.

One possible "other method" is for S/MIME (CMS) to define it's own
structure for sender-signed attributes.

Another "other method" is to reuse a signed attribute structure which has
already been designed, debated, and standardized within X.509.

I agree with Jim that we should be pursuing the second approach, rather
than the first.  Using the existing X.509 signed attribute structure
has the following significant advantages over the modify-CMS proposal:

 a) it is not S/MIME-specific, and
 b) it is not limited to sender-generated disclaimers of the form:
     "I authorize myself to obligate the company for up to $1000".

Using a CMS signed attribute in conjunction with a corporate database
of project budgets is one possible scenario, but why choose a mechanism
limits you to just that one usage model.  Using X.509 signed attributes
does not preclude the use of online authorization databases, but it
also allows the same mechanism to be used for public-key-based
(offline) authorization.

The design rule should be: don't create a protocol-specific and
usage-model-specific mechanism when a non-protocol-specific, general
purpose, standardized mechanism already exists.

> The problem with this [Jim's] approach is that it means a person must
> have a different certificate for each privillege level they have.

The reason I deliberately used the phrase "X.509 signed attribute"
instead of "attribute certificate" is to get around this notion that
"certificates" are somehow a scarce commodity.  They aren't.  For the
sender-generated $1000 disclaimer example, they can be generated on the
fly just as CMS-signed-attributes would be.

Regards,
Dave K.
----------
X-Sun-Data-Type: x-pkcs7-signature
X-Sun-Data-Name: S/MIME Cryptographic Signature
X-Sun-Encoding-Info: base64
Content-Disposition: attachment; filename="smime.p7s"
X-Sun-Content-Lines: 33

Date: Mon, 05 Jan 1998 11:47:07 -0500
From: Phillip Hallam-Baker <[email-masked]>
Organization: VeriSign Inc.
To: "Jim Schaad (Exchange)" <[email-masked]>
CC: "'Paul Hoffman / IMC'" <[email-masked]>, ietf-smime <[email-masked]>
Subject: Re: CMS Critical flag for signed attributes?
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms057775C31229632A60B3DACD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jim Schaad (Exchange) wrote:

> I would strongly disagree that the place to put this is in the CMS or
> S/MIME specifications.  This is the type of statement which belongs in
> the Certificate Policy statment for the certificate itself and not on
> individual signatures.  I don't see a case where you would have some
> signatures from a person being binding and some not binding.  (What
> happens if the signer forgets to set the bit, does it then become
> binding on the corperation?)

The problem with this approach is that it means a person must have
a different certificate for each privillege level they have.

I am anticipating disclaimers of the form 'the value of any contract
agreement entered into under this message is less than $1000'. I 
would expect an automated 'contract box' to accept input in the
form of signed S/MIME messages, consult some corporate database of
project budgets and possibly authorize some small value contracts
automatically. Doing this requires either that we solve the AI
problem and parse the contract or we find some other method of
limiting the exposure due to such a device.

Also consider the alternative scheme in which the contracts would
be vetted in some way. There is obviously a need to ensure that 
those vetting the contracts do not exceed their authority (e.g.
they are in collusion with some fraud and making authorizations
beyond their authority).

The other problem is that it does not address the four corners issue.
The reason certificate policies were largely abandoned as a means of
specifying the criteria for issuing a certificate was that they
might not be binding in court. As Michael Baum points out, a court
might decide that they are not even admissible. Courts are likely
to decide to restrict their debate to the 'four corners' of the 
document in dispute.

So if your disclaimer happens to be in a different document (the 
certificate) you may be out of luck. 

If you have two documents A and B where A makes mention of B but
B makes no mention of A, A is quite likely to be ruled out in
in a dispute concerning the enforcability B.

This is why the Certificate Practices Statement is bound into
the certificate issued and certificate policy statements are
not generally employed as a means of stating a CA's certification
policy. 

The problem Jim raises may well not have a perfect soultion,
but just because we cannot prevent fraud does not mean we should
not do what we can to avoid incompetence!

Also note that if fraud can be proven (as seems likely) there 
are other remedies - insurance etc. and the court case is
likely to be of a rather different nature.

A particular form of incompetence that concerns me is the
incompetence of automated signing robots. I suspect that at
some level in the corporate infrastructure there will emerge
a need for some device that is essentially accepting some 
input and signing it. I would like to try to ensure that 
we can errect some safeguards arround such devices so that
the effects of various attacks can be mitigated.

		Phill
--------------ms057775C31229632A60B3DACD
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms057775C31229632A60B3DACD--

Date: Mon, 5 Jan 1998 10:48:22 -0500
To: Phillip Hallam-Baker <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: CMS Critical flag for signed attributes?
Cc: ietf-smime <[email-masked]>
Sender: [email-masked]

All,

I agree with Phillip's proposal:

>One entirely backwards compatible method of doing this would be to
>create
>an OID whose attributes would simply be a list of critical extensions.
>S/MIME v3 clients would be required to understand the OID semantics.

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

Date: Mon, 05 Jan 1998 10:48:08 -0500
From: Phillip Hallam-Baker <[email-masked]>
Organization: VeriSign Inc.
To: John Pawling <[email-masked]>
CC: ietf-smime <[email-masked]>
Subject: Re: CMS Critical flag for signed attributes?
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms881850F160D6EB28B09F855A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John Pawling wrote:

> One of the primary requirements of the S/MIME v3 set of specs is to maintain
> backwards compatibility with the S/MIME v2 set of specs.  PKCS #7 does not
> include a critical flag in the Attributes syntax, so we need to consider how
> this would be implemented without breaking backward compatibility.

Agreed.

One entirely backwards compatible method of doing this would be to
create
an OID whose attributes would simply be a list of critical extensions.
S/MIME v3 clients would be required to understand the OID semantics.

> One
> alternative would be to make the critical flag optional.  

Then it would have no effect. The point of CRITICAL is that it provides
a single point of obligation.

>The value of the
> version number in the signerInfo SEQUENCE could be used to indicate if the
> critical flag is being used.  Assuming that the S/MIME v2 products examine
> the version value, they could determine if they could decode the rest of the
> signerInfo SEQUENCE based on the value of the version number.
> 
> This raises further issues such as:
> 
> 1) How do sending agents determine if specific receiving agents can handle
> the critical flag?

I don't think this can be guaranteed in an asynchronous protocol,
especially
since we are defining a message syntax and not a transport protocol.
 
> 2) What happens if a S/MIME v3 agent sends a signedData with critical flag
> present and the receiving S/MIME v2 agent determines that it can't decode
> it.  How does the receiving agent communicate the failure to the sending agent?

I don't think this is a critical problem. I understand the problems of
legacy software - I've been struggling for the past four years to 
get minor corrections into HTTP that were suggested in 1993!

The reason for the critical flag is to provide a mechanism for 
placing contract disclaimers. I would hope and expect folk who 
are going to rely on contracts exchanged via S/MIME would
upgrade their clients.

One of the mistakes we made with HTTP was to underestimate the 
rate at which browsers would become obsolescent. We failed to 
kill HTTP 0.9 back in 1992 because there were 'hundreds' of
0.9 servers.

I think we should focus on the backwards compatibility problem
as 'old clients will not break', rather than 'old clients won't
become useless'.

I don't think the critical flag is a facility that will be essential
for a while, probably not for a couple of years or so. The reason
I am raising the issue now is that two years is the time it takes
for a positive expectation that a feature is supported can be
made.

Also I am proposing the critical flag as only one piece of a broader
contract processing infrastructure. In a corporate environment an
employee receiving a contract had better make sure it gets filed
somewhere a bit more accessible than their personal hard drive! I
would expect some sort of 'contract repository' to be an essential
part of the infrastructure I am anticipating. This is a point where
the infrastructure can raise the 'insufficient authorization' error
flag if no other.

The point I am making is that if this feature is to be supported at
all we have to have it in the base spec as a required feature. We 
do not require the Version 2 clients to support it but we do draw
the line at V3.

		Phill
--------------ms881850F160D6EB28B09F855A
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms881850F160D6EB28B09F855A--

Date: Mon, 5 Jan 1998 09:39:25 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: CMS Critical flag for signed attributes?
Sender: [email-masked]

----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 44

> From: Phillip Hallam-Baker <[email-masked]>
> 
> Should there be a criticallity flag for signed attributes?
> 
> The application I am thiniking of is limiting an employees signing
> authority inside a company. An obvious way to do this would be to have
> an OID for the signed attribute 'this message does not constitute an
> offer or acceptance of a contract'.

Phill,

It's not clear which authority you have in mind for generating the
signed attribute.  If it's the message author, then enclosing the text

  'this message does not constitute an offer or acceptance of
   a contract'

within the body of the message or the CMS authenticated attributes would
seem to be the appropriate solution, rather than inventing OIDs to stand
for that text, and having the author choose from a checklist of applicable
OIDs/statements that could be attached to a message.

But if MIT is the authority grantor, and MIT doesn't want Mr. Foo the
janitor to be authorized to sign contracts, then the appropriate location
is in the X.509 v3 subjectDirectoryAttributes extension of Mr. Foo's
certificate issued by MIT (marked critical or not, as appropriate).

Or if Mr. Foo has a VeriSign identity certificate, MIT could issue an
attribute certificate against it, authorizing Mr. Foo to enter buildings
after hours, but not authorizing him to sign contracts.

In general, for well-structured and standardized information, I believe
the appropriate container is a certificate (identity or attribute), not
the signed attributes defined by CMS.  Signed attributes can only be
generated by the message author.  Attribute certs can be generated by
anyone, including the CA, the message author, or a third-party
authority-granting entity.

In short, I don't think there is a need for a criticality flag for
CMS signed attributes, because that is not where the critical information
should go.

Dave K.
----------
X-Sun-Data-Type: x-pkcs7-signature
X-Sun-Data-Name: S/MIME Cryptographic Signature
X-Sun-Encoding-Info: base64
Content-Disposition: attachment; filename="smime.p7s"
X-Sun-Content-Lines: 33

Date: Mon, 5 Jan 1998 09:08:02 -0500
To: Phillip Hallam-Baker <[email-masked]>, ietf-smime <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: CMS Critical flag for signed attributes?
Sender: [email-masked]

All,

One of the primary requirements of the S/MIME v3 set of specs is to maintain
backwards compatibility with the S/MIME v2 set of specs.  PKCS #7 does not
include a critical flag in the Attributes syntax, so we need to consider how
this would be implemented without breaking backward compatibility.  One
alternative would be to make the critical flag optional.  The value of the
version number in the signerInfo SEQUENCE could be used to indicate if the
critical flag is being used.  Assuming that the S/MIME v2 products examine
the version value, they could determine if they could decode the rest of the
signerInfo SEQUENCE based on the value of the version number.  

This raises further issues such as:

1) How do sending agents determine if specific receiving agents can handle
the critical flag? 

2) What happens if a S/MIME v3 agent sends a signedData with critical flag
present and the receiving S/MIME v2 agent determines that it can't decode
it.  How does the receiving agent communicate the failure to the sending agent?

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

From: "Rich Ankney" <[email-masked]>
To: "Jim Schaad (Exchange)" <[email-masked]>, "[email-masked]'" <[email-masked]>, <[email-masked]>
Subject: Re: Incorporate some PKCS#7 V2.0 items into CMS
Date: Mon, 5 Jan 1998 07:46:04 -0500
Sender: [email-masked]

I had not included the authenticated attributes in AuthenticatedData since
I
didn't see a reason for it (for my purposes, anyway).  I could go ahead and

put it in, since it would work the same way as it does in SignedData.

I also have no objections to using a MAC in SignedData for those cases
where it will actually work (i.e. pre-shared key).

Regards,
Rich

----------
> From: Jim Schaad (Exchange) <[email-masked]>
> To: [email-masked]'; 'Rich Ankney' <[email-masked]>;
[email-masked]
> Subject: RE: Incorporate some PKCS#7 V2.0 items into CMS
> Date: Sunday, January 04, 1998 10:03 PM
> 
> It turns out that I was not fully functional when I wrote the list of
> reasons below, and I left out what was to me the most important one.
> What I want to do with the MAC modified signedData object is to run CMR
> messages via it.  This requires the ability to have authenticated
> attributes travel with the message.  This is a feature which is not
> provided by the use of the AuthendicatedData structure, and thus the
> reason that I put it into the signedData object.   Notice that I was
> very careful NOT to duplicate the same set of functionality as is
> provided by Authenticated data, that is I am signing the Authenticated
> attrubutes and not the data with the MAC algorithm.
> 
> That being said, I can live with the lack of support for this and
> provide the introduction mechanism in a different way.  This proposal
> however does add a new level of ability that was not present in the PKCS
> #7 1.5 specifications.
> 
> jim schaad
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, December 31, 1997 6:22 AM
> To: Jim Schaad (Exchange); 'Rich Ankney'; [email-masked]
> Subject: RE: Incorporate some PKCS#7 V2.0 items into CMS
> 
> 
> All,
> 
> I am not a MAC expert, but I have a few comments anyway.  It seems that
> the
> security processing requirements for MAC objects are significantly
> different
> than the processing requirements for non-MAC signedData objects.  If
> this is
> true, then I believe that it makes more sense to define a separate
> object
> (i.e. Rich's AuthenticatedData proposal) than to add complexity to
> signedData (Jim's proposals to add ukm and RecipientIdentifier to
> signerInfo).  I assume that Rich's proposal is to use signedData to
> provide
> signature services other than MAC and to use AuthenticatedData to
> provide
> MAC services.  This definition of two distinct objects allows an OID to
> be
> assigned for each which can be used to identify each object.  When a CMS
> object is received, the receiving agent can examine the contentInfo
> contentType to quickly identify which type of processing is required to
> validate the object.  
> 
> ================================
> John Pawling   
> [email-masked]                             
> J.G. Van Dyke & Associates, Inc.           
> ================================
> 
> 
> At 02:46 PM 12/30/97 -0800, Jim Schaad (Exchange) wrote:
> >I made these changes to the SignedData and Enveloped data fields for
> two
> >reasons:
> >
> >1.  S/MIME is primarly concerned with the transport of these two
> >encoding formats and has not yet defined how to transport other
> encoding
> >types, and
> >2.  I wanted to keep the total number of "things" that I had to deal
> >with to a minimum.
> >
> >We could easily add transport of other types if needed.  The second
> goal
> >is just a desire on my part and could easily be overridden by others.
> >It may be that the added complexity that I have added to the SignedData
> >and EnvelopedData out weight the benifits of having just the two types.
> >
> >jim
> >

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Rich Ankney'" <[email-masked]>, [email-masked]
Subject: RE: Incorporate some PKCS#7 V2.0 items into CMS
Date: Sun, 4 Jan 1998 19:03:48 -0800 
Sender: [email-masked]

It turns out that I was not fully functional when I wrote the list of
reasons below, and I left out what was to me the most important one.
What I want to do with the MAC modified signedData object is to run CMR
messages via it.  This requires the ability to have authenticated
attributes travel with the message.  This is a feature which is not
provided by the use of the AuthendicatedData structure, and thus the
reason that I put it into the signedData object.   Notice that I was
very careful NOT to duplicate the same set of functionality as is
provided by Authenticated data, that is I am signing the Authenticated
attrubutes and not the data with the MAC algorithm.

That being said, I can live with the lack of support for this and
provide the introduction mechanism in a different way.  This proposal
however does add a new level of ability that was not present in the PKCS
#7 1.5 specifications.

jim schaad

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, December 31, 1997 6:22 AM
To: Jim Schaad (Exchange); 'Rich Ankney'; [email-masked]
Subject: RE: Incorporate some PKCS#7 V2.0 items into CMS

All,

I am not a MAC expert, but I have a few comments anyway.  It seems that
the
security processing requirements for MAC objects are significantly
different
than the processing requirements for non-MAC signedData objects.  If
this is
true, then I believe that it makes more sense to define a separate
object
(i.e. Rich's AuthenticatedData proposal) than to add complexity to
signedData (Jim's proposals to add ukm and RecipientIdentifier to
signerInfo).  I assume that Rich's proposal is to use signedData to
provide
signature services other than MAC and to use AuthenticatedData to
provide
MAC services.  This definition of two distinct objects allows an OID to
be
assigned for each which can be used to identify each object.  When a CMS
object is received, the receiving agent can examine the contentInfo
contentType to quickly identify which type of processing is required to
validate the object.  

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

At 02:46 PM 12/30/97 -0800, Jim Schaad (Exchange) wrote:
>I made these changes to the SignedData and Enveloped data fields for
two
>reasons:
>
>1.  S/MIME is primarly concerned with the transport of these two
>encoding formats and has not yet defined how to transport other
encoding
>types, and
>2.  I wanted to keep the total number of "things" that I had to deal
>with to a minimum.
>
>We could easily add transport of other types if needed.  The second
goal
>is just a desire on my part and could easily be overridden by others.
>It may be that the added complexity that I have added to the SignedData
>and EnvelopedData out weight the benifits of having just the two types.
>
>jim
>

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, ietf-smime <[email-masked]>
Subject: RE: CMS Critical flag for signed attributes?
Date: Fri, 2 Jan 1998 13:45:49 -0800 
Sender: [email-masked]

I would strongly disagree that the place to put this is in the CMS or
S/MIME specifications.  This is the type of statement which belongs in
the Certificate Policy statment for the certificate itself and not on
individual signatures.  I don't see a case where you would have some
signatures from a person being binding and some not binding.  (What
happens if the signer forgets to set the bit, does it then become
binding on the corperation?) 

This is a Certificate Extension issue (and can be critical there) and
not a signature issue.

-----Original Message-----
From: Paul Hoffman / IMC [mailto:[email-masked]]
Sent: Friday, January 02, 1998 9:47 AM
To: ietf-smime
Subject: Re: CMS Critical flag for signed attributes?

At 12:33 PM 1/2/98 -0500, Phillip Hallam-Baker wrote:
>I agree, but I want to make sure that the resulting wording makes a
>critical attribute something that can be raised in court as something
>a recipient should have made themselves aware of before relying on the
>document as an agreement.

Boy, I'd like to see some suggested wording for this. This doesn't sound
like typical wording for IETF specifications, does it? :-)

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 02 Jan 1998 09:46:46 -0800
To: ietf-smime <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: CMS Critical flag for signed attributes?
Sender: [email-masked]

At 12:33 PM 1/2/98 -0500, Phillip Hallam-Baker wrote:
>I agree, but I want to make sure that the resulting wording makes a
>critical attribute something that can be raised in court as something
>a recipient should have made themselves aware of before relying on the
>document as an agreement.

Boy, I'd like to see some suggested wording for this. This doesn't sound
like typical wording for IETF specifications, does it? :-)

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 02 Jan 1998 12:33:43 -0500
From: Phillip Hallam-Baker <[email-masked]>
Organization: VeriSign Inc.
To: Paul Hoffman / IMC <[email-masked]>
CC: ietf-smime <[email-masked]>
Subject: Re: CMS Critical flag for signed attributes?
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms00CA4ED7CCC9400F77FA42F1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Paul Hoffman / IMC wrote:
> 
> At 03:25 PM 12/31/97 -0500, Phillip Hallam-Baker wrote:
> >It seems to me we may just need a critical flag just like there is in
> >the X.509v3 certificate. If the critical bit is set and the client does
> >not understand the semantics of the attribute a client is required to
> >inform the user of the fact.
> 
> This sounds alright to me, but not the differences in action between PKIX
> and S/MIME. In PKIX, you MUST not process a cert that has a critical
> attribute you don't understand. In S/MIME, you propose that we "inform the
> user", which is the handwaving we're forced to do when a signature check
> fails.
> 
> If we go with this idea, the handwaving wording for what happens for failed
> criticality should be identical as the handwaving wording we use for failed
> signature validation. In fact, I'd like to see that wording appear only
> once as the same outcome to two different bad events.

I agree, but I want to make sure that the resulting wording makes a
critical attribute something that can be raised in court as something
a recipient should have made themselves aware of before relying on the
document as an agreement.

The concern I have in the back of my mind is Mr Mop, the janitor who 
sends  a signed message the recipient then claims in court is a binding
contract on behalf of his employer. MIT students are now required
to get an X.509 cert during registration. I'm pretty sure that MIT
does not intend them to be signing contracts binding on the 
corporation:-)

		Phill
--------------ms00CA4ED7CCC9400F77FA42F1
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms00CA4ED7CCC9400F77FA42F1--

Date: Fri, 2 Jan 1998 13:16:31 -0200 (EDT)
From: Ed Gerck <[email-masked]>
Reply-To: Ed Gerck <[email-masked]>
To: EKR <[email-masked]>
cc: David Sternlight <[email-masked]>, [email-masked]
Subject: Re: Weakening the rigid heirarchical trust model
Sender: [email-masked]

On 1 Jan 1998, EKR wrote:

-> [snip, requoted]
-> If you desire to have a secure environment, you can't place trust
-> in entities which don't take similar security measures. So, true,
-> high security S/MIME users won't interoperate with low security
-> S/MIME users -- in the sense that the high security users (by policy)
-> don't trust the low security users. That doesn't mean that they're
-> not both speaking S/MIME any more than the fact that the NSA won't
-> tell me classified information means we don't both speak English.
-> 

If the high-security users decide not to depend on unsafe X.509 CRLs in
order to decide if a cert is valid (eg, supose they would use a type of
Kerberos tickets) or if the high-security users decide to use PGP and
X.509 then they would already be non-S/MIME for all practical purposes,
even though they could be both talking MIME.

Thus, what I was calling interoperability is not a MIME-interoperability,
but a S/MIME interoperability. In other words, high-security users will in
general differ from low-security users in more predicates than just
different policies or different root-keys for each user, but in the
protocols for each user. What you mentioned is not that, but a case in
which the protocol is still S/MIME for both users (thus, compatible)  but
the reference frames are incompatible with each other. This case I would
consider not a case of lack of interoperation but simply to be out of
tune. Please note that what I had in mind was a true protocol difference
which cannot be solved by any possible change (or tuning) of parameters.

-> I'd observe that S/MIME already has the capability to produce 
-> noninteroperability because of different security requirements,
-> simply because different users may choose to have different
-> lists of root keys.

Generally, this would not be called noninteroperability but
misconfiguration, the difference being:

(i) misconfiguration can be solved by a suitable change of parameters
while keeping the same protocols on each side,

(ii) noninteroperability cannot be solved by any change of parameters on
each side but requires at least one side to introduce a different
protocol. 

Clearly, for S/MIME (as for any standard) the goal is to guarantee
interoperability irrespective of vendor choices, whereas a compatible
configuration would depend on the user choices (and thus, irrelevant to
the standard itself). 

-> S/MIME is a messaging spec. In and of itself, however, it's not a
-> specification for a complete system. I don't consider this to be a 
-> weakness. It's simply out of scope. 

Agreed, this is exactly my central point. Indeed, what is out of scope for
S/MIME may be crucial and part of the scope when a higher-security level
is considered for e-mail messages. But this does not invalidate S/MIME for
the bulk of Internet e-mail messages and allows self-signed certs to be
used without qualms in S/MIME -- which was my original point.

Cheers,

Ed
______________________________________________________________________
Dr.rer.nat. E. Gerck                     [email-masked]
http://novaware.cps.softex.br

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cms-02.txt
Date: Fri, 02 Jan 1998 09:28:45 -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		: Cryptographic Message Syntax
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-02.txt
	Pages		: 29
	Date		: 31-Dec-97
	
   This document describes the Cryptographic Message Syntax.  This
   syntax is used to digitally sign, digest, or encrypt arbitrary
   messages.
 
   The Cryptographic Message Syntax is derived from PKCS #7 version 1.5.
   Wherever possible, backward compatibility is preserved; however,
   changes were necessary to accommodate attribute certificate transfer
   and key agreement techniques for key management.
 
   This draft is being discussed on the ''ietf-smime'' mailing list. To
   subscribe, send a message to:
        [email-masked]
   with the single ''subscribe'' word in the body of the message. Also,
   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-cms-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-smime-cms-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-cms-02.txt".
	
NOTE:	The mail server at ds.internic.net 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-cms-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-cms-02.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: Ed Gerck <[email-masked]>
Cc: David Sternlight <[email-masked]>, [email-masked]
Subject: Re: Weakening the rigid heirarchical trust model
From: EKR <[email-masked]>
Date: 01 Jan 1998 15:31:02 -0800
Lines: 87
Sender: [email-masked]

Ed Gerck <[email-masked]> writes:
> On 31 Dec 1997, EKR wrote:
> 
> -> Ed Gerck <[email-masked]> writes:
> -> > The bottom line is that S/MIME aims at a security level which is not
> -> > critical, while it can be perfectly operational for the bulk use of the
> -> > Internet today. A honest and correct appraisal of this fact must be more
> -> > useful than snake-oil, here too. 
> -> I absolutely agree. I was simply observing that it's quite possible
> -> to create a profile of S/MIME that is usable in a high security
> -> environment.
> -> 
> 
> First of all, a Happy New Year!
Indeed.

> Ok, agreed. But that environment (and protocol) would not be S/MIME any
> longer -- otherwise, the non-interoperability specter would appear again.
I agree with the second part of this statement but not the first.
If you desire to have a secure environment, you can't place trust
in entities which don't take similar security measures. So, true,
high security S/MIME users won't interoperate with low security
S/MIME users -- in the sense that the high security users (by policy)
don't trust the low security users. That doesn't mean that they're
not both speaking S/MIME any more than the fact that the NSA won't
tell me classified information means we don't both speak English.

I'd observe that S/MIME already has the capability to produce 
noninteroperability because of different security requirements,
simply because different users may choose to have different
lists of root keys.

> Thus, what I also observed was simply that you can't push S/MIME beyond
> the specs and there would no gain in pushing for stricter procedures than
> needed. To exemplify, I provided examples of application behaviors which
> are NOT defined in the S/MIME specs and which may cause problems in a
> higher-security environment as a function of the implementation, even
> though the application is 100% S/MIME compliant and perfectly acceptable
> in a lower-security environment. 
>
> Therefore, these security concerns cannot be considered as implementation
> bugs of a spec -- because the specs are moot on that. Rather, they reflect
> implementation freedom allowed by the specs. Of course, if you get an
> out-of-the-box S/MIME application you may rightly expect it to conform to
> the S/MIME standard -- targeting a pre-defined security level for which
> the concerns I exemplified are simply non-existent. 
> 
> Now, if we agree that the problems I exemplified (out of a larger list) 
> are not in the S/MIME wish-list then we must also agree that they are
> neither protocol bugs nor implementation bugs. They are just features that
> someone may need but will NOT find in S/MIME -- by design.
> 
> To further clarify the issue (and following your numbers above):
> 
> (1) No, the examples I supplied reflect neither protocol bugs nor
> implementation bugs in S/MIME, because they belong to a security class
> beyond the S/MIME specs. In such a higher-security reference frame, they
> may be called protocol weaknesses in S/MIME and just reflect the fact that
> you are using a tool beyond its design assumptions. This does not impair
> the use of S/MIME for the bulk of Internet e-mail messages, for which it
> is obviously designed. 
>
> (2) Such protocol weaknesses cannot be solved by a "band-aid" type
> solution with some sort of hardware that carries some amount of trust,
> because a system is usually as strong as its weakest part. In the open
> environment of the Internet, it is very risky to consider that the
> solution of a protocol weakness would be guaranteed by a hardware
> limitation. 
I think I see what you're saying, but I disagree with the conclusion.
S/MIME is a messaging spec. In and of itself, however, it's not a
specification for a complete system. I don't consider this to be a 
weakness. It's simply out of scope. But, I guess this is pretty much
a philosophical issue. 

> I read the article some time ago and enjoyed it, because even though I
> entirely agree with its line of thought I also entirely disagree with its
> main conclusion: "You can't trust code that you did not totally create
> yourself." (But, discussing this would certainly be off-topic -- however,
> I would gladly explain my reasonings privately though). 
Fair enough. I think this is at the root of our disagreement wrt
trapdoors. 

-Ekr

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

Date: Thu, 1 Jan 1998 20:45:35 -0200 (EDT)
From: Ed Gerck <[email-masked]>
To: EKR <[email-masked]>
cc: David Sternlight <[email-masked]>, [email-masked]
Subject: Re: Weakening the rigid heirarchical trust model
Sender: [email-masked]

On 31 Dec 1997, EKR wrote:

-> Ed Gerck <[email-masked]> writes:
-> > The bottom line is that S/MIME aims at a security level which is not
-> > critical, while it can be perfectly operational for the bulk use of the
-> > Internet today. A honest and correct appraisal of this fact must be more
-> > useful than snake-oil, here too. 
-> I absolutely agree. I was simply observing that it's quite possible
-> to create a profile of S/MIME that is usable in a high security
-> environment.
-> 

First of all, a Happy New Year!

Ok, agreed. But that environment (and protocol) would not be S/MIME any
longer -- otherwise, the non-interoperability specter would appear again.

-> >[snip, already requoted] 
-> > My point was that a protocol weakness cannot be solved by hardware, no
-> > matter how controlled.
-> Yes, but a lot of the things you were complaining about (e.g.
-> bad randomness for key generation,  programs which are willing
-> to give up the key, etc.) are (1) not protocol bugs but
-> implementation bugs and (2) can be fixed by trusted hardware.
-> 

We seem to be moving in circles here because this is NOT what I had in
mind. The difference in understanding may have been caused by myself, when
I poorly explained my objection (out of a desire to be concise). My
objection was NOT to point out that S/MIME has protocol bugs, but I seeked
to define its security limits so that we may consider S/MIME working
within its design assumptions (for example, the fact that you can't carry
an elephant in your Porsche doesn't make the Porsche a bad transportation
vehicle, just shows its designs limits). 

Going back to the original thread, this consideration led me to justify
the use of self-signed certs in S/MIME as coherent with the need to use
self-signed CA root certs and with the desired security level in S/MIME. 

Thus, what I also observed was simply that you can't push S/MIME beyond
the specs and there would no gain in pushing for stricter procedures than
needed. To exemplify, I provided examples of application behaviors which
are NOT defined in the S/MIME specs and which may cause problems in a
higher-security environment as a function of the implementation, even
though the application is 100% S/MIME compliant and perfectly acceptable
in a lower-security environment. 

Therefore, these security concerns cannot be considered as implementation
bugs of a spec -- because the specs are moot on that. Rather, they reflect
implementation freedom allowed by the specs. Of course, if you get an
out-of-the-box S/MIME application you may rightly expect it to conform to
the S/MIME standard -- targeting a pre-defined security level for which
the concerns I exemplified are simply non-existent. 

Now, if we agree that the problems I exemplified (out of a larger list) 
are not in the S/MIME wish-list then we must also agree that they are
neither protocol bugs nor implementation bugs. They are just features that
someone may need but will NOT find in S/MIME -- by design.

To further clarify the issue (and following your numbers above):

(1) No, the examples I supplied reflect neither protocol bugs nor
implementation bugs in S/MIME, because they belong to a security class
beyond the S/MIME specs. In such a higher-security reference frame, they
may be called protocol weaknesses in S/MIME and just reflect the fact that
you are using a tool beyond its design assumptions. This does not impair
the use of S/MIME for the bulk of Internet e-mail messages, for which it
is obviously designed. 

(2) Such protocol weaknesses cannot be solved by a "band-aid" type
solution with some sort of hardware that carries some amount of trust,
because a system is usually as strong as its weakest part. In the open
environment of the Internet, it is very risky to consider that the
solution of a protocol weakness would be guaranteed by a hardware
limitation. 

-> > -> That said, the issue of trapdoors is a red herring. Ultimately
-> > -> you have to trust your vendor not to intentionally compromise your
-> > -> security--or do it all yourself. Read "Reflections On Trusting Trust"
-> > -> for an example that makes this point quite clearly.
-> > 
-> > First, "not intentionally compromised" is difficult to disprove,
-> > especially when you bear the burden of proof in a tamper-proof device, no?
-> > (Further, as you may remember from the case of Stac vs Microsoft, Stac
-> > proved by reverse assembly of MS's code that DoubleSpace used substantial
-> > code from Stac, but Stac was also found guilty of "invading" MS's code.)
-> >
-> > Second, as above, no vendors or third-parties can be trusted in today's
-> > competitive environment-- not even Volkswagen vis-a-vis General Motors. 
-> > What the international Internet community needs is not some immaterial
-> > trust on a foreign government or company or, even, on a domestic
-> > government or company -- but open knowledge and fail-safe procedures. 
-> > After all, if trust would be such a safe "blank check" then the whole
-> > issue of key-escrow, TTP legislation and CAs would be moot. 
-> I think you're missing the point here. The vast majority of users
-> of security critical software are using software supplied by
-> others, even if those others are in-house. If those suppliers can't
-> be trusted not to intentionally compromise your security, there
-> are very few measures that you can take to really protect yourself.
-> 
-> > BTW, "Trusting Trust" reflects the wrong assumption that trust is
-> > transitive -- which it is not.
->
-> From this, I infer that you haven't actually read "Reflections on
-> Trusting Trust", but are just guessing what it's about based
-> on the title. Am I right?
->

No ;-)

I read the article some time ago and enjoyed it, because even though I
entirely agree with its line of thought I also entirely disagree with its
main conclusion: "You can't trust code that you did not totally create
yourself." (But, discussing this would certainly be off-topic -- however,
I would gladly explain my reasonings privately though). 
 
-> Certainly your comments don't speak at all to the point that the
-> paper is trying to make. (Hint: It's not about cryptography at
-> all.)
-> 

One of the reasons I enjoyed the paper is its title, because the title is
an anti-climax to the paper! 

However, when you refered the paper (for the curious: 
http://www1.acm.org:81/classics/sep95/) you apparently did it to support a
take-it-or-leave-it attitude: either you would have to trust the vendor or
do it all by yourself. The first being undesirable and risky (example, MS
vs Stac. GM vs VW, etc.)  and the second obviously impossible, we would
have to accept the first option. Such was your implict conclusion.

My comment was that indeed the title is wrong (what Ken also states in the
paper) but trust can also be modelled as "soft-trust" -- which offers a
way out of this paradox when one allows for multiple independent trust
channels. 

Cheers,

Ed

______________________________________________________________________
Dr.rer.nat. E. Gerck                     [email-masked]
http://novaware.cps.softex.br