Subject: ESS-01 issues not finished
From: "Jim Schaad (Exchange)" <[email-masked]>
To: "Paul Hoffman (E-mail)" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Date: Sat, 28 Feb 1998 21:16:56 -0800

The following items from my comments for ESS-01 did not make it into
ESS-02 so here it is again.  Hopefully this time it will get some
discussion.

1.  Section 3.1.1 paragraph 5.  I disagree that some SignerInfos within
a SignedData object may be permitted to be missing security labels
without any restrictions.  I propose the following replacement paragraph
(new last sentence).

"There can be multiple SignerInfos within a SignedData object, and each
SignerInfo may include authenticatedAttributes. Therefore, a single
SignedData object may include multiple security labels, each SignerInfo
having an eSSSecurityLabel attribute. For example, an originator can
send a
signed message with two SignerInfos, one containing a DSS signature, the
other containing an RSA signature. Not all of the SignerInfos need to
include security labels, but in all of the SignerInfos that do contain
security labels, the security labels MUST be identical.  Additionally, a
client
SHOULD NOT allow access to the mail if it cannot verify atleast one of
the 
SignerInfos which contains the security label."

Jim

From: "Jim Schaad (Exchange)" <[email-masked]>
To: [email-masked], "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Criticality of Authenticated Attributes
Date: Fri, 27 Feb 1998 13:34:38 -0800
Sender: [email-masked]

There is a problem with making essSecurityLabel critical.  This means
that it cannot be used in S/MIME v2 clients and they will not understand
the signed message which comes in.  The version on the signedData object
would be 3.  With this change we have now moved to the point where no
items in ESS (except for mlExpansionHistory which is a server side
"feature") can be done with S/MIME v2.  If we accept this then we need
to re-write the intro to ESS.

jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, February 25, 1998 2:29 PM
To: Russ Housley; [email-masked]
Cc: [email-masked]
Subject: Re: Criticality of Authenticated Attributes

All,

I agree with Russ.  Furthermore, I believe that essSecurityLabel should
be
the only attribute that is required to always be critical.  ESS should
not
require criticality for attributes that legacy products need to process
(contentType, messageDigest, signingTime, smimeCapabilities).  I don't
believe that the following new attributes should be mandated to always
be
critical: contentIdentifier, mlExpansionHistory, receiptRequest, and
contentHints.  So, that only leaves essSecurityLabel as being mandatory
critical.

Furthermore, I recommend that the following text should be added to the
description of the critical flag in CMS, Sec 5.2: "Note that setting
critical to TRUE will cause interoperability problems with legacy
software
that does not recognize the AuthAttribute ASN.1 syntax."

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

At 08:48 AM 2/25/98 -0500, Russ Housley wrote:
>Paul:
>
>Please add a sentence to the description of each authenticated
attribute.
>We need to specify whether the attribute is always critical, never
>critical, or the originator's choice.
>
>I think that security label should always be critical.
>
>Russ
>
>

From: "Jim Schaad (Exchange)" <[email-masked]>
To: [email-masked], "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: ESS-02 Comments part 2
Date: Fri, 27 Feb 1998 13:34:37 -0800
Sender: [email-masked]

John,

From: [email-masked] [mailto:[email-masked]]
All,

I agree with all of Jim's comments except that I have a few comments
regarding his comments:

At 06:40 PM 2/25/98 -0800, Jim Schaad (Exchange) wrote:
>1.  Section 1 pargraph #2:  Since as time goes by it becomes harder for
>me to understand what sections of this document require SMIME3 and what
>can be implemented using SMIME2, I would like to be explicit here.
>Replace with the following paragraph: "The services described here are
>extensions to S/MIME version 2 [SMIME2] and S/MIME version 3 [SMIME3].
>The Security Label and Mail List Agent services can be added to S/MIME
>version 2, but the Secure Reciepts service requires [CMS] and can only
>be added to S/MIME version 3."  then contue with the last sentence.

[JSP:  Why do you think that signed receipts can't be added to an S/MIME
v2
product?  It seems like support for the receiptRequest attribute could
be
added.  Similarly, the S/MIME v2 product could be enhanced to support
the
Receipt content.  I understand that these are noon-trivial enhancements,
but
I don't see why they couldn't be implemented.]

[Jim Schaad: The problem here is that the way you do signing of non-data
content has changed from PKCS#7 to CMS (direct DER encode to wrapping in
Octet string).  This means that the receipts generated from one client
could not be read by another client.  This is a large enough change that
I think we should cut off this line of implementation up front.\

>5.  Section 2.10 -- Please insert a section describing the
>msgDigestAttribute here:
>2.10  Message Digest Attribute
>
>This attribute is used only in a Secure Receipt authenticated
attributes
>section.  It contains the message digest of the SignedData object for
>which a receipt is being created.  Only one msgDigestAttribute can
>appear in an authenteicated attributes set.
>
>ASN goes here...\

[JSP: Did you mean "Message Signature Digest".  If so, then I recommend
the
following re-wording of your proposed para:

"2.10  Message Signature Digest Attribute

This attribute can only be used in the authenticated attributes of a
signed
receipt.  It contains the digest of the ASN.1 DER encoded
authenticatedAttributes included in the original signedData that
requested
the signed receipt.  Only one msgSigDigest attribute can appear in an
authenticated attributes set.  Section 2 provides more details regarding
the
use of the msgSigDigest authenticated attribute.  It is defined as
follows:

msgSigDigest ::= OCTET STRING."]

[Jim Schaad:  This looks good, except that I question the reference to
section 2.  This is already in section 2 so the reference does not make
sense.  Propose we accept the above with the deletion of sentence
starting "Section 2 ...".]

>9.  Section 4.1, paragraph 5.  Please as the following sentence.  "An
>MLA SHOULD NOT expand and redistribute a message if it cannot validate
>one or more outer signatures."

[JSP: I respectfully disagree with this comment.  A user could send a
double-wrapped message (i.e. envelopedData encapsulating signedData) to
an
MLA in which there is not an outer signedData.  Furthermore, a user may
send
a single-wrapped signedData or envelopedData message to an MLA in which
there is not an outer signedData.] 

[Jim Schaad:  Would the following sentence be more acceptable.  "If an
MLA finds a message with a SignerData object where one or more of of the
SignerInfo objects contain an mlExpansionHistory attribute, and the MLA
is unable to verify atleast one of these SignerInfo objects then the MLA
SHOULD NOT expand and redistribute the message."]

>10.  Section 4.2.1, Bullet 2.
>This is along the lines of a question,  Should the new RecipientInfos
be
>unioned with the existing set or replaced.  There are no security
>reasons why it cannot be replacement but this seems odd to me.

[JSP:  The MLA deletes the existing recipientInfos and builds a new
recipientInfo for each member of the ML.  The recipientInfos in the
original
message are not needed in the MLA-expanded message because those users
can
decrypt the original message.  For example, user 1 sends a message
containing recipientInfos for: ML1, Tom and Dick.  ML1, Tom and Dick
each
receive their copy of the message and decrypt it using their copy of
recipientInfo.  The MLA representing ML1 will expand the copy of the
message
that it received.  The recipientInfos for ML1, Tom and Dick are not
required
in the MLA-expanded message, because the message is not being sent to
ML1,
Tom and Dick.  It is being sent to the ML recipients.]

[Jim Schaad:  Agreed.]

>13.  Section 1.4 and Appendix A.  We should not be refering to the imc
>URL for the oids anymore or saying we intend to move to IANA to keep
the
>registry.   Recommend deletion of section 1.4 and the inclusion of the
>OIDs used by this draft in Appendix A.

[JSP: Why can't we refer to the S/MIME OIDs document?  It includes an
ASN.1
module that includes all of the OIDs.  The ESS and CMS modules can
immport
this module.]

[Jim Schaad:  That is find for the OIDS defined by CMS and S/MIME,
however I firmly believe that a document that defines the structures
referenced by an OID should also define the OID.]

Date: Thu, 26 Feb 1998 13:59:12 -0500
To: Russ Housley <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: ESS-02 Comments
Cc: Paul Hoffman / IMC <[email-masked]>, [email-masked]
Sender: [email-masked]

Russ,

Whatever you want to do is fine with me.  I thought that the S/MIME OIDs was
a part of the document tree, but if it is easier to divvy up these OIDs in
the various docs, then that is fine with me.

- John Pawling

At 01:44 PM 2/26/98 -0500, Russ Housley wrote:
>John:
>
>If we take that approack, then the OID module must be added to our document
>tree.
>
>Russ
>
>
>At 12:06 PM 2/26/98 -0500, John Pawling wrote:
>>Russ,
>>
>>The CMS and ESS modules could import the OIDs from the S/MIME OIDs module.
>>Defining the OIDs in multiple modules invites inconsistencies.
>>
>>- John Pawling
>>
>>
>>At 09:40 AM 2/26/98 -0500, Russ Housley wrote:
>>>Paul:
>>>
>>>The OID in the registry is not sufficient.  Please look at CMS Appendix A,
>>>and you will see that the OIDs needed to implement CMS are part of the CMS
>>>module.
>>>
>>>Russ
>> 
>

Date: Thu, 26 Feb 1998 13:44:51 -0500
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: Re: ESS-02 Comments
Cc: Paul Hoffman / IMC <[email-masked]>, [email-masked]
Sender: [email-masked]

John:

If we take that approack, then the OID module must be added to our document
tree.

Russ

At 12:06 PM 2/26/98 -0500, John Pawling wrote:
>Russ,
>
>The CMS and ESS modules could import the OIDs from the S/MIME OIDs module.
>Defining the OIDs in multiple modules invites inconsistencies.
>
>- John Pawling
>
>
>At 09:40 AM 2/26/98 -0500, Russ Housley wrote:
>>Paul:
>>
>>The OID in the registry is not sufficient.  Please look at CMS Appendix A,
>>and you will see that the OIDs needed to implement CMS are part of the CMS
>>module.
>>
>>Russ
> 

Date: Thu, 26 Feb 1998 13:46:48 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Fwd: I-D ACTION:draft-ietf-pkix-crmf-00.txt
Sender: [email-masked]

For those people who do not also watch the PKIX list ....

>
>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>This draft is a work item of the Public-Key Infrastructure (X.509) Working
Group
>of the IETF.
>
>        Title           : Certificate Request Message Format
>        Author(s)       : D. Solo, C. Adams, D. Kemp, M. Myers
>        Filename        : draft-ietf-pkix-crmf-00.txt
>        Pages           : 18
>        Date            : 25-Feb-98
>
>This document describes the Certificate Request Message Format (CRMF).
>This syntax is used to convey a request for a certificate to a
>Certification Authority (CA) (possibly via a Registration Authority
>(RA)) for the purposes of X.509 certificate production.  The request
>will typically include a public key and associated registration
>information.
>
>The key words ''MUST'', ''REQUIRED'', ''SHOULD'', ''RECOMMENDED'',
>and ''MAY'' in this document (in uppercase, as shown)
>are to be interpreted as described in RFC 2119.
>
>Please send comments on this document to the [email-masked]
>mail list.
>
>
>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-pkix-crmf-00.txt".
>A URL for the Internet-Draft is:
>ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-crmf-00.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-pkix-crmf-00.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.
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>

>ENCODING mime
>FILE /internet-drafts/draft-ietf-pkix-crmf-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-crmf-00.txt>
> 

Date: Thu, 26 Feb 1998 13:40:09 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: ESS EncapsulatedContentType
Sender: [email-masked]

All,

IMHO, the Receipt contentType does serve a purpose and I believe that it
should be retained.  It indicates the contentType of the message that
requested the signed receipt.  If the app is managing multiple flavors of
contents, then this field will point the app in the right direction to find
the message that matches the Receipt signedContentIdentifier.  

For example, lets say that CMS/ESS was being used in conjunction with X.400.
The content types could be P2, P22, P772, etc.  The Receipt contentType
field will indicate which flavor of message that it needs to locate to
validate the signed receipt.

In summary, I believe that it would be short-sighted to remove the Receipt
contentType.

- John Pawling

At 11:08 AM 2/26/98 -0500, David P. Kemp wrote:
>> From: [email-masked] (John Pawling)
>> 
>> I respectfully disagree with Dave that contentType should be removed from
>> the Receipt content syntax.  It is included in the signed receipt to assist
>> the application that must validate the signed receipt with the process of
>> identifying the original message (or hash of the message) that requested the
>> signed receipt.  The original message (or hash of the message) is required
>> to validate the signed receipt.  The Receipt contentType will especially be
>> valuable to apps that must manage contents of multiple types.  Therefore, I
>> believe that contentType should be retained and that it should be changed to
>> a mandatory field which will always contain the value copied from the
>> signedData encapContentInfo eContentType field of the message requesting the
>> signed receipt.
>
>
>I don't object to keeping contentType in Receipt if it serves a purpose.
>However, I still don't understand what the purpose is.  Currently, the
>eContentType field of the innermost signed data will *always* contain
>id-data, no?  If Russ' proposal to define 4 additional OIDs for X.411
>builtin message types, or my (as yet unproposed) proposal to define
>a single id-data-x411 OID for X.411 messages is adopted, there will
>be at most a few eContentType values.  In practice, a single user
>is not likely to have both S/MIME and X.411 original messages awaiting
>receipts, so the contentType field in the Receipt will be totally
>useless in distinguishing which message the receipt applies to.
>At best, it could only help distinguish between S/MIME and X.411 messages.
>
>Even then (if there were multiple content types), what is the purpose
>of including contentType in the Receipt?  The Receipt
>signedContentIdentifier uniquely identifies the message to which the
>receipt applies, so the UA only needs to validate the receipt against
>that single message.
>
>What am I missing?
>
>

Date: Thu, 26 Feb 1998 13:19:08 -0500
To: [email-masked] (David P. Kemp)
From: Russ Housley <[email-masked]>
Subject: Re: CMS-03 Comments
Cc: [email-masked]
Sender: [email-masked]

Dave:

I did not think of that.  I will remove the SIZE from the attrValue.

Russ

At 10:07 AM 2/26/98 -0500, David P. Kemp wrote:
>> From: Russ Housley <[email-masked]>
>> 
>> I added SIZE in four places.  Here is the updated ASN.1:
>> AuthAttributes ::= SET SIZE (1..MAX) OF AuthAttribute
>> 
>> AuthAttribute ::= SEQUENCE { 
>>   attrType OBJECT IDENTIFIER, 
>>   critical BOOLEAN DEFAULT FALSE, 
>>   attrValues SET SIZE (1..MAX) OF AttributeValue }
>
>
>That's fine with me.  I hesitated to constrain the number of attrValues
>because conceivably the attrType OID alone would be sufficient to
>convey the meaning of a particular (future-defined) attribute.  But
>either way is OK.
> 

Date: Thu, 26 Feb 1998 13:13:32 -0500
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: Re: ESS EncapsulatedContentType
Cc: [email-masked]
Sender: [email-masked]

I have no objection to the deletion of content type from the receipt request.

Russ

At 08:49 AM 2/26/98 -0500, John Pawling wrote:
>All,
>
>I agree with Dave Kemp that contentType should be removed from the ESS
>receiptRequest attribute because it is redundant to the signedData
>encapContentInfo eContentType OID.  This results in:
>
>   ReceiptRequest ::= SEQUENCE {
>      signedContentIdentifier ContentIdentifier,
>      receiptsFrom ReceiptsFrom,
>      receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames }
>
>
>I respectfully disagree with Dave that contentType should be removed from
>the Receipt content syntax.  It is included in the signed receipt to assist
>the application that must validate the signed receipt with the process of
>identifying the original message (or hash of the message) that requested the
>signed receipt.  The original message (or hash of the message) is required
>to validate the signed receipt.  The Receipt contentType will especially be
>valuable to apps that must manage contents of multiple types.  Therefore, I
>believe that contentType should be retained and that it should be changed to
>a mandatory field which will always contain the value copied from the
>signedData encapContentInfo eContentType field of the message requesting the
>signed receipt. This results in:
>
>Receipt ::= SEQUENCE {
>  version                   Version,  
>  contentType               ContentType,
>  signedContentIdentifier   ContentIdentifier,
>  originatorSignatureValue  OCTET STRING }
>
>
>If nobody objects to the deletion of contentType from receiptRequest and the
>retention of contentType in the Receipt content, then the following changes
>need to be made to ESS:
>
>
>1) Sec 2.2: Please delete bullet 2 stating: "2. The encapsulated content
>type is optionally noted in the
>encapsulatedContentType field."
>
>
>2) Sec 2.4, bullet 2.2:  Please make the following change:
> 
>OLD: 2.2. The encapsulatedContentType and signedContentIdentifier
>     values are copied from the original signedData signerInfo 
>     receiptRequest attribute into the corresponding fields in the 
>     Receipt structure.
>
>NEW: 2.2. The original signedData encapContentInfo eContentType object 
>     identifier is copied into the Receipt contentType.
>
>     2.3. The original signedData signerInfo receiptRequest 
>     signedContentIdentifier is copied into the Receipt  
>     signedContentIdentifier.
>
>
>3) Sec 2.8, last para:  Please change as follows:
>
>OLD: "The encapsulatedContentType and signedContentIdentifier fields are
>copied from the receiptRequest attribute of the SignerInfo contained within
>the message being receipted, and are used to link the receipt to the
>original signed message. The originatorSignatureValue field contains the
>signatureValue copied from the SignerInfo requesting the signed receipt."
>
>NEW: "The contentType, signedContentIdentifier and originatorSignatureValue
>fields are copied from the original signedData object that requested the
>signed receipt (see Sec 2.4), and are used to link the signed receipt to the
>original signed message." 
>
>
>================================
>John Pawling   
>[email-masked]                             

>J.G. Van Dyke & Associates, Inc.           
>================================
> 

Date: Thu, 26 Feb 1998 13:33:37 -0500
To: "Jim Schaad (Exchange)" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: ESS-02 Comments part 2
Sender: [email-masked]

All,

I agree with all of Jim's comments except that I have a few comments
regarding his comments:

At 06:40 PM 2/25/98 -0800, Jim Schaad (Exchange) wrote:
>1.  Section 1 pargraph #2:  Since as time goes by it becomes harder for
>me to understand what sections of this document require SMIME3 and what
>can be implemented using SMIME2, I would like to be explicit here.
>Replace with the following paragraph: "The services described here are
>extensions to S/MIME version 2 [SMIME2] and S/MIME version 3 [SMIME3].
>The Security Label and Mail List Agent services can be added to S/MIME
>version 2, but the Secure Reciepts service requires [CMS] and can only
>be added to S/MIME version 3."  then contue with the last sentence.

[JSP:  Why do you think that signed receipts can't be added to an S/MIME v2
product?  It seems like support for the receiptRequest attribute could be
added.  Similarly, the S/MIME v2 product could be enhanced to support the
Receipt content.  I understand that these are noon-trivial enhancements, but
I don't see why they couldn't be implemented.]

>5.  Section 2.10 -- Please insert a section describing the
>msgDigestAttribute here:
>2.10  Message Digest Attribute
>
>This attribute is used only in a Secure Receipt authenticated attributes
>section.  It contains the message digest of the SignedData object for
>which a receipt is being created.  Only one msgDigestAttribute can
>appear in an authenteicated attributes set.
>
>ASN goes here...\

[JSP: Did you mean "Message Signature Digest".  If so, then I recommend the
following re-wording of your proposed para:

"2.10  Message Signature Digest Attribute

This attribute can only be used in the authenticated attributes of a signed
receipt.  It contains the digest of the ASN.1 DER encoded
authenticatedAttributes included in the original signedData that requested
the signed receipt.  Only one msgSigDigest attribute can appear in an
authenticated attributes set.  Section 2 provides more details regarding the
use of the msgSigDigest authenticated attribute.  It is defined as follows:

msgSigDigest ::= OCTET STRING."]

>9.  Section 4.1, paragraph 5.  Please as the following sentence.  "An
>MLA SHOULD NOT expand and redistribute a message if it cannot validate
>one or more outer signatures."

[JSP: I respectfully disagree with this comment.  A user could send a
double-wrapped message (i.e. envelopedData encapsulating signedData) to an
MLA in which there is not an outer signedData.  Furthermore, a user may send
a single-wrapped signedData or envelopedData message to an MLA in which
there is not an outer signedData.] 

>10.  Section 4.2.1, Bullet 2.
>This is along the lines of a question,  Should the new RecipientInfos be
>unioned with the existing set or replaced.  There are no security
>reasons why it cannot be replacement but this seems odd to me.

[JSP:  The MLA deletes the existing recipientInfos and builds a new
recipientInfo for each member of the ML.  The recipientInfos in the original
message are not needed in the MLA-expanded message because those users can
decrypt the original message.  For example, user 1 sends a message
containing recipientInfos for: ML1, Tom and Dick.  ML1, Tom and Dick each
receive their copy of the message and decrypt it using their copy of
recipientInfo.  The MLA representing ML1 will expand the copy of the message
that it received.  The recipientInfos for ML1, Tom and Dick are not required
in the MLA-expanded message, because the message is not being sent to ML1,
Tom and Dick.  It is being sent to the ML recipients.]

>13.  Section 1.4 and Appendix A.  We should not be refering to the imc
>URL for the oids anymore or saying we intend to move to IANA to keep the
>registry.   Recommend deletion of section 1.4 and the inclusion of the
>OIDs used by this draft in Appendix A.

[JSP: Why can't we refer to the S/MIME OIDs document?  It includes an ASN.1
module that includes all of the OIDs.  The ESS and CMS modules can immport
this module.]

Date: Thu, 26 Feb 1998 12:06:16 -0500
To: Russ Housley <[email-masked]>, Paul Hoffman / IMC <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: ESS-02 Comments
Cc: [email-masked]
Sender: [email-masked]

Russ,

The CMS and ESS modules could import the OIDs from the S/MIME OIDs module.
Defining the OIDs in multiple modules invites inconsistencies.

- John Pawling

At 09:40 AM 2/26/98 -0500, Russ Housley wrote:
>Paul:
>
>The OID in the registry is not sufficient.  Please look at CMS Appendix A,
>and you will see that the OIDs needed to implement CMS are part of the CMS
>module.
>
>Russ

Date: Thu, 26 Feb 1998 11:37:26 -0500
To: "'IETF S/MIME'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: ESS-02 MLA and OriginatorInfo
Sender: [email-masked]

All, I agree with Scott. - John Pawling

At 07:52 AM 2/26/98 PST, Scott Hollenbeck wrote:
>Section 4.2.1 of ESS-02 describes MLA processing of an EnvelopedData
>message.  It correctly describes how the MLA must replace existing
>RecipientInfo structures with new structures created for each list
>member.  However, I think we've left something out because the MLA
>must also replace the existing OriginatorInfo structure and we don't
>mention that anywhere.
>
>I suggest we move the current paragraphs numbered 3 and 4 to 4 and 5
>respectively, and add a new paragraph 3 as follows:
>
>"3. The MLA removes the existing originatorInfo field and replaces
>it with a new originatorInfo value built from information describing
>the MLA."
>
>----->
>Scott Hollenbeck (mailto:[email-masked])
>Xerox Special Information Systems
>Arlington, Virginia, USA
>
>
>

Date: Thu, 26 Feb 1998 09:40:52 -0500
To: Paul Hoffman / IMC <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: ESS-02 Comments
Cc: [email-masked]
Sender: [email-masked]

Paul:

The OID in the registry is not sufficient.  Please look at CMS Appendix A,
and you will see that the OIDs needed to implement CMS are part of the CMS
module.

Russ

At 05:12 PM 2/25/98 -0800, Paul Hoffman / IMC wrote:
>At 04:26 PM 2/25/98 -0500, David P. Kemp wrote:
>>1) Sec 1.1.1: The first paragraph was a bit difficult to parse.
>>Recommend changing it to: "Not all messages need to be triple wrapped.
>>Triple wrapping is used when a message must be signed, then encrypted,
>>and then have authenticated attributes bound to the encrypted body.
>>Outer attributes may be added or removed by the message originator or
>>intermediate agents, and may be authenticated by intermediate agents or
>>the final recipient."
>
>This looks good to me. Do others like the new wording?
>
>>2) Appendix A: Please add the definition of the id-ct-receipt OID to
>>the ASN.1 module, if the OID will not be imported from CMS or
>>another module.  id-ct-receipt is not currently included in any of the
>>Internet-Drafts, nor are any of the new authenticated attributes.
>
>id-ct-receipt is defined in the OIDs registry at
><http://www.imc.org/ietf-smime/oids.html>, as described in ESS section 1.4.
>
>>It would be useful to include the OIDs for all the attributes defined
>>in Sec 1.3.4 in an ASN.1 module (ESS, CMS, or other), and harmonize the
>>name of the attribute with the name of the OID listed in the object
>>registry:
>
>Good suggestion. Done.
>
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
> 

Date: Thu, 26 Feb 1998 11:08:16 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: ESS EncapsulatedContentType
Sender: [email-masked]

> From: [email-masked] (John Pawling)
> 
> I respectfully disagree with Dave that contentType should be removed from
> the Receipt content syntax.  It is included in the signed receipt to assist
> the application that must validate the signed receipt with the process of
> identifying the original message (or hash of the message) that requested the
> signed receipt.  The original message (or hash of the message) is required
> to validate the signed receipt.  The Receipt contentType will especially be
> valuable to apps that must manage contents of multiple types.  Therefore, I
> believe that contentType should be retained and that it should be changed to
> a mandatory field which will always contain the value copied from the
> signedData encapContentInfo eContentType field of the message requesting the
> signed receipt.

I don't object to keeping contentType in Receipt if it serves a purpose.
However, I still don't understand what the purpose is.  Currently, the
eContentType field of the innermost signed data will *always* contain
id-data, no?  If Russ' proposal to define 4 additional OIDs for X.411
builtin message types, or my (as yet unproposed) proposal to define
a single id-data-x411 OID for X.411 messages is adopted, there will
be at most a few eContentType values.  In practice, a single user
is not likely to have both S/MIME and X.411 original messages awaiting
receipts, so the contentType field in the Receipt will be totally
useless in distinguishing which message the receipt applies to.
At best, it could only help distinguish between S/MIME and X.411 messages.

Even then (if there were multiple content types), what is the purpose
of including contentType in the Receipt?  The Receipt
signedContentIdentifier uniquely identifies the message to which the
receipt applies, so the UA only needs to validate the receipt against
that single message.

What am I missing?

From: Scott Hollenbeck <[email-masked]>
To: "'IETF S/MIME'" <[email-masked]>
Subject: ESS-02 MLA and OriginatorInfo
Date: Thu, 26 Feb 1998 07:52:33 PST
Sender: [email-masked]

Section 4.2.1 of ESS-02 describes MLA processing of an EnvelopedData
message.  It correctly describes how the MLA must replace existing
RecipientInfo structures with new structures created for each list
member.  However, I think we've left something out because the MLA
must also replace the existing OriginatorInfo structure and we don't
mention that anywhere.

I suggest we move the current paragraphs numbered 3 and 4 to 4 and 5
respectively, and add a new paragraph 3 as follows:

"3. The MLA removes the existing originatorInfo field and replaces
it with a new originatorInfo value built from information describing
the MLA."

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

Date: Thu, 26 Feb 1998 10:26:48 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: RE: ESS-02 Comments
Sender: [email-masked]

All,

My responses to Jim's comments are in-line:

At 06:40 PM 2/25/98 -0800, Jim Schaad (Exchange) wrote:
>I have no problems with John's changes except as follows:
<snip>
>
>This actually refers to Sec 2.2, bullet 5.  The text appears to imply
>that the sender must be included on in the receiptsTo field.  This is
>not correct.  I suggest the line be  "The message originator MUST
>populate the rceiptsTo field with a GeneralNames for each entity to whom
>the recipient should send the signed receipt.  The message originator
>MUST include their own Generalnames in the receiptsTo field to receive a
>receipt."

[JSP: I agree.  Great catch.  In my effort to minimize the number of words
in the text, I added a false constraint.  Recommend that Sec 2.3, bullet 5
should be replaced with the following text:     

"5. The message originator MUST populate the receiptsTo field with a
GeneralNames for each entity to whom the recipient should send the signed
receipt.  If the message originator requires that the recipient should send
the signed receipt to the originator, then the originator MUST include a
GeneralNames for itself in the receiptsTo field.  GeneralNames is a SEQUENCE
OF GeneralName.  receiptsTo is a SEQUENCE OF GeneralNames in which each
GeneralNames represents an entity.  There may be multiple GeneralName
instances in each GeneralNames.  At a minimum, the message originator MUST
populate each entity's GeneralNames with the address to which the signed
receipt should be sent.  Optionally, the message originator MAY also
populate each entity's GeneralNames with other GeneralName instances (such
as directoryName)."]

<snip>
>I have the sma issue here as with the above change and would like to see
>similar wording.

[JSP: Agree.  Recommend that Sec 2.7, last para, last sentence should be
changed as follows:

OLD: "The field is mandatory, and the originator's name(s) MUST be included
in the receiptsTo list." 

NEW: The message originator MUST populate the receiptsTo field with a
GeneralNames for each entity to whom the recipient should send the signed
receipt.  If the message originator requires that the recipient should send
the signed receipt to the originator, then the originator MUST include a
GeneralNames for itself in the receiptsTo field."]

<snip>
>This will also require a definition of UTF8String --- should we include
>it at this point or only in the appendix at the end?  I think the
>appendix is sufficient.

[JSP: Appendix is sufficient.]

>> 26) Sec 4.2, intro, 3rd para:  Please delete the following 
>> paragraph:  "When
>> the MLA creates the new attribute list for its signature, the MLA MUST
>> propagate forward each attribute in the old signature, unless the MLA
>> explicitly replaces the attribute with a new value. An MLA 
>> will frequently
>> encounter attributes, or parts of attributes, which it does 
>> not understand.
>> Attributes such as security labels cannot be removed from the 
>> new signature
>> being created without compromising the security of the 
>> system. Because it is
>> impossible to enumerate the future list of attributes which 
>> have security
>> implicitions, an MLA MUST propagate forward all attributes 
>> which it does not
>> explicity replace
>
>I would like to see this pargraph kept, in part because it gives a
>rational for what follows in the next item.

[JSP: I respectfully disagree.  I believe that the aforementioned paragraph
is confusing because it does not distinguish between the inner and outer
signedData objects.  I believe that the following text expresses the
requirements more accurately and is placed in the optimal place in the MLA
processing description to emphasize the fact that we are talking about the
MLA creating/replacing the outer signedData object (and that this has
nothing to do with the inner signedData object).  Furthermore, this is the
only place in the processing description that needs to address this topic,
so there is no need for an intro para earlier in the text.]

>> 27) sec 4.2.2, bullet 3.2.1 should be changed as follows:
>> 
>>  OLD: 3.2.1. The MLA strips the existing outermost SignedData layer 
>>              after remembering the value of the mlExpansionHistory 
>>              attribute in that layer, if one was there.
>> 
>>  NEW: 3.2.1. The MLA strips the existing outermost SignedData layer 
>>              after remembering the value of the 
>>              mlExpansionHistory and 
>>              all other authenticated attributes in that layer, if 
>>              present.
>> 
>> 
>> 28) sec 4.2.2, bullet 3.2.3, first para, should be changed as follows:
>> 
>>  OLD: 3.2.3. The MLA adds an mlExpansionHistory attribute. The 
>>              SignedData layer created by the MLA replaces the 
>>              original 
>>              outermost SignedData layer.
>> 
>>  NEW: 3.2.3. The outermost signedData layer created by the MLA 
>>              replaces the original outermost signedData layer.  The 
>>              MLA MUST create an authenticated attribute list for the 
>>              new outermost signedData layer which MUST include each 
>>              authenticated attribute present in the original 
>>              outermost 
>>              signedData layer, unless the MLA explicitly replaces the 
>>              attribute with a new value.  A special case is the 
>>              mlExpansionHistory attribute.  The MLA MUST add an 
>>              mlExpansionHistory authenticated attribute to the outer 
>>              signedData layer as follows: ....
>> 
>> 
>
> 
>

Date: Thu, 26 Feb 1998 10:07:21 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: CMS-03 Comments
Sender: [email-masked]

> From: Russ Housley <[email-masked]>
> 
> I added SIZE in four places.  Here is the updated ASN.1:
> AuthAttributes ::= SET SIZE (1..MAX) OF AuthAttribute
> 
> AuthAttribute ::= SEQUENCE { 
>   attrType OBJECT IDENTIFIER, 
>   critical BOOLEAN DEFAULT FALSE, 
>   attrValues SET SIZE (1..MAX) OF AttributeValue }

That's fine with me.  I hesitated to constrain the number of attrValues
because conceivably the attrType OID alone would be sufficient to
convey the meaning of a particular (future-defined) attribute.  But
either way is OK.

Date: Thu, 26 Feb 1998 09:54:23 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: ESS-02 Comments
Sender: [email-masked]

All,

I like the new wording.

- John Pawling

At 05:12 PM 2/25/98 -0800, Paul Hoffman / IMC wrote:
>At 04:26 PM 2/25/98 -0500, David P. Kemp wrote:
>>1) Sec 1.1.1: The first paragraph was a bit difficult to parse.
>>Recommend changing it to: "Not all messages need to be triple wrapped.
>>Triple wrapping is used when a message must be signed, then encrypted,
>>and then have authenticated attributes bound to the encrypted body.
>>Outer attributes may be added or removed by the message originator or
>>intermediate agents, and may be authenticated by intermediate agents or
>>the final recipient."
>
>This looks good to me. Do others like the new wording?

<snip>

Date: Thu, 26 Feb 1998 09:51:37 -0500
To: Russ Housley <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Criticality of Authenticated Attributes
Cc: [email-masked]
Sender: [email-masked]

Russ,

I still believe that the legacy software is an issue because it will reject
the signedData when it detects the new version number that it doesn't
recognize, so the outcome is the same (i.e. the signedData won't be decoded
and verified).  However, your recommended wording is fine with me.

- John Pawling

At 09:26 AM 2/26/98 -0500, Russ Housley wrote:
>John:
>
>I do not think that "legacy software" is an issue.  If any of the=
 attributes
>are critical, the version number should handle that situation.
>
>How about: =20
>Caution should be exercised in adopting any critical attributeswhich might
>reduce interoperability.=20
>Russ
>
>At 05:28 PM 2/25/98 -0500, John Pawling wrote:
>>All,
>>
>>I agree with Russ.=A0 Furthermore, I believe that essSecurityLabel should=
 be
>>the only attribute that is required to always be critical.=A0 ESS should=
 not
>>require criticality for attributes that legacy products need to process
>>(contentType, messageDigest, signingTime, smimeCapabilities).=A0 I don't
>>believe that the following new attributes should be mandated to always be
>>critical: contentIdentifier, mlExpansionHistory, receiptRequest, and
>>contentHints.=A0 So, that only leaves essSecurityLabel as being mandatory
>>critical.
>>
>>Furthermore, I recommend that the following text should be added to the
>>description of the critical flag in CMS, Sec 5.2: "Note that setting
>>critical to TRUE will cause interoperability problems with legacy software
>>that does not recognize the AuthAttribute ASN.1 syntax."
>>
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
>>John Pawling=A0=A0=20
>>[email-masked]=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=20
>>J.G. Van Dyke & Associates, Inc.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D

Date: Thu, 26 Feb 1998 09:26:32 -0500
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: Re: Criticality of Authenticated Attributes
Cc: [email-masked], [email-masked]
Sender: [email-masked]

John:

I do not think that "legacy software" is an issue.  If any of the attributes
are critical, the version number should handle that situation.

How about:  
Caution should be exercised in adopting any critical attributeswhich might
reduce interoperability. 
Russ

At 05:28 PM 2/25/98 -0500, John Pawling wrote:
>All,
>
>I agree with Russ.  Furthermore, I believe that essSecurityLabel should be
>the only attribute that is required to always be critical.  ESS should not
>require criticality for attributes that legacy products need to process
>(contentType, messageDigest, signingTime, smimeCapabilities).  I don't
>believe that the following new attributes should be mandated to always be
>critical: contentIdentifier, mlExpansionHistory, receiptRequest, and
>contentHints.  So, that only leaves essSecurityLabel as being mandatory
>critical.
>
>Furthermore, I recommend that the following text should be added to the
>description of the critical flag in CMS, Sec 5.2: "Note that setting
>critical to TRUE will cause interoperability problems with legacy software
>that does not recognize the AuthAttribute ASN.1 syntax."
>
>================================
>John Pawling   
>[email-masked]                             
>J.G. Van Dyke & Associates, Inc.           
>================================
>
>
>At 08:48 AM 2/25/98 -0500, Russ Housley wrote:
>>Paul:
>>
>>Please add a sentence to the description of each authenticated attribute.
>>We need to specify whether the attribute is always critical, never
>>critical, or the originator's choice.
>>
>>I think that security label should always be critical.
>>
>>Russ
>>
>>
>  

Date: Thu, 26 Feb 1998 08:49:56 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: ESS EncapsulatedContentType
Sender: [email-masked]

All,

I agree with Dave Kemp that contentType should be removed from the ESS
receiptRequest attribute because it is redundant to the signedData
encapContentInfo eContentType OID.  This results in:

   ReceiptRequest ::= SEQUENCE {
      signedContentIdentifier ContentIdentifier,
      receiptsFrom ReceiptsFrom,
      receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames }

I respectfully disagree with Dave that contentType should be removed from
the Receipt content syntax.  It is included in the signed receipt to assist
the application that must validate the signed receipt with the process of
identifying the original message (or hash of the message) that requested the
signed receipt.  The original message (or hash of the message) is required
to validate the signed receipt.  The Receipt contentType will especially be
valuable to apps that must manage contents of multiple types.  Therefore, I
believe that contentType should be retained and that it should be changed to
a mandatory field which will always contain the value copied from the
signedData encapContentInfo eContentType field of the message requesting the
signed receipt. This results in:

Receipt ::= SEQUENCE {
  version                   Version,  
  contentType               ContentType,
  signedContentIdentifier   ContentIdentifier,
  originatorSignatureValue  OCTET STRING }

If nobody objects to the deletion of contentType from receiptRequest and the
retention of contentType in the Receipt content, then the following changes
need to be made to ESS:

1) Sec 2.2: Please delete bullet 2 stating: "2. The encapsulated content
type is optionally noted in the
encapsulatedContentType field."

2) Sec 2.4, bullet 2.2:  Please make the following change:
 
OLD: 2.2. The encapsulatedContentType and signedContentIdentifier
     values are copied from the original signedData signerInfo 
     receiptRequest attribute into the corresponding fields in the 
     Receipt structure.

NEW: 2.2. The original signedData encapContentInfo eContentType object 
     identifier is copied into the Receipt contentType.

     2.3. The original signedData signerInfo receiptRequest 
     signedContentIdentifier is copied into the Receipt  
     signedContentIdentifier.

3) Sec 2.8, last para:  Please change as follows:

OLD: "The encapsulatedContentType and signedContentIdentifier fields are
copied from the receiptRequest attribute of the SignerInfo contained within
the message being receipted, and are used to link the receipt to the
original signed message. The originatorSignatureValue field contains the
signatureValue copied from the SignerInfo requesting the signed receipt."

NEW: "The contentType, signedContentIdentifier and originatorSignatureValue
fields are copied from the original signedData object that requested the
signed receipt (see Sec 2.4), and are used to link the signed receipt to the
original signed message." 

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

Date: Thu, 26 Feb 1998 08:16:26 -0500
To: [email-masked] (David P. Kemp)
From: Russ Housley <[email-masked]>
Subject: Re: CMS-03 Comments
Cc: [email-masked]
Sender: [email-masked]

Dave:

>How about adding a size constraint to the ASN.1.  Do we envision
>ever needing an empty set of authenticated or unauthenticated
>attributes?
>
>  AuthAttributes ::= SET SIZE(1..MAX) OF AuthAttribute
>
>  UnauthAttributes ::= SET SIZE(1..MAX) OF UnauthAttribute

I added SIZE in four places.  Here is the updated ASN.1:
AuthAttributes ::= SET SIZE (1..MAX) OF AuthAttribute

AuthAttribute ::= SEQUENCE { 
  attrType OBJECT IDENTIFIER, 
  critical BOOLEAN DEFAULT FALSE, 
  attrValues SET SIZE (1..MAX) OF AttributeValue }

UnauthAttributes ::= SET SIZE (1..MAX) OF UnauthAttribute

UnauthAttribute ::= SEQUENCE { 
  attrType OBJECT IDENTIFIER, 
  attrValues SET SIZE (1..MAX) OF AttributeValue }

AttributeValue ::= ANY 
Russ 

From: ross <[email-masked]>
To: Russ Housley <[email-masked]>, [email-masked], John Pawling <[email-masked]>
MMDF-Warning:  Parse error in original version of preceding line at post.mail.demon.net
Cc: [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at post.mail.demon.net
Subject: Re: Criticality of Authenticated Attributes
Date: Thu, 26 Feb 1998 08:29:41 -0800
Sender: [email-masked]

For the record, I also agree with Russ and John.
-----Original Message-----
From: John Pawling <[email-masked]>
To: Russ Housley <[email-masked]>; [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Wednesday, February 25, 1998 2:59 PM
Subject: Re: Criticality of Authenticated Attributes

>All,
>
>I agree with Russ.  Furthermore, I believe that essSecurityLabel should be
>the only attribute that is required to always be critical.  ESS should not
>require criticality for attributes that legacy products need to process
>(contentType, messageDigest, signingTime, smimeCapabilities).  I don't
>believe that the following new attributes should be mandated to always be
>critical: contentIdentifier, mlExpansionHistory, receiptRequest, and
>contentHints.  So, that only leaves essSecurityLabel as being mandatory
>critical.
>
>Furthermore, I recommend that the following text should be added to the
>description of the critical flag in CMS, Sec 5.2: "Note that setting
>critical to TRUE will cause interoperability problems with legacy software
>that does not recognize the AuthAttribute ASN.1 syntax."
>
>================================
>John Pawling   
>[email-masked]                             
>J.G. Van Dyke & Associates, Inc.           
>================================
>
>
>At 08:48 AM 2/25/98 -0500, Russ Housley wrote:
>>Paul:
>>
>>Please add a sentence to the description of each authenticated attribute.
>>We need to specify whether the attribute is always critical, never
>>critical, or the originator's choice.
>>
>>I think that security label should always be critical.
>>
>>Russ
>>
>>
>

From: "Michael Myers" <[email-masked]>
To: "Rich Ankney" <[email-masked]>, "'Ietf-Smime (E-mail)'" <[email-masked]>, "John Pawling" <[email-masked]>
Subject: Re: Inclusion of the issuer and serial number in authenticated information
Date: Wed, 25 Feb 1998 20:23:18 -0700
Sender: [email-masked]

Would this capability be used to intentionally transit a well-defined domain
of authority?

Would, say, a SET certificate issuer have any problems with an application
that enables S/MIME usage of a SET-certified public key and corresponding
private key?

Or is this capability being established to facilitate, for example, the
sharing of a key pair among a group of related users, all of whom are
operating within the same domain of authority?

If the intent is to address the former, either singly or in combination with
the likes of the latter example, then attention should be given to technical
enforcement of policy.

In any case, use of a hash of the CA's public key in the message should be
aligned with the use of keyIdentifier form of AuthorityKeyIdentifier in
end-entity certificates.

Mike

-----Original Message-----
From: Rich Ankney <[email-masked]>
To: 'Ietf-Smime (E-mail)' <[email-masked]>; John Pawling
<[email-masked]>
Date: Wednesday, February 25, 1998 6:44 PM
Subject: Re: Inclusion of the issuer and serial number in authenticated
information

>I've been having a side conversation with Ambarish Malpani of Valicert.
>He raised the following question (in a different context):  can we really
>ensure that the issuer DN is unique?  Clearly it will (or should) be in
>the context of a single root CA (assuming each CA ensures there are
>no duplicates in the names it certifies).  But this may not be true where
>we have cross-certification.  Should we include something else to make
>the construct unique (e.g. hash of the CA public key)?  (This affects
>things besides CMS, of course...)
>
>Regards,
>Rich
>
>----------
>> From: John Pawling <[email-masked]>
>> To: 'Ietf-Smime (E-mail)' <[email-masked]>
>> Subject: RE: Inclusion of the issuer and serial number in authenticated
>information
>> Date: Wednesday, February 25, 1998 5:02 PM
>>
>> All,
>>
>> I agree with Jim Schaad's issuer/serialNumber authenticated attribute
>> proposal because:
>>
>> 1) I agree that it meets a valid requirement because it is certainly
>> possible to have multiple certs containing the same public key material.
>>
>> 2) It provides the flexibility to bind the signer's cert (via the
>> issuer/serialNumber) with the signed data without forcing the signer to
>> always include the signer's cert in the signedData object.  In other
>words,
>> if the signer knows that the recipient already has the signer's cert,
>then
>> the signer should not be forced to send the signer's cert in the
>signedData.
>>
>> 3) It is backwards compatible with S/MIME v2 legacy software because the
>> legacy software will ignore the new attribute, but it can still verify
>the
>> signedData signature.
>>
>> ================================
>> John Pawling
>> [email-masked]
>> J.G. Van Dyke & Associates, Inc.
>> ================================
>>
>>
>>
>>
>

Date: Thu, 26 Feb 1998 10:21:34 +0530
From: abhishek gupta <[email-masked]>
Reply-To: [email-masked]
Organization: HCL-Technologies
To: Rich Ankney <[email-masked]>
Cc: "'Ietf-Smime (E-mail)'" <[email-masked]>, John Pawling <[email-masked]>
Subject: Re: Inclusion of the issuer and serial number in authenticated information
Sender: [email-masked]

Rich Ankney wrote:
> 
> I've been having a side conversation with Ambarish Malpani of Valicert.
> He raised the following question (in a different context):  can we really
> ensure that the issuer DN is unique?  Clearly it will (or should) be in
> the context of a single root CA (assuming each CA ensures there are
> no duplicates in the names it certifies).  But this may not be true where
> we have cross-certification.  Should we include something else to make
> the construct unique (e.g. hash of the CA public key)?  (This affects
> things besides CMS, of course...)

I feel what that in the wake of the ceaseless
expansion of the Net, and the ever increasing
commerce through it, and our accepting the
need and urgency of the security aspects - in
a never before fashion, it becomes important
that we try to come up with some
international consensus on a central
certificate issuing and managing authority.
Something like what IANA is for IP addresses.
The central assigned authority can be
responsible for passing the busk for issuing
certificates to different authorities, and
also see to the uniqueness of the serial
numbers, by supplying a different set of
number to each of them.

Also it would be advisable to have a
foresight to the magnitude of the serial
numbers and other associated numbers required
for the cause, to prevent some number crunch
in the near future, since this thing is
really going to catch on. Learning from past
for a better future is the IT industry's
motto.

Regards
Abhishek Gupta

> 
> Regards,
> Rich
> 
> ----------
> > From: John Pawling <[email-masked]>
> > To: 'Ietf-Smime (E-mail)' <[email-masked]>
> > Subject: RE: Inclusion of the issuer and serial number in authenticated
> information
> > Date: Wednesday, February 25, 1998 5:02 PM
> >
> > All,
> >
> > I agree with Jim Schaad's issuer/serialNumber authenticated attribute
> > proposal because:
> >
> > 1) I agree that it meets a valid requirement because it is certainly
> > possible to have multiple certs containing the same public key material.
> >
> > 2) It provides the flexibility to bind the signer's cert (via the
> > issuer/serialNumber) with the signed data without forcing the signer to
> > always include the signer's cert in the signedData object.  In other
> words,
> > if the signer knows that the recipient already has the signer's cert,
> then
> > the signer should not be forced to send the signer's cert in the
> signedData.
> >
> > 3) It is backwards compatible with S/MIME v2 legacy software because the
> > legacy software will ignore the new attribute, but it can still verify
> the
> > signedData signature.
> >
> > ================================
> > John Pawling
> > [email-masked]
> > J.G. Van Dyke & Associates, Inc.
> > ================================
> >
> >
> >
> >

Date: Thu, 26 Feb 1998 10:13:28 +0530
From: abhishek gupta <[email-masked]>
Reply-To: [email-masked]
Organization: HCL-Technologies
To: Ed Gerck <[email-masked]>
Cc: John Lowry <[email-masked]>, Stephen Klump <[email-masked]>, "'Ietf-Smime (E-mail)'" <[email-masked]>, "'Jim Schaad (Exchange)'" <[email-masked]>
Subject: Re: Inclusion of the issuer and serial number in authenticated  information
Sender: [email-masked]

Hi

I agree that inclusion of issuer's serial
number must be there in the certificate. If
this is not so then we are working on a basic
assumption that all the issuer's are
absolutely trusted, and hence there is no
need to check repudiation from them. This
should not be the case and the issuing
authority too should be checked for
non-repudiation.

Regards
Abhishek gupta

Date: Thu, 26 Feb 1998 09:42:37 +0530
From: abhishek gupta <[email-masked]>
Reply-To: [email-masked]
Organization: HCL-Technologies
To: Stephen Klump <[email-masked]>
Cc: "'Ietf-Smime (E-mail)'" <[email-masked]>, "'Jim Schaad (Exchange)'" <[email-masked]>
Subject: Re: Inclusion of the issuer and serial number in authenticated information
Sender: [email-masked]

Hi,

Pardon me if I am wrong, but under the
constraint of a single certificate per key,
the holder of the certificate can no longer
act on a trusted as well as non trusted
basis. The person concerned may not always
intend the intent of certificate to be
trusted even though he might have full intent
of accepting non-repudiation of the sent
information.

Regards
abhishek gupta

From: "Blake Ramsdell" <[email-masked]>
To: "'Rich Ankney'" <[email-masked]>, "'Ietf-Smime (E-mail)'" <[email-masked]>, "John Pawling" <[email-masked]>
Subject: RE: Inclusion of the issuer and serial number in authenticated in formation
Date: Wed, 25 Feb 1998 19:10:43 -0800
Sender: [email-masked]

On Wednesday, February 25, 1998 5:49 PM, Rich Ankney
[SMTP:[email-masked]] wrote:
> I've been having a side conversation with Ambarish Malpani of
Valicert.
> He raised the following question (in a different context):  can we
> really
> ensure that the issuer DN is unique?  Clearly it will (or should) be
in
> 
> the context of a single root CA (assuming each CA ensures there are
> no duplicates in the names it certifies).  But this may not be true
> where
> we have cross-certification.  Should we include something else to make
> the construct unique (e.g. hash of the CA public key)?  (This affects
> things besides CMS, of course...)

I don't think that there is any problem with multiple issuers with the
same name (besides the inconvenience).  The cert path using the wrong
issuer certificate will fail cryptographically (the signature check will
fail), so the path will be broken, and the signature will not be
trusted.  I have seen at least two X.509 cert path implementations that
implement a certificate database using the combination of issuer name
and serial number as the primary key into the database, so I think that
the worst attack is denial of service (getting the "wrong" cert
identified by issuer and serial number).

There are other cases (such as the one that Ambarish is worried about)
where there is no cryptographic binding -- the case in point is OCSP
where you request the revocation status of a certificate by specifying
the issuer name and serial number, and there is no real binding to
either the issuing CA certificate or the certificate for which you are
checking the status, since the response is not necessarily signed by the
issuer private key.  I may have characterized this incorrectly, so
someone slap me if I'm wrong.

Now that I think about it, I could be all wrong about everything I've
said here.  It happens.  I get tired.  Corrections welcome.

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

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: ESS-02 Comments part 2
Date: Wed, 25 Feb 1998 18:40:05 -0800
Sender: [email-masked]

1.  Section 1 pargraph #2:  Since as time goes by it becomes harder for
me to understand what sections of this document require SMIME3 and what
can be implemented using SMIME2, I would like to be explicit here.
Replace with the following paragraph: "The services described here are
extensions to S/MIME version 2 [SMIME2] and S/MIME version 3 [SMIME3].
The Security Label and Mail List Agent services can be added to S/MIME
version 2, but the Secure Reciepts service requires [CMS] and can only
be added to S/MIME version 3."  then contue with the last sentence.

Please note that I am note sure that MLAs can be implemented using v2
S/MIME since I remember that there are some wrapping and nesting
implementations in the original specs and I don't remember how much got
removed when went into the IETF.

2.  Section 1.2:  This applies both to the current spec and to the
modification suggested by John.  Lets reverse the order of the wrapping
so we go from outermost to inner most (thus matching what one sees when
reading one of these things) and add some indentiation so that we can
assoicate wrapping layers with the steps in section 1.1.2.

3. Section 1.3.4  It would be convenent to add a column which defines in
what document each of the attributes is defined.  The list that I have
today would be:
contentHints		ESS
contentIdentifer		ESS
contentType			CMS
counterSignature		CMS
messageDigest		CMS
mlExpansionHistory	ESS
receiptRequest		ESS
signingTime			CMS
smimeCapabilites		SMIME3
essSecurityLabel		ESS
msgSigDigest		ESS			inner only
yes

4.  Section 1.5 -- I would like to add a new section at this point to
define and describe the new ESS attributes which can be used outside of
the three different security services.  The exception to this is
contentHints,  I would like to see contentHints move from the ESS to the
CMS drafts.  This attribute is going to be useful for a number of
different services (such as PKIP) and I see no reason why they should
reference ESS just to get this one attribute.

5.  Section 2.10 -- Please insert a section describing the
msgDigestAttribute here:
2.10  Message Digest Attribute

This attribute is used only in a Secure Receipt authenticated attributes
section.  It contains the message digest of the SignedData object for
which a receipt is being created.  Only one msgDigestAttribute can
appear in an authenteicated attributes set.

ASN goes here...

6.  Section 2.9 -- Please move this from the ESS draft to the CMS draft.

7.  Section 3.1.1  Please add the following sentence to the end of the
last paragraph. "A local security policy should exist for handling of
messages which contain an eSSSecurityLabel attribute only in SignerInfos
which cannot be validated."

8.  Section 4.1, paragraph 4.

9.  Section 4.1, paragraph 5.  Please as the following sentence.  "An
MLA SHOULD NOT expand and redistribute a message if it cannot validate
one or more outer signatures."

10.  Section 4.2.1, Bullet 2.
This is along the lines of a question,  Should the new RecipientInfos be
unioned with the existing set or replaced.  There are no security
reasons why it cannot be replacement but this seems odd to me.

11.  Section 4.4 paragraph 1.  Replace "the processing agent should
return an error." with "the processing agent should provide notification
of the error to a human mail list adminstrator.  The mail list
administrator is responsible for correcting the overflow condition."

12.  Section 4.4.  We are in the process of removing almost every other
instance of a bounded sequence.  Do we want to remove the bound of
ub-ml-expansion-history as well?  I see no reason not to and recomend we
do so.  This would create the following changes:
 - Remove the last sentence in Section 4.4 paragraph 1.
 - Change the ASN to
    MLExpansionHistory ::= SEQUENCE SIZE (1..MAX) OF MLData
 - delete the definition of ub-ml-expansion-history.

13.  Section 1.4 and Appendix A.  We should not be refering to the imc
URL for the oids anymore or saying we intend to move to IANA to keep the
registry.   Recommend deletion of section 1.4 and the inclusion of the
OIDs used by this draft in Appendix A.

From: "Jim Schaad (Exchange)" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: ESS-02 Comments
Date: Wed, 25 Feb 1998 18:40:03 -0800
Sender: [email-masked]

I have no problems with John's changes except as follows:

> 9) Sec 2.3, bullet 5: Please replace bullet 5 with the following: "The
> message originator MUST populate the receiptsTo field so that 
> the recipient
> can determine the address(es) to which to send the signed 
> receipt.  The
> message originator MUST populate the receiptsTo field with a 
> GeneralNames
> for each entity to whom the recipient should send the signed receipt
> including, but not limited to, the message originator itself. 
>  GeneralNames
> is a SEQUENCE OF GeneralName.  receiptsTo is a SEQUENCE OF 
> GeneralNames in
> which each GeneralNames represents an entity.  There may be multiple
> GeneralName instances in the GeneralNames which represents an 
> entity.  At a
> minimum, the message originator MUST populate each entity's 
> GeneralNames
> with the address to which the signed receipt should be sent.  
> Optionally,
> the message originator MAY also populate each entity's 
> GeneralNames with
> other GeneralName instances (such as directoryName)."

This actually refers to Sec 2.2, bullet 5.  The text appears to imply
that the sender must be included on in the receiptsTo field.  This is
not correct.  I suggest the line be  "The message originator MUST
populate the rceiptsTo field with a GeneralNames for each entity to whom
the recipient should send the signed receipt.  The message originator
MUST include their own Generalnames in the receiptsTo field to receive a
receipt."

> 19) Sec 2.7, last para, last sent: Please replace "The field 
> is mandatory,
> and the originator's name(s) MUST be included in the 
> receiptsTo list." with
> "The message originator MUST populate the receiptsTo field with a
> GeneralNames for each entity to whom the recipient should 
> send the signed
> receipt including, but not limited to, the message originator itself."

I have the sma issue here as with the above change and would like to see
similar wording.

> 
> 25) Sec 3.2: Please change ESSPrivacyMark to:
> "ESSPrivacyMark ::= CHOICE {
>   pString      PrintableString SIZE (1..ub-privacy-mark-length),
>   utf8String   UTF8String SIZE (1..MAX)
>   -- If utf8String is used, the contents must be in UTF-8 [UTF8]
> }"

This will also require a definition of UTF8String --- should we include
it at this point or only in the appendix at the end?  I think the
appendix is sufficient.

> 
> 
> 26) Sec 4.2, intro, 3rd para:  Please delete the following 
> paragraph:  "When
> the MLA creates the new attribute list for its signature, the MLA MUST
> propagate forward each attribute in the old signature, unless the MLA
> explicitly replaces the attribute with a new value. An MLA 
> will frequently
> encounter attributes, or parts of attributes, which it does 
> not understand.
> Attributes such as security labels cannot be removed from the 
> new signature
> being created without compromising the security of the 
> system. Because it is
> impossible to enumerate the future list of attributes which 
> have security
> implicitions, an MLA MUST propagate forward all attributes 
> which it does not
> explicity replace

I would like to see this pargraph kept, in part because it gives a
rational for what follows in the next item.

> 
> 
> 27) sec 4.2.2, bullet 3.2.1 should be changed as follows:
> 
>  OLD: 3.2.1. The MLA strips the existing outermost SignedData layer 
>              after remembering the value of the mlExpansionHistory 
>              attribute in that layer, if one was there.
> 
>  NEW: 3.2.1. The MLA strips the existing outermost SignedData layer 
>              after remembering the value of the 
> mlExpansionHistory and 
>              all other authenticated attributes in that layer, if 
>              present.
> 
> 
> 28) sec 4.2.2, bullet 3.2.3, first para, should be changed as follows:
> 
>  OLD: 3.2.3. The MLA adds an mlExpansionHistory attribute. The 
>              SignedData layer created by the MLA replaces the 
> original 
>              outermost SignedData layer.
> 
>  NEW: 3.2.3. The outermost signedData layer created by the MLA 
>              replaces the original outermost signedData layer.  The 
>              MLA MUST create an authenticated attribute list for the 
>              new outermost signedData layer which MUST include each 
>              authenticated attribute present in the original 
> outermost 
>              signedData layer, unless the MLA explicitly replaces the 
>              attribute with a new value.  A special case is the 
>              mlExpansionHistory attribute.  The MLA MUST add an 
>              mlExpansionHistory authenticated attribute to the outer 
>              signedData layer as follows: ....
> 
> 

Date: Wed, 25 Feb 1998 21:15:25 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: "'Ietf-Smime (E-mail)'" <[email-masked]>
Subject: Re: Inclusion of the issuer and serial number in authenticated information
Sender: [email-masked]

For a given issuer, the serial number must be unique.

Rich Ankney wrote:
> 
> I've been having a side conversation with Ambarish Malpani of Valicert.
> He raised the following question (in a different context):  can we really
> ensure that the issuer DN is unique?  Clearly it will (or should) be in
> the context of a single root CA (assuming each CA ensures there are
> no duplicates in the names it certifies).  But this may not be true where
> we have cross-certification.  Should we include something else to make
> the construct unique (e.g. hash of the CA public key)?  (This affects
> things besides CMS, of course...)
> 
> Regards,
> Rich
> 
> ----------
> > From: John Pawling <[email-masked]>
> > To: 'Ietf-Smime (E-mail)' <[email-masked]>
> > Subject: RE: Inclusion of the issuer and serial number in authenticated
> information
> > Date: Wednesday, February 25, 1998 5:02 PM
> >
> > All,
> >
> > I agree with Jim Schaad's issuer/serialNumber authenticated attribute
> > proposal because:
> >
> > 1) I agree that it meets a valid requirement because it is certainly
> > possible to have multiple certs containing the same public key material.
> >
> > 2) It provides the flexibility to bind the signer's cert (via the
> > issuer/serialNumber) with the signed data without forcing the signer to
> > always include the signer's cert in the signedData object.  In other
> words,
> > if the signer knows that the recipient already has the signer's cert,
> then
> > the signer should not be forced to send the signer's cert in the
> signedData.
> >
> > 3) It is backwards compatible with S/MIME v2 legacy software because the
> > legacy software will ignore the new attribute, but it can still verify
> the
> > signedData signature.
> >
> > ================================
> > John Pawling
> > [email-masked]
> > J.G. Van Dyke & Associates, Inc.
> > ================================
> >
> >
> >
> >

Phil
-- 
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
                 http://www.five-points.com
------------------------------------------------------------

From: "Rich Ankney" <[email-masked]>
To: "'Ietf-Smime (E-mail)'" <[email-masked]>, "John Pawling" <[email-masked]>
Subject: Re: Inclusion of the issuer and serial number in authenticated information
Date: Wed, 25 Feb 1998 20:49:16 -0500
Sender: [email-masked]

I've been having a side conversation with Ambarish Malpani of Valicert.
He raised the following question (in a different context):  can we really
ensure that the issuer DN is unique?  Clearly it will (or should) be in 
the context of a single root CA (assuming each CA ensures there are
no duplicates in the names it certifies).  But this may not be true where
we have cross-certification.  Should we include something else to make
the construct unique (e.g. hash of the CA public key)?  (This affects
things besides CMS, of course...)

Regards,
Rich

----------
> From: John Pawling <[email-masked]>
> To: 'Ietf-Smime (E-mail)' <[email-masked]>
> Subject: RE: Inclusion of the issuer and serial number in authenticated
information
> Date: Wednesday, February 25, 1998 5:02 PM
> 
> All,
> 
> I agree with Jim Schaad's issuer/serialNumber authenticated attribute
> proposal because:
> 
> 1) I agree that it meets a valid requirement because it is certainly
> possible to have multiple certs containing the same public key material. 
> 
> 2) It provides the flexibility to bind the signer's cert (via the
> issuer/serialNumber) with the signed data without forcing the signer to
> always include the signer's cert in the signedData object.  In other
words,
> if the signer knows that the recipient already has the signer's cert,
then
> the signer should not be forced to send the signer's cert in the
signedData.
> 
> 3) It is backwards compatible with S/MIME v2 legacy software because the
> legacy software will ignore the new attribute, but it can still verify
the
> signedData signature.
> 
> ================================
> John Pawling   
> [email-masked]                             
> J.G. Van Dyke & Associates, Inc.           
> ================================
> 
> 
> 
> 

Date: Wed, 25 Feb 1998 17:12:49 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: ESS-02 Comments
Sender: [email-masked]

At 04:26 PM 2/25/98 -0500, David P. Kemp wrote:
>1) Sec 1.1.1: The first paragraph was a bit difficult to parse.
>Recommend changing it to: "Not all messages need to be triple wrapped.
>Triple wrapping is used when a message must be signed, then encrypted,
>and then have authenticated attributes bound to the encrypted body.
>Outer attributes may be added or removed by the message originator or
>intermediate agents, and may be authenticated by intermediate agents or
>the final recipient."

This looks good to me. Do others like the new wording?

>2) Appendix A: Please add the definition of the id-ct-receipt OID to
>the ASN.1 module, if the OID will not be imported from CMS or
>another module.  id-ct-receipt is not currently included in any of the
>Internet-Drafts, nor are any of the new authenticated attributes.

id-ct-receipt is defined in the OIDs registry at
<http://www.imc.org/ietf-smime/oids.html>, as described in ESS section 1.4.

>It would be useful to include the OIDs for all the attributes defined
>in Sec 1.3.4 in an ASN.1 module (ESS, CMS, or other), and harmonize the
>name of the attribute with the name of the OID listed in the object
>registry:

Good suggestion. Done.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Wed, 25 Feb 1998 13:55:40 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: ESS EncapsulatedContentType
Sender: [email-masked]

> From: Russ Housley <[email-masked]>
> 
> All:
> 
> ESS currently includes this definition.
> 
>   EncapsulatedContentType ::= CHOICE {
>     built-in ...
>     external ...
>     externalWithSubtype ... }
> 
> External is an OID, and it is similar to the content type carried in
> signed-data.  We could eliminate the built-in if we assigned OIDs for each
> of the few integers that are assigned.  This would simplify the structure.
> 
> The externalWithSubtype will not be used often, and the subtype is not
> really important in the receipt request context.  It is really used to flag
> that automatic processing of the message is necessary.  Therefore, I
> propose moving the subtype to a separtae authenticated attribute.
> 
> If people accept both of these proposals, then the ESS document should use
> the content type attribute defined in the CMS document.

ESS included the definition of EncapsulatedContentType, which was used
only in ReceiptRequest and Receipt.  Since both of these structures
include the mandatory field signedContentIdentifier which uniquely
ties the receipt to the request, there would seem to be no reason
to also include the OPTIONAL encapsulatedContentType field.

Instead of replacing EncapsulatedContentType with ContentType, I
propose that the content type field be deleted entirely from
the two structures, yielding:

   ReceiptRequest ::= SEQUENCE {
      signedContentIdentifier ContentIdentifier,
      receiptsFrom ReceiptsFrom,
      receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames }
 
   Receipt ::= SEQUENCE {
      version Version,
      signedContentIdentifier ContentIdentifier,
      originatorSignatureValue OCTET STRING }

( Note that if the inclusion of EncapsulatedContentType was an attempt
to accommodate X.411 delivery reports, it was a highly incomplete
attempt.  X.411 defines:

  PerReportDeliveryFields ::= SET {
      subject-submission-identifier SubjectSubmissionIdentifier,
      content-identifier ContentIdentifier OPTIONAL,
      content-type ContentType OPTIONAL,
      original-encoded-information-types ... OPTIONAL,
      extensions [1] IMPLICIT EXTENSIONS CHOSEN FROM {
         message-security-label,
         content-correlator,
         originator-and-DL-expansion-history,
         reporting-DL-name,
         reporting-MLA-certificate,
         report-origin-authentication-check } DEFAULT {} }

So selecting just the content-type field for inclusion in S/MIME
receipts in no way enables support for X.411 delivery reports. )

If there is no requirement satisfied by the inclusion of an optional
contentType in ReceiptRequest and Receipt, then that field should be
eliminated.

  Dave Kemp

Date: Wed, 25 Feb 1998 16:26:29 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: ESS-02 Comments
Sender: [email-masked]

Here are a couple of comments in addition to John's comprehensive
list of 38 changes:

1) Sec 1.1.1: The first paragraph was a bit difficult to parse.
Recommend changing it to: "Not all messages need to be triple wrapped.
Triple wrapping is used when a message must be signed, then encrypted,
and then have authenticated attributes bound to the encrypted body.
Outer attributes may be added or removed by the message originator or
intermediate agents, and may be authenticated by intermediate agents or
the final recipient."

2) Appendix A: Please add the definition of the id-ct-receipt OID to
the ASN.1 module, if the OID will not be imported from CMS or
another module.  id-ct-receipt is not currently included in any of the
Internet-Drafts, nor are any of the new authenticated attributes.

It would be useful to include the OIDs for all the attributes defined
in Sec 1.3.4 in an ASN.1 module (ESS, CMS, or other), and harmonize the
name of the attribute with the name of the OID listed in the object
registry:

Attribute                   OID
--------------------     ----------------------
contentHints             id-aa-contentHint
contentIdentifier        id-aa-contentIdentifier
contentType              id-contentType
counterSignature         id-countersignature
encapsulatedContentType  (delete id-aa-encapContentType from OID registry)
messageDigest            id-messageDigest
mlExpansionHistory       id-aa-mlExpandHistory
receiptRequest           id-aa-receiptRequest
signingTime              id-signingTime
smimeCapabilities        (referenced in -msg draft, not in OID registry)
essSecurityLabel         id-aa-securityLabel
(*** add to table 1.3.4) id-aa-msgSigDigest 

Date: Wed, 25 Feb 1998 12:40:20 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: RE: Inclusion of the issuer and serial number in authenticated information
Sender: [email-masked]

> From: John Lowry <[email-masked]>
> 
> Not a stupid statement, but incorrect nonetheless ...  :-)

I have to agree with Stephen - the statement is correct.

The user has certain responsibilities with respect to the private
key - the primary one being not to disclose it to others.  Without
that restriction on the user's behavior, there is nothing the
CA or the Relying Party can do to ensure that certification
is meaningful.

Another responsibility of the user is not to "disclose" it to
his or her alternate personalities :-) by requesting certification
of the same key under different policies or practices.  Yes,
it is impossible for the CA to ensure that a given key has not been
certified elsewhere by the same user.  But that is no more impossible
than for the CA to ensure that the key has not been certified elsewhere
by a *different* user (i.e. that the private key has not been
compromised).

> I think this is an application issue and can be solved by binding
> the signing certificate chain with the signed document.

Denis Pinkas would agree with you that binding the certificate or
chain to the signed data is a good idea.  I don't disagree
with that in principle, but I regard it as an additional
"protection in depth" measure, not the first line of defense.

As a standard practice, keys should not be multiply-certified.

Specific exceptions can be made when the implications are
well-understood (recertifying a key at validity expiration, changing
administrative details such as name or organizational unit *IF* those
details are not critical to Relying Parties, augmenting the user's
privileges, etc.)

Date: Wed, 25 Feb 1998 22:32:04 -0200 (EDT)
From: Ed Gerck <[email-masked]>
To: John Lowry <[email-masked]>
cc: Stephen Klump <[email-masked]>, "'Ietf-Smime (E-mail)'" <[email-masked]>, "'Jim Schaad (Exchange)'" <[email-masked]>
Subject: RE: Inclusion of the issuer and serial number in authenticated  information
Sender: [email-masked]

On Wed, 25 Feb 1998, John Lowry wrote:

>[snip, OK]
>Note that as a practical matter, it is impossible for CAs to
>search each other's key spaces to ensure global uniqueness ...

(yes, never say never...)

This is not mandated by X.509 either, only that the key and DN be unique
at that CA. Further, X.509 also accepts DN duplication in the *same* CA --
but not cert duplication.

Cheers,

Ed
______________________________________________________________________
Dr.rer.nat. E. Gerck                     [email-masked]
http://novaware.cps.softex.br
    --- Meta-Certificate Group member, http://www.mcg.org.br ---

Date: Wed, 25 Feb 1998 17:36:09 -0500
To: Russ Housley <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: CMS-03 Comments
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Russ,

I agree with all of your recommendations.

I also agree with Dave Kemp's enhancement to add SIZE(1..MAX) to
AuthAttributes and UnauthAttributes.

Thanx for listening,
John Pawling

At 09:58 AM 2/25/98 -0500, Russ Housley wrote:
>John:
>
>1)  How about the following ASN.1.  It has shorter names.
>AuthAttributes ::= SET OF AuthAttribute
>
>AuthAttribute ::= SEQUENCE { 
>  attrType OBJECT IDENTIFIER, 
>  critical BOOLEAN DEFAULT FALSE, 
>  attrValues SET OF AttributeValue }
>
>UnauthAttributes ::= SET OF UnauthAttribute
>
>UnauthAttribute ::= SEQUENCE { 
>  attrType OBJECT IDENTIFIER, 
>  attrValues SET OF AttributeValue }
>
>2) >Recommend that the following sentence replace the aforementioned text:
>>"Note that only the value octets of the envelopedData encryptedContentInfo
>>encryptedContent OCTET STRING are encrypted; the OCTET STRING tag and length
>>octets are not encrypted."
>
>How about: "The input to the content-encryption process is the "value" of the
>content being enveloped.  Only the value octets of the envelopedData
>encryptedContentInfo encryptedContent OCTET STRING are encrypted; the OCTET
>STRING tag and length octets are not encrypted."
>
>Russ 
>

Date: Wed, 25 Feb 1998 17:28:42 -0500
To: Russ Housley <[email-masked]>, [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Criticality of Authenticated Attributes
Cc: [email-masked]
Sender: [email-masked]

All,

I agree with Russ.  Furthermore, I believe that essSecurityLabel should be
the only attribute that is required to always be critical.  ESS should not
require criticality for attributes that legacy products need to process
(contentType, messageDigest, signingTime, smimeCapabilities).  I don't
believe that the following new attributes should be mandated to always be
critical: contentIdentifier, mlExpansionHistory, receiptRequest, and
contentHints.  So, that only leaves essSecurityLabel as being mandatory
critical.

Furthermore, I recommend that the following text should be added to the
description of the critical flag in CMS, Sec 5.2: "Note that setting
critical to TRUE will cause interoperability problems with legacy software
that does not recognize the AuthAttribute ASN.1 syntax."

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

At 08:48 AM 2/25/98 -0500, Russ Housley wrote:
>Paul:
>
>Please add a sentence to the description of each authenticated attribute.
>We need to specify whether the attribute is always critical, never
>critical, or the originator's choice.
>
>I think that security label should always be critical.
>
>Russ
>
>

Date: Wed, 25 Feb 1998 17:02:20 -0500
To: "'Ietf-Smime (E-mail)'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Inclusion of the issuer and serial number in authenticated information
Sender: [email-masked]

All,

I agree with Jim Schaad's issuer/serialNumber authenticated attribute
proposal because:

1) I agree that it meets a valid requirement because it is certainly
possible to have multiple certs containing the same public key material. 

2) It provides the flexibility to bind the signer's cert (via the
issuer/serialNumber) with the signed data without forcing the signer to
always include the signer's cert in the signedData object.  In other words,
if the signer knows that the recipient already has the signer's cert, then
the signer should not be forced to send the signer's cert in the signedData.

3) It is backwards compatible with S/MIME v2 legacy software because the
legacy software will ignore the new attribute, but it can still verify the
signedData signature.

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

Date: Wed, 25 Feb 1998 14:51:21 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: S/MIME Index?
Cc: [email-masked]
Sender: [email-masked]

You are right that this is a big burden on the editor ....

Russ

At 02:04 PM 2/25/98 -0500, Phillip H. Griffin wrote:
>Just pulled down the latest HTTP draft and noticed that 
>it has a wonderful index at the end of the document. Is
>it possible that S/MIME could do the same? Big impact
>on the editors, but it could really add a lot to the 
>value of the final published works.
>
>Phil
>-- 
>Phillip H. Griffin         Griffin Consulting
>[email-masked]        ASN.1-SET-Java-Security
>919.828.7114               1625 Glenwood Avenue
>919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
>------------------------------------------------------------
>          Visit  http://www.fivepointsfestival.com
>                 http://www.five-points.com
>------------------------------------------------------------
> 

Date: Wed, 25 Feb 1998 14:14:17 -0500
To: "Phillip H. Griffin" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: CMS-03 Comments
Cc: John Pawling <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Phil:

>If authenticated attributes are to be DER encoded, they
>will be subject to the sorting rules required to assure
>that they are unique if a SET is used. This may lead to
>unanticipated results, including interoperabilty problems.
>
>If we are free to do as we wish here in redefining types,
>I would much prefer to see 
>
> AuthAttributes ::= SEQUENCE OF AuthAttribute
>
>used instead. It would allow senders to explicitly
>control the order of the AuthAttribute components,
>and would offer less processing overhead.

I agree.  I always prefer SEQUENCE OF; however, I need to
use SET OF for backward compatibility with PKCS#7 v1.5.

Russ 

Date: Wed, 25 Feb 1998 14:25:49 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Another CMS-03 Comment
Cc: [email-masked]
Sender: [email-masked]

John:

>The CMS ASN.1 module includes the ExtendedCertificateInfo syntax which
>includes "attributes Attributes" as a field.  "Attributes" is no longer
>defined within the module or imported from any other module.  Recommend that
>"attributes Attributes" should be changed to: "attributes UnauthAttributes".

Oops.  I will fix it.

Russ 

Date: Wed, 25 Feb 1998 14:04:25 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: [email-masked]
Subject: S/MIME Index?
Sender: [email-masked]

Just pulled down the latest HTTP draft and noticed that 
it has a wonderful index at the end of the document. Is
it possible that S/MIME could do the same? Big impact
on the editors, but it could really add a lot to the 
value of the final published works.

Phil
-- 
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
                 http://www.five-points.com
------------------------------------------------------------

From: Carlisle Adams <[email-masked]>
To: "'Ietf-Smime (E-mail)'" <[email-masked]>, "'Jim Schaad (Exchange)'" <[email-masked]>
Subject: RE: Inclusion of the issuer and serial number in authenticated information
Date: Wed, 25 Feb 1998 13:57:32 -0500
Sender: [email-masked]

Hi Jim,

>----------
>From: 	Jim Schaad (Exchange)[SMTP:[email-masked]]
>Sent: 	Wednesday, February 25, 1998 1:25 AM
>To: 	Ietf-Smime (E-mail)
>Subject: 	Inclusion of the issuer and serial number in authenticated
>information
>
>In discussions with other people here at Microsoft about the questions
>of building certificate chains and what you sign with (a certificate or
>a key), we came up with an interesting security hole from a legal
>standpoint.  If a person gets more than one certificate for a given key,
>a person could switch certificates in the signed data object to the
>other certificate thus potentially changing the legal liability of the
>signature.

Denis Pinkas has been talking about this for a long time now (see, for
example, some of his postings to the PKIX list some time back, where the
context of the discussion was proof-of-possession in operational
protocols).  Ultimately, what you want (from both a security and a legal
standpoint) is that a signature is computed not only over some data, but
also over the certificate (or cert. identifier) containing the public
key to be used to verify the signature.

Within something like CMS there are two very simple solutions.  The
first is what you suggested:

>To address this problem, I strongly suggest we do the following:
>
>1.  In CMS we define an authenticated attribute which contains the
>issuer and serial number of the certificate which was used to sign the
>message.

The other is to put the certificate itself (rather than the issuer &
serial number) in an authenticated attribute.  This might be attractive
if the certificate is not carried elsewhere in the envelope or if it is
desirable to have the relevant information (e.g., the verification key
to check the signature) right there at your fingertips.  In any case,
either solution is probably fine (though for CMS I suspect the former is
preferable...).

>2.  We require this new attribute to be included in the
>authenticatedAttributes section of the message if one exists.  (We can't
>do anything about the problem if it does not exists.)

I suppose you could also say that an authenticateAttributes section
SHOULD exist, for this very reason.

>If the list thinks this is a problem which needs to be addressed, I will
>come up with a detailed proposal to fix this and submit it to the list.
>
>jim schaad

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

Date: Wed, 25 Feb 1998 13:34:47 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: [email-masked]
Subject: Re: CMS-03 Comments
Sender: [email-masked]

Great idea!

David P. Kemp wrote:
> 
> > From: Russ Housley <[email-masked]>
> >
> > John:
> >
> > 1)  How about the following ASN.1.  It has shorter names.
> > AuthAttributes ::= SET OF AuthAttribute
> >
> > AuthAttribute ::= SEQUENCE {
> >   attrType OBJECT IDENTIFIER,
> >   critical BOOLEAN DEFAULT FALSE,
> >   attrValues SET OF AttributeValue }
> >
> > UnauthAttributes ::= SET OF UnauthAttribute
> >
> > UnauthAttribute ::= SEQUENCE {
> >   attrType OBJECT IDENTIFIER,
> >   attrValues SET OF AttributeValue }
> 
> Russ,
> 
> How about adding a size constraint to the ASN.1.  Do we envision
> ever needing an empty set of authenticated or unauthenticated
> attributes?
> 
>   AuthAttributes ::= SET SIZE(1..MAX) OF AuthAttribute
> 
>   UnauthAttributes ::= SET SIZE(1..MAX) OF UnauthAttribute

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
                        www.five-points.com
------------------------------------------------------------

Date: Wed, 25 Feb 1998 11:30:51 -0500
To: Stephen Klump <[email-masked]>, "'Ietf-Smime (E-mail)'" <[email-masked]>, "'Jim Schaad (Exchange)'" <[email-masked]>
From: John Lowry <[email-masked]>
Subject: RE: Inclusion of the issuer and serial number in authenticated information
Sender: [email-masked]

Not a stupid statement, but incorrect nonetheless ...  :-)

Examples where I may reuse the key include:
I may choose to use my crypto token with it's key to register
for certificates from more than one CA.  A certificate is
nothing more than a binding of an identity with a key.  It
is the tuple that counts, not the key.  The key as identity
is an SPKI hallucination.  Further, I may choose to retain my 
key after expiration of the first certificate validity period.

Note that as a practical matter, it is impossible for CAs to
search each other's key spaces to ensure global uniqueness ...

The difficulty is that we know that different CAs will have
different quality of practice and the application has potential
to become confused.   Note that it is the application that has
the problem though.

I think this is an application issue and can be solved by binding
the signing certificate chain with the signed document.
This issue has been dealt with before although not widely
discussed.  One might consider including the chain in the 
hash calculation for the signature.  Other methods could
also be derived.

Regards,

John Lowry

At 08:39 AM 2/25/98 -0500, Stephen Klump wrote:
>Hello,
>
>Stop me when I write something dumb.
>
>One should never, never issue two (or more) certificates for a single
>key.
>
>If anyone allows this, they have forgotten the root word of
>"certificate"
>is "certify".  A certificate that shares a key with other certificates
>is
>worthless because it does not certify anything.  If your company assigns
>any kind of legal or civil liability to a certificate, and then it goes
>and
>issues multiple certificates for a single key, your company is going to
>get
>bitten one day.
>
>Having said that, it still can't hurt to put a SEQUENCE OF
>IssuerAndSerialNumber
>(one for each signer; gives capability if people want to implement
>multiple signers)
>in the authenticated attributes; we can just check them against the ones
>in the signerInfos.
>
>Cheers,
>Stephen - Entrust Technologies
>
>
>>----------
>>From: 	Jim Schaad (Exchange)[SMTP:[email-masked]]
>>Sent: 	Wednesday, February 25, 1998 1:25 AM
>>To: 	Ietf-Smime (E-mail)
>>Subject: 	Inclusion of the issuer and serial number in authenticated
>>information
>>
>>In discussions with other people here at Microsoft about the questions
>>of building certificate chains and what you sign with (a certificate or
>>a key), we came up with an interesting security hole from a legal
>>standpoint.  If a person gets more than one certificate for a given key,
>>a person could switch certificates in the signed data object to the
>>other certificate thus potentially changing the legal liability of the
>>signature.
>>
>>To address this problem, I strongly suggest we do the following:
>>
>>1.  In CMS we define an authenticated attribute which contains the
>>issuer and serial number of the certificate which was used to sign the
>>message.
>>
>>2.  We require this new attribute to be included in the
>>authenticatedAttributes section of the message if one exists.  (We can't
>>do anything about the problem if it does not exists.)
>>
>>If the list thinks this is a problem which needs to be addressed, I will
>>come up with a detailed proposal to fix this and submit it to the list.
>>
>>jim schaad
>>
>
>

Date: Wed, 25 Feb 1998 10:28:01 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: CMS-03 Comments
Sender: [email-masked]

> From: Russ Housley <[email-masked]>
> 
> John:
> 
> 1)  How about the following ASN.1.  It has shorter names.
> AuthAttributes ::= SET OF AuthAttribute
> 
> AuthAttribute ::= SEQUENCE { 
>   attrType OBJECT IDENTIFIER, 
>   critical BOOLEAN DEFAULT FALSE, 
>   attrValues SET OF AttributeValue }
> 
> UnauthAttributes ::= SET OF UnauthAttribute
> 
> UnauthAttribute ::= SEQUENCE { 
>   attrType OBJECT IDENTIFIER, 
>   attrValues SET OF AttributeValue }

Russ,

How about adding a size constraint to the ASN.1.  Do we envision
ever needing an empty set of authenticated or unauthenticated
attributes?

  AuthAttributes ::= SET SIZE(1..MAX) OF AuthAttribute

  UnauthAttributes ::= SET SIZE(1..MAX) OF UnauthAttribute

Date: Wed, 25 Feb 1998 09:58:18 -0500
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: Re: CMS-03 Comments
Cc: [email-masked], [email-masked]
Sender: [email-masked]

John:

1)  How about the following ASN.1.  It has shorter names.
AuthAttributes ::= SET OF AuthAttribute

AuthAttribute ::= SEQUENCE { 
  attrType OBJECT IDENTIFIER, 
  critical BOOLEAN DEFAULT FALSE, 
  attrValues SET OF AttributeValue }

UnauthAttributes ::= SET OF UnauthAttribute

UnauthAttribute ::= SEQUENCE { 
  attrType OBJECT IDENTIFIER, 
  attrValues SET OF AttributeValue }

2) >Recommend that the following sentence replace the aforementioned text:
>"Note that only the value octets of the envelopedData encryptedContentInfo
>encryptedContent OCTET STRING are encrypted; the OCTET STRING tag and length
>octets are not encrypted."

How about: "The input to the content-encryption process is the "value" of the
content being enveloped.  Only the value octets of the envelopedData
encryptedContentInfo encryptedContent OCTET STRING are encrypted; the OCTET
STRING tag and length octets are not encrypted."

Russ 

Date: Wed, 25 Feb 1998 08:48:22 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Criticality of Authenticated Attributes
Cc: [email-masked]
Sender: [email-masked]

Paul:

Please add a sentence to the description of each authenticated attribute.
We need to specify whether the attribute is always critical, never
critical, or the originator's choice.

I think that security label should always be critical.

Russ

Date: Wed, 25 Feb 1998 09:09:27 -0500
To: "Jim Schaad (Exchange)" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Comments on CMS-03
Cc: "Ietf-Smime (E-mail)" <[email-masked]>
Sender: [email-masked]

Jim:

>1.  Section 5.1  --- NOTE this would replace John's comment #2
> Since we are now using EncapulsatedContentInfo in four different
>structures, lets do a break out on the fields of it.  This would allow
>for the single description of the eContent field being optional which
>would apply to all four locations where it is referenced. 

Good idea.  I will do it for CMS-04.

>2.  Section 5.1  Since we are now octet encoding the eContent field, I
>don't see any reason to say that for "external signatures" that the
>content type must be id-data.  Recommend we delete this sentence

Agree.  I now say: "If the eContent value within EncapsulatedContentInfo is
absent, then the signatureValue is calculated and the eContentType is assigned
as though the eContent value was present."

>3.  Section 5.1 Add following sentence to description of version "If the
>encapsulated content type is id-data, then the value of the version
>shall be 1; however, if the encapsulated content type is other than
>id-data, then the value of version shall be 3."

Agree.  The new words are: "version is the syntax version number.  If no
attribute certificates are present in the certificates field and the
encapsulated content type is id-data, then the value of version shall be 1;
however, if attribute certificates are present or the encapsulated content
type
is other than id-data, then the value of version shall be 3."

>4.  Section 5.2 paragraph describing version.  There is an extra and in
>the last sentence: "authenticatedAttributes and field is absent" --
>remove the and

Fixed.  See words in 3 above.

>5.  -Section 5.3 last paragraph.  I don't think this paragraph makes
>sense any more.  It was refering to the content section and we no longer
>DER encode content.  Recommend we just delete the entire paragraph.

Agree.  It will be gone in CMS-04.

>6.  Sections 8 and 9 should have a enumerated list of the steps similar
>to that in section 7 describing how to create these items.

For section 9, I agree.  Rich Ankney and I are working on thise words.

For section 8, PKCS#7 did not include such a list.  I guess the felt it was
obvious.  Before I put the time into this one, I would like to hear what
others
think.

>7.  I heartly second John's recommendation for adding to
>authenticatedAttributes to the AuthenticatedData structure.

Rich Ankney and I are working on that addition.

>8.  Part of my continuing fight to remove MD2 from the world.  Please
>remove MD2 form the list of examples in DigestAlgorithmIdentifier.  If
>you want a third example use RIPEMD-160.

I agree.  Looking into this further, I found that MD2 was not released to the
public for any use.  It was released for particular purposes when used with
PEM.  So, CMS-04 will not reference MD2.

Russ 

Date: Wed, 25 Feb 1998 08:32:00 -0500
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: RE: Comments on CMS-03
Cc: [email-masked]
Sender: [email-masked]

John:

Here is the replacement sentence that I will include in CMS-04:
If the eContent value within EncapsulatedContentInfo is absent, then the
signatureValue is calculated and the eContentType is assigned as though the
eContent value was present. 
Russ

At 04:38 PM 2/24/98 -0500, John Pawling wrote:
>Jim,
>
>I agree.  Recommend that CMS Sec 5.1, next to last para, last sent should be
>deleted.  Also recommend that the preceding sentence should be changed to:
>"If the eContent value within EncapsulatedContentInfo is absent, then the
>signatureValue is calculated and the eContentType is set as though the
>eContent value is present."
>
>- John Pawling
>
>
>At 12:39 PM 2/24/98 -0800, Jim Schaad (Exchange) wrote:
>>John,
>>
>>I'm sorry but I disagree.  Yes there must be an OID in the eContentType
>>field, however the absense of of the eContent field does not change what
>>you place into the eContentType field.  The content type is still the
>>OID which describes the content which you are going to be signing (i.e.
>>data, a receipt).  There is no need for an id-absent-conent OID
>>
>>jim
>>
>>-----Original Message-----
>>From: [email-masked]
[<mailto:[email-masked]%5D>mailto:[email-masked]]
>>Sent: Tuesday, February 24, 1998 5:17 AM
>>To: Jim Schaad (Exchange)
>>Cc: Ietf-Smime (E-mail)
>>Subject: Re: Comments on CMS-03
>>
>>
>>Jim,
>>
>>I agree with your comments except that I have the following comment:
>>
>>You wrote:
>>>2.  Section 5.1  Since we are now octet encoding the eContent field, I
>>>don't see any reason to say that for "external signatures" that the
>>>content type must be id-data.  Recommend we delete this sentence
>>
>>EncapsulatedContentInfo eContentType is not an optional field, so there
>>must
>>be an OID populated in the field.  When signedData is used to support
>>the
>>"external signatures" feature, there needs to be an OID in the
>>eContentType
>>field that indicates that the eContent field is absent.  Recommend that
>>Russ
>>should define an id-absent-content OID.
>>
>>================================
>>John Pawling   
>>[email-masked]                             
>>J.G. Van Dyke & Associates, Inc.           
>>================================
>>
>>
>  

From: Stephen Klump <[email-masked]>
To: "'Ietf-Smime (E-mail)'" <[email-masked]>, "'Jim Schaad (Exchange)'" <[email-masked]>
Subject: RE: Inclusion of the issuer and serial number in authenticated information
Date: Wed, 25 Feb 1998 08:39:30 -0500
Sender: [email-masked]

Hello,

Stop me when I write something dumb.

One should never, never issue two (or more) certificates for a single
key.

If anyone allows this, they have forgotten the root word of
"certificate"
is "certify".  A certificate that shares a key with other certificates
is
worthless because it does not certify anything.  If your company assigns
any kind of legal or civil liability to a certificate, and then it goes
and
issues multiple certificates for a single key, your company is going to
get
bitten one day.

Having said that, it still can't hurt to put a SEQUENCE OF
IssuerAndSerialNumber
(one for each signer; gives capability if people want to implement
multiple signers)
in the authenticated attributes; we can just check them against the ones
in the signerInfos.

Cheers,
Stephen - Entrust Technologies

>----------
>From: 	Jim Schaad (Exchange)[SMTP:[email-masked]]
>Sent: 	Wednesday, February 25, 1998 1:25 AM
>To: 	Ietf-Smime (E-mail)
>Subject: 	Inclusion of the issuer and serial number in authenticated
>information
>
>In discussions with other people here at Microsoft about the questions
>of building certificate chains and what you sign with (a certificate or
>a key), we came up with an interesting security hole from a legal
>standpoint.  If a person gets more than one certificate for a given key,
>a person could switch certificates in the signed data object to the
>other certificate thus potentially changing the legal liability of the
>signature.
>
>To address this problem, I strongly suggest we do the following:
>
>1.  In CMS we define an authenticated attribute which contains the
>issuer and serial number of the certificate which was used to sign the
>message.
>
>2.  We require this new attribute to be included in the
>authenticatedAttributes section of the message if one exists.  (We can't
>do anything about the problem if it does not exists.)
>
>If the list thinks this is a problem which needs to be addressed, I will
>come up with a detailed proposal to fix this and submit it to the list.
>
>jim schaad
>

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: Inclusion of the issuer and serial number in authenticated inform ation
Date: Tue, 24 Feb 1998 22:25:45 -0800
Sender: [email-masked]

In discussions with other people here at Microsoft about the questions
of building certificate chains and what you sign with (a certificate or
a key), we came up with an interesting security hole from a legal
standpoint.  If a person gets more than one certificate for a given key,
a person could switch certificates in the signed data object to the
other certificate thus potentially changing the legal liability of the
signature.

To address this problem, I strongly suggest we do the following:

1.  In CMS we define an authenticated attribute which contains the
issuer and serial number of the certificate which was used to sign the
message.

2.  We require this new attribute to be included in the
authenticatedAttributes section of the message if one exists.  (We can't
do anything about the problem if it does not exists.)

If the list thinks this is a problem which needs to be addressed, I will
come up with a detailed proposal to fix this and submit it to the list.

jim schaad

Date: Tue, 24 Feb 1998 17:12:20 -0500
To: "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Degenerate CMS-03 Comment
Sender: [email-masked]

Blake,

I agree with you.  Forget this proposal.

- John Pawling

At 02:08 PM 2/24/98 -0800, Blake Ramsdell wrote:
>On Tuesday, February 24, 1998 1:45 PM, [email-masked]
>[SMTP:[email-masked]] wrote:
>> Recommend that this should be changed to:  "In the degenerate case
>where
>> there are no signers, the EncapsulatedContentInfo value being "signed"
>is
>> irrelevant.  In this case, the EncapsulatedContentInfo eContentType
>MUST
>> be
>> set to id-absent-content and the eContent field of the
>> EncapsulatedContentInfo value MUST be omitted."
>> 
>> Recommend that Russ should define an id-absent-content OID.
>
>Whoops.  Backwards compatibility alert.
>
>I'm not sure how the current v2 clients will react to an OID other than
>id-data for a certs-CRLs-only message (which are currently SignedData
>with absent content, and zero SignerInfos).
>
>Is it important to make the change to use id-absent-content or
>equivalent?
>
>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]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Degenerate CMS-03 Comment
Date: Tue, 24 Feb 1998 14:08:35 -0800
Sender: [email-masked]

On Tuesday, February 24, 1998 1:45 PM, [email-masked]
[SMTP:[email-masked]] wrote:
> Recommend that this should be changed to:  "In the degenerate case
where
> there are no signers, the EncapsulatedContentInfo value being "signed"
is
> irrelevant.  In this case, the EncapsulatedContentInfo eContentType
MUST
> be
> set to id-absent-content and the eContent field of the
> EncapsulatedContentInfo value MUST be omitted."
> 
> Recommend that Russ should define an id-absent-content OID.

Whoops.  Backwards compatibility alert.

I'm not sure how the current v2 clients will react to an OID other than
id-data for a certs-CRLs-only message (which are currently SignedData
with absent content, and zero SignerInfos).

Is it important to make the change to use id-absent-content or
equivalent?

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

Date: Tue, 24 Feb 1998 17:07:48 -0500
To: "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Degenerate CMS-03 Comment
Sender: [email-masked]

All,

I just thought of a problem with my proposal.  If an S/MIME v3 agent needs
to send a degenerate signedData to a S/MIME v2 legacy agent, then the
inclusion of the id-absent-content OID may cause problems.  Therefore, I
won't pursue this proposal.

- John Pawling

At 04:44 PM 2/24/98 -0500, John Pawling wrote:
>All,
>
>CMS, Sec 5.1, last para states:  "In the degenerate case where there are no
>signers, the EncapsulatedContentInfo value being "signed" is irrelevant.  In
>this case, the content type within the EncapsulatedContentInfo value being
>"signed" should be data (as defined in section 4), and the content field of
>the EncapsulatedContentInfo value should be omitted."
>
>Recommend that this should be changed to:  "In the degenerate case where
>there are no signers, the EncapsulatedContentInfo value being "signed" is
>irrelevant.  In this case, the EncapsulatedContentInfo eContentType MUST be
>set to id-absent-content and the eContent field of the
>EncapsulatedContentInfo value MUST be omitted."
>
>Recommend that Russ should define an id-absent-content OID.
>
>================================
>John Pawling   
>[email-masked]                             
>J.G. Van Dyke & Associates, Inc.           
>================================
>
>
>
>

Date: Tue, 24 Feb 1998 16:44:56 -0500
To: "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Degenerate CMS-03 Comment
Sender: [email-masked]

All,

CMS, Sec 5.1, last para states:  "In the degenerate case where there are no
signers, the EncapsulatedContentInfo value being "signed" is irrelevant.  In
this case, the content type within the EncapsulatedContentInfo value being
"signed" should be data (as defined in section 4), and the content field of
the EncapsulatedContentInfo value should be omitted."

Recommend that this should be changed to:  "In the degenerate case where
there are no signers, the EncapsulatedContentInfo value being "signed" is
irrelevant.  In this case, the EncapsulatedContentInfo eContentType MUST be
set to id-absent-content and the eContent field of the
EncapsulatedContentInfo value MUST be omitted."

Recommend that Russ should define an id-absent-content OID.

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

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Comments on CMS-03
Date: Tue, 24 Feb 1998 13:43:50 -0800
Sender: [email-masked]

This sounds good to me.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, February 24, 1998 1:38 PM
To: Jim Schaad (Exchange)
Cc: Ietf-Smime (E-mail)
Subject: RE: Comments on CMS-03

Jim,

I agree.  Recommend that CMS Sec 5.1, next to last para, last sent
should be
deleted.  Also recommend that the preceding sentence should be changed
to:
"If the eContent value within EncapsulatedContentInfo is absent, then
the
signatureValue is calculated and the eContentType is set as though the
eContent value is present."

- John Pawling

At 12:39 PM 2/24/98 -0800, Jim Schaad (Exchange) wrote:
>John,
>
>I'm sorry but I disagree.  Yes there must be an OID in the eContentType
>field, however the absense of of the eContent field does not change
what
>you place into the eContentType field.  The content type is still the
>OID which describes the content which you are going to be signing (i.e.
>data, a receipt).  There is no need for an id-absent-conent OID
>
>jim
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Tuesday, February 24, 1998 5:17 AM
>To: Jim Schaad (Exchange)
>Cc: Ietf-Smime (E-mail)
>Subject: Re: Comments on CMS-03
>
>
>Jim,
>
>I agree with your comments except that I have the following comment:
>
>You wrote:
>>2.  Section 5.1  Since we are now octet encoding the eContent field, I
>>don't see any reason to say that for "external signatures" that the
>>content type must be id-data.  Recommend we delete this sentence
>
>EncapsulatedContentInfo eContentType is not an optional field, so there
>must
>be an OID populated in the field.  When signedData is used to support
>the
>"external signatures" feature, there needs to be an OID in the
>eContentType
>field that indicates that the eContent field is absent.  Recommend that
>Russ
>should define an id-absent-content OID.
>
>================================
>John Pawling   
>[email-masked]                             
>J.G. Van Dyke & Associates, Inc.           
>================================
>
>

Date: Tue, 24 Feb 1998 16:38:13 -0500
To: "Jim Schaad (Exchange)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Comments on CMS-03
Cc: "Ietf-Smime (E-mail)" <[email-masked]>
Sender: [email-masked]

Jim,

I agree.  Recommend that CMS Sec 5.1, next to last para, last sent should be
deleted.  Also recommend that the preceding sentence should be changed to:
"If the eContent value within EncapsulatedContentInfo is absent, then the
signatureValue is calculated and the eContentType is set as though the
eContent value is present."

- John Pawling

At 12:39 PM 2/24/98 -0800, Jim Schaad (Exchange) wrote:
>John,
>
>I'm sorry but I disagree.  Yes there must be an OID in the eContentType
>field, however the absense of of the eContent field does not change what
>you place into the eContentType field.  The content type is still the
>OID which describes the content which you are going to be signing (i.e.
>data, a receipt).  There is no need for an id-absent-conent OID
>
>jim
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Tuesday, February 24, 1998 5:17 AM
>To: Jim Schaad (Exchange)
>Cc: Ietf-Smime (E-mail)
>Subject: Re: Comments on CMS-03
>
>
>Jim,
>
>I agree with your comments except that I have the following comment:
>
>You wrote:
>>2.  Section 5.1  Since we are now octet encoding the eContent field, I
>>don't see any reason to say that for "external signatures" that the
>>content type must be id-data.  Recommend we delete this sentence
>
>EncapsulatedContentInfo eContentType is not an optional field, so there
>must
>be an OID populated in the field.  When signedData is used to support
>the
>"external signatures" feature, there needs to be an OID in the
>eContentType
>field that indicates that the eContent field is absent.  Recommend that
>Russ
>should define an id-absent-content OID.
>
>================================
>John Pawling   
>[email-masked]                             
>J.G. Van Dyke & Associates, Inc.           
>================================
>
>

Date: Tue, 24 Feb 1998 15:45:28 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Correction to ESS-02 Comments
Sender: [email-masked]

All,

Please replace "Communication Security Protocol" with "Common Security
Protocol" in the following comment:

>37) App B: Please delete the [MSP4] reference and add the [ACP120] reference
>as follows: "[ACP120] Oct 97 Allied Communication Publication (ACP) 120
>Communication Security Protocol Specification."

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

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Comments on CMS-03
Date: Tue, 24 Feb 1998 12:39:52 -0800
Sender: [email-masked]

John,

I'm sorry but I disagree.  Yes there must be an OID in the eContentType
field, however the absense of of the eContent field does not change what
you place into the eContentType field.  The content type is still the
OID which describes the content which you are going to be signing (i.e.
data, a receipt).  There is no need for an id-absent-conent OID

jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, February 24, 1998 5:17 AM
To: Jim Schaad (Exchange)
Cc: Ietf-Smime (E-mail)
Subject: Re: Comments on CMS-03

Jim,

I agree with your comments except that I have the following comment:

You wrote:
>2.  Section 5.1  Since we are now octet encoding the eContent field, I
>don't see any reason to say that for "external signatures" that the
>content type must be id-data.  Recommend we delete this sentence

EncapsulatedContentInfo eContentType is not an optional field, so there
must
be an OID populated in the field.  When signedData is used to support
the
"external signatures" feature, there needs to be an OID in the
eContentType
field that indicates that the eContent field is absent.  Recommend that
Russ
should define an id-absent-content OID.

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

From: Brian Korver <[email-masked]>
Subject: Re: How to do UTF-8
To: [email-masked]
Date: Tue, 24 Feb 1998 12:02:45 -0800 (PST)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Phillip H. Griffin writes:
> > UTF8 characters), but this SIZE clause has a different purpose:
> > to force the string to have at least one character.
> > An omitted OPTIONAL variable length item (SEQUENCE OF, xxxString, etc)
> > can have two possible encodings - absent, or zero length.  By forcing
> 
> I like DavidK's argument here. The zero does make life a 
> little more difficult for hand coders. A minimum of one 
> character allows them to switch solely on present or absent.
> 
> > the item in question to have at least one element, the encoding
> > ambiguity is eliminated.  I've gotten in the habit of including the
> > SIZE clause as boilerplate.
> 
> A very good habit. 

Phil,

Watch out.  Although the distinction may not exist here, there are
many contexts in which an absent string and a zero-length string
are not the same thing at all.  

brian
[email-masked]

Date: Tue, 24 Feb 1998 14:52:50 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: ESS-02 Comments
Sender: [email-masked]

All,

As usual, Paul has done a brilliant job of incorporating the comments into
ESS.  I have the following comments regarding the 16 Feb 98 ESS-02 I-D:

1) General: Please ensure that all occurrences of essSecurityLabel are
spelled consistently.  The capitalization of the leading "ess" has been
expressed in several different manners.

2) Sec 1.2, last para: Jim Schaad asked that support for multipart/signed
should be added to ESS.  Recommend changing first sentence of last para to
start with "There is usually no purpose...".

3) Sec 1.2, new last para:  Please add: "The following layers depict an
example of a triple wrapped message in which the inner MIME messages is
multipart/signed.  Starting from the innermost layer and working outwards,
the layers are:

ContentInfo: data type
Inner SignedData block with absent content
MIME entity (multipart/signed: part 2: Inner SignedData w/o content) 
Original content ("Hello, world!")
MIME entity (multipart/signed: part 1: original content)
ContentInfo: data type
EnvelopedData block
MIME entity
ContentInfo: data type
Outer SignedData block
MIME entity"

4) Sec 1.3.2, last para, last sent: Please replace "eSSSsecurityLabel" with
"essSecurityLabel".

5) Sec 1.3.4, Table:  Jim Schaad stated "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."  I agree with Jim.

6) Sec 1.3.4, Table: Please delete encapsulatedContentType row because the
encapsulatedContentType is being eliminated.

7) Sec 1.3.4, last para, last sent: Please delete this sentence because
encapsulatedContentType is being eliminated.

8) Sec 2.2, bullet 2: Please change "encapsulatedContentType" to "contentType".

9) Sec 2.3, bullet 5: Please replace bullet 5 with the following: "The
message originator MUST populate the receiptsTo field so that the recipient
can determine the address(es) to which to send the signed receipt.  The
message originator MUST populate the receiptsTo field with a GeneralNames
for each entity to whom the recipient should send the signed receipt
including, but not limited to, the message originator itself.  GeneralNames
is a SEQUENCE OF GeneralName.  receiptsTo is a SEQUENCE OF GeneralNames in
which each GeneralNames represents an entity.  There may be multiple
GeneralName instances in the GeneralNames which represents an entity.  At a
minimum, the message originator MUST populate each entity's GeneralNames
with the address to which the signed receipt should be sent.  Optionally,
the message originator MAY also populate each entity's GeneralNames with
other GeneralName instances (such as directoryName)."

10) Sec 2.3, 3rd para, last sent: Please replace "MUST" with "SHOULD" in the
following: "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."  In all other places in the spec, we
have stated that the recipient SHOULD (rather than MUST) return a signed
receipt.

11) Sec 2.4, bullet 2.2: Please change "encapsulatedContentType" to
"contentType".

12) Sec 2.4, bullet 9, first sent: Please replace "contentInfo content ANY
field" with "EncapsulatedContentInfo eContent OCTET STRING" in the following
sent:  "The ASN.1 DER encoded Receipt content MUST be directly encoded
within the signedData contentInfo content ANY field." 

13) Sec 2.4, bullet 9, 2nd sent:  Please replace "contentInfo contentType"
with "EncapsulatedContentInfo eContentType" in the following sent:  "The
id-ct-receipt object identifier MUST be included in the signedData
contentInfo contentType."

14) Sec 2.5, bullet 1, 2nd sent: Please delete everything after the
semi-colon in the following sent:  "The software initiates the sequence of
recipients with the value(s) of receiptsTo; otherwise, the software
initiates the sequence of recipients with the signer (that is, the
originator) of the SignerInfo that includes the receiptRequest attribute."

15) Sec 2.6, 1rst para, 2nd sent:  Please replace "contentInfo contentType"
with "EncapsulatedContentInfo eContentType" in the following sent:  "It is
identified by the presence of the id-ct-receipt object identifier in the
contentInfo contentType value of the signedData object including the Receipt
content."

16) Sec 2.6, bullets 2, 5 and 5.2: Please change "encapsulatedContentType"
to "contentType".

17) Sec 2.7: Please replace "encapsulatedContentType
EncapsulatedContentType" with "contentType ContentType" in the
receiptRequest ASN.1 definition.

18) Sec 2.7: Please delete the following text: 

"The encapsulatedContentType field identifies the content type of the
original message. In BuiltinContentType, the values of 0 and 1 have been
deprecated and SHOULD NOT be used. Unless the data to be placed in the
encapsulatedContentType field has been profiled to be different in the
present operating environment, the internal content type SHOULD be placed in
the ExternalContentType choice of encapsulatedContentType.

EncapsulatedContentType ::= CHOICE {
  built-in BuiltinContentType,
  external ExternalContentType,
  externalWithSubtype ExternalContentWithSubtype }

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

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

ExternalContentType ::= OBJECT IDENTIFIER

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

19) Sec 2.7, last para, last sent: Please replace "The field is mandatory,
and the originator's name(s) MUST be included in the receiptsTo list." with
"The message originator MUST populate the receiptsTo field with a
GeneralNames for each entity to whom the recipient should send the signed
receipt including, but not limited to, the message originator itself."

20) Sec 2.8: Please replace "encapsulatedContentType
EncapsulatedContentType" with "contentType ContentType" in the Receipt ASN.1
definition.

21) Sec 2.8, last para: Please change "encapsulatedContentType" to
"contentType".

22) Sec 2.9: Please change ContentHints to the following (note changes to
both components):
"ContentHints ::= SEQUENCE {
  contentDescription UTF8String SIZE (1..MAX) OPTIONAL,
  contentType ContentType}"

23) Sec 2.9: Please delete the following text:
"DirectoryString ::= CHOICE {
  teletexString TeletexString (SIZE (1..MAX)),
  printableString PrintableString (SIZE (1..MAX)),
  bmpString  BMPString (SIZE (1..MAX)),
  universalString UniversalString (SIZE (1..MAX)) }

The construct "SIZE (1..MAX)" is used in the DirectoryString syntax to
constrain each CHOICE to have at least one entry. MAX indicates that the
upper bound is unspecified.  Implementations are free to choose an upper
bound that suits their environment."

24) Sec 3.2, 1rst para:  Please change "[MSP4]" to "[ACP120]".

25) Sec 3.2: Please change ESSPrivacyMark to:
"ESSPrivacyMark ::= CHOICE {
  pString      PrintableString SIZE (1..ub-privacy-mark-length),
  utf8String   UTF8String SIZE (1..MAX)
  -- If utf8String is used, the contents must be in UTF-8 [UTF8]
}"

26) Sec 4.2, intro, 3rd para:  Please delete the following paragraph:  "When
the MLA creates the new attribute list for its signature, the MLA MUST
propagate forward each attribute in the old signature, unless the MLA
explicitly replaces the attribute with a new value. An MLA will frequently
encounter attributes, or parts of attributes, which it does not understand.
Attributes such as security labels cannot be removed from the new signature
being created without compromising the security of the system. Because it is
impossible to enumerate the future list of attributes which have security
implicitions, an MLA MUST propagate forward all attributes which it does not
explicity replace."

27) sec 4.2.2, bullet 3.2.1 should be changed as follows:

 OLD: 3.2.1. The MLA strips the existing outermost SignedData layer 
             after remembering the value of the mlExpansionHistory 
             attribute in that layer, if one was there.

 NEW: 3.2.1. The MLA strips the existing outermost SignedData layer 
             after remembering the value of the mlExpansionHistory and 
             all other authenticated attributes in that layer, if 
             present.

28) sec 4.2.2, bullet 3.2.3, first para, should be changed as follows:

 OLD: 3.2.3. The MLA adds an mlExpansionHistory attribute. The 
             SignedData layer created by the MLA replaces the original 
             outermost SignedData layer.

 NEW: 3.2.3. The outermost signedData layer created by the MLA 
             replaces the original outermost signedData layer.  The 
             MLA MUST create an authenticated attribute list for the 
             new outermost signedData layer which MUST include each 
             authenticated attribute present in the original outermost 
             signedData layer, unless the MLA explicitly replaces the 
             attribute with a new value.  A special case is the 
             mlExpansionHistory attribute.  The MLA MUST add an 
             mlExpansionHistory authenticated attribute to the outer 
             signedData layer as follows: ....

29) Sec 4.3 Title: Please replace "Recipt" with "Receipt".

30) Sec 4.3, last para:  Please replace "The interesting cases are combining
insteadOf with inAddtionTo." with "In the table above, the term
"insteadOf(A+B)" means that the effective policy is the union of A's
insteadOf GeneralNames and B's inAdditionTo GeneralNames.  The term
"inAdditionTo(A+B)" means that the effective policy is the union of A's and
B's inAdditionTo GeneralNames."

31) Sec 4.4: Please change MLReceiptPolicy as follows:
"MLReceiptPolicy ::= CHOICE {
  none         [0] NULL,
  insteadOf    [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
  inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }"

32) Sec 4.4: Please delete "ub-insteadOf INTEGER ::= 16" and
"ub-inAdditionTo INTEGER ::= 16".

33) ASN.1 Module: Please add ContentType as an import from the CMS module.

34) ASN.1 Module: Please change all ASN.1 syntaxes as described above.

35) ASN.1 Module: Please add: "MsgSigDigest ::= OCTET STRING"

36) ASN.1 Module: Please add the following comment:
"--The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1
--constructs. A valid ASN.1 SEQUENCE can have zero or more entries.
--The SIZE (1..MAX) construct constrains the SEQUENCE to have at least
--one entry. MAX indicates the upper bound is unspecified. 
--Implementations are free to choose an upper bound that suits their 
--environment."

37) App B: Please delete the [MSP4] reference and add the [ACP120] reference
as follows: "[ACP120] Oct 97 Allied Communication Publication (ACP) 120
Communication Security Protocol Specification."

38) App D: Please delete the open issue because the msgSigDigest OID has
been defined and is included in the S/MIME OIDs document.

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

  

Date: Tue, 24 Feb 1998 11:08:43 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: CMS-03 Comments
Sender: [email-masked]

Phil,

I agree with your comments which are consistent with those of Russ Housley.
In summary, I agree that SignerInfo unauthenticatedAttributes should not be
defined as "Attributes", but rather as UnauthAttributes as follows:

UnauthAttributes ::= SET OF UnauthAttribute

UnauthAttribute ::= SEQUENCE { 
   attrType    OBJECT IDENTIFIER, 
   attrValues  SET OF AttributeValue }

AttributeValue ::= ANY

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

Date: Tue, 24 Feb 1998 10:32:46 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: ESS 2.9 text
Sender: [email-masked]

Phil,

The contentHints syntax is being changed to replace DirectoryString with
UTF8String, so the DirectoryString syntax is no longer required in ESS.
However, your comment is still applicable because I believe that there will
be other fields that are constrained by MAX.  For example, I believe that
MLReceiptPolicy should be changed as follows:  

MLReceiptPolicy ::= CHOICE {
  none [0] NULL,
  insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
  inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }

The PKIX X.509 Certificate and CRL Profile (aka PKIX I) includes:

"Appendix C. ASN.1 Notes

The construct

       SEQUENCE SIZE (1..MAX) OF

appears in several ASN.1 constructs. A valid ASN.1 sequence will have
zero or more entries. The SIZE (1..MAX) construct constrains the
sequence to have at least one entry. MAX indicates the upper bound is
unspecified. Implementations are free to choose an upper bound that
suits their environment."

Recommend that the MAX text in section 2.9 should be deleted.  Recommend
that the aforementioned excerpt from PKIX I should be included as a comment
in the ESS ASN.1 module.  This will ensure consistency between the PKIX and
S/MIME specs.

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

At 09:36 AM 2/24/98 -0500, [email-masked] wrote:
>Hope this has not already been mentioned.
>
>The text in 2.9 ...
>
> The construct "SIZE (1..MAX)" is used in the DirectoryString 
> syntax to constrain each CHOICE to have at least one entry. 
>
>could be improved by changing the second line to read...
>
> notation to constrain each choice alternative to contain
> at least one character.  
> 
>The text following the above...
>
> MAX indicates that the upper bound is unspecified.  
> Implementations are free to choose an upper bound that 
> suits their environment.
>
>will create problems. If one implementor chooses an upper 
>bound of 64 and sends a message to an implementor with an
>upper bound of say 32, the message will fail to decode.
>
>Implementors should be allowed to choose the upper bound 
>that suits them for messages that they send, but should be 
>prepared to receive messages of any length.
>
>Phil
>-- 
>Phillip H. Griffin         Griffin Consulting
>[email-masked]        ASN.1-SET-Java-Security
>919.828.7114               1625 Glenwood Avenue
>919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
>------------------------------------------------------------
>          Visit  http://www.fivepointsfestival.com
>                 http://www.five-points.com
>------------------------------------------------------------
>

Date: Tue, 24 Feb 1998 10:25:06 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: [email-masked]
Subject: Re: CMS-03 Comments
Sender: [email-masked]

John Pawling wrote:
> 
> All,
> 
> I have the following comments to the Jan 98 CMS-03 I-D:
> 
> 1) Sec 2, last sent:  Please delete "Since the signed-data content type
> requires DER encoding, an extra pass may be necessary   when a content type
> other than data is encapsulated."  According to CMS Sec 5.3, DER encoding of
> the content is not always required.
> 
> 2) Sec 5.1, next to last para, last 2 sents:  Please make the following
> change because EncapsulatedContentInfo is not optional (the eContent field
> within EncapsulatedContentInfo is optional):
> 
> Old: "If the EncapsulatedContentInfo value is absent, the signatureValue is
> calculated as though the EncapsulatedContentInfo value was present.  The
> presumed EncapsulatedContentInfo must have the content type set to id-data
> (as defined in section 4) and the content omitted."
> 
> New: "If the EncapsulatedContentInfo eContent value is absent, the
> signatureValue is calculated as though the eContent value was present.  The
> EncapsulatedContentInfo must have the eContentType set to id-data (as
> defined in section 4) and the eContent field omitted."
> 
> 3) Sec 5.2 and App A: Recommend that SignerInfo unauthenticatedAttributes
> should be defined as "Attributes" instead of "CMSAttributes" since CMS
> prohibits unauthenticatedAttributes from being marked as critical, so the
> critical flag can never be used in this case.  The CMS ASN.1 module can
> import Attributes and Attribute from X.501.
>

X.501 defines type Attribute, but does not define type Attributes
(at least not in the 1997 version, and I believe in no other). Type
Attributes is defined in PKCS#6,8 & 10, though PKCS#9 states that it
is also defined in PKCS#7 (it is only referenced in v1.5). All of the
PKCS definitions of type Attributes are the same, and the type is 
multiply defined since these RSA publications did not use ASN.1 
modules.

> 4) Sec 5.3, 1rst para, 3rd sent: Please make the following change to clarify
> the text:
> 
> old: "Specifically, the initial input is the content OCTET STRING of the
> content field of the EncapsulatedContentInfo value to which the signing
> process is applied.  Only the contents of the OCTET STRING are input to the
> message digest algorithm, not the identifier octets or the length octets."
> 
> new: "Specifically, the initial input is the encapContentInfo eContent OCTET
> STRING to which the signing process is applied.  Only the octets composing
> the value of the eContent OCTET STRING are input to the message digest
> algorithm, not the OCTET STRING tag and length octets."
> 
> 5) Sec 5.3, 3rd para: Please make the following change because the data
> content type is no longer a special case.  This text applies to all content
> types:
> 
> old: "When the content being signed has a content type of data (as defined
> in section 4) and the authenticatedAttributes field is absent, then just the
> value of the data (e.g., the contents of a file) is input to the message
> digest calculation."
> 
> new: "When the authenticatedAttributes field is absent, then only the octets
> composing the value of the signedData encapContentInfo eContent OCTET STRING
> (e.g., the contents of a file) are input to the message digest calculation."
> 
> 6) Sec 5.3, 4th para: Please make the following change to clarify the text:
> 
> old: "Although the identifier octets and the length octets are not included
> in the message digest calculation,.."
> 
> new: "Although the encapContentInfo eContent OCTET STRING tag and length
> octets are not included in the message digest calculation,..."
> 
> 7) Sec 6.3, first 3 paras:  IMHO, the first 3 paragraphs of Sec 6.3 should
> be replaced with:  "The content-encryption key for the desired
> content-encryption algorithm is generated at random.  The data to be
> protected is padded as described below.  The padded data is then encrypted
> using the content-encryption key.  The encryption operation maps an
> arbitrary string of octets (the data) to another string of octets (the
> ciphertext) under control of a content-encryption key.  The encrypted data
> is included in the envelopedData encryptedContentInfo encryptedContent OCTET
> STRING."
> 
> These are the paragraphs that I believe should be deleted because I believe
> that they are obsolete and are not required for S/MIME v2 backwards
> compatibility:
> 
>    "The input to the content-encryption process is the "value" of the
>    content being enveloped.  Only the content octets; identifier or
>    length octets are not included.
> 
>    When the content being enveloped has content type of data (as defined
>    in section 4), then just the value of the data (e.g., the contents of
>    a file) is encrypted.  This has the advantage that the length of the
>    content being encrypted need not be known in advance of the
>    encryption process.
> 
>    The identifier octets and the length octets are not encrypted.  The
>    length octets may be protected implicitly by the encryption process,
>    depending on the encryption algorithm.  The identifier octets are not
>    protected at all, although they can be recovered from the content
>    type, assuming that the content type uniquely determines the
>    identifier octets.  Explicit protection of the identifier and length
>    octets requires that the signed-data content type be employed prior
>    to digital enveloping."
> 
> 8) Sec 9 and App A: Recommend adding authenticatedAttributes to the
> AuthenticatedData SEQUENCE.  I believe that the signingTime and
> essSecurityLabel authenticatedAttributes would be useful.  If
> authenticatedAttributes are present, then the MAC value could be calculated
> on the concatenation of the content (value octets of the encapContentInfo
> eContent OCTET STRING) and DER encoded authenticatedAttributes.  The
> messageDigest attribute would not be used.
> 
> 9) Sec 11.2: Please make the following change to be consistent with the
> signedData encapContentInfo change:
> 
> old: "The message-digest attribute type specifies the message digest of the
> contents octets of the DER encoding of the content field of the ContentInfo
> value being signed in signed-data, where the message digest is computed
> using the signer's message digest algorithm."
> 
> new: "The message-digest attribute type specifies the message digest of the
> encapContentInfo eContent OCTET STRING being signed in signed-data (see
> Section 5.3), where the message digest is computed using the signer's
> message digest algorithm."
> 
> 10) App A: Import "Attribute" and "Attributes" from X.501 so they can be
> used for signedData signerInfo unauthenticatedAttributes.
>

I believe that both Attribute and Attributes should be defined 
in S/MIME and not imported from elsewhere.

Though X.501 does define an ASN.1 type Attribute, it may cause some
confusion to rely on this definition. The current version of the type,
and several previous versions are all based on the information object
class ATTRIBUTE, an ASN.1:1994 construct. Their components are defined
in terms of the fields of the ATTRIBUTE class. There are many fields
in the ATTRIBUTE class defintion that are not needed or useful to
S/MIME.

The current 1997 X.501 type Attribute is much more complex than
what is needed for PKCS #7. This is why the PKCS #7 revision (which
defines both v1.5 AND the new v1.6 using ASN.1:1994) takes care to 
define Attribute so that a simple version can be implemented for 
PKCS #7, and to insulate PKCS from future changes to the X.501 
defintion, which is currently ...

Attribute ::= SEQUENCE {
   type ATTRIBUTE.&id ({ SupportedAttributes }),
   values SET SIZE (0 .. MAX) OF ATTRIBUTE.&TYPE ({
SupportedAttributes}{@type}),
   valuesWithContext SET SIZE (1 .. MAX) OF SEQUENCE {
      value ATTRIBUTE.&Type ({SupportedAttributes}{@type}) OPTIONAL,
      contextList SET SIZE (1 .. MAX) OF Context } OPTIONAL }

All S/MIME needs is a simple Attribute definition, that contains
only the 'type' and 'values' components. Defining this type in
S/MIME will add to the long term stability of this standard. 

> 11) The following proposals were made at an informal meeting held in San
> Francisco on 14 Jan 98 to discuss S/MIME-related issues, but are not
> included in CMS-03:
> 
> "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.)
> 
> 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 identifying information
> (i.e., subject DN and/or subjectAltName)."  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 MUST also examine the keyUsage extension, if present, to
> determine the intended usage of the public key included in the cert."
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 
> 
> 
> 

Phil
-- 
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
                 http://www.five-points.com
------------------------------------------------------------

Date: Tue, 24 Feb 1998 09:36:39 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: [email-masked]
Subject: ESS 2.9 text
Sender: [email-masked]

Hope this has not already been mentioned.

The text in 2.9 ...

 The construct "SIZE (1..MAX)" is used in the DirectoryString 
 syntax to constrain each CHOICE to have at least one entry. 

could be improved by changing the second line to read...

 notation to constrain each choice alternative to contain
 at least one character.  
 
The text following the above...

 MAX indicates that the upper bound is unspecified.  
 Implementations are free to choose an upper bound that 
 suits their environment.

will create problems. If one implementor chooses an upper 
bound of 64 and sends a message to an implementor with an
upper bound of say 32, the message will fail to decode.

Implementors should be allowed to choose the upper bound 
that suits them for messages that they send, but should be 
prepared to receive messages of any length.

Phil
-- 
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
                 http://www.five-points.com
------------------------------------------------------------

Date: Tue, 24 Feb 1998 08:17:09 -0500
To: "Jim Schaad (Exchange)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Comments on CMS-03
Cc: "Ietf-Smime (E-mail)" <[email-masked]>
Sender: [email-masked]

Jim,

I agree with your comments except that I have the following comment:

You wrote:
>2.  Section 5.1  Since we are now octet encoding the eContent field, I
>don't see any reason to say that for "external signatures" that the
>content type must be id-data.  Recommend we delete this sentence

EncapsulatedContentInfo eContentType is not an optional field, so there must
be an OID populated in the field.  When signedData is used to support the
"external signatures" feature, there needs to be an OID in the eContentType
field that indicates that the eContent field is absent.  Recommend that Russ
should define an id-absent-content OID.

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

Date: Mon, 23 Feb 1998 20:13:33 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: [email-masked]
Subject: Re: Another CMS-03 Comment
Sender: [email-masked]

I agree. This makes life easier for programmers.

Blake Ramsdell wrote:
> 
> On Monday, February 23, 1998 9:59 AM, [email-masked]
> [SMTP:[email-masked]] wrote:
> > I propose:
> >
> >       AuthAttributes ::= SET SIZE(1..MAX) OF AuthAttribute
> >
> >       AuthAttribute ::= SEQUENCE {
> >           type       OBJECT IDENTIFIER,
> >           critical   BOOLEAN DEFAULT FALSE,
> >           values     SET OF AttributeValue }
> >
> >       UnauthAttributes ::= SET SIZE(1..MAX) OF UnauthAttribute
> >
> >       UnauthAttribute ::= SEQUENCE {
> >           type       OBJECT IDENTIFIER,
> >           values     SET OF AttributeValue }
> >
> >       AttributeValue ::= ANY
> 
> If I have a strong preference, it would be to do it this way.
> 
> 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

-- 
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
                 http://www.five-points.com
------------------------------------------------------------

Date: Mon, 23 Feb 1998 18:00:08 -0500 (EST)
From: Bancroft Scott <[email-masked]>
To: "David P. Kemp" <[email-masked]>
Cc: [email-masked]
Subject: Re: How to do UTF-8
Sender: [email-masked]

On Mon, 23 Feb 1998, David P. Kemp wrote:

> > In ASN.1 an omitted OPTIONAL variable length item has a single encoding -
> > absent.  In ASN.1 a value with a missing item is entirely different from
> > one where the length is zero.
> 
> If one is carrying a C language string (null-terminated array of
> characters) in a structure with a fixed-size buffer, how does the
> application distinguish between absent and zero-length?
> 
> Assuming that an ASN.1 library takes a "char *" as an argument, that
> argument can be a null pointer or a pointer to "\0", thus from the
> library's point of view the encoding is unambiguous.  But from the
> application's point of view, it is ambiguous unless one carries around
> an additional "empty" flag for each static buffer,

These two techniques that you describe here are what the OSS ASN.1 Tools
for C employs to distinguish between absent and zero-length.

> or define a special
> "length" value of -1 to mean absent.

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

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, <[email-masked]>
Subject: RE: Another CMS-03 Comment
Date: Mon, 23 Feb 1998 14:49:12 -0800
Sender: [email-masked]

On Monday, February 23, 1998 9:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> I propose:
> 
>       AuthAttributes ::= SET SIZE(1..MAX) OF AuthAttribute
> 
>       AuthAttribute ::= SEQUENCE { 
>           type       OBJECT IDENTIFIER, 
>           critical   BOOLEAN DEFAULT FALSE, 
>           values     SET OF AttributeValue }
> 
>       UnauthAttributes ::= SET SIZE(1..MAX) OF UnauthAttribute
> 
>       UnauthAttribute ::= SEQUENCE {
>           type       OBJECT IDENTIFIER,
>           values     SET OF AttributeValue }
> 
>       AttributeValue ::= ANY 

If I have a strong preference, it would be to do it this way.

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

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, [email-masked]
Subject: RE: ESS EncapsulatedContentType
Date: Mon, 23 Feb 1998 14:27:40 -0800
Sender: [email-masked]

I would love this change.  I have never really understood exactly what
was suppose to go into EncapsulatedContentType anyway.  This makes it
clear to me what I put in there.

jim

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Monday, February 23, 1998 7:35 AM
To: [email-masked]
Subject: ESS EncapsulatedContentType

All:

ESS currently includes this definition.

  EncapsulatedContentType ::= CHOICE {
    built-in ...
    external ...
    externalWithSubtype ... }

External is an OID, and it is similar to the content type carried in
signed-data.  We could eliminate the built-in if we assigned OIDs for
each
of the few integers that are assigned.  This would simplify the
structure.

The externalWithSubtype will not be used often, and the subtype is not
really important in the receipt request context.  It is really used to
flag
that automatic processing of the message is necessary.  Therefore, I
propose moving the subtype to a separtae authenticated attribute.

If people accept both of these proposals, then the ESS document should
use
the content type attribute defined in the CMS document.

Russ

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "Russ Housley (E-mail)" <[email-masked]>
Cc: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: Comments on CMS-03
Date: Mon, 23 Feb 1998 14:16:07 -0800
Sender: [email-masked]

1.  Section 5.1  --- NOTE this would replace John's comment #2
	Since we are now using EncapulsatedContentInfo in four different
structures, lets do a break out on the fields of it.  This would allow
for the single description of the eContent field being optional which
would apply to all four locations where it is referenced.	

2.  Section 5.1  Since we are now octet encoding the eContent field, I
don't see any reason to say that for "external signatures" that the
content type must be id-data.  Recommend we delete this sentence

3.  Section 5.1 Add following sentence to description of version "If the
encapsulated content type is id-data, then the value of the version
shall be 1; however, if the encapsulated content type is other than
id-data, then the value of version shall be 3."

4.  Section 5.2 paragraph describing version.  There is an extra and in
the last sentence: "authenticatedAttributes and field is absent" --
remove the and

5.  -Section 5.3 last paragraph.  I don't think this paragraph makes
sense any more.  It was refering to the content section and we no longer
DER encode content.  Recommend we just delete the entire paragraph.

6.  Sections 8 and 9 should have a enumerated list of the steps similar
to that in section 7 describing how to create these items.

7.  I heartly second John's recommendation for adding to
authenticatedAttributes to the AuthenticatedData structure.

8.  Part of my continuing fight to remove MD2 from the world.  Please
remove MD2 form the list of examples in DigestAlgorithmIdentifier.  If
you want a third example use RIPEMD-160.

From: "Jim Schaad (Exchange)" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: CMS-03 Comments
Date: Mon, 23 Feb 1998 14:16:06 -0800
Sender: [email-masked]

John,

My memory of the following is slightly different, but this may be
colored by previous history.   I have been working with Blake to put
this into the S/MIME message draft.  After reading this however I think
that this should really be put into the CMS draft as it would be more
general than just S/MIME.

> 11) The following proposals were made at an informal meeting 
> held in San
> Francisco on 14 Jan 98 to discuss S/MIME-related issues, but are not
> included in CMS-03:
>  
> "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.) 
> 
> 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 identifying information
> (i.e., subject DN and/or subjectAltName)."  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 MUST also examine the keyUsage extension, if present, to 
> determine the intended usage of the public key included in the cert."
> 
> 
> ================================
> John Pawling   
> [email-masked]                             
> J.G. Van Dyke & Associates, Inc.           
> ================================
> 

Date: Mon, 23 Feb 1998 13:56:16 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: CMS-03 Comments
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Phil,

The goal is that the S/MIME v3 set of specs will allow an S/MIME v3 agent to
generate a signedData object (assuming that all optional new stuff is
omitted) that can be verified by a legacy "as-is" v2 agent, and vice versa.
Changing AuthAttributes to SEQUENCE OF AuthAttribute will break that "bits
on the wire" compatibility, because the legacy "as-is" v2 agent won't be
able to decode the authenticated attributes because it will be expecting a
"SET OF" tag rather than "SEQUENCE OF".  Therefore, I still agree with Russ'
proposed syntax as follows: (I changed the UnauthAttribute component names,
but that is orthogonal to the point that you making):

AuthAttributes ::= SET OF AuthAttribute

AuthAttribute ::= SEQUENCE { 
  attrType OBJECT IDENTIFIER, 
  critical BOOLEAN DEFAULT FALSE, 
  attrValues SET OF AttributeValue }

UnauthAttributes ::= SET OF UnauthAttribute

UnauthAttribute ::= SEQUENCE { 
  attrType OBJECT IDENTIFIER, 
  attrValues SET OF AttributeValue }

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

Date: Mon, 23 Feb 1998 13:38:33 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: John Pawling <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: CMS-03 Comments
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> Maintaining backwards compatibility with PKCS #7 v1.5 is an important goal
> of many of the S/MIME WG members.  Your suggestion makes sense, but it
> breaks backwards compatibility with PKCS #7 v1.5 (which uses "SET OF").
> 

Understood, and I know we've had this discussion before.
Just wanted to look it over one last time in light of the
differences that already exist between UnAuthAttributes
and

   AuthAttribute ::= SEQUENCE { 
      type       OBJECT IDENTIFIER, 
      critical   BOOLEAN DEFAULT FALSE, 
      values     SET OF AttributeValue } 

though I understand the reasoning here. Seems to me like 
a relatively minor change since it only impacts a tag.

Phil

> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 
> At 09:18 AM 2/23/98 -0500, [email-masked] wrote:
> >If authenticated attributes are to be DER encoded, they
> >will be subject to the sorting rules required to assure
> >that they are unique if a SET is used. This may lead to
> >unanticipated results, including interoperabilty problems.
> >
> >If we are free to do as we wish here in redefining types,
> >I would much prefer to see
> >
> >   AuthAttributes ::= SEQUENCE OF AuthAttribute
> >
> >used instead. It would allow senders to explicitly
> >control the order of the AuthAttribute components,
> >and would offer less processing overhead.
> >
> >Phil
> >

-- 
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
                 http://www.five-points.com
------------------------------------------------------------

Date: Mon, 23 Feb 1998 13:33:32 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Another CMS-03 Comment
Sender: [email-masked]

All,

Dave's proposal is fine with me.  The intent of my comment was to remove the
typo in Russ' original proposal which mixed "Unauth" and "auth" as follows:
 
"UnauthAttribute ::= SEQUENCE { 
  authAttrType OBJECT IDENTIFIER, 
  authAttrValues SET OF AttributeValue }"

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

At 12:59 PM 2/23/98 -0500, David P. Kemp wrote:
>> From: [email-masked] (John Pawling)
>>
>>    ... proposed by Russ as follows:
>>
>> UnauthAttributes ::= SET OF UnauthAttribute
>> 
>> UnauthAttribute ::= SEQUENCE { 
>>    unAuthAttrType    OBJECT IDENTIFIER, 
>>    unAuthAttrValues  SET OF AttributeValue }
>> 
>> AttributeValue ::= ANY 
>
>
>Just as a matter of style, why pick different names for the internal
>elements of each structure.  It seem cleaner to me to reuse the
>internal identifiers within each structure.
>
>In other words, what is the rationale for making up a new identifier
>"unAuthAttrType" instead of using the existing identifier "type".
>
>
>I propose:
>
>      AuthAttributes ::= SET SIZE(1..MAX) OF AuthAttribute
>
>      AuthAttribute ::= SEQUENCE { 
>          type       OBJECT IDENTIFIER, 
>          critical   BOOLEAN DEFAULT FALSE, 
>          values     SET OF AttributeValue }
>
>      UnauthAttributes ::= SET SIZE(1..MAX) OF UnauthAttribute
>
>      UnauthAttribute ::= SEQUENCE {
>          type       OBJECT IDENTIFIER,
>          values     SET OF AttributeValue }
>
>      AttributeValue ::= ANY 
>

Date: Mon, 23 Feb 1998 12:59:23 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Another CMS-03 Comment
Sender: [email-masked]

> From: [email-masked] (John Pawling)
>
>    ... proposed by Russ as follows:
>
> UnauthAttributes ::= SET OF UnauthAttribute
> 
> UnauthAttribute ::= SEQUENCE { 
>    unAuthAttrType    OBJECT IDENTIFIER, 
>    unAuthAttrValues  SET OF AttributeValue }
> 
> AttributeValue ::= ANY 

Just as a matter of style, why pick different names for the internal
elements of each structure.  It seem cleaner to me to reuse the
internal identifiers within each structure.

In other words, what is the rationale for making up a new identifier
"unAuthAttrType" instead of using the existing identifier "type".

I propose:

      AuthAttributes ::= SET SIZE(1..MAX) OF AuthAttribute

      AuthAttribute ::= SEQUENCE { 
          type       OBJECT IDENTIFIER, 
          critical   BOOLEAN DEFAULT FALSE, 
          values     SET OF AttributeValue }

      UnauthAttributes ::= SET SIZE(1..MAX) OF UnauthAttribute

      UnauthAttribute ::= SEQUENCE {
          type       OBJECT IDENTIFIER,
          values     SET OF AttributeValue }

      AttributeValue ::= ANY 

Date: Mon, 23 Feb 1998 12:17:26 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: CMS-03 Comments
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Phil,

Maintaining backwards compatibility with PKCS #7 v1.5 is an important goal
of many of the S/MIME WG members.  Your suggestion makes sense, but it
breaks backwards compatibility with PKCS #7 v1.5 (which uses "SET OF").  

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

At 09:18 AM 2/23/98 -0500, [email-masked] wrote:
>If authenticated attributes are to be DER encoded, they
>will be subject to the sorting rules required to assure
>that they are unique if a SET is used. This may lead to
>unanticipated results, including interoperabilty problems.
>
>If we are free to do as we wish here in redefining types,
>I would much prefer to see 
>
>   AuthAttributes ::= SEQUENCE OF AuthAttribute
>
>used instead. It would allow senders to explicitly
>control the order of the AuthAttribute components,
>and would offer less processing overhead.
>
>Phil
>

Date: Mon, 23 Feb 1998 12:13:05 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: ESS EncapsulatedContentType
Sender: [email-masked]

All,

I agree with Russ' proposal.  If nobody objects, then all occurrences of
encapsulatedContentType in ESS should be replaced by contentType.

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

At 10:34 AM 2/23/98 -0500, Russ Housley wrote:
>All:
>
>ESS currently includes this definition.
>
>  EncapsulatedContentType ::= CHOICE {
>    built-in ...
>    external ...
>    externalWithSubtype ... }
>
>External is an OID, and it is similar to the content type carried in
>signed-data.  We could eliminate the built-in if we assigned OIDs for each
>of the few integers that are assigned.  This would simplify the structure.
>
>The externalWithSubtype will not be used often, and the subtype is not
>really important in the receipt request context.  It is really used to flag
>that automatic processing of the message is necessary.  Therefore, I
>propose moving the subtype to a separtae authenticated attribute.
>
>If people accept both of these proposals, then the ESS document should use
>the content type attribute defined in the CMS document.
>
>Russ
>

Date: Mon, 23 Feb 1998 11:57:58 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Another CMS-03 Comment
Sender: [email-masked]

Russ (and friends),

The CMS ASN.1 module includes the ExtendedCertificateInfo syntax which
includes "attributes Attributes" as a field.  "Attributes" is no longer
defined within the module or imported from any other module.  Recommend that
"attributes Attributes" should be changed to: "attributes UnauthAttributes"
where UnauthAttributes is defined as proposed by Russ as follows:

UnauthAttributes ::= SET OF UnauthAttribute

UnauthAttribute ::= SEQUENCE { 
   unAuthAttrType    OBJECT IDENTIFIER, 
   unAuthAttrValues  SET OF AttributeValue }

AttributeValue ::= ANY 

This ensures backward compatibility with PKCS #7 v1.5 because it imported
"Attributes" from the 1988 X.501 spec (which is equivalent to Russ' proposed
UnauthAttributes).

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

Date: Mon, 23 Feb 1998 11:12:31 -0500
To: Russ Housley <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: CMS-03 Comments
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Russ,

Thank you very much for addressing my comments.  I agree with all of your
responses and recommendations except I have the following commments:

1) You proposed:
"UnauthAttribute ::=3D SEQUENCE {=20
   authAttrType      OBJECT IDENTIFIER,=20
   authAttrValues    SET OF AttributeValue }"

Recommend:
"UnauthAttribute ::=3D SEQUENCE {=20
   unAuthAttrType    OBJECT IDENTIFIER,=20
   unAuthAttrValues  SET OF AttributeValue }"

2) [JSP1:
>>7) Sec 6.3, first 3 paras:=A0 IMHO, the first 3 paragraphs of Sec 6.3=
 should
>>be replaced with:=A0 "The content-encryption key for the desired
>>content-encryption algorithm is generated at random.=A0 The data to be
>>protected is padded as described below.=A0 The padded data is then=
 encrypted
>>using the content-encryption key.=A0 The encryption operation maps an
>>arbitrary string of octets (the data) to another string of octets (the
>>ciphertext) under control of a content-encryption key.=A0 The encrypted=
 data
>>is included in the envelopedData encryptedContentInfo encryptedContent=
 OCTET
>>STRING."=A0=20
>>
>>These are the paragraphs that I believe should be deleted because I=
 believe
>>that they are obsolete and are not required for S/MIME v2 backwards
>>compatibility:
>>
>>=A0=A0 "The input to the content-encryption process is the "value" of the
>>=A0=A0 content being enveloped.=A0 Only the content octets; identifier or
>>=A0=A0 length octets are not included.
>>
>>=A0=A0 When the content being enveloped has content type of data (as=
 defined
>>=A0=A0 in section 4), then just the value of the data (e.g., the contents=
 of
>>=A0=A0 a file) is encrypted.=A0 This has the advantage that the length of=
 the
>>=A0=A0 content being encrypted need not be known in advance of the
>>=A0=A0 encryption process.
>>
>>=A0=A0 The identifier octets and the length octets are not encrypted.=A0=
 The
>>=A0=A0 length octets may be protected implicitly by the encryption=
 process,
>>=A0=A0 depending on the encryption algorithm.=A0 The identifier octets are=
 not
>>=A0=A0 protected at all, although they can be recovered from the content
>>=A0=A0 type, assuming that the content type uniquely determines the
>>=A0=A0 identifier octets.=A0 Explicit protection of the identifier and=
 length
>>=A0=A0 octets requires that the signed-data content type be employed prior
>>=A0=A0 to digital enveloping."]

[Russ:
>I do like your lead in paragraph.  However, the fact that the tag and=
 length
>octets are not encrypted needs to be preserved.]=20

[JSP2: When you say "tag and length octets", do you mean the tag and length
octets of the envelopedData encryptedContentInfo encryptedContent OCTET
STRING?  If so, then I agree with your comment and please see below for
exact wordsmithing requests.

If that is not what you meant, then please explain.  Please don't assume
that the data to be encrypted is always ASN.1 encoded.  There may not always
be ASN.1 tag and length octets at the beginning of the plaintext content
that must be encrypted.  For example, the data to be encrypted may be the
contents of a file containing ASCII characters (with no leading ASN.1 tag
and length octets).]

[Russ:
>How about:
>The content-encryption key for the desired content-encryption algorithm is
>randomly generated.  The data to be protected is padded as described below,
>then the padded data is encrypted using the content-encryption key.  The
>encryption operation maps an arbitrary string of octets (the data) to=
 another
>string of octets (the ciphertext) under control of a content-encryption=
 key.=20
>The encrypted data is included in the envelopedData encryptedContentInfo
>encryptedContent OCTET STRING.]

[JSP2: Fine so far.]

[Russ:
>The input to the content-encryption process is the "value" of the content
>being enveloped. Only the content octets are encrypted; the tag and the=
 length
>octets are not included. The length octets may be protected implicitly by=
 the
>encryption process, depending on the encryption algorithm.  The tag octets=
 are
>not protected at all, although they can be recovered from the content type,
>assuming that the content type uniquely determines the identifier octets.=
=20
>Explicit protection of the identifier and length octets requires that the
>signed-data content type be employed prior to digital enveloping.]

[JSP2: Recommend that the following sentence replace the aforementioned=
 text:
"Note that only the value octets of the envelopedData encryptedContentInfo
encryptedContent OCTET STRING are encrypted; the OCTET STRING tag and length
octets are not encrypted."]

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

Date: Mon, 23 Feb 1998 10:34:57 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: ESS EncapsulatedContentType
Sender: [email-masked]

All:

ESS currently includes this definition.

  EncapsulatedContentType ::= CHOICE {
    built-in ...
    external ...
    externalWithSubtype ... }

External is an OID, and it is similar to the content type carried in
signed-data.  We could eliminate the built-in if we assigned OIDs for each
of the few integers that are assigned.  This would simplify the structure.

The externalWithSubtype will not be used often, and the subtype is not
really important in the receipt request context.  It is really used to flag
that automatic processing of the message is necessary.  Therefore, I
propose moving the subtype to a separtae authenticated attribute.

If people accept both of these proposals, then the ESS document should use
the content type attribute defined in the CMS document.

Russ

Date: Mon, 23 Feb 1998 08:39:29 -0500
To: [email-masked] (David P. Kemp)
From: Russ Housley <[email-masked]>
Subject: Re: How to do UTF-8
Cc: [email-masked]
Sender: [email-masked]

Dave raises a good point.  I support the use of SIZE to ensure that absent
OPTIONAL and present zero length fields are not both possible.  This is one
less path in the code that must be implemented and tested.

Russ

At 03:48 PM 2/20/98 -0500, David P. Kemp wrote:
>> From: Paul Hoffman / IMC <[email-masked]>
>>
>> >And while we're UTF8'ing, we should also replace the DirectoryString in
>> >the ContentHints attribute:
>> >
>> >ContentHints ::= SEQUENCE {
>> >  contentDescription UTF8String SIZE(1..MAX) OPTIONAL,
>> >  contentType OBJECT IDENTIFIER }
>> 
>> I don't see any reason to do the SIZE(1..MAX). It made sense for the old
>> strings, but I don't think we need it here. Can we elide it?
>
>
>I agree that an upper bound on the string size may not be useful (and
>may be difficult to translate into a buffer size for variable-length
>UTF8 characters), but this SIZE clause has a different purpose:
>to force the string to have at least one character.
>An omitted OPTIONAL variable length item (SEQUENCE OF, xxxString, etc)
>can have two possible encodings - absent, or zero length.  By forcing
>the item in question to have at least one element, the encoding
>ambiguity is eliminated.  I've gotten in the habit of including the
>SIZE clause as boilerplate.
>
>I believe someone mentioned some time ago that this was a problem that
>should be addressed in X.680/690, instead of in every application protocol.
>But AFAIK it has not been addressed yet.
> 

Date: Mon, 23 Feb 1998 08:47:39 -0500
To: Paul Hoffman / IMC <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: How to do UTF-8
Cc: [email-masked]
Sender: [email-masked]

Also, the language can be implicitly determined by the security policy OID.

Russ

At 12:13 PM 2/20/98 -0800, Paul Hoffman / IMC wrote:
>At 08:35 AM 2/20/98 -0500, John Pawling wrote:
>>The part of Paul's proposal that I question is the inclusion of languageTag
>>in ESSFreeText. I would like to avoid forcing the receiving software to
>>check for two sources of languageTags.  It would be much cleaner if we could
>>always use embedded language tags in the UTF8String.  I understand Paul's
>>concern that the concept of embedding language tags in UTF-8 strings is
>>immature.  However, if we believe that the concept will be nailed down in
>>the next few weeks, then I believe that it is worth the risk to simply use
>>UTF8String.  If embedded language tags is a risky concept that may get
>>thrown out altogether, then I believe that we should stick with Paul's
>>proposal. 
>
>Drat. I seem to be in the minority here in my worry that the IETF won't get
>language tags in UTF-8. I'm again assured they will, so I agree with John and
>others to take out the optional language tag. My proposed privacy mark is
now:
>
>ESSPrivacyMark ::= CHOICE {
>    pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
>    utf8String   UTF8String
>}
>
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
> 

Date: Mon, 23 Feb 1998 09:48:59 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: How to do UTF-8
Cc: [email-masked]
Sender: [email-masked]

> In ASN.1 an omitted OPTIONAL variable length item has a single encoding -
> absent.  In ASN.1 a value with a missing item is entirely different from
> one where the length is zero.

If one is carrying a C language string (null-terminated array of
characters) in a structure with a fixed-size buffer, how does the
application distinguish between absent and zero-length?

Assuming that an ASN.1 library takes a "char *" as an argument, that
argument can be a null pointer or a pointer to "\0", thus from the
library's point of view the encoding is unambiguous.  But from the
application's point of view, it is ambiguous unless one carries around
an additional "empty" flag for each static buffer, or define a special
"length" value of -1 to mean absent.

Of course, I never liked the IEEE floating point distinction between
+0.0 and -0.0 either. :-)

Date: Mon, 23 Feb 1998 09:18:22 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: Russ Housley <[email-masked]>
CC: John Pawling <[email-masked]>, [email-masked], [email-masked]
Subject: Re: CMS-03 Comments
Sender: [email-masked]

If authenticated attributes are to be DER encoded, they
will be subject to the sorting rules required to assure
that they are unique if a SET is used. This may lead to
unanticipated results, including interoperabilty problems.

If we are free to do as we wish here in redefining types,
I would much prefer to see 

   AuthAttributes ::= SEQUENCE OF AuthAttribute

used instead. It would allow senders to explicitly
control the order of the AuthAttribute components,
and would offer less processing overhead.

Phil

Russ Housley wrote:
> 
> John:
> 
> Thanks for the comments.  Here are my responses.
> 
> >1) Sec 2, last sent:  Please delete "Since the signed-data content type
> >requires DER encoding, an extra pass may be necessary   when a content type
> >other than data is encapsulated."  According to CMS Sec 5.3, DER encoding of
> >the content is not always required.
> 
> Agree.  I will replace the sentence; it may be a good idea to point out that
> authenticated attributes are DER encoded.  How about, "Authenticated
> attributes
> within the signed-data content type require DER encoding."
> 
> >2) Sec 5.1, next to last para, last 2 sents:  Please make the following
> >change because EncapsulatedContentInfo is not optional (the eContent field
> >within EncapsulatedContentInfo is optional):
> >
> >Old: "If the EncapsulatedContentInfo value is absent, the signatureValue is
> >calculated as though the EncapsulatedContentInfo value was present.  The
> >presumed EncapsulatedContentInfo must have the content type set to id-data
> >(as defined in section 4) and the content omitted."
> >
> >New: "If the EncapsulatedContentInfo eContent value is absent, the
> >signatureValue is calculated as though the eContent value was present.  The
> >EncapsulatedContentInfo must have the eContentType set to id-data (as
> >defined in section 4) and the eContent field omitted."
> 
> Good catch.  How about the following as a replacement for that paragraph:
> The optional omission of the eContent within the EncapsulatedContentInfo field
> makes it possible to construct "external signatures."  In the case of external
> signatures, the content being signed is absent from the
> EncapsulatedContentInfo
> value included in the signed-data content type.  If the eContent value within
> EncapsulatedContentInfo is absent, then the signatureValue is calculated as
> though the eContent value was present, the eContentType value within
> EncapsulatedContentInfo must be set to id-data (as defined in section 4), and
> the eContent field omitted.
> 
> >3) Sec 5.2 and App A: Recommend that SignerInfo
> unauthenticatedAttributes>should be defined as "Attributes" instead of
> "CMSAttributes" since CMS
> >prohibits unauthenticatedAttributes from being marked as critical, so the
> >critical flag can never be used in this case.  The CMS ASN.1 module can
> >import Attributes and Attribute from X.501.
> 
> One group has already tried to define some private authenticated attributes.
> Since we imported the structure from X.501, they used the macros defined there
> for their definition.  This made the job much harder since they include
> irrelevant information like matching rules.
> 
> I replaced CMSAttributes with two types: AuthAttributes and UnauthAttributes:
> AuthAttributes ::= SET OF AuthAttribute
> 
> AuthAttribute ::= SEQUENCE {
>   attrType OBJECT IDENTIFIER,
>   critical BOOLEAN DEFAULT FALSE,
>   attrValues SET OF AttributeValue }
> 
> UnauthAttributes ::= SET OF UnauthAttribute
> 
> UnauthAttribute ::= SEQUENCE {
>   authAttrType OBJECT IDENTIFIER,
>   authAttrValues SET OF AttributeValue }
> 
> AttributeValue ::= ANY
> Does this resolve your concern?
> 
> >4) Sec 5.3, 1rst para, 3rd sent: Please make the following change to clarify
> >the text:
> >
> >old: "Specifically, the initial input is the content OCTET STRING of the
> >content field of the EncapsulatedContentInfo value to which the signing
> >process is applied.  Only the contents of the OCTET STRING are input to the
> >message digest algorithm, not the identifier octets or the length octets."
> >
> >new: "Specifically, the initial input is the encapContentInfo eContent OCTET
> >STRING to which the signing process is applied.  Only the octets composing
> >the value of the eContent OCTET STRING are input to the message digest
> >algorithm, not the OCTET STRING tag and length octets."
> 
> Good clarification.  I did a small amount of word smithing:
> Specifically, the initial input is the encapContentInfo eContent OCTET STRING
> to which the signing process is applied.  Only the octets comprising the value
> of the eContent OCTET STRING are input to the message digest algorithm, not
> the
> tag or the length octets.
> 
> >5) Sec 5.3, 3rd para: Please make the following change because the
> data>content type is no longer a special case.  This text applies to all
> content
> >types:
> >
> >old: "When the content being signed has a content type of data (as defined
> >in section 4) and the authenticatedAttributes field is absent, then just the
> >value of the data (e.g., the contents of a file) is input to the message
> >digest calculation."
> >
> >new: "When the authenticatedAttributes field is absent, then only the octets
> >composing the value of the signedData encapContentInfo eContent OCTET STRING
> >(e.g., the contents of a file) are input to the message digest calculation."
> 
> Agree.
> 
> >6) Sec 5.3, 4th para: Please make the following change to clarify the text:
> >
> >old: "Although the identifier octets and the length octets are not included
> >in the message digest calculation,.."
> >
> >new: "Although the encapContentInfo eContent OCTET STRING tag and length
> >octets are not included in the message digest calculation,..."
> 
> Agree.
> 
> >7) Sec 6.3, first 3 paras:  IMHO, the first 3 paragraphs of Sec 6.3 should
> >be replaced with:  "The content-encryption key for the desired
> >content-encryption algorithm is generated at random.  The data to be
> >protected is padded as described below.  The padded data is then encrypted
> >using the content-encryption key.  The encryption operation maps an
> >arbitrary string of octets (the data) to another string of octets (the
> >ciphertext) under control of a content-encryption key.  The encrypted data
> >is included in the envelopedData encryptedContentInfo encryptedContent OCTET
> >STRING."
> >
> >These are the paragraphs that I believe should be deleted because I believe
> >that they are obsolete and are not required for S/MIME v2 backwards
> >compatibility:
> >
> >   "The input to the content-encryption process is the "value" of the
> >   content being enveloped.  Only the content octets; identifier or
> >   length octets are not included.
> >
> >   When the content being enveloped has content type of data (as defined
> >   in section 4), then just the value of the data (e.g., the contents of
> >   a file) is encrypted.  This has the advantage that the length of the
> >   content being encrypted need not be known in advance of the
> >   encryption process.
> >
> >   The identifier octets and the length octets are not encrypted.  The
> >   length octets may be protected implicitly by the encryption process,
> >   depending on the encryption algorithm.  The identifier octets are not
> >   protected at all, although they can be recovered from the content
> >   type, assuming that the content type uniquely determines the
> >   identifier octets.  Explicit protection of the identifier and length
> >   octets requires that the signed-data content type be employed prior
> >   to digital enveloping."
> 
> I do like your lead in paragraph.  However, the fact that the tag and length
> octets are not encrypted needs to be preserved.  How about:
> The content-encryption key for the desired content-encryption algorithm is
> randomly generated.  The data to be protected is padded as described below,
> then the padded data is encrypted using the content-encryption key.  The
> encryption operation maps an arbitrary string of octets (the data) to another
> string of octets (the ciphertext) under control of a content-encryption key.
> The encrypted data is included in the envelopedData encryptedContentInfo
> encryptedContent OCTET STRING.
> 
> The input to the content-encryption process is the "value" of the content
> being
> enveloped.  Only the content octets are encrypted; the tag and the length
> octets are not included.  The length octets may be protected implicitly by the
> encryption process, depending on the encryption algorithm.  The tag octets are
> not protected at all, although they can be recovered from the content type,
> assuming that the content type uniquely determines the identifier octets.
> Explicit protection of the identifier and length octets requires that the
> signed-data content type be employed prior to digital enveloping.
> 
> >8) Sec 9 and App A: Recommend adding authenticatedAttributes to
> the>AuthenticatedData SEQUENCE.  I believe that the signingTime and
> >essSecurityLabel authenticatedAttributes would be useful.  If
> >authenticatedAttributes are present, then the MAC value could be calculated
> >on the concatenation of the content (value octets of the encapContentInfo
> >eContent OCTET STRING) and DER encoded authenticatedAttributes.  The
> >messageDigest attribute would not be used.
> 
> Agree.  I will work with Rich Ankney to come up with an acceptable syntax.
> 
> >9) Sec 11.2: Please make the following change to be consistent with the
> >signedData encapContentInfo change:
> >
> >old: "The message-digest attribute type specifies the message digest of the
> >contents octets of the DER encoding of the content field of the ContentInfo
> >value being signed in signed-data, where the message digest is computed
> >using the signer's message digest algorithm."
> >
> >new: "The message-digest attribute type specifies the message digest of the
> >encapContentInfo eContent OCTET STRING being signed in signed-data (see
> >Section 5.3), where the message digest is computed using the signer's
> >message digest algorithm."
> 
> Agree.
> 
> >10) App A: Import "Attribute" and "Attributes" from X.501 so they can be
> >used for signedData signerInfo unauthenticatedAttributes.
> 
> Disagree.  See proposed AuthAttrinutes and UnauthAttributes above.
> 
> >11) The following proposals were made at an informal meeting held in San
> >Francisco on 14 Jan 98 to discuss S/MIME-related issues, but are not
> >included in CMS-03:
> >
> >"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.)
> >
> >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 identifying information
> >(i.e., subject DN and/or subjectAltName)."  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 MUST also examine the keyUsage extension, if present, to
> >determine the intended usage of the public key included in the cert."
> 
> Sorry, I do not have this in my notes.  Please start a thread on the mail list
> to come to concensus on the ASN.1 syntax for the new attribute.
> 
> Again, thanks of the speedy and thorough review,
>  Russ

-- 
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
                 http://www.five-points.com
------------------------------------------------------------

Date: Sun, 22 Feb 1998 15:53:04 -0500
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: Re: CMS-03 Comments
Cc: [email-masked], [email-masked]
Sender: [email-masked]

John:

Thanks for the comments.  Here are my responses.

>1) Sec 2, last sent:  Please delete "Since the signed-data content type
>requires DER encoding, an extra pass may be necessary   when a content type
>other than data is encapsulated."  According to CMS Sec 5.3, DER encoding of
>the content is not always required.

Agree.  I will replace the sentence; it may be a good idea to point out that
authenticated attributes are DER encoded.  How about, "Authenticated
attributes
within the signed-data content type require DER encoding."

>2) Sec 5.1, next to last para, last 2 sents:  Please make the following
>change because EncapsulatedContentInfo is not optional (the eContent field
>within EncapsulatedContentInfo is optional):
>
>Old: "If the EncapsulatedContentInfo value is absent, the signatureValue is
>calculated as though the EncapsulatedContentInfo value was present.  The
>presumed EncapsulatedContentInfo must have the content type set to id-data
>(as defined in section 4) and the content omitted." 
>
>New: "If the EncapsulatedContentInfo eContent value is absent, the
>signatureValue is calculated as though the eContent value was present.  The
>EncapsulatedContentInfo must have the eContentType set to id-data (as
>defined in section 4) and the eContent field omitted."

Good catch.  How about the following as a replacement for that paragraph:
The optional omission of the eContent within the EncapsulatedContentInfo field
makes it possible to construct "external signatures."  In the case of external
signatures, the content being signed is absent from the
EncapsulatedContentInfo
value included in the signed-data content type.  If the eContent value within
EncapsulatedContentInfo is absent, then the signatureValue is calculated as
though the eContent value was present, the eContentType value within
EncapsulatedContentInfo must be set to id-data (as defined in section 4), and
the eContent field omitted.

>3) Sec 5.2 and App A: Recommend that SignerInfo
unauthenticatedAttributes>should be defined as "Attributes" instead of
"CMSAttributes" since CMS
>prohibits unauthenticatedAttributes from being marked as critical, so the
>critical flag can never be used in this case.  The CMS ASN.1 module can
>import Attributes and Attribute from X.501.

One group has already tried to define some private authenticated attributes. 
Since we imported the structure from X.501, they used the macros defined there
for their definition.  This made the job much harder since they include
irrelevant information like matching rules.

I replaced CMSAttributes with two types: AuthAttributes and UnauthAttributes:
AuthAttributes ::= SET OF AuthAttribute

AuthAttribute ::= SEQUENCE { 
  attrType OBJECT IDENTIFIER, 
  critical BOOLEAN DEFAULT FALSE, 
  attrValues SET OF AttributeValue }

UnauthAttributes ::= SET OF UnauthAttribute

UnauthAttribute ::= SEQUENCE { 
  authAttrType OBJECT IDENTIFIER, 
  authAttrValues SET OF AttributeValue }

AttributeValue ::= ANY 
Does this resolve your concern?

>4) Sec 5.3, 1rst para, 3rd sent: Please make the following change to clarify
>the text:
>
>old: "Specifically, the initial input is the content OCTET STRING of the
>content field of the EncapsulatedContentInfo value to which the signing
>process is applied.  Only the contents of the OCTET STRING are input to the
>message digest algorithm, not the identifier octets or the length octets."
>
>new: "Specifically, the initial input is the encapContentInfo eContent OCTET
>STRING to which the signing process is applied.  Only the octets composing
>the value of the eContent OCTET STRING are input to the message digest
>algorithm, not the OCTET STRING tag and length octets."

Good clarification.  I did a small amount of word smithing:
Specifically, the initial input is the encapContentInfo eContent OCTET STRING
to which the signing process is applied.  Only the octets comprising the value
of the eContent OCTET STRING are input to the message digest algorithm, not
the
tag or the length octets.

>5) Sec 5.3, 3rd para: Please make the following change because the
data>content type is no longer a special case.  This text applies to all
content
>types:
>
>old: "When the content being signed has a content type of data (as defined
>in section 4) and the authenticatedAttributes field is absent, then just the
>value of the data (e.g., the contents of a file) is input to the message
>digest calculation."
>
>new: "When the authenticatedAttributes field is absent, then only the octets
>composing the value of the signedData encapContentInfo eContent OCTET STRING
>(e.g., the contents of a file) are input to the message digest calculation."

Agree.

>6) Sec 5.3, 4th para: Please make the following change to clarify the text:
>
>old: "Although the identifier octets and the length octets are not included
>in the message digest calculation,.."
>
>new: "Although the encapContentInfo eContent OCTET STRING tag and length
>octets are not included in the message digest calculation,..." 

Agree.

>7) Sec 6.3, first 3 paras:  IMHO, the first 3 paragraphs of Sec 6.3 should
>be replaced with:  "The content-encryption key for the desired
>content-encryption algorithm is generated at random.  The data to be
>protected is padded as described below.  The padded data is then encrypted
>using the content-encryption key.  The encryption operation maps an
>arbitrary string of octets (the data) to another string of octets (the
>ciphertext) under control of a content-encryption key.  The encrypted data
>is included in the envelopedData encryptedContentInfo encryptedContent OCTET
>STRING."  
>
>These are the paragraphs that I believe should be deleted because I believe
>that they are obsolete and are not required for S/MIME v2 backwards
>compatibility:
>
>   "The input to the content-encryption process is the "value" of the
>   content being enveloped.  Only the content octets; identifier or
>   length octets are not included.
>
>   When the content being enveloped has content type of data (as defined
>   in section 4), then just the value of the data (e.g., the contents of
>   a file) is encrypted.  This has the advantage that the length of the
>   content being encrypted need not be known in advance of the
>   encryption process.
>
>   The identifier octets and the length octets are not encrypted.  The
>   length octets may be protected implicitly by the encryption process,
>   depending on the encryption algorithm.  The identifier octets are not
>   protected at all, although they can be recovered from the content
>   type, assuming that the content type uniquely determines the
>   identifier octets.  Explicit protection of the identifier and length
>   octets requires that the signed-data content type be employed prior
>   to digital enveloping."

I do like your lead in paragraph.  However, the fact that the tag and length
octets are not encrypted needs to be preserved.  How about:
The content-encryption key for the desired content-encryption algorithm is
randomly generated.  The data to be protected is padded as described below,
then the padded data is encrypted using the content-encryption key.  The
encryption operation maps an arbitrary string of octets (the data) to another
string of octets (the ciphertext) under control of a content-encryption key. 
The encrypted data is included in the envelopedData encryptedContentInfo
encryptedContent OCTET STRING.

The input to the content-encryption process is the "value" of the content
being
enveloped.  Only the content octets are encrypted; the tag and the length
octets are not included.  The length octets may be protected implicitly by the
encryption process, depending on the encryption algorithm.  The tag octets are
not protected at all, although they can be recovered from the content type,
assuming that the content type uniquely determines the identifier octets. 
Explicit protection of the identifier and length octets requires that the
signed-data content type be employed prior to digital enveloping.

>8) Sec 9 and App A: Recommend adding authenticatedAttributes to
the>AuthenticatedData SEQUENCE.  I believe that the signingTime and
>essSecurityLabel authenticatedAttributes would be useful.  If
>authenticatedAttributes are present, then the MAC value could be calculated
>on the concatenation of the content (value octets of the encapContentInfo
>eContent OCTET STRING) and DER encoded authenticatedAttributes.  The
>messageDigest attribute would not be used.

Agree.  I will work with Rich Ankney to come up with an acceptable syntax.

>9) Sec 11.2: Please make the following change to be consistent with the
>signedData encapContentInfo change:
>
>old: "The message-digest attribute type specifies the message digest of the
>contents octets of the DER encoding of the content field of the ContentInfo
>value being signed in signed-data, where the message digest is computed
>using the signer's message digest algorithm."
>
>new: "The message-digest attribute type specifies the message digest of the
>encapContentInfo eContent OCTET STRING being signed in signed-data (see
>Section 5.3), where the message digest is computed using the signer's
>message digest algorithm."

Agree.

>10) App A: Import "Attribute" and "Attributes" from X.501 so they can be
>used for signedData signerInfo unauthenticatedAttributes.

Disagree.  See proposed AuthAttrinutes and UnauthAttributes above.

>11) The following proposals were made at an informal meeting held in San
>Francisco on 14 Jan 98 to discuss S/MIME-related issues, but are not
>included in CMS-03:
> 
>"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.) 
>
>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 identifying information
>(i.e., subject DN and/or subjectAltName)."  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 MUST also examine the keyUsage extension, if present, to 
>determine the intended usage of the public key included in the cert."

Sorry, I do not have this in my notes.  Please start a thread on the mail list
to come to concensus on the ASN.1 syntax for the new attribute.

Again, thanks of the speedy and thorough review,
 Russ 

Date: Sun, 22 Feb 1998 15:01:25 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Language Tags - Re: How to do UTF-8
To: "Phillip H. Griffin" <[email-masked]>
Cc: Ned Freed <[email-masked]>, Paul Hoffman / IMC <[email-masked]>, [email-masked]
Sender: [email-masked]

> > The distinction here is between environments that support markup tags and
> > those which do not. Unless you propose to make your strings into HTML
> > documents you're talking about a plain text environment.

> Really? The last time I checked (this morning) I was getting

>    (3) <underline>Road Kill on the Information Highway</underline>,
>    Myhrvold, Nathan, 1993, Internal Microsoft Memorandum.  Would
>    love a copy of this.

> in my mail. But I'm comfortable with this, and have even
> come to expect such.

But message bodies _are_ an environment that supports multiple media types,
many of which provide markup tag facilities. This is quite different than
string fields in S/MIME information objects, where I doubt very much that
you want to try and support full HTML (or worse, MHTML).

> > No, the Whistler proposal creates new Unicode codepoints. These are neither
> > escape characters or announcers, both of which are things at odds with the
> > design principles of Unicode.

> That's good. They should pass through 'coders' nicely,
> and should be easy enough to filter for those who don't
> want them by manipulating the ASN.1 in bits on the wire
> compatible ways.

There really should be little reason to do this. Unicode contains lots of
codepoints that don't get displayed; these are simply more of them. Anything
that supports Unicode has to be prepared to deal with the presence of this
sort of thing. (Full Unicode support even when you have a complete BMP
font available isn't exactly a piece of cake...)

> In fact, I suppose that's the rub for IESG. It's quite
> easy to eliminate national language support from UTF8String,
> or to exclude any unwanted languages if you're adept at
> manipulating the ASN.1. I suspect that lots of implementors
> will end up only supporting the ASCII characters here to
> save money and reduce time to market.

As far as I know the IETF does not at present have any requirements that say
you must be able to display full Unicode or even some selected subset. However,
the best way to create such a requirement is for a significant number of
vendors not to meet such requirements and cause problems by not doing so.
Interoperability problems are every bit as much of an anathema to the IETF as
markup and escape sequences are to the Unicode Technical Committee.

I note in passing that in many cases vendors will be using platforms with
built-in support for Unicode. In such cases not handling a reasonably full
repetiore is inexcusable.

> > > When I consider the impact of non content, language control
> > > characters on the SIZE constraint aspect of this issue, it
> > > also raises a concern. If the number of embedded language
> > > tags is open ended, how will an application ever be able to
> > > correctly anticipate how many characters need to be handled
> > > in his buffer? This thought makes Paul's single optional
> > > languageTag component idea even more appealing. It's use
> > > effectively limits the application to only having to handle
> > > at most one language at a time, while still meeting the need
> > > to support national languages.

> Though I notice no comment here, let me note that your
> solution presents yet another interesting test case for
> implementors, besides the one's pointed out recently by
> DavidK:

>    An application receives an unconstrained ietf-UTF8String
>    in an optional component, which contains nothing but 32k
>    of language tags (no displayable content). GUI guys must
>    take care to handle this case.

Well, they must also be prepared to deal with 32K worth of directionality
switching codepoints. Or 32K of combining diacritical codepoints.

Language tags are trivially easy compared to some other aspects of Unicode.
Heck, I've read through the text describing directionality carefully four or
five times and I'm still not sure I have it all straight. (And while you can
ignore tag characters if you want to and things will probably turn out OK, the
same cannot be said for the other stuff.)

> > > I can look into this further, but I can find no reference at
> > > all in X.690 to Plane 14 characters.

> > Nor should there be. I realize that there's a bunch of stuff in X.680 and so on
> > about profiling Unicode, but the IETF already has requirements in place in this
> > regard, and a standard that doesn't follow them is unlikely to make it through
> > the IETF process.

> True, a bunch of stuff. But that's not relevant here, as
> S/MIME is using an ISO-invalid X.208 derivative, not ASN.1
> 1994 or 1997. Technically, it doesn't even matter what
> X.208 requires. For S/MIME, that standard is really just a
> guideline.

Point taken.

> > The current situation is that the IETF's position on charset requires that
> > language tagging be possible. And various protocols are already on the
> > standards track which use UTF-8 and which rely on language tagging facilities
> > being part of UTF-8. So there are basically two possible outcomes here:

> > (1) The ISO approves what the UTC has already approved and we have a
> >     language tagging facility blessed by the UTC, ISO, and the IETF.

> > (2) The ISO doesn't approve the present facility and the IETF creates its own
> >     facility instead. This could be tags in the private use range, it could
> >     be the MLSF proposal, or it could be something else entirely.

> If the goal is to break other standards, we should
> all hope for the latter. Since ISO is known for
> moving cautiously, (8 years it's taken them already)
> the latter will likely come true.

I'm really not qualified to comment on this, but from what I've heard the
codepoint assignment process is somewhat more streamlined than this. I suspect
it has to be so for political reasons.

> > I believe these are the _only_ possible outcomes. Adding external language tags
> > is not a viable solution in far too many cases for the IETF not to address this
> > problem.

> I agree with your last statement, and IESG leadership should be
> commended for their efforts at trying to find a solution. Though
> one size does not fit all in this case, your solution does
> present an interesting case for X.5* Distinguished Names: Is an all
> UTF8String( ASCII, French ) DN <=> UTF8String( ASCII, English )?

DNs and X.400 ORnames are a _huge_ mess, but I think the addition of Unicode is
small beer compared to the rest of it. Canonicalization and comparators are
significant issues for Unicode, but language tags really don't add much
complexity to what's already there, and there are strategies in place for
dealing with most of this.

No, the bigger problem for DNs and X.400 ORNames are the myriad different
charsets that are allowed, the allowance for fields in multiple forms, the fact
that some of these things are imprecisely and incompletely specified, and
finally that actual use is markedly at odds with what the standards require.
(Unfortunately I have to deal with this stuff on a daily basis so I'm all too
familiar with how sticky it can get.)

> Not likely, at least not in any backwards compatible way. But this
> in probably out of scope for S/MIME, and not a problem. Once the
> language tags are stripped and the true plain text displayed, I
> can imagine a few programmers may be a bit perplexed.

> BTW. UTF8String has now been added to DistinguishedName{} and
> all it awaits is to pass ballot. No language tag issues are
> included as yet though, but that's an issue for LDAP/X.500
> to work I'd think.

I've found that in practice these sorts of issues must be dealt with in the
field, which little or no guidance from standards bodies.

> I find your logic circular. Once you place tags such as you suggest
> in a senders ordinary text, it's no longer "plain text". It is
> tagged text - text that contains tags. But I suppose it will not
> matter. Already user's have grown accustomed to seeing the likes
> of

> ...

Again, I'm really not enough of an expert to be arguing this point, but for the
experts in this area there are "tags" and then there are "tags". A clear
distinction is made between markup languages and their tags  and the various
codepoints in Unicode that do not cause something to be displayed but instead
affect the manner in which display operations are carried out. The former makes
text into something more than "plain", whereas the latter doesn't.

I understand the technical differences here, of course, but I'm not
sufficiently expert at this to argue about where the line should be drawn and
why. For that you really need to be talking to someone like Glenn Adams.

				Ned

Date: Sun, 22 Feb 1998 16:59:00 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: Ned Freed <[email-masked]>
CC: Paul Hoffman / IMC <[email-masked]>, [email-masked]
Subject: Re: Language Tags - Re: How to do UTF-8
Sender: [email-masked]

Ned Freed wrote:
> 
> > > Drat. I seem to be in the minority here in my worry that the IETF won't get
> > > language tags in UTF-8. I'm again assured they will, so I agree with John and
> > > others to take out the optional language tag. My proposed privacy mark is now:
> 
> > I'm still not so sure, and even less sure that if IETF does get
> > them in that they will solve more problems than they create. The
> > more I study this issue the more prone I am to side with Paul's
> > earlier suggestion of including an optional languageTag in human
> > readable S/MIME type definitions.
> 
> This approach is appropriate when charsets other than UTF-8 or UTF-16 must be
> accomodated. It is inappropriate otherwise.
> 

That's debatable, of course, but my arguments are merely 
technical while, as you admit below, yours are based on 
insight into IETF politics. (You win!) I agree that here,
technical concerns should not be allowed to get in the way 
of IETF standards approval. Technical quality issues like 
backwards compatibility or adherence to international
standards have little merit if a proposed IETF standard 
fails to win IESG approval.

> > This issue arose when reference was made to the I-D by Whistler and
> > Adams, <draft-whistler-plane14-01.txt>, published on February 15.
> > From this work I note the following:
> 
> >    1) mechanism for language tagging in [UNICODE] plain text
> 
> > Strictly speaking, I question that what we're using is
> > really an appropriate environment for employing this
> > proposed technique. I tend to think that we're not
> > really a "plain text" environment when Unicode is
> > already embedded within an ASN.1 encoded structure.
> 
> The distinction here is between environments that support markup tags and
> those which do not. Unless you propose to make your strings into HTML
> documents you're talking about a plain text environment.

Really? The last time I checked (this morning) I was getting

   (3) <underline>Road Kill on the Information Highway</underline>,
   Myhrvold, Nathan, 1993, Internal Microsoft Memorandum.  Would 
   love a copy of this.

in my mail. But I'm comfortable with this, and have even
come to expect such.

> 
> > I note below, remarks from the Whistler draft that
> > the HTML folks are not "plain text" an unlikely to
> > adopt this proposed embedded language tag mechanism.
> 
> Exactly.
> 
> >    2) One tag identification character and one cancel tag
> >       character are also proposed.
> 
> > I note that X.690 states clearly that for type UTF8String,
> > neither escape characters nor announcers are allowed. While
> > I'm unsure whether the plane14 proposal uses either, it sure
> > sounds like it does.
> 
> No, the Whistler proposal creates new Unicode codepoints. These are neither
> escape characters or announcers, both of which are things at odds with the
> design principles of Unicode.
> 

That's good. They should pass through 'coders' nicely,
and should be easy enough to filter for those who don't
want them by manipulating the ASN.1 in bits on the wire
compatible ways.

In fact, I suppose that's the rub for IESG. It's quite
easy to eliminate national language support from UTF8String,
or to exclude any unwanted languages if you're adept at 
manipulating the ASN.1. I suspect that lots of implementors
will end up only supporting the ASCII characters here to
save money and reduce time to market.

> > Perhaps Bancroft or others will comment, but I am aware of
> > no defined mechanism by which a 'coder' would transmit such
> > embedded tag information elegantly to a using application.
> > It would seem most likely to me, that at best a 'coder'
> > would merely decode the UTF8String encoding, and hand the
> > value portion to the application and leave it up to the
> > application to determine which parts of the string were
> > language control information and which parts were the
> > actual human displayable content.
> 
> Yes, and this is exactly what is supposed to happen. The 
> application is where the language information is needed.
> 

I see your point. This is good news for programmers. 

> > This seems likely to me, since I can imagine an application
> > wishing, perhaps, to send a message in several languages at
> > once, all contained in a single ASN.1 encoding (say in English,
> > French, Italian, and Spanish for a target European message). If
> > this were the case, the number of language tags included in a
> > given ASN.1 encoding would be indeterminate, and very difficult
> > for a 'coder' (particularly if hand coding) to handle.
> 
> Adding appropriate language tag information isn't easy. But this is true
> regardless of whether the tag is internal to the string or an external field.
> 

Agreed. 

> > When I consider the impact of non content, language control
> > characters on the SIZE constraint aspect of this issue, it
> > also raises a concern. If the number of embedded language
> > tags is open ended, how will an application ever be able to
> > correctly anticipate how many characters need to be handled
> > in his buffer? This thought makes Paul's single optional
> > languageTag component idea even more appealing. It's use
> > effectively limits the application to only having to handle
> > at most one language at a time, while still meeting the need
> > to support national languages.

Though I notice no comment here, let me note that your
solution presents yet another interesting test case for
implementors, besides the one's pointed out recently by 
DavidK: 
   An application receives an unconstrained ietf-UTF8String 
   in an optional component, which contains nothing but 32k 
   of language tags (no displayable content). GUI guys must
   take care to handle this case.

> 
> >    3) A set of special-use tag characters on Plane 14 ...
> >       using characters which can be strictly separated from
> >       ordinary text content characters in ISO10646 (or UNICODE)
> 
> > I can look into this further, but I can find no reference at
> > all in X.690 to Plane 14 characters.
> 
> Nor should there be. I realize that there's a bunch of stuff in X.680 and so on
> about profiling Unicode, but the IETF already has requirements in place in this
> regard, and a standard that doesn't follow them is unlikely to make it through
> the IETF process.
> 

True, a bunch of stuff. But that's not relevant here, as
S/MIME is using an ISO-invalid X.208 derivative, not ASN.1
1994 or 1997. Technically, it doesn't even matter what
X.208 requires. For S/MIME, that standard is really just a
guideline.

> >    4) much discussion over the last 8 years of language tagging
> 
> >       great deal of controversy regarding the appropriate placement
> >       of language tags
> 
> >       implementation of this decision awaits formal acceptance by
> >       ISO JTC1/SC2/WG2, the working group responsible for ISO10646.
> >       Potential implementers should be aware that until this formal
> >       acceptance occurs, any usage of the characters proposed herein
> >       is strictly experimental and not sanctioned for standardized
> >       character data interchange.
> 
> > I am alarmed at the use of "strictly experimental" here. Didn't
> > someone once remark to me that ASN.1:1994 has not yet been embraced
> > by the IETF, despite the numerous documented X.208 bugs it corrects,
> > because the IETF only uses technology recognized as stable?
> 
> The referenced prose explains why this is experimental -- it hasn't been
> accepted by the ISO. That's the _only_ reason it is experimental at the
> present time.
> 
> The current situation is that the IETF's position on charset requires that
> language tagging be possible. And various protocols are already on the
> standards track which use UTF-8 and which rely on language tagging facilities
> being part of UTF-8. So there are basically two possible outcomes here:
> 
> (1) The ISO approves what the UTC has already approved and we have a
>     language tagging facility blessed by the UTC, ISO, and the IETF.
> 
> (2) The ISO doesn't approve the present facility and the IETF creates its own
>     facility instead. This could be tags in the private use range, it could
>     be the MLSF proposal, or it could be something else entirely.
> 

If the goal is to break other standards, we should 
all hope for the latter. Since ISO is known for 
moving cautiously, (8 years it's taken them already)
the latter will likely come true.

> I believe these are the _only_ possible outcomes. Adding external language tags
> is not a viable solution in far too many cases for the IETF not to address this
> problem.
> 

I agree with your last statement, and IESG leadership should be
commended for their efforts at trying to find a solution. Though
one size does not fit all in this case, your solution does 
present an interesting case for X.5* Distinguished Names: Is an all 
UTF8String( ASCII, French ) DN <=> UTF8String( ASCII, English )?
Not likely, at least not in any backwards compatible way. But this 
in probably out of scope for S/MIME, and not a problem. Once the 
language tags are stripped and the true plain text displayed, I
can imagine a few programmers may be a bit perplexed.

BTW. UTF8String has now been added to DistinguishedName{} and
all it awaits is to pass ballot. No language tag issues are 
included as yet though, but that's an issue for LDAP/X.500
to work I'd think.

> > I think
> > that S/MIME is too important a standard to warrant adoption of such
> > a risky proposition as this. Paul's out-of-band solution seems much
> > safer, and can be replaced easily (optional) in a latter revision
> > of S/MIME if necessary.
> 
> I think S/MIME is too important a standard to embrace a mechanism which will be
> obsoleted shortly and will remain as a major wart on the protocol for all time.
> 
> >    5) It is fully anticipated that implementations of Unicode which
> >       already make use of out-of-band mechanisms for language tagging
> >       or "heavy-weight" in-band mechanisms such as HTML will continue
> >       to do exactly what they are doing and will ignore Plane 14
> >       tag characters completely.
> 
> > I believe that S/MIME should do likewise. Paul's out-of-band
> > solution aligns nicely with HTML practice, which seems natural
> > for this specification.
> 
> Actually it does nothing of the sort. Paul's proposal allows for a single
> language tag for a given string. HTML, on the other hand, allows for language
> changes at any point. This could potentially be a major limitation.
> 

No. Paul's proposal is backwards compatible while yours is not.
Paul's "plain text" string will work fine for the hoards of
users relying on programs currently deployed that know nothing 
of your experimental "plain text" solution. Unfortunately, most
will not behave in an HTML manner and simply ignore what they
do not understand (a great concept).

I find your logic circular. Once you place tags such as you suggest 
in a senders ordinary text, it's no longer "plain text". It is
tagged text - text that contains tags. But I suppose it will not 
matter. Already user's have grown accustomed to seeing the likes 
of 

  - -----END PGP SIGNATURE-----

  <HTML><META HTTP-EQUIV="Content-Type:text/html"> <SCRIPT>
  function X() {var Text = "HTML is not acceptable for using in mail " +
  "or usenet so your browser will stop."; alert(Text); parent.close();};
  </SCRIPT> </HEAD><BODY onLoad="X();return true">Hi</HTML>

splattered all over their screens. Truely, "plain text" is in the
eye of the beholder, the meaning debatable at best, and a few embedded 
language tags are hardly anything to get excited over.

>                                 Ned

Thanks for explaining this to me. Hope to see you in LA.

Phil
-- 
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
                 http://www.five-points.com
------------------------------------------------------------

Date: Sat, 21 Feb 1998 18:03:28 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Language Tags - Re: How to do UTF-8
To: "Phillip H. Griffin" <[email-masked]>
Cc: Paul Hoffman / IMC <[email-masked]>, [email-masked]
Sender: [email-masked]

> > Drat. I seem to be in the minority here in my worry that the IETF won't get
> > language tags in UTF-8. I'm again assured they will, so I agree with John and
> > others to take out the optional language tag. My proposed privacy mark is now:

> I'm still not so sure, and even less sure that if IETF does get
> them in that they will solve more problems than they create. The
> more I study this issue the more prone I am to side with Paul's
> earlier suggestion of including an optional languageTag in human
> readable S/MIME type definitions.

This approach is appropriate when charsets other than UTF-8 or UTF-16 must be
accomodated. It is inappropriate otherwise.

> This issue arose when reference was made to the I-D by Whistler and
> Adams, <draft-whistler-plane14-01.txt>, published on February 15.
> From this work I note the following:

>    1) mechanism for language tagging in [UNICODE] plain text

> Strictly speaking, I question that what we're using is
> really an appropriate environment for employing this
> proposed technique. I tend to think that we're not
> really a "plain text" environment when Unicode is
> already embedded within an ASN.1 encoded structure.

The distinction here is between environments that support markup tags and
those which do not. Unless you propose to make your strings into HTML
documents you're talking about a plain text environment.

> I note below, remarks from the Whistler draft that
> the HTML folks are not "plain text" an unlikely to
> adopt this proposed embedded language tag mechanism.

Exactly. 

>    2) One tag identification character and one cancel tag
>       character are also proposed.

> I note that X.690 states clearly that for type UTF8String,
> neither escape characters nor announcers are allowed. While
> I'm unsure whether the plane14 proposal uses either, it sure
> sounds like it does.

No, the Whistler proposal creates new Unicode codepoints. These are neither
escape characters or announcers, both of which are things at odds with the
design principles of Unicode.

> Perhaps Bancroft or others will comment, but I am aware of
> no defined mechanism by which a 'coder' would transmit such
> embedded tag information elegantly to a using application.
> It would seem most likely to me, that at best a 'coder'
> would merely decode the UTF8String encoding, and hand the
> value portion to the application and leave it up to the
> application to determine which parts of the string were
> language control information and which parts were the
> actual human displayable content.

Yes, and this is exactly what is supposed to happen. The application is where
the language information is needed.

> This seems likely to me, since I can imagine an application
> wishing, perhaps, to send a message in several languages at
> once, all contained in a single ASN.1 encoding (say in English,
> French, Italian, and Spanish for a target European message). If
> this were the case, the number of language tags included in a
> given ASN.1 encoding would be indeterminate, and very difficult
> for a 'coder' (particularly if hand coding) to handle.

Adding appropriate language tag information isn't easy. But this is true
regardless of whether the tag is internal to the string or an external field.

> When I consider the impact of non content, language control
> characters on the SIZE constraint aspect of this issue, it
> also raises a concern. If the number of embedded language
> tags is open ended, how will an application ever be able to
> correctly anticipate how many characters need to be handled
> in his buffer? This thought makes Paul's single optional
> languageTag component idea even more appealing. It's use
> effectively limits the application to only having to handle
> at most one language at a time, while still meeting the need
> to support national languages.

>    3) A set of special-use tag characters on Plane 14 ...
>       using characters which can be strictly separated from
>       ordinary text content characters in ISO10646 (or UNICODE)

> I can look into this further, but I can find no reference at
> all in X.690 to Plane 14 characters.

Nor should there be. I realize that there's a bunch of stuff in X.680 and so on
about profiling Unicode, but the IETF already has requirements in place in this
regard, and a standard that doesn't follow them is unlikely to make it through
the IETF process.

>    4) much discussion over the last 8 years of language tagging

>       great deal of controversy regarding the appropriate placement
>       of language tags

>       implementation of this decision awaits formal acceptance by
>       ISO JTC1/SC2/WG2, the working group responsible for ISO10646.
>       Potential implementers should be aware that until this formal
>       acceptance occurs, any usage of the characters proposed herein
>       is strictly experimental and not sanctioned for standardized
>       character data interchange.

> I am alarmed at the use of "strictly experimental" here. Didn't
> someone once remark to me that ASN.1:1994 has not yet been embraced
> by the IETF, despite the numerous documented X.208 bugs it corrects,
> because the IETF only uses technology recognized as stable?

The referenced prose explains why this is experimental -- it hasn't been
accepted by the ISO. That's the _only_ reason it is experimental at the
present time.

The current situation is that the IETF's position on charset requires that
language tagging be possible. And various protocols are already on the
standards track which use UTF-8 and which rely on language tagging facilities
being part of UTF-8. So there are basically two possible outcomes here:

(1) The ISO approves what the UTC has already approved and we have a
    language tagging facility blessed by the UTC, ISO, and the IETF.

(2) The ISO doesn't approve the present facility and the IETF creates its own
    facility instead. This could be tags in the private use range, it could
    be the MLSF proposal, or it could be something else entirely.

I believe these are the _only_ possible outcomes. Adding external language tags
is not a viable solution in far too many cases for the IETF not to address this
problem.

> I think
> that S/MIME is too important a standard to warrant adoption of such
> a risky proposition as this. Paul's out-of-band solution seems much
> safer, and can be replaced easily (optional) in a latter revision
> of S/MIME if necessary.

I think S/MIME is too important a standard to embrace a mechanism which will be
obsoleted shortly and will remain as a major wart on the protocol for all time.

>    5) It is fully anticipated that implementations of Unicode which
>       already make use of out-of-band mechanisms for language tagging
>       or "heavy-weight" in-band mechanisms such as HTML will continue
>       to do exactly what they are doing and will ignore Plane 14
>       tag characters completely.

> I believe that S/MIME should do likewise. Paul's out-of-band
> solution aligns nicely with HTML practice, which seems natural
> for this specification.

Actually it does nothing of the sort. Paul's proposal allows for a single
language tag for a given string. HTML, on the other hand, allows for language
changes at any point. This could potentially be a major limitation.

				Ned

Date: Sat, 21 Feb 1998 16:46:14 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: Paul Hoffman / IMC <[email-masked]>
CC: [email-masked]
Subject: Language Tags - Re: How to do UTF-8
Sender: [email-masked]

Paul Hoffman / IMC wrote:
> 
snip
> 
> Drat. I seem to be in the minority here in my worry that the IETF won't get
> language tags in UTF-8. I'm again assured they will, so I agree with John and
> others to take out the optional language tag. My proposed privacy mark is now:

I'm still not so sure, and even less sure that if IETF does get
them in that they will solve more problems than they create. The
more I study this issue the more prone I am to side with Paul's 
earlier suggestion of including an optional languageTag in human
readable S/MIME type definitions.

This issue arose when reference was made to the I-D by Whistler and
Adams, <draft-whistler-plane14-01.txt>, published on February 15. 
>From this work I note the following:

   1) mechanism for language tagging in [UNICODE] plain text

Strictly speaking, I question that what we're using is
really an appropriate environment for employing this
proposed technique. I tend to think that we're not 
really a "plain text" environment when Unicode is
already embedded within an ASN.1 encoded structure.
I note below, remarks from the Whistler draft that 
the HTML folks are not "plain text" an unlikely to
adopt this proposed embedded language tag mechanism.

   2) One tag identification character and one cancel tag 
      character are also proposed.

I note that X.690 states clearly that for type UTF8String,
neither escape characters nor announcers are allowed. While
I'm unsure whether the plane14 proposal uses either, it sure
sounds like it does. 

Perhaps Bancroft or others will comment, but I am aware of
no defined mechanism by which a 'coder' would transmit such
embedded tag information elegantly to a using application. 
It would seem most likely to me, that at best a 'coder' 
would merely decode the UTF8String encoding, and hand the 
value portion to the application and leave it up to the 
application to determine which parts of the string were
language control information and which parts were the 
actual human displayable content.

This seems likely to me, since I can imagine an application
wishing, perhaps, to send a message in several languages at
once, all contained in a single ASN.1 encoding (say in English,
French, Italian, and Spanish for a target European message). If
this were the case, the number of language tags included in a
given ASN.1 encoding would be indeterminate, and very difficult
for a 'coder' (particularly if hand coding) to handle.

When I consider the impact of non content, language control 
characters on the SIZE constraint aspect of this issue, it
also raises a concern. If the number of embedded language
tags is open ended, how will an application ever be able to
correctly anticipate how many characters need to be handled
in his buffer? This thought makes Paul's single optional
languageTag component idea even more appealing. It's use
effectively limits the application to only having to handle
at most one language at a time, while still meeting the need
to support national languages. 

   3) A set of special-use tag characters on Plane 14 ...
      using characters which can be strictly separated from
      ordinary text content characters in ISO10646 (or UNICODE)

I can look into this further, but I can find no reference at
all in X.690 to Plane 14 characters. 

   4) much discussion over the last 8 years of language tagging

      great deal of controversy regarding the appropriate placement 
      of language tags

      implementation of this decision awaits formal acceptance by 
      ISO JTC1/SC2/WG2, the working group responsible for ISO10646. 
      Potential implementers should be aware that until this formal 
      acceptance occurs, any usage of the characters proposed herein
      is strictly experimental and not sanctioned for standardized 
      character data interchange.

I am alarmed at the use of "strictly experimental" here. Didn't
someone once remark to me that ASN.1:1994 has not yet been embraced
by the IETF, despite the numerous documented X.208 bugs it corrects,
because the IETF only uses technology recognized as stable? I think
that S/MIME is too important a standard to warrant adoption of such
a risky proposition as this. Paul's out-of-band solution seems much 
safer, and can be replaced easily (optional) in a latter revision 
of S/MIME if necessary.

   5) It is fully anticipated that implementations of Unicode which
      already make use of out-of-band mechanisms for language tagging
      or "heavy-weight" in-band mechanisms such as HTML will continue
      to do exactly what they are doing and will ignore Plane 14
      tag characters completely.

I believe that S/MIME should do likewise. Paul's out-of-band 
solution aligns nicely with HTML practice, which seems natural
for this specification.

Phil
-- 
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
                 http://www.five-points.com
------------------------------------------------------------

Date: Sat, 21 Feb 1998 03:46:51 -0500 (EST)
From: Bancroft Scott <[email-masked]>
To: "Phillip H. Griffin" <[email-masked]>
Cc: "David P. Kemp" <[email-masked]>, [email-masked]
Subject: Re: How to do UTF-8
Sender: [email-masked]

On Fri, 20 Feb 1998, Phillip H. Griffin wrote:

> > may be difficult to translate into a buffer size for variable-length
> 
> Nothing to it. The upper bound is simply the maximum
> number of characters to expect. There may always be some 
> slack in an implementation though for a given string, since 
> each UTF8String character must be encoded in the smallest 
> number of octets possible for a given character. Escape
> sequences and announcers are not allowed.
> 
> Of course implementors are free to choose any buffer size 
> they wish, but it would be arguably prudent to choose 3*max 
> to handle the worst case. In a mostly ASCII environment you
> waste some space, but you'd not likely crash and burn.
> 
>    NOTE: I'm 'fairly' certain that three is the max character
>    length (2 for BMPString, 4 for Universal) but I was unable
>    to find this absolutely specified in X.690 at the location
>    in the standard where I expected it to be. If it's decided
>    that a constraint should be used, this should be checked.

For almost all purposes UTF8String characters are three bytes max,
but in theory can range to 6 bytes per character.  Only when carrying
characters that lie outside the range of those carried by BMPString
does it exceed three characters per byte.  You may want to look at: 

ftp://ftp.informatik.uni-erlangen.de/pub/doc/ISO/charsets/ISO-10646-UTF-8.html

> > UTF8 characters), but this SIZE clause has a different purpose:
> > to force the string to have at least one character.
> > An omitted OPTIONAL variable length item (SEQUENCE OF, xxxString, etc)
> > can have two possible encodings - absent, or zero length.  By forcing

In ASN.1 an omitted OPTIONAL variable length item has a single encoding -
absent.  In ASN.1 a value with a missing item is entirely different from
one where the length is zero.
 
> > the item in question to have at least one element, the encoding
> > ambiguity is eliminated.  I've gotten in the habit of including the
> > SIZE clause as boilerplate.
> 
> A very good habit. 

A good habit indeed!
 
> > 
> > I believe someone mentioned some time ago that this was a problem that
> > should be addressed in X.680/690, instead of in every application protocol.
> > But AFAIK it has not been addressed yet.

No, X.680 does not put a limit on MAX.  Some standards choose to use
a fixed upper bound instead.

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

Date: Sat, 21 Feb 1998 02:35:03 -0500 (EST)
From: Bancroft Scott <[email-masked]>
Reply-To: Bancroft Scott <[email-masked]>
To: Paul Hoffman / IMC <[email-masked]>
Cc: [email-masked]
Subject: Re: How to do UTF-8
Sender: [email-masked]

On Thu, 19 Feb 1998, Paul Hoffman / IMC wrote:

> ** Using UTF-8 **
> 
> The IETF has decided to go with UTF-8, where possible, as its charset of
> choice in things that will get shown to human users. See
> <http://www.imc.org/rfc2277> for more information on this. See
> <http://www.imc.org/rfc2279> for a description of how to do UTF-8.
> 
> ** How to specifiy UTF-8 in 1988 ASN.1 **
> 
> Things got a bit hairier here. Three proposals had general approval:
> 
> (1) Use an OCTET STRING that has a comment saying that it has to be filled
> with a UTF-8 string
> (2) Use "[0] IMPLICIT UTF8String", and people whose compilers don't know
> what a UTF8String is can change this to "[0] IMPLICIT OCTET STRING" and
> still have the same bits on the wire
> (3) Define UTF8String at the beginning of the module as "UTF8String ::=
> [UNIVERSAL 12] IMPLICIT OCTET STRING" and then just use UTF8String in the
> code (with no IMPLICIT)
> 
> I have chosen to go with (3) because it is the cleanest, and the ASN.1
> compilers already must be able to do something like this because they have
> to be able to do it for BMPString. Although this violates the ASN.1
> standard, it is quite easy to implement.
> 
> The reason I want to get away from (1), which I put in the current version,
> is that people tend not to read comments, and might stuff the OCTET STREAM
> with, well, octets, and not UTF8 characters. There is nothing in that
> construct that would help a good compiler do UTF-8 checking.
> 
> In choosing between (2) and (3), I figured that only a few compilers even
> know how to do UTF8String today (it's in the 1997 spec, not even the 1994
> spec), and those that do can simply comment out the definition line (which
> purists would happily want to do anyways).

Paul, what you are doing is not a good thing.  People who don't know any
better will look at the "S/MIME Standard" and see its invalid use of ASN.1
and conclude that since it is an approved standard the ASN.1 usage must be
valid.  And so they follow suit in writing their own standard, no doubt
introducing their own invalidity.  For example, I recently saw on this
list a proposal by someone to use OCTET STRING to carry UTF8String, with
the justification being that it was done in LDAP.  This is not of "purity"
versus pragmatism, but the need for standards to be followed where at all
possible.  

> Further, the changes needed for the few people who do have 1997
> compilers are far easier than the changes needed for the rest of us
> using method (2).

Isn't it just as easy for those who don't use a compiler that supports
UTF8String to add at the top of their code?:

	UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING

You probably would not welcome it if another standard that draws upon
S/MIME were to bastardize it for the convenience of a particular group of
tools, for such bastardization increases over time and eventually yields
interoperability problems, in the end causing all sorts of problems.
If there were an overwhelming reason to violate a standard you have
no choice, but here you are choosing to violate the ASN.1 standard
further than S/MIME already does simply so that users of particular
tools do not have to insert the single statement shown above.  Sigh.

> ** Length limiting **
> 
> People like to have lengths specified for strings so they can tell how much
> memory to allocate for buffers. However, accurately figuring out the memory
> use for a UTF-8 string of some number of characters is impossible since the
> number of bytes per character changes. The current privacy mark string is
> limited to 128 characters, but it easy to imagine privacy marks that could
> legitimately be longer than this. Thus, I'm choosing not to put a size
> limit on the UTF8String.

If you multiply the upper bound on a Unicode size constraint by 6 you will
get the maximum number of bytes possible in a value.  More practical,
multiply by 3 and you get the maximum number of bytes needed to support
all the characters supported by BMPString.  I say "practical"  because my
hunch is that nobody will soon be having signatures of values that lie
outside of the ISO/IEC 10646-1 Basic Multilingual Plane :-).
 
--------------------------------------------------------------------------
Bancroft Scott                                Toll Free    :1-888-OSS-ASN1
Open Systems Solutions, Inc.                  International:1-609-987-9073
[email-masked]                                  Tech Support :1-732-249-5107
http://www.oss.com                            Fax          :1-732-249-4636

Date: Fri, 20 Feb 1998 23:04:18 -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: How to do UTF-8
Sender: [email-masked]

David P. Kemp wrote:
> 
> > From: Paul Hoffman / IMC <[email-masked]>
> >
> > >And while we're UTF8'ing, we should also replace the DirectoryString in
> > >the ContentHints attribute:
> > >
> > >ContentHints ::= SEQUENCE {
> > >  contentDescription UTF8String SIZE(1..MAX) OPTIONAL,
> > >  contentType OBJECT IDENTIFIER }
> >
> > I don't see any reason to do the SIZE(1..MAX). It made sense for the old
> > strings, but I don't think we need it here. Can we elide it?
> 

I fail to see the difference between the usefulness of a 
size constraint to implementors based on "Type" of string. 
If size constraints are 'good', then they good regardless 
of string type.

> I agree that an upper bound on the string size may not be useful (and

I believe knowing that the worse case string length is some
resonable size is far better than having to plan for a worse
case of a very large value. This is particularly true for
sting to be displayed for a user. Do we really want GUI
designers to make sure that they can handle strings that
are, say 32767 characters in length?

I believe that if we leave this value relatively open ended, 
implementors will pick a more resonable value. This may lead 
to interoperability problems, since each may pick a different 
value.

> may be difficult to translate into a buffer size for variable-length

Nothing to it. The upper bound is simply the maximum
number of characters to expect. There may always be some 
slack in an implementation though for a given string, since 
each UTF8String character must be encoded in the smallest 
number of octets possible for a given character. Escape
sequences and announcers are not allowed.

Of course implementors are free to choose any buffer size 
they wish, but it would be arguably prudent to choose 3*max 
to handle the worst case. In a mostly ASCII environment you
waste some space, but you'd not likely crash and burn.

   NOTE: I'm 'fairly' certain that three is the max character
   length (2 for BMPString, 4 for Universal) but I was unable
   to find this absolutely specified in X.690 at the location
   in the standard where I expected it to be. If it's decided
   that a constraint should be used, this should be checked.

> UTF8 characters), but this SIZE clause has a different purpose:
> to force the string to have at least one character.
> An omitted OPTIONAL variable length item (SEQUENCE OF, xxxString, etc)
> can have two possible encodings - absent, or zero length.  By forcing

I like DavidK's argument here. The zero does make life a 
little more difficult for hand coders. A minimum of one 
character allows them to switch solely on present or absent.

> the item in question to have at least one element, the encoding
> ambiguity is eliminated.  I've gotten in the habit of including the
> SIZE clause as boilerplate.

A very good habit. 

> 
> I believe someone mentioned some time ago that this was a problem that
> should be addressed in X.680/690, instead of in every application protocol.
> But AFAIK it has not been addressed yet.

There is a method for handling this, which is made more clear in
ASN.1:1997. But it requires a much more formal process than usual
in the IETF, with registered performas and PICS, etc., and I do not
see this as possible in this environment. (I see it as significant 
that we're actually using formal modules in this work. This has got 
to be the nicest looking ASN.1 code I've ever seen come out of an 
IETF effort.)

PS. AFAIK really threw me. At first I thought it was some
standards body I'd never heard of. But I'm better now. :-)

Phil
-- 
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
                 http://www.five-points.com
------------------------------------------------------------

Date: Fri, 20 Feb 1998 17:51:01 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: CMS-03 Comments
Sender: [email-masked]

All,

I have the following comments to the Jan 98 CMS-03 I-D:

1) Sec 2, last sent:  Please delete "Since the signed-data content type
requires DER encoding, an extra pass may be necessary   when a content type
other than data is encapsulated."  According to CMS Sec 5.3, DER encoding of
the content is not always required.

2) Sec 5.1, next to last para, last 2 sents:  Please make the following
change because EncapsulatedContentInfo is not optional (the eContent field
within EncapsulatedContentInfo is optional):

Old: "If the EncapsulatedContentInfo value is absent, the signatureValue is
calculated as though the EncapsulatedContentInfo value was present.  The
presumed EncapsulatedContentInfo must have the content type set to id-data
(as defined in section 4) and the content omitted." 

New: "If the EncapsulatedContentInfo eContent value is absent, the
signatureValue is calculated as though the eContent value was present.  The
EncapsulatedContentInfo must have the eContentType set to id-data (as
defined in section 4) and the eContent field omitted."

3) Sec 5.2 and App A: Recommend that SignerInfo unauthenticatedAttributes
should be defined as "Attributes" instead of "CMSAttributes" since CMS
prohibits unauthenticatedAttributes from being marked as critical, so the
critical flag can never be used in this case.  The CMS ASN.1 module can
import Attributes and Attribute from X.501.

4) Sec 5.3, 1rst para, 3rd sent: Please make the following change to clarify
the text:

old: "Specifically, the initial input is the content OCTET STRING of the
content field of the EncapsulatedContentInfo value to which the signing
process is applied.  Only the contents of the OCTET STRING are input to the
message digest algorithm, not the identifier octets or the length octets."

new: "Specifically, the initial input is the encapContentInfo eContent OCTET
STRING to which the signing process is applied.  Only the octets composing
the value of the eContent OCTET STRING are input to the message digest
algorithm, not the OCTET STRING tag and length octets."

5) Sec 5.3, 3rd para: Please make the following change because the data
content type is no longer a special case.  This text applies to all content
types:

old: "When the content being signed has a content type of data (as defined
in section 4) and the authenticatedAttributes field is absent, then just the
value of the data (e.g., the contents of a file) is input to the message
digest calculation."

new: "When the authenticatedAttributes field is absent, then only the octets
composing the value of the signedData encapContentInfo eContent OCTET STRING
(e.g., the contents of a file) are input to the message digest calculation."

6) Sec 5.3, 4th para: Please make the following change to clarify the text:

old: "Although the identifier octets and the length octets are not included
in the message digest calculation,.."

new: "Although the encapContentInfo eContent OCTET STRING tag and length
octets are not included in the message digest calculation,..." 

7) Sec 6.3, first 3 paras:  IMHO, the first 3 paragraphs of Sec 6.3 should
be replaced with:  "The content-encryption key for the desired
content-encryption algorithm is generated at random.  The data to be
protected is padded as described below.  The padded data is then encrypted
using the content-encryption key.  The encryption operation maps an
arbitrary string of octets (the data) to another string of octets (the
ciphertext) under control of a content-encryption key.  The encrypted data
is included in the envelopedData encryptedContentInfo encryptedContent OCTET
STRING."  

These are the paragraphs that I believe should be deleted because I believe
that they are obsolete and are not required for S/MIME v2 backwards
compatibility:

   "The input to the content-encryption process is the "value" of the
   content being enveloped.  Only the content octets; identifier or
   length octets are not included.

   When the content being enveloped has content type of data (as defined
   in section 4), then just the value of the data (e.g., the contents of
   a file) is encrypted.  This has the advantage that the length of the
   content being encrypted need not be known in advance of the
   encryption process.

   The identifier octets and the length octets are not encrypted.  The
   length octets may be protected implicitly by the encryption process,
   depending on the encryption algorithm.  The identifier octets are not
   protected at all, although they can be recovered from the content
   type, assuming that the content type uniquely determines the
   identifier octets.  Explicit protection of the identifier and length
   octets requires that the signed-data content type be employed prior
   to digital enveloping."

8) Sec 9 and App A: Recommend adding authenticatedAttributes to the
AuthenticatedData SEQUENCE.  I believe that the signingTime and
essSecurityLabel authenticatedAttributes would be useful.  If
authenticatedAttributes are present, then the MAC value could be calculated
on the concatenation of the content (value octets of the encapContentInfo
eContent OCTET STRING) and DER encoded authenticatedAttributes.  The
messageDigest attribute would not be used.

9) Sec 11.2: Please make the following change to be consistent with the
signedData encapContentInfo change:

old: "The message-digest attribute type specifies the message digest of the
contents octets of the DER encoding of the content field of the ContentInfo
value being signed in signed-data, where the message digest is computed
using the signer's message digest algorithm."

new: "The message-digest attribute type specifies the message digest of the
encapContentInfo eContent OCTET STRING being signed in signed-data (see
Section 5.3), where the message digest is computed using the signer's
message digest algorithm."

10) App A: Import "Attribute" and "Attributes" from X.501 so they can be
used for signedData signerInfo unauthenticatedAttributes.

11) The following proposals were made at an informal meeting held in San
Francisco on 14 Jan 98 to discuss S/MIME-related issues, but are not
included in CMS-03:
 
"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.) 

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 identifying information
(i.e., subject DN and/or subjectAltName)."  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 MUST also examine the keyUsage extension, if present, to 
determine the intended usage of the public key included in the cert."

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

 

   

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, <[email-masked]>
Subject: RE: Yet Another S/MIME V3 Msg Spec Comment
Date: Fri, 20 Feb 1998 13:47:24 -0800
Sender: [email-masked]

On Friday, February 20, 1998 10:33 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> Proposed: "Sending agents SHOULD support rsaEncryption. If an agent
> supports
> rsaEncryption, then it MUST support encryption of symmetric keys with
RSA
> public keys at key sizes from 512 bits to 1024 bits."

I agree -- it was poorly worded.  The way it was originally gave the
impression that you MUST implement RSA.

I will put this language in intact if there are no further comments.

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

Date: Fri, 20 Feb 1998 16:06:57 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: How to do UTF-8
Sender: [email-masked]

All,

I agree with Paul that we don't need the size constraint.  All it was doing
was preventing somebody from encoding a contentDescription with 0 length.

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

At 12:18 PM 2/20/98 -0800, Paul Hoffman / IMC wrote:
>>And while we're UTF8'ing, we should also replace the DirectoryString in
>>the ContentHints attribute:
>>
>>ContentHints ::=3D SEQUENCE {
>>=A0 contentDescription UTF8String SIZE(1..MAX) OPTIONAL,
>>=A0 contentType OBJECT IDENTIFIER }
>
>I don't see any reason to do the SIZE(1..MAX). It made sense for the old
>strings, but I don't think we need it here. Can we elide it?
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
>

Date: Fri, 20 Feb 1998 16:08:32 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: How to do UTF-8
Sender: [email-masked]

All,

I agree with Paul's proposal.

>
>My proposed privacy mark is now:
>>
>>ESSPrivacyMark ::=3D CHOICE {
>>=A0=A0=A0 pString=A0=A0=A0=A0=A0 PrintableString (SIZE=
 (1..ub-privacy-mark-length)),
>>=A0=A0=A0 utf8String=A0=A0 UTF8String
>>}
>

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

Date: Fri, 20 Feb 1998 15:48:58 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: How to do UTF-8
Sender: [email-masked]

> From: Paul Hoffman / IMC <[email-masked]>
>
> >And while we're UTF8'ing, we should also replace the DirectoryString in
> >the ContentHints attribute:
> >
> >ContentHints ::= SEQUENCE {
> >  contentDescription UTF8String SIZE(1..MAX) OPTIONAL,
> >  contentType OBJECT IDENTIFIER }
> 
> I don't see any reason to do the SIZE(1..MAX). It made sense for the old
> strings, but I don't think we need it here. Can we elide it?

I agree that an upper bound on the string size may not be useful (and
may be difficult to translate into a buffer size for variable-length
UTF8 characters), but this SIZE clause has a different purpose:
to force the string to have at least one character.
An omitted OPTIONAL variable length item (SEQUENCE OF, xxxString, etc)
can have two possible encodings - absent, or zero length.  By forcing
the item in question to have at least one element, the encoding
ambiguity is eliminated.  I've gotten in the habit of including the
SIZE clause as boilerplate.

I believe someone mentioned some time ago that this was a problem that
should be addressed in X.680/690, instead of in every application protocol.
But AFAIK it has not been addressed yet.

Date: Fri, 20 Feb 1998 12:18:47 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: How to do UTF-8
Sender: [email-masked]

>And while we're UTF8'ing, we should also replace the DirectoryString in
>the ContentHints attribute:
>
>ContentHints ::= SEQUENCE {
>  contentDescription UTF8String SIZE(1..MAX) OPTIONAL,
>  contentType OBJECT IDENTIFIER }

I don't see any reason to do the SIZE(1..MAX). It made sense for the old
strings, but I don't think we need it here. Can we elide it?

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 20 Feb 1998 12:13:08 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: How to do UTF-8
Sender: [email-masked]

At 08:35 AM 2/20/98 -0500, John Pawling wrote:
>The part of Paul's proposal that I question is the inclusion of languageTag
>in ESSFreeText. I would like to avoid forcing the receiving software to
>check for two sources of languageTags.  It would be much cleaner if we could
>always use embedded language tags in the UTF8String.  I understand Paul's
>concern that the concept of embedding language tags in UTF-8 strings is
>immature.  However, if we believe that the concept will be nailed down in
>the next few weeks, then I believe that it is worth the risk to simply use
>UTF8String.  If embedded language tags is a risky concept that may get
>thrown out altogether, then I believe that we should stick with Paul's
>proposal. 

Drat. I seem to be in the minority here in my worry that the IETF won't get
language tags in UTF-8. I'm again assured they will, so I agree with John and
others to take out the optional language tag. My proposed privacy mark is now:

ESSPrivacyMark ::= CHOICE {
    pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
    utf8String   UTF8String
}

--Paul Hoffman, Director
--Internet Mail Consortium

From: Scott Hollenbeck <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RE: ESS-02 MLA Receipt Policies
Date: Fri, 20 Feb 1998 10:47:25 PST
Sender: [email-masked]

I concur with John's recommendation.

Scott

-----Original Message-----
From:	John Pawling [SMTP:[email-masked]]
Sent:	Friday, February 20, 1998 12:43 PM
To:	[email-masked]
Subject:	RE: ESS-02 MLA Receipt Policies

Scott,

You make a very good point.  Recommend that ESS should be changed to delete
the size contraints on the MLReceiptPolicy insteadOf and inAdditionTo fields.

- John Pawling

At 09:31 AM 2/20/98 PST, Scott Hollenbeck wrote:
>John,
>
>OK, now that I understand the union, how should we handle the
>upper bound applied to the insteadOf field?  As it's written
>right now, the list of names is bounded by ub-insteadOf, with
>a value of 16 decimal.  Suppose the union of the two lists
>produces a list with more than 16 elements.  What gets
>truncated?
>
>Scott
>
>-----Original Message-----
>From:	John Pawling [SMTP:[email-masked]]
>Sent:	Friday, February 20, 1998 11:27 AM
>To:	'IETF S/MIME'
>Subject:	Re: ESS-02 MLA Receipt Policies
>
>Scott,
>
>Yes.
>
>================================
>John Pawling   
>[email-masked]                             
>J.G. Van Dyke & Associates, Inc.           
>================================
>
>>Now I need to understand something about the intended union of the
>>policies.  Consider this case:
>>
>>A's policy is insteadOf, and B's policy is inAdditionTo.  The table
>>says the union is insteadOf(A+B).  Does this mean the effective policy
>>is the union of A's insteadOf names and B's inAdditionTo names to yield
>>insteadOf(insteadOf(A) + inAdditionTo(B))?  I know there aren't any other
>>names available, but the table entry makes it look like there should be
>>insteadOf names for B.
>>
>>----->
>>Scott Hollenbeck (mailto:[email-masked])
>>Xerox Special Information Systems
>>Arlington, Virginia, USA

Date: Fri, 20 Feb 1998 13:33:18 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Yet Another S/MIME V3 Msg Spec Comment
Sender: [email-masked]

All,

Recommend the following clarification to S/MIME v3 Message Specification,
Sec 2.3, last para:

Existing: "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."

Proposed: "Sending agents SHOULD support rsaEncryption. If an agent supports
rsaEncryption, then it MUST support encryption of symmetric keys with RSA
public keys at key sizes from 512 bits to 1024 bits."

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

Date: Fri, 20 Feb 1998 12:42:56 -0500
To: <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: ESS-02 MLA Receipt Policies
Sender: [email-masked]

Scott,

You make a very good point.  Recommend that ESS should be changed to delete
the size contraints on the MLReceiptPolicy insteadOf and inAdditionTo fields.

- John Pawling

At 09:31 AM 2/20/98 PST, Scott Hollenbeck wrote:
>John,
>
>OK, now that I understand the union, how should we handle the
>upper bound applied to the insteadOf field?  As it's written
>right now, the list of names is bounded by ub-insteadOf, with
>a value of 16 decimal.  Suppose the union of the two lists
>produces a list with more than 16 elements.  What gets
>truncated?
>
>Scott
>
>-----Original Message-----
>From:	John Pawling [SMTP:[email-masked]]
>Sent:	Friday, February 20, 1998 11:27 AM
>To:	'IETF S/MIME'
>Subject:	Re: ESS-02 MLA Receipt Policies
>
>Scott,
>
>Yes.
>
>================================
>John Pawling   
>[email-masked]                             
>J.G. Van Dyke & Associates, Inc.           
>================================
>
>>Now I need to understand something about the intended union of the
>>policies.  Consider this case:
>>
>>A's policy is insteadOf, and B's policy is inAdditionTo.  The table
>>says the union is insteadOf(A+B).  Does this mean the effective policy
>>is the union of A's insteadOf names and B's inAdditionTo names to yield
>>insteadOf(insteadOf(A) + inAdditionTo(B))?  I know there aren't any other
>>names available, but the table entry makes it look like there should be
>>insteadOf names for B.
>>
>>----->
>>Scott Hollenbeck (mailto:[email-masked])
>>Xerox Special Information Systems
>>Arlington, Virginia, USA
>>
>>
>
>
>

From: Scott Hollenbeck <[email-masked]>
To: "'John Pawling'" <[email-masked]>, "'IETF S/MIME'" <[email-masked]>
Subject: RE: ESS-02 MLA Receipt Policies
Date: Fri, 20 Feb 1998 09:31:27 PST
Sender: [email-masked]

John,

OK, now that I understand the union, how should we handle the
upper bound applied to the insteadOf field?  As it's written
right now, the list of names is bounded by ub-insteadOf, with
a value of 16 decimal.  Suppose the union of the two lists
produces a list with more than 16 elements.  What gets
truncated?

Scott

-----Original Message-----
From:	John Pawling [SMTP:[email-masked]]
Sent:	Friday, February 20, 1998 11:27 AM
To:	'IETF S/MIME'
Subject:	Re: ESS-02 MLA Receipt Policies

Scott,

Yes.

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

>Now I need to understand something about the intended union of the
>policies.  Consider this case:
>
>A's policy is insteadOf, and B's policy is inAdditionTo.  The table
>says the union is insteadOf(A+B).  Does this mean the effective policy
>is the union of A's insteadOf names and B's inAdditionTo names to yield
>insteadOf(insteadOf(A) + inAdditionTo(B))?  I know there aren't any other
>names available, but the table entry makes it look like there should be
>insteadOf names for B.
>
>----->
>Scott Hollenbeck (mailto:[email-masked])
>Xerox Special Information Systems
>Arlington, Virginia, USA
>
>

Date: Fri, 20 Feb 1998 11:50:53 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Another S/MIME V3 Msg Spec Comment
Sender: [email-masked]

All,

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.
The aforementioned change was correctly made in the CMS document (i.e. the
text was deleted), but the text must still be added to the S/MIME V3 Msg Spec.

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

Date: Fri, 20 Feb 1998 11:38:02 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Many changes to the ASN.1 OIDs page
Sender: [email-masked]

Paul,

Two comments regarding the "OIDs Used with S/MIME" document:

1) Please change id-dsa-with-sha1 to: 

id-dsa-with-sha1 OBJECT IDENTIFIER ::=
   {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 3}
--        (The parameters field must be absent. Implementations should
--        also accept identifiers in which the parameters field is 
--        present and contains a NULL ASN.1 type.)

Note: Absent is the default according to the changes that are supposed to be
made to X9.57 by Rich Ankney.

2) Please add:

id-dsa OBJECT IDENTIFIER ::=
   {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1}
--       (When used in CMS signedData signerInfo signatureAlgorithm,
--        the parameters field must be absent. Implementations should
--        also accept identifiers in which the parameters field is 
--        present and contains a NULL ASN.1 type.)

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

Date: Fri, 20 Feb 1998 11:26:35 -0500
To: "'IETF S/MIME'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: ESS-02 MLA Receipt Policies
Sender: [email-masked]

Scott,

Yes.

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

>Now I need to understand something about the intended union of the
>policies.  Consider this case:
>
>A's policy is insteadOf, and B's policy is inAdditionTo.  The table
>says the union is insteadOf(A+B).  Does this mean the effective policy
>is the union of A's insteadOf names and B's inAdditionTo names to yield
>insteadOf(insteadOf(A) + inAdditionTo(B))?  I know there aren't any other
>names available, but the table entry makes it look like there should be
>insteadOf names for B.
>
>----->
>Scott Hollenbeck (mailto:[email-masked])
>Xerox Special Information Systems
>Arlington, Virginia, USA
>
>

From: Scott Hollenbeck <[email-masked]>
To: "'IETF S/MIME'" <[email-masked]>
Subject: ESS-02 MLA Receipt Policies
Date: Fri, 20 Feb 1998 07:55:11 PST
Sender: [email-masked]

First, two minor typos in the table in section 4.3:

The entry for "A's policy is missing" and "B's policy is inAdditionTo"
is misspelled.  "inAddtionTo(B)" should be "inAdditionTo(B)".

The entry for "B's policy is missing" and "A's policy is inAdditionTo"
is misspelled.  "inAditionTo" should be "inAdditionTo".

Now I need to understand something about the intended union of the
policies.  Consider this case:

A's policy is insteadOf, and B's policy is inAdditionTo.  The table
says the union is insteadOf(A+B).  Does this mean the effective policy
is the union of A's insteadOf names and B's inAdditionTo names to yield
insteadOf(insteadOf(A) + inAdditionTo(B))?  I know there aren't any other
names available, but the table entry makes it look like there should be
insteadOf names for B.

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

Date: Fri, 20 Feb 1998 10:17:06 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: How to do UTF-8
Sender: [email-masked]

All,

I agree with Dave Kemp's proposed ContentHints change.

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

Date: Fri, 20 Feb 1998 09:35:14 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: How to do UTF-8
Sender: [email-masked]

Paul,

I agree with John Pawling's rationale on language tagging.  There
appears to be little risk that the IETF will not come up with a
solution for imbedded language tags in UTF8 strings, therefore any
S/MIME-specific backup scheme just adds unnecessary complexity.  The
benefit of using ESSFreeText, if any, would be short term, while the
complexity would linger on forever.

And while we're UTF8'ing, we should also replace the DirectoryString in
the ContentHints attribute:

ContentHints ::= SEQUENCE {
  contentDescription UTF8String SIZE(1..MAX) OPTIONAL,
  contentType OBJECT IDENTIFIER }

Dave Kemp

Date: Fri, 20 Feb 1998 08:35:49 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: How to do UTF-8
Sender: [email-masked]

All,

I agree with almost everything in Paul's proposal.  Our (VDA) v3 X.509
Certificate implementation uses a 1984-based ASN.1 Toolkit.  We successfully
used the strategy proposed by Paul to implement UniversalString.  We defined
UniversalString as [UNIVERSAL 28] IMPLICIT OCTET STRING.  We have proven
that our implementation of UniversalString is interoperable with several
other implementations, one of which was using the "modern" OSS ASN.1
ToolKit.  This is the same strategy that Paul is proposing for UTF8String.

The part of Paul's proposal that I question is the inclusion of languageTag
in ESSFreeText. I would like to avoid forcing the receiving software to
check for two sources of languageTags.  It would be much cleaner if we could
always use embedded language tags in the UTF8String.  I understand Paul's
concern that the concept of embedding language tags in UTF-8 strings is
immature.  However, if we believe that the concept will be nailed down in
the next few weeks, then I believe that it is worth the risk to simply use
UTF8String.  If embedded language tags is a risky concept that may get
thrown out altogether, then I believe that we should stick with Paul's
proposal. 

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

Date: Thu, 19 Feb 1998 17:45:27 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: How to do UTF-8
Sender: [email-masked]

Here's a summary of the discussion so far, with my tentative conclusions:

** Need for UTF-8 in the privacy mark **

The privacy mark is free text that may be shown to a human, and the human
may need to make a decision based on the text shown. Thus, the text must be
in a charset that is understanable by the human. The previous specification
had this as a PrintableString because that's what's in X.411.

** Using UTF-8 **

The IETF has decided to go with UTF-8, where possible, as its charset of
choice in things that will get shown to human users. See
<http://www.imc.org/rfc2277> for more information on this. See
<http://www.imc.org/rfc2279> for a description of how to do UTF-8.

** How to specifiy UTF-8 in 1988 ASN.1 **

Things got a bit hairier here. Three proposals had general approval:

(1) Use an OCTET STRING that has a comment saying that it has to be filled
with a UTF-8 string
(2) Use "[0] IMPLICIT UTF8String", and people whose compilers don't know
what a UTF8String is can change this to "[0] IMPLICIT OCTET STRING" and
still have the same bits on the wire
(3) Define UTF8String at the beginning of the module as "UTF8String ::=
[UNIVERSAL 12] IMPLICIT OCTET STRING" and then just use UTF8String in the
code (with no IMPLICIT)

I have chosen to go with (3) because it is the cleanest, and the ASN.1
compilers already must be able to do something like this because they have
to be able to do it for BMPString. Although this violates the ASN.1
standard, it is quite easy to implement.

The reason I want to get away from (1), which I put in the current version,
is that people tend not to read comments, and might stuff the OCTET STREAM
with, well, octets, and not UTF8 characters. There is nothing in that
construct that would help a good compiler do UTF-8 checking.

In choosing between (2) and (3), I figured that only a few compilers even
know how to do UTF8String today (it's in the 1997 spec, not even the 1994
spec), and those that do can simply comment out the definition line (which
purists would happily want to do anyways). Further, the changes needed for
the few people who do have 1997 compilers are far easier than the changes
needed for the rest of us using method (2). And, again, once we made the
change in (2), someone later reading the code would not know that this had
to be a UTF-8 string.

** Length limiting **

People like to have lengths specified for strings so they can tell how much
memory to allocate for buffers. However, accurately figuring out the memory
use for a UTF-8 string of some number of characters is impossible since the
number of bytes per character changes. The current privacy mark string is
limited to 128 characters, but it easy to imagine privacy marks that could
legitimately be longer than this. Thus, I'm choosing not to put a size
limit on the UTF8String.

** Language tagging **

Ned Freed pointed out that current direction we're supposed to be pursuing
is language tags embedded in UTF-8. However, the draft for that
functionality has just been proposed this week in the IETF, and is unlikely
to be finalized before S/MIME. I believe strongly in language tagging, and
want to get people in the habit of doing it from the start. Thus, I'm going
to use an optional laguage tag with a comment that says if you have
embedded the language tag in the UTF8String, do not include the language
tag. This lets us have language tags now, and lets people move to embedded
language tags when that spec is final.

** And what I propose is **

-- At the beginning of the module
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING

-- Then
ESSPrivacyMark ::= CHOICE {
    pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
    freeText     ESSFreeText
}

ESSFreeText ::= SEQUENCE {
    languageTag  PrintableString OPTIONAL,
    text         UTF8String
    --languageTag is an language tag defined in [RFC1766]; it SHOULD NOT
    --   be used if the text string has an implicit UTF-8 language tag
}

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 19 Feb 1998 18:17:27 -0500
To: Russ Housley <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: ESS MLA Attributes Comment
Cc: [email-masked]
Sender: [email-masked]

Russ,

I agree that the MLA MUST NEVER change the original signer's securityLabel
authenticated attribute contained in the innermost signedData.  Because
CMS/ESS binds the securityLabel authenticatedAttribute with the signature of
the data, intermediate entities can't change the securityLabel without
breaking the original signer's signature.  That is an excellent feature of
CMS/ESS.

However, I respectfully disagree with your proposal that the MLA must be
restricted from defining the securityLabel values in the outermost
signedData envelope that it creates and signs.  When an MLA-expanded message
is received by the ultimate recipient, the receiving software will process
the securityLabel defined by the MLA when it validates the MLA-generated
outermost signedData layer and will separately process the securityLabel
defined by the original signer when it validates the innermost signedData
layer.  IMHO, the policy defining how an MLA derives the values for the
securityLabel included in the outermost signedData that it signs should be a
matter of local customer policy, not mandated by the ESS spec.  Your
proposal would unnecessarily (IMHO) limit the flexibility of the CMS/ESS
spec, so I oppose it.  
 
================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
===============================

At 03:44 PM 2/19/98 -0500, Russ Housley wrote:
>John:
>
>I disagree with your handling of security label.  MLAs should not modify an
>existing security label attribute.  This action would encourage label
>translation.
>
>I suggest that we permit the addition of a security label if it is absent,
>but otherwise the MLA should preserve the outter security label.
>
>Russ
>

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: Comment on ESS and Privacy Marks
Date: Thu, 19 Feb 1998 13:00:03 -0800
Sender: [email-masked]

I also agree with the change to IMPLICIT.   This was a classic case of
my not fully understanding ASN.  I thank Bancroft for the discussion on
implicit vs excplicit as I now have a much clearer understanding of
these issues.

jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, February 19, 1998 5:32 AM
> To: [email-masked]
> Subject: RE: Comment on ESS and Privacy Marks
> 
> 
> All,
> 
> I agree with Bancroft Scott that ESSPrivacyMark should be 
> re-defined as follows:
> 
> > ESSPrivacyMark ::= CHOICE {
> >    pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
> >    utf8String   [0] IMPLICIT UTF8String (SIZE 
> (1..ub-privacy-mark-length))
> > }
> 
> 
> Note Bancroft's point as follows:
> 
> >Another
> >benefit is that if someone is using a tool that does not support
> >UTF8String they can simply change it to "[0] OCTET STRING" 
> and get the
> >same encoding. 
> 
> ================================
> John Pawling   
> [email-masked]                             
> J.G. Van Dyke & Associates, Inc.           
> ================================
> 
> 
> 

Date: Thu, 19 Feb 1998 15:44:54 -0500
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: Re: ESS MLA Attributes Comment
Cc: [email-masked]
Sender: [email-masked]

John:

I disagree with your handling of security label.  MLAs should not modify an
existing security label attribute.  This action would encourage label
translation.

I suggest that we permit the addition of a security label if it is absent,
but otherwise the MLA should preserve the outter security label.

Russ

At 08:53 AM 2/18/98 -0500, John Pawling wrote:
>All,
>
>The 16 Feb 98 ESS, sec 4.2, intro, 3rd para, states:
>"When the MLA creates the new attribute list for its signature, the MLA
>MUST propagate forward each attribute in the old signature, unless the MLA
>explicitly replaces the attribute with a new value. An MLA will frequently
>encounter attributes, or parts of attributes, which it does not
>understand. Attributes such as security labels cannot be removed from
>the new signature being created without compromising the security of the
>system. Because it is impossible to enumerate the future list of attributes
>which have security implicitions, an MLA MUST propagate forward all
>attributes which it does not explicity replace."
>
>
>I agree with the intent of the aforementioned paragraph that the MLA MUST
>propagate forward each authenticated attribute present in the old outermost
>signature, unless the MLA explicitly replaces the attribute with a new
>value.  However, I disagree with some of the other statements in the text
>and I believe that the text needs to be more precise.  Propose that the
>aforementioned text should be deleted and that the following changes should
>replace it:
>
>1) sec 4.2.2, bullet 3.2.1 should be changed as follows:
>
> OLD: 3.2.1. The MLA strips the existing outermost SignedData layer after
> 	     remembering the value of the mlExpansionHistory attribute in that
>             layer, if one was there.
>
> NEW: 3.2.1. The MLA strips the existing outermost SignedData layer after
>  	     remembering the value of the mlExpansionHistory and all other
>             authenticated attributes in that layer, if present.
>
>
>2) sec 4.2.2, bullet 3.2.3, first para, should be changed as follows:
>
> OLD: 3.2.3. The MLA adds an mlExpansionHistory attribute. The SignedData
>	     layer created by the MLA replaces the original outermost SignedData
>	     layer.
>
> NEW: 3.2.3. The outermost signedData layer created by the MLA replaces the
>original 
>             outermost signedData layer.  The MLA MUST create an
authenticated
>             attribute list for the new outermost signedData layer which
>MUST include  
>             each authenticated attribute present in the original outermost
>signedData
>             layer, unless the MLA explicitly replaces the attribute with a
>new value.
>             For example, the MLA MUST include the securityLabel attribute
>present in the
>             original outermost signedData layer unless it replaces that
>attribute with
>             a new securityLabel attribute that it creates.  A special case
>is the 
>             mlExpansionHistory attribute.  The MLA MUST add an
>mlExpansionHistory 
>             authenticated attribute to the outer signedData layer as
>follows: ....
>
>Note: The proposed 3.2.3 change specifies that the MLA can replace the
>securityLabel in the outermost signedData layer, not the innermost
>signedData layer.  The MLA can never change any of the authenticated
>attributes in the innermost signedData layer (including the securityLabel)
>because that would break the original signer's signature of the innermost

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

Date: Thu, 19 Feb 1998 08:32:14 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: RE: Comment on ESS and Privacy Marks
Sender: [email-masked]

All,

I agree with Bancroft Scott that ESSPrivacyMark should be re-defined as follows:

> ESSPrivacyMark ::= CHOICE {
>    pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
>    utf8String   [0] IMPLICIT UTF8String (SIZE (1..ub-privacy-mark-length))
> }

Note Bancroft's point as follows:

>Another
>benefit is that if someone is using a tool that does not support
>UTF8String they can simply change it to "[0] OCTET STRING" and get the
>same encoding. 

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

Date: Thu, 19 Feb 1998 00:25:19 -0500 (EST)
From: Bancroft Scott <[email-masked]>
Reply-To: Bancroft Scott <[email-masked]>
To: "Jim Schaad (Exchange)" <[email-masked]>
Cc: "'Paul Hoffman / IMC'" <[email-masked]>, [email-masked]
Subject: RE: Comment on ESS and Privacy Marks
Sender: [email-masked]

On Wed, 18 Feb 1998, Jim Schaad (Exchange) wrote:

> At this point I am feeling really over my head on the question of UTF-8
> vs OCTECT string, I don't have enough knowledge to put in useful input
> on that issue.  My general impression however is that I would perfer to
> have the type explicit in this case rather than implicit.
> 
> Independent of that issue however, I think we should consider doing
> either an implicit [0] or explicit [0] tag on the utf8String field.
> Thus we would use
> 
> ESEPrivacyMark ::= CHOICE {
>  pString	PrintableString (SIZE (1..ub-privacy-mark-length)),
>  utf8String EXPLICIT [0] OCTET STRING
> }

I can not think of a single case where an explicit tag is useful on
type OCTET STRING, for the contents is always opaque and is never
affected by tagging, whether IMPLICIT or EXPLICIT.  Given this, the
only purpose that explicit tagging on this type serves is to increase
code size, message size and transmission time.

If we are hell-bent on using OCTET STRING to carry UTF8String
characters then I strongly recommend that you use an implicitly
tagged OCTET STRING.  That is:

 ESEPrivacyMark ::= CHOICE {
    pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
    utf8String   [0] IMPLICIT OCTET STRING -- MUST contain UTF-8-encoded characters
 }

The benefits of doing this are:

a) People who use tools that *do not* support UTF8String can accomplish
the same thing as they can if the type is tagged EXPLICIT, except that
there is no double tagging.  For those not familiar with the details, "[0]
EXPLICIT OCTET STRING" results in a double-tagged encoding of: 

	[0] length1 [UNIVERSAL 4] length2 UTF8String-value

whereas "[0] IMPLICIT OCTET STRING" results in an encoding of:

	[0] length UTF8String-value

b) People who use tools that *do* support UTF8String can leave the
definition as [0] IMPLICIT OCTET STRING if they wish, or they can change
the definition to "[0] IMPLICIT UTF8String" and end up with exactly the
same encoding as with no change.  The benefit to doing is that they can
then rely on the tool they are using to automatically check the validity
of the UTF8String value (especially during development) if they wish. 

c) Implicit tagging of OCTET STRING is most efficient all around and
does not impact anyone adversely.

d) If in a future version of S/MIME you choose to use valid ASN.1 
consisting solely of the current ASN.1 version, you will be able
to change the "[0] IMPLICIT OCTET STRING" to "[0] IMPLICIT UTF8String"
without affecting the bits on the wire (i.e., the resulting encoding),
whereas "[0] EXPLICIT OCTET STRING" cannot be changed to use UTF8String
under any circumstance without introducing interoperability problems.

e) "[0] IMPLICIT OCTET STRING is absolutely no pain to folks who wish to
use X.208-specific toolkits, for it is simply an implicitly tagged octet
string that they all support.

My personal preference is to define:

 ESEPrivacyMark ::= CHOICE {
    pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
    utf8String   [0] IMPLICIT UTF8String (SIZE (1..ub-privacy-mark-length))
 }

One benefit is that you are able to clearly express the type and properly
constrain it in size (something you can't do with OCTET STRING that
carries a UTF8String value, other than by a comment - see below.)  Another
benefit is that if someone is using a tool that does not support
UTF8String they can simply change it to "[0] OCTET STRING" and get the
same encoding.  The down side to this is that it is invalid ASN.1 since
the S/MIME module mixes use of UTF8String with ANY, but this violation
is already occuring since BMPString is being used, so matters are not
being made any worse.

> It would also be instructive to look at the issue of the size of the
> utf8String field.  It was limited to a specific length for the
> PrintableString version.  Should the utf8String version also be of
> limited length?

Yes, a length would be ideal, for it tells implementors the max number of
characters they need to support.  Note though that with OCTET STRING
there is no practical way to indicate the maximum number of characters
that is to be supported, only the maximum number of bytes used to encode
the character string value, for a size constraint on OCTET STRING 
is a byte count, while a size constraint on UTF8String is a count of
the number of characters.  

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

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, [email-masked]
Subject: RE: Comment on ESS and Privacy Marks
Date: Wed, 18 Feb 1998 17:07:19 -0800
Sender: [email-masked]

At this point I am feeling really over my head on the question of UTF-8
vs OCTECT string, I don't have enough knowledge to put in useful input
on that issue.  My general impression however is that I would perfer to
have the type explicit in this case rather than implicit.

Independent of that issue however, I think we should consider doing
either an implicit [0] or explicit [0] tag on the utf8String field.
Thus we would use

ESEPrivacyMark ::=3D CHOICE {
 pString	PrintableString (SIZE (1..ub-privacy-mark-length)),
 utf8String EXPLICIT [0] OCTET STRING
}

It would also be instructive to look at the issue of the size of the
utf8String field.  It was limited to a specific length for the
PrintableString version.  Should the utf8String version also be of
limited length?

jim

-----Original Message-----
From: Paul Hoffman / IMC [mailto:[email-masked]]
Sent: Wednesday, February 18, 1998 11:06 AM
To: [email-masked]
Subject: RE: Comment on ESS and Privacy Marks

>...
>=A0 PKIFreeText ::=3D SEQUENCE {=20
>=A0=A0=A0=A0=A0 languageTag=A0 PrintableString OPTIONAL, --RFC 1766 =
language tag
>=A0=A0=A0=A0=A0 text=A0=A0=A0=A0=A0=A0=A0=A0 OCTET =
STRING=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 --carries a UTF-8 string
>=A0 } -- the languageTag field may be used to indicate the language=20
>=A0=A0=A0 -- of the text contained in the "text" field
>...
>Therefore, I recommend that we leave ESS as is:
>
>ESSPrivacyMark ::=3D CHOICE {
>=A0 pString=A0=A0=A0=A0=A0 PrintableString (SIZE =
(1..ub-privacy-mark-length)),
>=A0 utf8String=A0=A0 OCTET STRING
>=A0 -- If utf8String is used, the contents must be in UTF-8 [UTF8]
>}

Not to stir things up too far, but this begs the question: wouldn't the
following be better?

ESSPrivacyMark ::=3D CHOICE {
=A0 pString=A0=A0=A0=A0=A0 PrintableString (SIZE =
(1..ub-privacy-mark-length)),
=A0 betterString=A0=A0 PKIFreeText
}

I *like* having a language tag associated with a UTF-8, and this gives
implementors the same option as before but allows them to include a
language
tag.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Wed, 18 Feb 1998 15:24:17 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: RE: Comment on ESS and Privacy Marks
To: Paul Hoffman / IMC <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> I *like* having a language tag associated with a UTF-8, and this gives
> implementors the same option as before but allows them to include a language
> tag.

The current direction we're supposed to be pursuing is language tags embedded
in UTF-8. The facilities for this have received approval by the Unicode
Technical committee and now await approval by the ISO 10646 folks. And there is
now an Internet draft by Glenn Adams explaining how this works.

Given the current state of affairs there should be no need for a language
tag associated with UTF-8-only strings. Strings which allow for different
charsets are another matter, of course.

				Ned

From: "Blake Ramsdell" <[email-masked]>
To: "'Rik Drummond'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Certificate exchange (was: RE: Comment on ESS and Privacy Marks )
Date: Wed, 18 Feb 1998 14:28:50 -0800
Sender: [email-masked]

On Wednesday, February 18, 1998 1:18 PM, Rik Drummond
[SMTP:[email-masked]] wrote:
> The EDIINT "Secure EDI over Internet WG" is testing our
recommendations 
> with 8 vendors. We are exchanging cert. in s/mime pkcs7 format. What
are 
> your recommendations in the use of pkcs12 format for cert. exchange?

For simply exchanging certificates, PKCS #12 is a big hammer.
Certs-only PKCS #7 messages are pretty easy to generate and parse,
though they don't offer any integrity or privacy services.  I guess it
depends on the need:  If you have a mechanism for chain validation on
the recipient side, and can qualify the a received certificate as
usable, then certs-only should work fine.

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: Rik Drummond <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Comment on ESS and Privacy Marks
Date: Wed, 18 Feb 1998 15:18:12 -0600
Sender: [email-masked]

The EDIINT "Secure EDI over Internet WG" is testing our recommendations 
with 8 vendors. We are exchanging cert. in s/mime pkcs7 format. What are 
your recommendations in the use of pkcs12 format for cert. exchange?

Regards, Rik

Chair IETF's EDIINT WG

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, <[email-masked]>
Subject: RE: Comment on ESS and Privacy Marks
Date: Wed, 18 Feb 1998 13:02:08 -0800
Sender: [email-masked]

On Wednesday, February 18, 1998 6:13 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> There are no occurrences of "UTF" in the PKIX X.509 Certrificate and
CRL
> Profile (aka PKIX Part 1).
> 
> Therefore, I recommend that we leave ESS as is:
> 
> ESSPrivacyMark ::= CHOICE {
>   pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
>   utf8String   OCTET STRING
>   -- If utf8String is used, the contents must be in UTF-8 [UTF8]
> }

John, I respectfully disagree.

1. UTF-8 has a universal tag number, and a defined syntax in the 1997
ASN.1 draft which is in the rubber stamp part of the standards process
(that is, the UTF-8 part of the standard will most likely not change at
all).

2. If we use the OCTET STRING hack, we will drag it along forever.
Every future implementation will have to understand that this OCTET
STRING really contains UTF-8 text.  We are at a point where we can avoid
this.

Personally, I believe that PKIX should switch to the UTF-8 universal tag
instead of OCTET STRING.  There is no reason to use an octet hole (as
multiple people refer to it) when a suitable type can be used.
Maintaining parity with PKIX in this case does not seem to be useful.  I
will bring this up on the PKIX mailing list, and see if there are any
comments.

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, 18 Feb 1998 11:06:10 -0800
To: <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Comment on ESS and Privacy Marks
Sender: [email-masked]

>...
>  PKIFreeText ::= SEQUENCE { 
>      languageTag  PrintableString OPTIONAL, --RFC 1766 language tag
>      text         OCTET STRING              --carries a UTF-8 string
>  } -- the languageTag field may be used to indicate the language 
>    -- of the text contained in the "text" field
>...
>Therefore, I recommend that we leave ESS as is:
>
>ESSPrivacyMark ::= CHOICE {
>  pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
>  utf8String   OCTET STRING
>  -- If utf8String is used, the contents must be in UTF-8 [UTF8]
>}

Not to stir things up too far, but this begs the question: wouldn't the
following be better?

ESSPrivacyMark ::= CHOICE {
  pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
  betterString   PKIFreeText
}

I *like* having a language tag associated with a UTF-8, and this gives
implementors the same option as before but allows them to include a language
tag.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Wed, 18 Feb 1998 09:12:48 -0500
To: <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Comment on ESS and Privacy Marks
Sender: [email-masked]

All,

Paul asked what is PKIX doing for UTF-8.

Carlisle Adams is including the following text in the PKIX Certificate
Management Protocol I-D (aka PKIX Part 3) in which an OCTET STRING is used
to carry a UTF-8 string:
=20
  PKIFreeText ::=3D SEQUENCE {=20
      languageTag  PrintableString OPTIONAL, --RFC 1766 language tag
      text         OCTET STRING              --carries a UTF-8 string
  } -- the languageTag field may be used to indicate the language=20
    -- of the text contained in the "text" field

There are no occurrences of "UTF" in the PKIX X.509 Certrificate and CRL
Profile (aka PKIX Part 1).

Therefore, I recommend that we leave ESS as is:

ESSPrivacyMark ::=3D CHOICE {
  pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
  utf8String   OCTET STRING
  -- If utf8String is used, the contents must be in UTF-8 [UTF8]
}

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

At 04:02 PM 2/16/98 -0800, Paul Hoffman / IMC wrote:
>>If this is the case, and UTF8String has UNIVERSAL 12 as its tag, I
>>recommend that we use that tag instead of OCTET STRING to package our
>>UTF8 strings.=A0 I don't know what PKIX is doing regarding this, but I
>>suspect that they should do the same thing.
>
>Well, I just turned in the next ESS draft, and I coded it as OCTET STRING.=
 I'm
>happy to change it in the one after this, as long as we're doing exactly=
 what
>the PKIX people are. Carlisle, what are you going to do in PKIX part 3?=
 Russ,
>how about PKIX part 1?
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
>

Date: Wed, 18 Feb 1998 08:53:08 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: ESS MLA Attributes Comment
Sender: [email-masked]

All,

The 16 Feb 98 ESS, sec 4.2, intro, 3rd para, states:
"When the MLA creates the new attribute list for its signature, the MLA
MUST propagate forward each attribute in the old signature, unless the MLA
explicitly replaces the attribute with a new value. An MLA will frequently
encounter attributes, or parts of attributes, which it does not
understand. Attributes such as security labels cannot be removed from
the new signature being created without compromising the security of the
system. Because it is impossible to enumerate the future list of attributes
which have security implicitions, an MLA MUST propagate forward all
attributes which it does not explicity replace."

I agree with the intent of the aforementioned paragraph that the MLA MUST
propagate forward each authenticated attribute present in the old outermost
signature, unless the MLA explicitly replaces the attribute with a new
value.  However, I disagree with some of the other statements in the text
and I believe that the text needs to be more precise.  Propose that the
aforementioned text should be deleted and that the following changes should
replace it:

1) sec 4.2.2, bullet 3.2.1 should be changed as follows:

 OLD: 3.2.1. The MLA strips the existing outermost SignedData layer after
 	     remembering the value of the mlExpansionHistory attribute in that
             layer, if one was there.

 NEW: 3.2.1. The MLA strips the existing outermost SignedData layer after
  	     remembering the value of the mlExpansionHistory and all other
             authenticated attributes in that layer, if present.

2) sec 4.2.2, bullet 3.2.3, first para, should be changed as follows:

 OLD: 3.2.3. The MLA adds an mlExpansionHistory attribute. The SignedData
	     layer created by the MLA replaces the original outermost SignedData
	     layer.

 NEW: 3.2.3. The outermost signedData layer created by the MLA replaces the
original 
             outermost signedData layer.  The MLA MUST create an authenticated
             attribute list for the new outermost signedData layer which
MUST include  
             each authenticated attribute present in the original outermost
signedData
             layer, unless the MLA explicitly replaces the attribute with a
new value.
             For example, the MLA MUST include the securityLabel attribute
present in the
             original outermost signedData layer unless it replaces that
attribute with
             a new securityLabel attribute that it creates.  A special case
is the 
             mlExpansionHistory attribute.  The MLA MUST add an
mlExpansionHistory 
             authenticated attribute to the outer signedData layer as
follows: ....

Note: The proposed 3.2.3 change specifies that the MLA can replace the
securityLabel in the outermost signedData layer, not the innermost
signedData layer.  The MLA can never change any of the authenticated
attributes in the innermost signedData layer (including the securityLabel)
because that would break the original signer's signature of the innermost
signedData layer.

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

Date: Tue, 17 Feb 1998 15:51:37 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Many changes to the ASN.1 OIDs page
Sender: [email-masked]

I would be much obliged if everyone would look at the S/MIME OIDs page at
<<http://www.imc.org/ietf-smime/oids.html>http://www.imc.org/ietf-smime/oid
s.html> and the ASN.1 module associated with it. Turns out that many of you
weren't reading carefully, and there were a bunch of errors in the algorithm
specifiers. I believe that I've fixed them all, but I believed that before,
too. :-)

Fine tooth combs are welcome here, as they are in reading the newly-revised
specs available at
<<http://www.imc.org/draft-ietf-smime-cms>http://www.imc.org/<http://www.im
c.org/draft-ietf-smime-cms>draft-ietf-smime-cms> and
<<http://www.imc.org/draft-ietf-smime-ess>http://www.imc.org/<http://www.im
c.org/draft-ietf-smime-ess>draft-ietf-smime-ess>. We don't want this
process to
drag out forever, so nitpick early and often.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 17 Feb 1998 17:49:30 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: John Pawling <[email-masked]>
CC: S-MIME List <[email-masked]>
Subject: Re: UTF8 Concerns
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The PKIX X.509 Certificate and CRL Profile defines DirectoryString exactly
> as stated in the latest ESS.  I believe that the S/MIME specs should be
> consistent with the PKIX specs, so I oppose any proposal that causes ESS to
> be out of sync with PKIX.  Recommend that you submit your proposal to the
> PKIX mail list.

John,

You read me wrong. I'm perfectly comfortable with DirectoryString
as currently defined, though I still argue that there is room for
improvement in the definition. As for "octet hole" solutions, I
tend, as you probably know, to ridicule them every chance I get.

My suggestion was made only in the context of possibly avoiding
a potential obstacle in making it through the standards process, 
and relative to the discussion of the definition of ESSPrivacyMark.
If the definition for this type has already passed muster, then
there's no problem. 

I very much agree with you that SMIME and PKIX need to be in sync.

Phil

> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 
> At 09:31 AM 2/17/98 -0500, [email-masked] wrote:
> >Hi there,
> >
> >The latest ESS document just posted to the list,
> >draft-ietf-smime-ess-02.txt, contains the following
> >ASN.1 type definition:
> >
> > DirectoryString ::= CHOICE {
> >   teletexString TeletexString (SIZE (1..MAX)),
> >   printableString PrintableString (SIZE (1..MAX)),
> >   bmpString  BMPString (SIZE (1..MAX)),
> >   universalString UniversalString (SIZE (1..MAX)) }
> >
> >The SMIME editors may wish to consider changing this
> >type to something like
> >
> > DirectoryString ::= CHOICE {
> >    utf8String  OCTET STRING }
> >
> >or to at least add UTF8 as a choice alternative. This
> >type seems likely to suffer the same criticism as
> >the ESSPrivacyMark type. Not sure how type GeneralNames
> >might be perceived, since it is IMPORTED for use in
> >the ESS module.
> >
> >Phil
> >--
> >Phillip H. Griffin         Griffin Consulting
> >[email-masked]        ASN.1-SET-Java-Security
> >919.828.7114               1625 Glenwood Avenue
> >919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
> >------------------------------------------------------------
> >          Visit  http://www.fivepointsfestival.com
> >                 http://www.five-points.com
> >------------------------------------------------------------
> >
> >

Date: Tue, 17 Feb 1998 16:53:54 -0500
To: S-MIME List <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: UTF8 Concerns
Sender: [email-masked]

Phil,

The PKIX X.509 Certificate and CRL Profile defines DirectoryString exactly
as stated in the latest ESS.  I believe that the S/MIME specs should be
consistent with the PKIX specs, so I oppose any proposal that causes ESS to
be out of sync with PKIX.  Recommend that you submit your proposal to the
PKIX mail list.

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

At 09:31 AM 2/17/98 -0500, [email-masked] wrote:
>Hi there,
>
>The latest ESS document just posted to the list,
>draft-ietf-smime-ess-02.txt, contains the following
>ASN.1 type definition:
>
> DirectoryString ::= CHOICE {
>   teletexString TeletexString (SIZE (1..MAX)),
>   printableString PrintableString (SIZE (1..MAX)),
>   bmpString  BMPString (SIZE (1..MAX)),
>   universalString UniversalString (SIZE (1..MAX)) }
>
>The SMIME editors may wish to consider changing this
>type to something like 
>
> DirectoryString ::= CHOICE {
>    utf8String  OCTET STRING }
>
>or to at least add UTF8 as a choice alternative. This
>type seems likely to suffer the same criticism as
>the ESSPrivacyMark type. Not sure how type GeneralNames
>might be perceived, since it is IMPORTED for use in
>the ESS module.
>
>Phil
>-- 
>Phillip H. Griffin         Griffin Consulting
>[email-masked]        ASN.1-SET-Java-Security
>919.828.7114               1625 Glenwood Avenue
>919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
>------------------------------------------------------------
>          Visit  http://www.fivepointsfestival.com
>                 http://www.five-points.com
>------------------------------------------------------------
>
>

From: Bruce Greenblatt <[email-masked]>
To: Paul Hoffman / IMC <[email-masked]>, [email-masked]
Subject: RE: Comment on ESS and Privacy Marks
Date: Tue, 17 Feb 1998 10:11:37 -0800
Sender: [email-masked]

I'd note the following passage from the LDAP v3 spec (RFC 2251)...

The LDAPString is a notational convenience to indicate that, although
   strings of LDAPString type encode as OCTET STRING types, the ISO
   10646 [13] character set (a superset of Unicode) is used, encoded
   following the UTF-8 algorithm [14]. Note that in the UTF-8 algorithm
   characters which are the same as ASCII (0x0000 through 0x007F) are
   represented as that same ASCII character in a single byte.  The other
   byte values are used to form a variable-length encoding of an
   arbitrary character.

        LDAPString ::= OCTET STRING

The definition in the ess-02 document is aligned with this, and appears
appropriate.

Bruce

Date: Tue, 17 Feb 1998 09:31:55 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: S-MIME List <[email-masked]>
Subject: UTF8 Concerns
Sender: [email-masked]

Hi there,

The latest ESS document just posted to the list,
draft-ietf-smime-ess-02.txt, contains the following
ASN.1 type definition:

 DirectoryString ::= CHOICE {
   teletexString TeletexString (SIZE (1..MAX)),
   printableString PrintableString (SIZE (1..MAX)),
   bmpString  BMPString (SIZE (1..MAX)),
   universalString UniversalString (SIZE (1..MAX)) }

The SMIME editors may wish to consider changing this
type to something like 

 DirectoryString ::= CHOICE {
    utf8String  OCTET STRING }

or to at least add UTF8 as a choice alternative. This
type seems likely to suffer the same criticism as
the ESSPrivacyMark type. Not sure how type GeneralNames
might be perceived, since it is IMPORTED for use in
the ESS module.

Phil
-- 
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
                 http://www.five-points.com
------------------------------------------------------------

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-ess-02.txt
Date: Tue, 17 Feb 1998 07:43:47 -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-02.txt
	Pages		: 35
	Date		: 16-Feb-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-02.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-ess-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-ess-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-ess-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-ess-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cms-03.txt
Date: Tue, 17 Feb 1998 07:43:40 -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-03.txt
	Pages		: 32
	Date		: 16-Feb-98
	
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.

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-03.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-cms-03.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-cms-03.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-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-cms-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

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

At 10:10 PM 2/16/98 -0500, Phillip H. Griffin wrote:
>The following definition:
>
>  BMP ::= UTF8String (FROM({0, 0, 0, 0}..replacementCharacter))
>
>would do the trick.

WAIT! STOP! The S/MIME WG is *not* the right place for this kind of
discussion,
regardless of how interesting it is to a small number of people.

Let's let the PKIX and S/MIME authors make a stab at it and then have others
comment on the proposed text. It can be very simple, and we don't need to
burden two mailing lists with this kind of minutae.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 16 Feb 1998 22:10:00 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: Blake Ramsdell <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: Re: Comment on ESS and Privacy Marks
Sender: [email-masked]

Blake Ramsdell wrote:
> 
> On Monday, February 16, 1998 1:08 PM, Phillip H. Griffin
> [SMTP:[email-masked]] wrote:
> > Type UTF8String has UNIVERSAL 12 as its tag. X.680 states
> > that "In the value notation all BMPString values are valid
> > UniversalString and UTF8String values", and notes that the
> > notation for defining individual character values is the
> > same for these types.
> 
> If this is the case, and UTF8String has UNIVERSAL 12 as its tag, I
> recommend that we use that tag instead of OCTET STRING to package our
> UTF8 strings.  I don't know what PKIX is doing regarding this, but I
> suspect that they should do the same thing.
> 
> As far as profiling UTF8String (should we constrain this to ISO 10646-1
> UCS-2 == BMPString == UNICODE), suggestions are welcome.

The following definition:

  BMP ::= UTF8String (FROM({0, 0, 0, 0}..replacementCharacter))

would do the trick.

I might mention, just for most folks that might find it odd that 
ASN.1 *is* sometimes simple (:-0), that to define any individual
national language characters, say for test purposes, the 
following ASN.1 value notations each produce distinct 
encodings of exactly the same values:

  aval BMPString       ::= {0, 0, 4, 56}
  aval UTF8String      ::= {0, 0, 4, 56}
  aval UniversalString ::= {0, 0, 4, 56}

If you consider, say, characters from a recent informative
RFC on the KOI8-U Ukrainian character set, you could define
such values by coding:

  cyrillicSmallLetterEn  UTF8String ::= {0, 0, 4, 61} -- 206 CE U043D
  cyrillicSmallLetterO   UTF8String ::= {0, 0, 4, 62} -- 207 CF U043E
  cyrillicSmallLetterPe  UTF8String ::= {0, 0, 4, 63} -- 208 D0 U043F

or

  cyrillicSmallLetterEn  BMPString ::= {0, 0, 4, 61} -- 206 CE U043D
  cyrillicSmallLetterO   BMPString ::= {0, 0, 4, 62} -- 207 CF U043E
  cyrillicSmallLetterPe  BMPString ::= {0, 0, 4, 63} -- 208 D0 U043F

Note here that the comments relate to the tables in the appendix
of draft-rfced-info-koi8-u-03.txt, and that the "U" numbers point
to the Unicode character numbers referenced in that draft. So it 
is possible to use such value notation to generate test data for 
all of the world's languages.

For your favorite visible ASCII (which I note is an acronym that 
never appears in the ASN.1 standards) character, the following 
example is provided in X.680:

  space BMPString ::= {0, 0, 0, 32}
  exclamationMark BMPString ::= {0, 0, 0, 33}
  quotationMark BMPString ::= {0, 0, 0, 34}
   ...  -- and so on
  tilde BMPString ::= {0, 0, 0, 126}

Note again that you can substitute UTF8String in all
of these definitions for BMPString (unicode).

It is also quite easy to create your own language types
that are constrained to a given specific permitted alphabet
that some coder tools will enforce. An old copy of the ASN.1
CHARACTER SET MODULE lists the following for example:

  BasicLatin ::=  BMPString (FROM(space..tilde))

  Hangul ::= BMPString 
      (FROM(hangulSyllableKiyeokA..hangulSyllableHieuhIIeung))

  Katakana ::= BMPString (FROM({0, 0, 48, 160}..{0, 0, 48, 255}))

  Bopomofo ::= BMPString (FROM({0, 0, 49, 0}..{0, 0, 49, 47}))

  Bmp ::= BMPString (FROM({0, 0, 0, 0}..replacementCharacter))

Notice that you can use defined character names like "space",
if you've defined such a character, or you can simply use 
numbers.

Phil

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

-- 
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: Mon, 16 Feb 1998 21:26:45 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: Comment on ESS and Privacy Marks
Sender: [email-masked]

Russ Housley wrote:
> 
> Does anyone have a requirement for characters that are not supported by
> PrintableString?  I do not want to add complexity unless it solves a
> problem for someone.
> 

Type PrintableString contains the following values:

     Name            Graphic
  Capital letters  A, B, ... Z
  Small letters    a, b, ... z
  Digits           0, 1, ... 9
  Space             (space)
  Apostrophe           '
  Left Parenthesis     (
  Right Parenthesis    )
  Plus sign            +
  Comma                ,
  Hyphen               -
  Full stop            .
  Solidus              /
  Colon                :
  Equal sign           =
  Question mark        ?

which looks like enough to do a lot of things, but
it omits some of my favorites, such as \ | { } [ ]
" < > * & $ # @ ! ` % and ~. While I am not claiming 
to have a 'requirement', I do think that not at least
allowing for all of the characters found easily by
users on their keyboards is an unfortunate subset,
even for folks in the US. 

I tend to believe that international standards should
support international languages, but it's just a belief
that it's the right thing to do; that it's the net 
we're trying to build; that it's the future. But I know
that actually implementing support for national languages
is difficult and costly.

Phil

> Russ
> 
> At 12:22 PM 2/16/98 -0800, Blake Ramsdell wrote:
> >On Friday, February 13, 1998 3:30 PM, [email-masked]
> >[SMTP:[email-masked]] wrote:
> >>    utf8String   OCTET STRING -- MUST contain UTF-8-encoded characters
> >
> >My understanding is that 1997 ASN.1 is going to include UTF-8.  Is there
> >a universal tag that we can use from any draft 1997 ASN.1 documents?  We
> >can employ the same hack we are currently using for BMP STRING --
> >defining a universal tag in an ASN.1 module.  I am concerned about the
> >backwards compatibility of saying to future clients "ESSPrivacyMark
> >SHOULD accept utf8String encoded as an OCTET STRING as well as a UTF8
> >STRING (or whatever the universal tag ends up being)".
> >
> >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
> >

-- 
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: Mon, 16 Feb 1998 17:18:04 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Comment on ESS and Privacy Marks
Sender: [email-masked]

>Does anyone have a requirement for characters that are not supported by
>PrintableString?  I do not want to add complexity unless it solves a
>problem for someone.

Well, given that PrintableString doesn't include "@", anything that might
include an RFC822 email address needs something else.

The big picture is that anything that is in a human language should use UTF-8.
We don't need it for RFC822 email addresses, domain names, or URLs, since they
are all defined as ASCII. Similarly, dates can be specified at UTCTimes.
However, policies, warnings, contracts, and so on that might be embodied in an
attribute MUST be able to be written in UTF-8 so that non-US folks can
unambiguously state what it is they are saying.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 16 Feb 1998 17:27:53 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: RE: Comment on ESS and Privacy Marks
Sender: [email-masked]

Does anyone have a requirement for characters that are not supported by
PrintableString?  I do not want to add complexity unless it solves a
problem for someone.

Russ

At 12:22 PM 2/16/98 -0800, Blake Ramsdell wrote:
>On Friday, February 13, 1998 3:30 PM, [email-masked]
>[SMTP:[email-masked]] wrote:
>>    utf8String   OCTET STRING -- MUST contain UTF-8-encoded characters
>
>My understanding is that 1997 ASN.1 is going to include UTF-8.  Is there
>a universal tag that we can use from any draft 1997 ASN.1 documents?  We
>can employ the same hack we are currently using for BMP STRING --
>defining a universal tag in an ASN.1 module.  I am concerned about the
>backwards compatibility of saying to future clients "ESSPrivacyMark
>SHOULD accept utf8String encoded as an OCTET STRING as well as a UTF8
>STRING (or whatever the universal tag ends up being)".
>
>Blake
>--
>Blake C. Ramsdell
>Worldtalk Corporation
>For current info, check http://www.deming.com/users/blaker
>Voice +1 425 882 8861 x103  Fax +1 425 882 8060
> 

Date: Mon, 16 Feb 1998 16:02:53 -0800
To: <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Comment on ESS and Privacy Marks
Sender: [email-masked]

>If this is the case, and UTF8String has UNIVERSAL 12 as its tag, I
>recommend that we use that tag instead of OCTET STRING to package our
>UTF8 strings.  I don't know what PKIX is doing regarding this, but I
>suspect that they should do the same thing.

Well, I just turned in the next ESS draft, and I coded it as OCTET STRING. I'm
happy to change it in the one after this, as long as we're doing exactly what
the PKIX people are. Carlisle, what are you going to do in PKIX part 3? Russ,
how about PKIX part 1?

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Comment on ESS and Privacy Marks
Date: Mon, 16 Feb 1998 14:43:19 -0800
Sender: [email-masked]

On Monday, February 16, 1998 1:08 PM, Phillip H. Griffin
[SMTP:[email-masked]] wrote:
> Type UTF8String has UNIVERSAL 12 as its tag. X.680 states 
> that "In the value notation all BMPString values are valid 
> UniversalString and UTF8String values", and notes that the 
> notation for defining individual character values is the 
> same for these types. 

If this is the case, and UTF8String has UNIVERSAL 12 as its tag, I
recommend that we use that tag instead of OCTET STRING to package our
UTF8 strings.  I don't know what PKIX is doing regarding this, but I
suspect that they should do the same thing.

As far as profiling UTF8String (should we constrain this to ISO 10646-1
UCS-2 == BMPString == UNICODE), suggestions are welcome.

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

Date: Mon, 16 Feb 1998 16:07:43 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: Blake Ramsdell <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: Re: Comment on ESS and Privacy Marks
Sender: [email-masked]

Hi there,

Type UTF8String has UNIVERSAL 12 as its tag. X.680 states 
that "In the value notation all BMPString values are valid 
UniversalString and UTF8String values", and notes that the 
notation for defining individual character values is the 
same for these types. 

X.680 also states that "UTF8String is synonymous with 
UniversalString at the abstract level and can be used 
wherever UniversalString is used (subject to rules requiring 
distinct tags) but has a different tag and is a distinct type.

NOTE - The encoding is different from that of UniversalString, 
and for most text will be less verbose.

The UniversalString and UTF8String types carries carry any 
character from ISO/IEC 10646-1. The set of characters in ISO/IEC 
10646-1 is generally too large for meaningful conformance to be 
required, and should normally be subsetted to a combination of 
the standard collections of characters in Annex A of ISO/IEC 10646-1.

Hope this helps. There are other places in X.680 where it is
recommended that a hole be left in the abstract syntax of a 
specification which allows an implementation to specify the
set of characters in this type that are supported in that
implementation. This technique allows the protocol to be
completely specified, but allows each implementation to 
avoid having to be able to receive and properly process the
entire 10646 set of characters, which is huge.

This technique, however, involves use of the ABSTRACT-SYNTAX
class, which I've never personally used. However, in a recent
lecture by the ASN.1 Rapporteur, it was explained in some detail.
But, I don't believe that such an approach would be well understood
enough by enough implementors to be of use to SMIME. And I doubt
seriously that there are more than a handful of tools out there
that properly handle this class definition. This is an ISO 
technique, which involves pics and performa statements and the
infrastructure to manage these things, so I doubt this would be 
of any use for our purposes. 

Phil

Blake Ramsdell wrote:
> 
> On Friday, February 13, 1998 3:30 PM, [email-masked]
> [SMTP:[email-masked]] wrote:
> >    utf8String   OCTET STRING -- MUST contain UTF-8-encoded characters
> 
> My understanding is that 1997 ASN.1 is going to include UTF-8.  Is there
> a universal tag that we can use from any draft 1997 ASN.1 documents?  We
> can employ the same hack we are currently using for BMP STRING --
> defining a universal tag in an ASN.1 module.  I am concerned about the
> backwards compatibility of saying to future clients "ESSPrivacyMark
> SHOULD accept utf8String encoded as an OCTET STRING as well as a UTF8
> STRING (or whatever the universal tag ends up being)".
> 
> 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

-- 
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]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Comment on ESS and Privacy Marks
Date: Mon, 16 Feb 1998 12:22:15 -0800
Sender: [email-masked]

On Friday, February 13, 1998 3:30 PM, [email-masked]
[SMTP:[email-masked]] wrote:
>    utf8String   OCTET STRING -- MUST contain UTF-8-encoded characters

My understanding is that 1997 ASN.1 is going to include UTF-8.  Is there
a universal tag that we can use from any draft 1997 ASN.1 documents?  We
can employ the same hack we are currently using for BMP STRING --
defining a universal tag in an ASN.1 module.  I am concerned about the
backwards compatibility of saying to future clients "ESSPrivacyMark
SHOULD accept utf8String encoded as an OCTET STRING as well as a UTF8
STRING (or whatever the universal tag ends up being)".

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

Date: Mon, 16 Feb 1998 10:38:03 -0500
To: [email-masked], [email-masked]
From: Russ Housley <[email-masked]>
Subject: RE: Comment on ESS and Privacy Marks
Cc: [email-masked]
Sender: [email-masked]

Jim & John:

In general, the privacy mark should simple by displayed to the user, and no
automated checks performed.

Russ

At 02:35 PM 2/13/98 -0800, Jim Schaad (Exchange) wrote:
>John,
>
>I have a real problem with this.  What you are saying is that as a
>general client it is not possible to make any sort of constent use the
>the PrivacyMark field when building a security label policy.  It is
>usable if you are in the US but not otherwise.  This is another case
>where we are now looking at two different ways of accomplishing the same
>task.
>
>I made a general assumption that as a client I should show the contents
>of the privacy mark someplace (otherwise why bother having the field),
>but I am unable to do this in a general way.
>
>If this is really what you want to do maybe we should make this a well
>defined OID in the SecurityCategory upfront
>
>jim
>
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Friday, February 13, 1998 1:18 PM
>To: Ietf-Smime (E-mail)
>Subject: Re: Comment on ESS and Privacy Marks
>
>
>Jim,
>
>I respectfully disagree with your proposal.  Any information that one
>would
>wish to place in a PrivacyMark can also be placed within a
>SecurityCategory.
>The SecurityCategory is a pair of {OID, ANY}.  An ASN.1 syntax can be
>defined for use in the SecurityCategory ANY field that is identified by
>the
>SecurityCategory OID.  The securityLabel security-policy-identifier
>identifies the security policy which defines how the SecurityCategories
>are
>defined and used.  An ASN.1 syntax can be defined for the
>SecurityCategory
>such that there are object identifiers identifying the various
>sub-fields of
>the SecurityCategory ASN.1 syntax.  These OIDs can (among other things)
>identify whether or not access control is required on the specified
>sub-field.  Therefore, one could define a SecurityCategory ASN.1 syntax
>that
>could include a BMPString (or other) which could be uniquely identified
>as
>not requiring access control.  That achieves the same goal as your
>proposal
>without changing the SecurityLabel syntax.  The SecurityLabel syntax
>included in ESS was chosen to be compatible with the X.411 securityLabel
>that is used in X.400 and many existing programs such as the US DoD
>Defense
>Message System.  I believe that it is an important goal to retain the
>X.411
>SecurityLabel syntax in ESS to promote interoperability with existing
>protocols and software that use the X.411 security label.  Also, I
>believe
>it is important to retain the X.411 syntax so that CMS/ESS applications
>can
>share common access control decision functions and other software
>modules
>that are already developed for use with the X.411 security label syntax.
>
>================================
>John Pawling   
>[email-masked]                             
>J.G. Van Dyke & Associates, Inc.           
>================================
>
>
>
>At 11:59 AM 2/13/98 -0800, Jim Schaad (Exchange) wrote:
>>I think that we have a problem with privacy marks as currently
>>represented in the ASN.  To be specific we are currently limited to
>>PrintableCharacters.  I believe that we must expand this to allow for
>>use of non-English langages.  I therefore propose that we switch to the
>>following definition of PrivacyMark

>>
>>PrivacyMark ::= CHOICE {
>>        PrintableString (SIZE (1..ub-privacy-mark-length)),
>>        BMPString (SIZE (1..ub-privacy-mark-length))
>>}
>>
>>jim schaad
>>
>>
> 

Date: Sun, 15 Feb 1998 18:25:45 -0400
To: (Recipient list suppressed)
From: Robert Vinet <[email-masked]>
Subject: Electronic Commerce Press Release
Sender: [email-masked]

New Electronic Commerce Site Takes the Hassle Out of Finding the Latest
ECommerce News

allECommerce -- The most comprehensive source of electronic commerce news,
resources and business strategy available anywhere.

Fredericton, NB Canada -- February 16, 1998 -- V-Networks, Inc. announces
allECommerce (http://www.allEC.com), the most comprehensive source of
Internet-based electronic commerce news, resources and business strategy,
on or off the web. allEC.com is designed to enlighten electronic commerce
professionals in every aspect of electronic commerce.

As the amount of content on the Internet explodes, the electronic commerce
industry insiders are turning to allECommerce to eliminate information
overload, increase productivity, and obtain a sharp competitive advantage
by staying informed.

allECommerce keeps its readers current on all aspects of the electronic
commerce arena. Updated daily, allECommerce provides original content and
provides a collection of time sensitive links to current ECommerce news
stories. The archives provide links to previous stories with stories dating
back to January 1, 1998.

The allEC.com web site offers a comprehensive and easy to navigate site
providing the most up to date electronic commerce:
=B0 Alerts=20
=B0 News=20
=B0 Solutions=20
=B0 Issues=20
=B0 Articles=20
=B0 Products=20
=B0 Research=20
=B0 Updates=20
=B0 Evaluation tools=20
=B0 Links to hundreds of electronic commerce vendors and products=20

The allEC.com Electronic Commerce Resource Centre provides visitors with
hundreds of valuable descriptions and links to consultants, suppliers,
facilitators and other companies working in the electronic commerce domain.

allEC.com reviews and lists electronic commerce related books with direct
links to the Computer Literacy=92s order page, where visitors can order book=
s
at great discount.

The ECommerce Calendar of Events lists trade shows and conferences that are
of interest to the electronic commerce professional.

Thousands of EC industry insiders rely on the allECommerce web site to keep
them current, and visit the site daily.

"allECommerce=92s goal is to provide a single source for anyone wanting to
keep abreast of the burgeoning electronic commerce arena. At allEC.com you
will find the latest news stories from around the world along with links to
the companies that sell products and services to carry out ECommerce on the
Net," boasted Robert Vinet, publisher of allEC.com. "Our popular web site
continues to gain thousand of new and repeat visitors each month. It was
recently updated to add even more features and improved navigation
techniques. Visitors can also participate in the online forum."

Visitors gain free access to allECommerce, without the need to register.
allEC.com is advertiser supported.

To keep its web site as 'open' to all as possible, the editors at allEC.com
chose not to use features that may restrict access through browser choice,
operating system, access speed and so forth.

V-Networks, Inc. is a privately held corporation managed by a team of
web-savvy entrepreneurs.
V-Networks, Inc. is base in Fredericton, New Brunswick, Canada.

Robert Vinet
Publisher
allECommerce
c/o V-Networks, Inc.
527 Beaverbrook Court, Suite 205
Fredericton, NB E3B 1X6
Canada
506 454 7145
[email-masked]
http://www.allEC.com

Date: Fri, 13 Feb 1998 18:29:51 -0500
To: "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Comment on ESS and Privacy Marks
Sender: [email-masked]

All,

Upon further reflection, I agree with Jim that the ESS SecurityLabel
PrivacyMark syntax should be enhanced.

Recommend the following: 

ESSPrivacyMark ::= CHOICE {
   pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
   utf8String   OCTET STRING -- MUST contain UTF-8-encoded characters
}

Also recommend re-naming the ESS SecurityLabel as follows:

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

This will allow ESS-compliant software to construct a ESSSecurityLabel that
includes the ESSPrivacyMark pString CHOICE which will be directly compatible
with a standard X.411 SecurityLabel.  This is true because the
ESSPrivacyMark pString CHOICE encoding is identical to the PricacyMark
printableString encoding because the CHOICE does add a tag.

Alternately, the ESS software can construct a ESSSecurityLabel that includes
ESSPrivacyMark utf8String CHOICE to meet the requirements of foreign
lanquages, etc.

This strategy allows CMS/ESS applications to share common access control
decision functions (ACDF) and other software modules that use the X.411
securityLabel syntax.  The common ACDF software can be developed to
recognize the ESSPrivacyMark CHOICE so that it can accept standard X.411
SecurityLabels (containing PrivacyMark printableString) and ESS
SecurityLabels (containing either privacyMark pString or utf8String CHOICE). 

The alternaive of defining a standard security category for UTF8-String
would be extremely difficult because every security policy would have to
recognize the standard SecurityCategory OID and syntax.

- John Pawling

At 02:35 PM 2/13/98 -0800, Jim Schaad (Exchange) wrote:
>John,
>
>I have a real problem with this.  What you are saying is that as a
>general client it is not possible to make any sort of constent use the
>the PrivacyMark field when building a security label policy.  It is
>usable if you are in the US but not otherwise.  This is another case
>where we are now looking at two different ways of accomplishing the same
>task.
>
>I made a general assumption that as a client I should show the contents
>of the privacy mark someplace (otherwise why bother having the field),
>but I am unable to do this in a general way.
>
>If this is really what you want to do maybe we should make this a well
>defined OID in the SecurityCategory upfront
>
>jim
>
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Friday, February 13, 1998 1:18 PM
>To: Ietf-Smime (E-mail)
>Subject: Re: Comment on ESS and Privacy Marks
>
>
>Jim,
>
>I respectfully disagree with your proposal.  Any information that one
>would
>wish to place in a PrivacyMark can also be placed within a
>SecurityCategory.
>The SecurityCategory is a pair of {OID, ANY}.  An ASN.1 syntax can be
>defined for use in the SecurityCategory ANY field that is identified by
>the
>SecurityCategory OID.  The securityLabel security-policy-identifier
>identifies the security policy which defines how the SecurityCategories
>are
>defined and used.  An ASN.1 syntax can be defined for the
>SecurityCategory
>such that there are object identifiers identifying the various
>sub-fields of
>the SecurityCategory ASN.1 syntax.  These OIDs can (among other things)
>identify whether or not access control is required on the specified
>sub-field.  Therefore, one could define a SecurityCategory ASN.1 syntax
>that
>could include a BMPString (or other) which could be uniquely identified
>as
>not requiring access control.  That achieves the same goal as your
>proposal
>without changing the SecurityLabel syntax.  The SecurityLabel syntax
>included in ESS was chosen to be compatible with the X.411 securityLabel
>that is used in X.400 and many existing programs such as the US DoD
>Defense
>Message System.  I believe that it is an important goal to retain the
>X.411
>SecurityLabel syntax in ESS to promote interoperability with existing
>protocols and software that use the X.411 security label.  Also, I
>believe
>it is important to retain the X.411 syntax so that CMS/ESS applications
>can
>share common access control decision functions and other software
>modules
>that are already developed for use with the X.411 security label syntax.
>
>================================
>John Pawling   
>[email-masked]                             
>J.G. Van Dyke & Associates, Inc.           
>================================
>
>
>
>At 11:59 AM 2/13/98 -0800, Jim Schaad (Exchange) wrote:
>>I think that we have a problem with privacy marks as currently
>>represented in the ASN.  To be specific we are currently limited to
>>PrintableCharacters.  I believe that we must expand this to allow for
>>use of non-English langages.  I therefore propose that we switch to the
>>following definition of PrivacyMark
>>
>>PrivacyMark ::= CHOICE {
>>        PrintableString (SIZE (1..ub-privacy-mark-length)),
>>        BMPString (SIZE (1..ub-privacy-mark-length))
>>}
>>
>>jim schaad
>>
>>
>

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Comment on ESS and Privacy Marks
Date: Fri, 13 Feb 1998 14:35:05 -0800
Sender: [email-masked]

John,

I have a real problem with this.  What you are saying is that as a
general client it is not possible to make any sort of constent use the
the PrivacyMark field when building a security label policy.  It is
usable if you are in the US but not otherwise.  This is another case
where we are now looking at two different ways of accomplishing the same
task.

I made a general assumption that as a client I should show the contents
of the privacy mark someplace (otherwise why bother having the field),
but I am unable to do this in a general way.

If this is really what you want to do maybe we should make this a well
defined OID in the SecurityCategory upfront

jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 13, 1998 1:18 PM
To: Ietf-Smime (E-mail)
Subject: Re: Comment on ESS and Privacy Marks

Jim,

I respectfully disagree with your proposal.  Any information that one
would
wish to place in a PrivacyMark can also be placed within a
SecurityCategory.
The SecurityCategory is a pair of {OID, ANY}.  An ASN.1 syntax can be
defined for use in the SecurityCategory ANY field that is identified by
the
SecurityCategory OID.  The securityLabel security-policy-identifier
identifies the security policy which defines how the SecurityCategories
are
defined and used.  An ASN.1 syntax can be defined for the
SecurityCategory
such that there are object identifiers identifying the various
sub-fields of
the SecurityCategory ASN.1 syntax.  These OIDs can (among other things)
identify whether or not access control is required on the specified
sub-field.  Therefore, one could define a SecurityCategory ASN.1 syntax
that
could include a BMPString (or other) which could be uniquely identified
as
not requiring access control.  That achieves the same goal as your
proposal
without changing the SecurityLabel syntax.  The SecurityLabel syntax
included in ESS was chosen to be compatible with the X.411 securityLabel
that is used in X.400 and many existing programs such as the US DoD
Defense
Message System.  I believe that it is an important goal to retain the
X.411
SecurityLabel syntax in ESS to promote interoperability with existing
protocols and software that use the X.411 security label.  Also, I
believe
it is important to retain the X.411 syntax so that CMS/ESS applications
can
share common access control decision functions and other software
modules
that are already developed for use with the X.411 security label syntax.

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

At 11:59 AM 2/13/98 -0800, Jim Schaad (Exchange) wrote:
>I think that we have a problem with privacy marks as currently
>represented in the ASN.  To be specific we are currently limited to
>PrintableCharacters.  I believe that we must expand this to allow for
>use of non-English langages.  I therefore propose that we switch to the
>following definition of PrivacyMark
>
>PrivacyMark ::= CHOICE {
>        PrintableString (SIZE (1..ub-privacy-mark-length)),
>        BMPString (SIZE (1..ub-privacy-mark-length))
>}
>
>jim schaad
>
>

From: Trevor Freeman <[email-masked]>
To: "Ietf-Smime (E-mail)" <[email-masked]>
Cc: "Pkix List (E-mail)" <[email-masked]>
Subject: RE: Key usage. No, wait, *extended* key usage
Date: Fri, 13 Feb 1998 13:38:31 -0800
Sender: [email-masked]

I am inclined to agree with both Jim and John. 
I agree with Jim that the contents of the extended key usage extension may
have implication on the cert chain. The difficulty with extended key usage
is that the set of possible values will never be constrained, so we don't
know what all the possible outcome would be of a check. I also agree with
john that the right place to clarify this point as what the right thing to
do is in the pkix workgroup.
Trevor
> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Friday, February 13, 1998 12:50 PM
> To:	Ietf-Smime (E-mail)
> Subject:	RE: Key usage. No, wait, *extended* key usage
> 
> Jim,
> 
> For some extensions, the X.509 and PKIX I specs specify when there are
> relationships that must be checked between the values in each of the
> extensions present in the certs that compose a cert path (ex:
> nameConstraints extension).  I can't find any text in X.509 or PKIX I that
> states any requirements for checking any relationship between the values
> in
> the extendedKeyUsage extension present in each cert in the cert path.  
> 
> Therefore, I don't agree with your implication that the S/MIME v3 Cert
> Handling spec should state any requirements about checking the
> extendedKeyUsage extension values in CA certs.  Furthermore, I agree with
> Pat Cain's "less-is-more" philosophy (see attached message) regarding
> minimizing the mandatory requirements included in the S/MIME v3 Cert
> Handling spec (CERT3).  I agree with Pat that CERT3 should not require any
> checks of the extendedKeyUsage extension.
> 
> - John Pawling
> 
> 
> At 12:00 PM 2/13/98 -0800, Jim Schaad (Exchange) wrote:
> >John,
> >
> >> 
> >> I agree with your suggestion to add wording like:  "Prior to using the
> >> public key included in a certificate to support S/MIME 
> >> security services, if
> >> the extendedKeyUsage extension is present in the certificate and is
> >> indicated as being critical, then the S/MIME software MUST 
> >> ensure that the
> >> id-kp-emailProtection OID is present.  This check is only 
> >> required for the
> >> end-entity certificates."
> >
> >The above is not the way that I had read the docs and how
> >extendedKeyUsage would/should be evaluated,  I am curious why you think
> >that only the end-entity certificate should be checked?  I had thought
> >that the entire chain should be checked even though I did not really
> >expect to see any extendedKeyUsage extensions once I got off the
> >end-entity certificate.
> >
> >I can see the case occuring where a super-CA might say that this CA can
> >only be used for issuing certifiate with the e-mail purpose and I am not
> >sure this should be so explicity disabled.
> >
> >jim
> >
> 
> 
> >Return-Path: <[email-masked]>
> >X-Sender: [email-masked]
> >Date: Fri, 06 Feb 1998 16:05:41 -0600
> >To: [email-masked]
> >From: Pat Cain <[email-masked]>
> >Subject: Re: un-*extended* key usage
> >Sender: [email-masked]
> >Precedence: bulk
> >
> >Friends,
> >
> >I worry that we may end up putting too many constraints on the SMIME
> >certificate(s)
> >that are not related to interoperability of the protocol. We originally
> >specified the 
> >key-usage and name extensions because they really (REALLY) did impact
> >interoperability. 
> >Almost all of the other useful X.509 extensions effect how the signature
> or
> >encrypted/random data is interpreted and/or used. For example, if I, as a
> >CA, issue certificates that are good for any number of protocols, it is
> >hard for me to beleive 
> >that SMIME (the protocol) really cares. Think of this in the 'Do I
> support
> >delta-CRLs' vain. I hope (pray) that we don't specify the CRL-ing
> technique
> >-- it's a CA policy decision. Much like what uses a particular
> certificate
> >is good for.
> >
> >I vote to leave specific recommendations for extended key usage, beyond
> >what X.509 discusses for criticality and other stuff, out of the spec. If
> a
> >particular CA wants 
> >to require extended OIDs in their certiifcates, so be it. But that's one
> of
> >those 
> >CA 'policy kind of' things.
> >
> >Pat
> >
> >

Date: Fri, 13 Feb 1998 16:17:40 -0500
To: "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Comment on ESS and Privacy Marks
Sender: [email-masked]

Jim,

I respectfully disagree with your proposal.  Any information that one would
wish to place in a PrivacyMark can also be placed within a SecurityCategory.
The SecurityCategory is a pair of {OID, ANY}.  An ASN.1 syntax can be
defined for use in the SecurityCategory ANY field that is identified by the
SecurityCategory OID.  The securityLabel security-policy-identifier
identifies the security policy which defines how the SecurityCategories are
defined and used.  An ASN.1 syntax can be defined for the SecurityCategory
such that there are object identifiers identifying the various sub-fields of
the SecurityCategory ASN.1 syntax.  These OIDs can (among other things)
identify whether or not access control is required on the specified
sub-field.  Therefore, one could define a SecurityCategory ASN.1 syntax that
could include a BMPString (or other) which could be uniquely identified as
not requiring access control.  That achieves the same goal as your proposal
without changing the SecurityLabel syntax.  The SecurityLabel syntax
included in ESS was chosen to be compatible with the X.411 securityLabel
that is used in X.400 and many existing programs such as the US DoD Defense
Message System.  I believe that it is an important goal to retain the X.411
SecurityLabel syntax in ESS to promote interoperability with existing
protocols and software that use the X.411 security label.  Also, I believe
it is important to retain the X.411 syntax so that CMS/ESS applications can
share common access control decision functions and other software modules
that are already developed for use with the X.411 security label syntax.

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

At 11:59 AM 2/13/98 -0800, Jim Schaad (Exchange) wrote:
>I think that we have a problem with privacy marks as currently
>represented in the ASN.  To be specific we are currently limited to
>PrintableCharacters.  I believe that we must expand this to allow for
>use of non-English langages.  I therefore propose that we switch to the
>following definition of PrivacyMark
>
>PrivacyMark ::= CHOICE {
>        PrintableString (SIZE (1..ub-privacy-mark-length)),
>        BMPString (SIZE (1..ub-privacy-mark-length))
>}
>
>jim schaad
>
>

From: Carlisle Adams <[email-masked]>
To: "'Ietf-Smime (E-mail)'" <[email-masked]>, "'Jim Schaad (Exchange)'" <[email-masked]>
Subject: RE: Comment on ESS and Privacy Marks
Date: Fri, 13 Feb 1998 16:04:22 -0500
Sender: [email-masked]

Hi Jim,

>----------
>From: 	Jim Schaad (Exchange)[SMTP:[email-masked]]
>Sent: 	Friday, February 13, 1998 2:59 PM
>To: 	Ietf-Smime (E-mail)
>Subject: 	Comment on ESS and Privacy Marks
>
>I think that we have a problem with privacy marks as currently
>represented in the ASN.  To be specific we are currently limited to
>PrintableCharacters.  I believe that we must expand this to allow for
>use of non-English langages.  I therefore propose that we switch to the
>following definition of PrivacyMark
>
>PrivacyMark ::= CHOICE {
>        PrintableString (SIZE (1..ub-privacy-mark-length)),
>        BMPString (SIZE (1..ub-privacy-mark-length))
>}

Just a note that it was this identical construct (for PKIFreeText in
PKIX-CMP) that was turned down at the IESG level and prevented CMP from
moving to Proposed Standard.  We were told by Harald Alvestrand that
UTF-8 String (or at least OCTET STRING holding UTF-8-encoded characters)
was to be used instead.

Carlisle.

Date: Fri, 13 Feb 1998 15:49:40 -0500
To: "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Key usage. No, wait, *extended* key usage
Sender: [email-masked]

Jim,

For some extensions, the X.509 and PKIX I specs specify when there are
relationships that must be checked between the values in each of the
extensions present in the certs that compose a cert path (ex:
nameConstraints extension).  I can't find any text in X.509 or PKIX I that
states any requirements for checking any relationship between the values in
the extendedKeyUsage extension present in each cert in the cert path.  

Therefore, I don't agree with your implication that the S/MIME v3 Cert
Handling spec should state any requirements about checking the
extendedKeyUsage extension values in CA certs.  Furthermore, I agree with
Pat Cain's "less-is-more" philosophy (see attached message) regarding
minimizing the mandatory requirements included in the S/MIME v3 Cert
Handling spec (CERT3).  I agree with Pat that CERT3 should not require any
checks of the extendedKeyUsage extension.

- John Pawling

At 12:00 PM 2/13/98 -0800, Jim Schaad (Exchange) wrote:
>John,
>
>> 
>> I agree with your suggestion to add wording like:  "Prior to using the
>> public key included in a certificate to support S/MIME 
>> security services, if
>> the extendedKeyUsage extension is present in the certificate and is
>> indicated as being critical, then the S/MIME software MUST 
>> ensure that the
>> id-kp-emailProtection OID is present.  This check is only 
>> required for the
>> end-entity certificates."
>
>The above is not the way that I had read the docs and how
>extendedKeyUsage would/should be evaluated,  I am curious why you think
>that only the end-entity certificate should be checked?  I had thought
>that the entire chain should be checked even though I did not really
>expect to see any extendedKeyUsage extensions once I got off the
>end-entity certificate.
>
>I can see the case occuring where a super-CA might say that this CA can
>only be used for issuing certifiate with the e-mail purpose and I am not
>sure this should be so explicity disabled.
>
>jim
>

>Return-Path: <[email-masked]>
>X-Sender: [email-masked]
>Date: Fri, 06 Feb 1998 16:05:41 -0600
>To: [email-masked]
>From: Pat Cain <[email-masked]>
>Subject: Re: un-*extended* key usage
>Sender: [email-masked]
>Precedence: bulk
>
>Friends,
>
>I worry that we may end up putting too many constraints on the SMIME
>certificate(s)
>that are not related to interoperability of the protocol. We originally
>specified the 
>key-usage and name extensions because they really (REALLY) did impact
>interoperability. 
>Almost all of the other useful X.509 extensions effect how the signature or
>encrypted/random data is interpreted and/or used. For example, if I, as a
>CA, issue certificates that are good for any number of protocols, it is
>hard for me to beleive 
>that SMIME (the protocol) really cares. Think of this in the 'Do I support
>delta-CRLs' vain. I hope (pray) that we don't specify the CRL-ing technique
>-- it's a CA policy decision. Much like what uses a particular certificate
>is good for.
>
>I vote to leave specific recommendations for extended key usage, beyond
>what X.509 discusses for criticality and other stuff, out of the spec. If a
>particular CA wants 
>to require extended OIDs in their certiifcates, so be it. But that's one of
>those 
>CA 'policy kind of' things.
>
>Pat
>
>

From: "Jim Schaad (Exchange)" <[email-masked]>
To: [email-masked], "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Key usage. No, wait, *extended* key usage
Date: Fri, 13 Feb 1998 12:00:00 -0800
Sender: [email-masked]

John,

> 
> I agree with your suggestion to add wording like:  "Prior to using the
> public key included in a certificate to support S/MIME 
> security services, if
> the extendedKeyUsage extension is present in the certificate and is
> indicated as being critical, then the S/MIME software MUST 
> ensure that the
> id-kp-emailProtection OID is present.  This check is only 
> required for the
> end-entity certificates."

The above is not the way that I had read the docs and how
extendedKeyUsage would/should be evaluated,  I am curious why you think
that only the end-entity certificate should be checked?  I had thought
that the entire chain should be checked even though I did not really
expect to see any extendedKeyUsage extensions once I got off the
end-entity certificate.

I can see the case occuring where a super-CA might say that this CA can
only be used for issuing certifiate with the e-mail purpose and I am not
sure this should be so explicity disabled.

jim

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: Comment on ESS and Privacy Marks
Date: Fri, 13 Feb 1998 11:59:59 -0800
Sender: [email-masked]

I think that we have a problem with privacy marks as currently
represented in the ASN.  To be specific we are currently limited to
PrintableCharacters.  I believe that we must expand this to allow for
use of non-English langages.  I therefore propose that we switch to the
following definition of PrivacyMark

PrivacyMark ::= CHOICE {
        PrintableString (SIZE (1..ub-privacy-mark-length)),
        BMPString (SIZE (1..ub-privacy-mark-length))
}

jim schaad

Date: Fri, 13 Feb 1998 09:46:25 -0500
To: Paul Hoffman / IMC <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: IETF Meeting Reminders
Cc: [email-masked]
Sender: [email-masked]

Paul:

That would be even better!

Russ

At 09:46 AM 2/12/98 -0800, Paul Hoffman / IMC wrote:
>At 08:46 AM 2/12/98 -0500, Russ Housley wrote:
>>My goal is to move the CMS, MSG, ESS, and CERT documents to
>>working group last call immediately following the LA meeting.
>
>I think you may be being a bit pessimistic here, Russ. The LA meeting is
>nearly
>two months away. I beleive that ESS will be ready for WG last call after the
>next draft, which should be out next week. I think we are rapidly closing
>in on
>MSG and CERT as well, and think we could be ready for WG last call on them
>within a month.
>
>Therefore, the LA meeting might be the *close* of WG last call for three of
>the
>four drafts, or we might close them before the WG meeting.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
> 

Date: Fri, 13 Feb 1998 09:58:37 -0500
To: Chen Wang <[email-masked]>, [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: What is the OID for CRS ??
Sender: [email-masked]

Chen,

IMHO, your question needs to be re-directed to the IETF PKIX WG mail list
([email-masked]).  At the Dec 97 Washington DC IETF, the S/MIME
WG decided that CRS should not be accepted as work under the S/MIME WG (see
following quote from minutes).  The S/MIME WG and PKIX WG agreed that CRS
should be pursued under the PKIX WG because cert mgmt protocols are a PKIX
responsibility, not S/MIME.  

Quote from minutes of Dec 97 S/MIME WG meeting:

"Add CRS to Charter? - Russ Housley

Russ proposed that the S/MIME WG should concur with the PKIX WG decision
that the CRS work should stay in the PKIX WG.  In other words, the S/MIME WG
should not define a Certificate Request format.  The S/MIME WG agreed with
Russ' proposal."

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

At 05:11 PM 2/12/98 -0600, Chen Wang wrote:
>
>Hi, all, what is the exact OID for CRS? I know the OID for CMS, since it is
>a id-smime-mod:
>
>id-mod-cms OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549)
>				pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) }
>
>so the CRS is something like:
>
>id-mod-crs OBJECT IDENTIFIER ::= { id-mod ?? }
>
>I can't find it anywhere in the smime-oids as in 
>"http://www.imc.org/ietf-smime".
>
>Perhaps the OID table need to be updated a bit? :^)
>
>	-- Chen Wang, netDox
>
>

Date: Fri, 13 Feb 1998 08:55:35 -0500
To: Chen Wang <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: What is the OID for CRS ??
Cc: [email-masked]
Sender: [email-masked]

Chen:

It has not been decided.  In fact, CRS is not part of the working group
charter.  An OID will not be assigned until the group formally requests a
charter change and the IESG agrees to that change.

Russ

At 05:11 PM 2/12/98 -0600, Chen Wang wrote:
>
>Hi, all, what is the exact OID for CRS? I know the OID for CMS, since it is
>a id-smime-mod:
>
>id-mod-cms OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549)
>				pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) }
>
>so the CRS is something like:
>
>id-mod-crs OBJECT IDENTIFIER ::= { id-mod ?? }
>
>I can't find it anywhere in the smime-oids as in 
>"http://www.imc.org/ietf-smime".
>
>Perhaps the OID table need to be updated a bit? :^)
>
>	-- Chen Wang, netDox
> 

Date: Thu, 12 Feb 1998 17:11:14 -0600 (CST)
From: Chen Wang <[email-masked]>
To: [email-masked]
Subject: What is the OID for CRS ??
Sender: [email-masked]

Hi, all, what is the exact OID for CRS? I know the OID for CMS, since it is
a id-smime-mod:

id-mod-cms OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549)
				pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) }

so the CRS is something like:

id-mod-crs OBJECT IDENTIFIER ::= { id-mod ?? }

I can't find it anywhere in the smime-oids as in 
"http://www.imc.org/ietf-smime".

Perhaps the OID table need to be updated a bit? :^)

	-- Chen Wang, netDox

Date: Thu, 12 Feb 1998 09:46:39 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: IETF Meeting Reminders
Sender: [email-masked]

At 08:46 AM 2/12/98 -0500, Russ Housley wrote:
>My goal is to move the CMS, MSG, ESS, and CERT documents to
>working group last call immediately following the LA meeting.

I think you may be being a bit pessimistic here, Russ. The LA meeting is
nearly
two months away. I beleive that ESS will be ready for WG last call after the
next draft, which should be out next week. I think we are rapidly closing
in on
MSG and CERT as well, and think we could be ready for WG last call on them
within a month.

Therefore, the LA meeting might be the *close* of WG last call for three of
the
four drafts, or we might close them before the WG meeting.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 12 Feb 1998 10:41:45 -0500 (EST)
From: [email-masked]
To: [email-masked]
Reply-To: [email-masked]
Subject: Is Your Web Site A Secret?
Sender: [email-masked]

To: [email-masked] 
     Is your web site the best kept secret on the Internet?

     We'll promote it to 50 search engines and indexes for $85
     and complete the job in 2 business days.  Satisfaction is
     guaranteed!

If you have a great product, but are not getting many inquiries from
your Web site, you may not be adequately listed on the Web's search
engines and indexes.

Millions of viewers daily use these facilities to find the products
and services they are looking for.  But if your site is not listed, no
one will see it.

Listings on most of these services are free.  However, locating and
filling out the forms required to get a listing can take several days,
and most people just don't have the time to do it.

That is why we offer a web site promotion service.

WHAT'S THE DEAL?

We will submit your site to 50 indexes and search engines for $85.  We
will accept the return of this E-mail, with the form below filled out,
as an order.  We will bill you upon completion of the promotion.  Our
terms are net 15 days from date of invoice.  Satisfaction guaranteed!

HOW LONG WILL IT TAKE?

Generally, we complete the submissions within 48 hours of
receiving your order.  It can take any individual search engine or
index up to three weeks to process your submission, although most are
much faster.

WHAT SEARCH ENGINES AND INDEXES ARE INCLUDED IN THE
PROMOTION?

The list changes from time to time.  This is our current list:

Alta Vista, BC Internet, BizCardz Business Directory, BizWeb, Excite,
Galaxy, HotBot, Infoseek, InfoSpace, Jayde Online Directory, JumpCity
JumpLink, Linkcentre Directory, LinkMonster, Lycos, Magellan,
Manufacturers Information Network, Net Happenings, Net Mall,
Net-Announce, New Page List, New Riders WWW Yellow Pages, Northern
Light, One World Plaza, Open Text Web Index, PageHost A-Z, PeekABoo,
Project Cool, Scrub The Web, Seven Wonders, Sserv, Starting Point, The
Galactic Galaxy, The Weekly Bookmark, True North,TurnPike, Unlock:The
Information Exchange, Web 100, Web Crawler, Web Walker, Web World
Internet Directory, WebVenture Hotlist, What's New, WhatUSeek,
Where2Go, World Wide Business Yellow Pages, Wow! Web Wonders!, WWW
Worm, YelloWWWeb, Your WebScout

HOW WILL I KNOW THAT YOU HAVE PROMOTED MY SITE?

When we have completed the promotion, we will send you an HTML
file as an attachment to your E-mail bill.  Save this file to your
disk, and view it through your Web browser.  It provides links to the
search engine we submitted your site to, plus any comments we received
from them when we did it.

ARE THERE ANY GUARANTEES?

We do not require prepayment.  Your satisfaction is guaranteed or
you don't pay the bill.

WHO IS OWL'S EYE PRODUCTIONS?

We are a web site promotion company located at:

   Owl's Eye Productions, Inc.
   260 E. Main Street
   Brewster, NY 10509
   Phone: (914) 278-4933
   Fax:     (914) 278-4507
   Email: [email-masked]

HOW DO I ORDER?

The easiest way to order is by e-mail.  Just hit the REPLY button on
your e-mail program and fill out the following information. (This
information will be posted to the search engines/indexes):

Your name: 
Company Name:
Address:
City:              State/Prov:     Zip/Postal Code: 
Telephone: 
Fax: 
Email address: 
URL:  http://
Site Title: 
Description (about 25 words): 
Key words (maximum of 25, in descending order of importance):

Proofs (Where shall we e-mail proofs): 

If  billing a different address, please complete the following:

Addressee: 
Company Name:
Address:
City:              State/Prov:     Zip/Postal Code: 
Telephone: 
Fax: 
Email address: 

We will bill via Email. (SE7N09)

Terms:  By returning this document via Email, you agree as follows:
You have the authority to purchase this service on behalf of your
company.    Terms are net 15 days.  Accounts sent to collections will
be liable for collection costs.  You agree to protect and indemnify
Owl's Eye Productions, Inc. in any claim for libel, copyright
violations, plagiarism, or privacy and other suits or claims based on
the content or subject matter of  your site.

WHAT HAPPENS NEXT?

When we receive your order, we will input the information into
our system.  Then we will run your promotion, capturing
any comments from search engines as we go.  We will incorporate these
into an HTML-formatted report to you, which we will attach to
your bill.
=====================================================================
                 Owl's Eye Productions, Inc.
                   260 E. Main Street
                   Brewster, NY 10509
Ph: 914-278-4933  Fx: 914-278-4507  E-mail: [email-masked]

Date: Thu, 12 Feb 1998 08:46:46 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: IETF Meeting Reminders
Sender: [email-masked]

All:

The following dates apply to the upcoming IETF meeting. Being early is far
better than being on time, so we should try to beat each date by at least
one week.  This allows the meeting attendees to read the relevant drafts
before coming to LA.  Here are some important deadlines:

	March 13 - Internet Draft submission cutoff date at 1700 EST
	March 20 - Pre-Registration Payment cutoff date at 1200 EST
	March 25 - Pre-Registration cutoff date at 1200 EST
	March 25 - Working Group agendas due date by 1200 EST
	March 25 - Registration Cancellations cutoff date by 1800 EST

Please send me tpoics for the adenda.  We have a total of two hours
scheduled.  I do not want to fill the whole two hours with presentations.
Rather, I would like to have a presentation that highlights open issues
with potential solutions, followed by group discussion and solution
selection.  My goal is to move the CMS, MSG, ESS, and CERT documents to
working group last call immediately following the LA meeting.  So, if you
have issues, lets get them on the agenda.

Russ
S/MIME WG Chair

Date: Wed, 11 Feb 1998 00:00:23 -0500
To: [email-masked]
From: "David M. Balenson" <[email-masked]>
Subject: REMINDER: ISOC 1998 Network and Distributed Security Symposium
Sender: [email-masked]

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

Ok, now that I got your attention, here's the missing text ...

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

1998 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM
March 11-13, 1998
Catamaran Resort Hotel
San Diego, California
Sponsored by the Internet Society
Program Chairs:  Matt Bishop, University of California at Davis
		 Steve Kent, BBN Technologies

ONLINE INFORMATION AND REGISTRATION:  http://www.isoc.org/ndss98
EARLY REGISTRATION DISCOUNT DEADLINE:  February 13, 1998

This 5th annual Symposium brings together researchers, implementers,
and users of network and distributed system security technologies
to discuss today's important security issues and challenges.  The
Symposium provides a mix of technical papers and panel presentations
that describe promising new approaches to security problems that
are practical and, to the extent possible, have been implemented.
NDSS'98 fosters the exchange of technical information and encourages
the Internet community to deploy available security technologies
and develop new solutions to unsolved problems.

KEYNOTE SPEAKER: Howard Gittleson, Director of the Internet Security 
Products Group at Bell Laboratories, Lucent Technologies

THIS YEAR'S TOPICS INCLUDE:
- Internet and Intranet security
- Implementation issues for electronic commerce
- All-optical networks security
- Secure single login
- Timestamping protocols
- Remote password protocols
- Mobile agent systems security
- Java security
- Trust management
- Traffic analysis of TCP gateways
- Secure bootstrapping
- Firewalls and IP security

NEW THIS YEAR!  PRE-CONFERENCE TECHNICAL TUTORIALS:
- Principles of Network Security (Dr. Stephen T. Kent, BBN Technologies)
- Electronic Payment Systems (Dr. B. Clifford Neuman, USC/ISI)
- Kerberos  (Jeffrey I. Schiller, MIT)
- Internet Security with Firewalls  (Fred Avolio, TIS)
- Web Security and Beyond (Dr. B. Clifford Neuman, USC/ISI)

FOR MORE INFORMATION contact the Internet Society:
     Internet Society, 12020 Sunrise Valley Drive, Reston, VA, 20191 USA
     Phone: +1 703 648 9888
     Fax: + 1 703 648 9887
     E-mail: [email-masked]
     URL: http://www.isoc.org/ndss98/

SPONSORSHIP OPPORTUNITIES AVAILABLE!  Take advantage of this high
visibility event.  Contact Torryn P. Brazell at the Internet Society
at +1 703 648 9888 or send e-mail to [email-masked].  
Sponsorship Chair: George Conrades, GTE Internetworking

THE INTERNET SOCIETY is a non-governmental organization for global
cooperation and coordination for the Internet and its
internetworking technologies and applications.

--=====================_887191223==_--

Date: Tue, 10 Feb 1998 18:33:29 -0500
To: [email-masked]
From: "David M. Balenson" <[email-masked]>
Subject: REMINDER: ISOC 1998 Network and Distributed System Security Symposium
Sender: [email-masked]

----------------------------------------------------------------------------
David M. Balenson, AR&E Cryptographic Technologies Group
Trusted Information Systems, 3060 Washington Road, Glenwood, MD 21738  USA
[email-masked]; 301-854-5358; fax 301-854-5363

Date: Tue, 10 Feb 1998 14:03:33 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Wording for removing PKI
Sender: [email-masked]

> From: Paul Hoffman / IMC <[email-masked]>
> 
> There seemed to be strong consensus that we should take out the wording in the
> current -msg and -cert drafts about how to do certificate registration.
> Here is
> my take on what needs to change in the two documents to do this. Please look
> this over, and if you're one of the "careful" types, see if there is anything
> else in either document that needs to be removed or changed.
> 
> As I said earlier, I think we need to address the issue, but only briefly. I
> chose to do it in the -msg document (see the section 3.7 change below), but am
> happy to put it in -cert instead. It seemed better in -msg because that's
> where
> we are talking about the format for other actions.

Paul,

I agree with your suggested changes, and with John Pawling's
modification to say explicitly that PKIX will define cert requests,
cert responses, and other PKI management operations.

Dave Kemp

Date: Mon, 9 Feb 1998 10:59:17 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Wording for removing PKI
Sender: [email-masked]

All,

I agree with all of Paul's recommended changes.  I have one minor comment:

Paul recommended the following text for the S/MIME v3 Msg Spec, sec 3.7:
>In 3.7, remove the entire section and its subsections, and replace it with:
>=A0=A0=A0 3.7 Registration Requests
>
>=A0=A0=A0 A sending agent that signs messages MUST have a certificate for=
 the
>=A0=A0=A0 signature so that a receiving agent can verify the signature.=
 There are
>=A0=A0=A0 many ways of getting certificates, such as through an exchange=
 with a
>=A0=A0=A0 certificate authority, through a hardware token or diskette, and=
 so on.
>
>=A0=A0=A0 S/MIME v2 [SMIMEV2] specified a method for "registering" public=
 keys
>=A0=A0=A0 with certificate authorities using an application/pkcs10 body=
 part. The
>=A0=A0=A0 IETF's PKIX Working Group is preparing another method for=
 requesting
>=A0=A0=A0 certificates; however, that work was not finished at the time of=
 this
>=A0=A0=A0 draft. S/MIME v3 does not specify how to request a certificate,=
 but
>=A0=A0=A0 instead mandates that every sending agent already has a=
 certificate.

Recommend that the following sentence should be re-worded:=20

Paul's sentence: "The IETF's PKIX Working Group is preparing another method
for requesting certificates; however, that work was not finished at the time
of this draft"=20

Proposed text: "The IETF's PKIX Working Group is preparing another method
for the: end-entity to request certificates; CA to respond to the request;
and exchange of other certificate management information.  However, that
work was not finished at the time of this draft."

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

Date: Sat, 7 Feb 1998 08:23:28 -0500 (EST)
From: [email-masked]
To: [email-masked]
Reply-To: [email-masked]
Subject: OK to send e-mail?
Sender: [email-masked]

OK to send an e-mail to [email-masked]? 

Date: Fri, 06 Feb 1998 16:05:41 -0600
To: [email-masked]
From: Pat Cain <[email-masked]>
Subject: Re: un-*extended* key usage
Sender: [email-masked]

Friends,

I worry that we may end up putting too many constraints on the SMIME
certificate(s)
that are not related to interoperability of the protocol. We originally
specified the 
key-usage and name extensions because they really (REALLY) did impact
interoperability. 
Almost all of the other useful X.509 extensions effect how the signature or
encrypted/random data is interpreted and/or used. For example, if I, as a
CA, issue certificates that are good for any number of protocols, it is
hard for me to beleive 
that SMIME (the protocol) really cares. Think of this in the 'Do I support
delta-CRLs' vain. I hope (pray) that we don't specify the CRL-ing technique
-- it's a CA policy decision. Much like what uses a particular certificate
is good for.

I vote to leave specific recommendations for extended key usage, beyond
what X.509 discusses for criticality and other stuff, out of the spec. If a
particular CA wants 
to require extended OIDs in their certiifcates, so be it. But that's one of
those 
CA 'policy kind of' things.

Pat

Date: Fri, 6 Feb 1998 14:11:31 -0500
To: "Blake Ramsdell" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Key usage. No, wait, *extended* key usage
Sender: [email-masked]

Blake,

PKIX I already documents the fact that D-H certs will include the keyUsage
extension with the keyAgreement bit set to 1 and that RSA certs will include
keyUsage with keyEncipherment set to 1, so the S/MIME certs spec doesn't
need to say anything about this topic.

In general, I believe that the S/MIME Certs spec should only include
S/MIME-specific requirements and that it should not repeat what is already
stated in X.509 and PKIX I.

- John Pawling

At 05:49 PM 2/5/98 -0800, Blake Ramsdell wrote:
>On Thursday, February 05, 1998 1:40 PM, [email-masked]
>[SMTP:[email-masked]] wrote:
>> Also, please note that the keyAgreement bit will be set to 1 if D-H or
>> KEA
>> is being used.
>
>You are using keyAgreement to indicate a certificate that is used to
>protect a symmetric key?
>
>We will likely need to document this in the cert 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
>
>

Date: Fri, 06 Feb 1998 09:15:14 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Wording for removing PKI
Sender: [email-masked]

There seemed to be strong consensus that we should take out the wording in=
 the
current -msg and -cert drafts about how to do certificate registration.
Here is
my take on what needs to change in the two documents to do this. Please look
this over, and if you're one of the "careful" types, see if there is=
 anything
else in either document that needs to be removed or changed.

As I said earlier, I think we need to address the issue, but only briefly. I
chose to do it in the -msg document (see the section 3.7 change below), but=
 am
happy to put it in -cert instead. It seemed better in -msg because that's
where
we are talking about the format for other actions.

--Paul Hoffman, Director
--Internet Mail Consortium

*****msg-01*****

In 1.1, remove the sentence:
=A0=A0=A0 This draft also defines how to create certification requests that
=A0=A0=A0 conform to PKCS #10 [PKCS-10], and the application/pkcs10 MIME=
 type
=A0=A0=A0 for transporting those requests.

In 1.1, further down, remove:
=A0=A0=A0 - "PKCS #10: Certification Request Syntax", [PKCS-10].

In 3.2.1, remove:
=A0=A0=A0 application/pkcs10=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 .p10

In 3.7, remove the entire section and its subsections, and replace it with:
=A0=A0=A0 3.7 Registration Requests

=A0=A0=A0 A sending agent that signs messages MUST have a certificate for=
 the
=A0=A0=A0 signature so that a receiving agent can verify the signature.=
 There are
=A0=A0=A0 many ways of getting certificates, such as through an exchange=
 with a
=A0=A0=A0 certificate authority, through a hardware token or diskette, and=
 so on.

=A0=A0=A0 S/MIME v2 [SMIMEV2] specified a method for "registering" public=
 keys
=A0=A0=A0 with certificate authorities using an application/pkcs10 body=
 part. The
=A0=A0=A0 IETF's PKIX Working Group is preparing another method for=
 requesting
=A0=A0=A0 certificates; however, that work was not finished at the time of=
 this
=A0=A0=A0 draft. S/MIME v3 does not specify how to request a certificate,=
 but
=A0=A0=A0 instead mandates that every sending agent already has a=
 certificate.

In 3.8, remove:
=A0=A0=A0 MIME type:=A0=A0 application/pkcs10
=A0=A0=A0 parameters:=A0 any
=A0=A0=A0 file suffix: any
and in the last entry (MIME type: application/octet-stream), remove p10.

In B, remove:
=A0=A0=A0 [PKCS-10] "PKCS #10: Certification Request Syntax", Internet Draft
=A0=A0=A0 draft-hoffman-pkcs-certif-req

In E.3, remove the entire section (we may be removing all of E, depending
on what I hear from IANA).

*****cert-01*****

In 1, remove:
=A0=A0=A0=A0 - ''PKCS #10: Certification Request Syntax'', [PKCS-10].

In 5, remove the entire section and its subsections (ga-chunk!). Renumber
section 6 to 5.

In A.6, remove the entire section.

In references, remove:
=A0=A0=A0 [PKCS-10], "PKCS #10: Certification Request Syntax", draft has=
 been
=A0=A0=A0 submitted for RFC status

Date: Fri, 6 Feb 1998 11:00:07 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Key usage. No, wait, *extended* key usage
Cc: [email-masked]
Sender: [email-masked]

> To: [email-masked] (David P. Kemp)
> 
> I suggest being conformant with the PKIX interpretation of this extension
> (the OID must be present only if the extension is marked critical) for
> three reasons:
> 
>  1. This is really a generalized cert validation issue, with S/MIME as the
> 	particular application in question, rather than being an S/MIME issue at
> 	its core. As such, it seems that being in agreement with PKIX is better
> 	than being different. (Although it certainly appears that stating this
> 	would not make S/MIME non-compliant with PKIX, as it includes an out for
> 	applications which would presumably also apply to protocol profiles.)

I agree that S/MIME should be fully conformant with PKIX and X.509.

However, the peculiar definition of the extKeyUsage extension (if the
critical bit is set, the cert must be used only for the specified purposes,
otherwise the purposes are only advisory) and certficatePolicies extension
(similar definition) have been discussed elsewhere, and as a result of
those discussions Warwick Ford will be processing a defect report
against X.509.

The problem is overloading the critical bit for two different purposes:

1) differentiating between clients that do or do not support a particular
   extension, and
2) differentiating between extensions that are intended by the CA to be
   mandatory-to-enforce or advisory in nature.

These may sound like similar purposes, but there are cases where the
CA really wants a particular extension to be MUST-enforce for all
supporting applications, but is not willing to shut out non-supporting
applications by setting the critical bit.  The non-supporting software
will eventually be upgraded, but the intended mandatory/advisory
semantics shouldn't depend on how long it takes to flush old software
out of the system.

For the certificatePolicies and extKeyUsage extensions, it is possible to
fix the problem in two ways:

1) define two new extensions for "advisoryCertPolicies" and
"advisoryExtKeyUsage" and retain the existing extensions as the
mandatory versions, or

2) define two new extensions which contain a boolean "advisory" flag
within the syntax of the extension value, and deprecate the existing
extensions.

For future extensions, of course, it would be preferable to
include the advisory flag in the extension syntax rather than defining
two parallel extensions with similar purposes.

Date: Thu, 05 Feb 1998 21:41:03 -0500
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: Critical Attributes
Sender: [email-masked]

I'll add my support to this proposal.  I too am hearing a clear
consensus here.

Chris

___________________

Russ Housley wrote:

> All:
>
> Having heard from several implementors that the
> SEQUENCE { OID, BOOLEAN, SET OF ANY } is not an
> implementation problem, the next draft of CMS will
> include this structure for attributes.
>
> I do not plan to allow unauthenticated attribute to
> be critical.  Since these attribute are not covered
> by the signature, they have no integrity protection.
> This means that an attacker or malicious recipient
> could turn the critical BOOLEAN to FALSE anyway.
>
> Russ

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Key usage. No, wait, *extended* key usage
Date: Thu, 5 Feb 1998 17:49:47 -0800
Sender: [email-masked]

On Thursday, February 05, 1998 1:40 PM, [email-masked]
[SMTP:[email-masked]] wrote:
> Also, please note that the keyAgreement bit will be set to 1 if D-H or
> KEA
> is being used.

You are using keyAgreement to indicate a certificate that is used to
protect a symmetric key?

We will likely need to document this in the cert 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: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, <[email-masked]>
Subject: RE: Key usage. No, wait, *extended* key usage
Date: Thu, 5 Feb 1998 17:47:44 -0800
Sender: [email-masked]

On Thursday, February 05, 1998 12:43 PM, [email-masked]
[SMTP:[email-masked]] wrote:
> I believe that S/MIME software which supports the keyUsage and
> extendedKeyUsage extensions MUST always ensure that the above checks
> are done, regardless of whether the extensions are marked critical.
> The only question is whether the S/MIME cert profile mandates support
> for these extensions.

I agree with this.

> I recommend that the two suggested texts be included in the S/MIME
> Cert Spec, with the phrase "and is indicated as being critical"
> deleted from each.

Yes, that's what I was getting at in my last message also.  I agree.

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

Date: Thu, 5 Feb 1998 13:48:25 -0800
To: [email-masked] (David P. Kemp)
From: Tim Dierks <[email-masked]>
Subject: Re: Key usage. No, wait, *extended* key usage
Cc: [email-masked]
Sender: [email-masked]

At 3:43 PM -0500 2/5/98, David P. Kemp wrote:
>I believe that S/MIME software which supports the keyUsage and
>extendedKeyUsage extensions MUST always ensure that the above checks
>are done, regardless of whether the extensions are marked critical.
>The only question is whether the S/MIME cert profile mandates support
>for these extensions.

I suggest being conformant with the PKIX interpretation of this extension
(the OID must be present only if the extension is marked critical) for
three reasons:

 1. This is really a generalized cert validation issue, with S/MIME as the
	particular application in question, rather than being an S/MIME issue at
	its core. As such, it seems that being in agreement with PKIX is better
	than being different. (Although it certainly appears that stating this
	would not make S/MIME non-compliant with PKIX, as it includes an out for
	applications which would presumably also apply to protocol profiles.)

 2. If S/MIME makes the PKIX interpretation standard, CAs could force the
	behavior you request by making the extended key usage extension critical.

 3. If you specify it this way, any existing certificate which has an
	extended key usage field by which does not include this OID cannot be
	used for S/MIME. Since several other elements of the S/MIME certificate
	profile seem to have been designed to allow certs issued without the
	specific use of S/MIME in mind to be used with the protocol, this action
	would appear to be in conflict with current direction.

 - Tim

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

Date: Thu, 5 Feb 1998 16:40:21 -0500
To: "[email-masked]'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Key usage. No, wait, *extended* key usage
Sender: [email-masked]

Blake,

>Don't we need to explain the keyUsage field for sending an encrypted
>message?  It seems that on an outbound message:  "Prior to creating and
>encrypted content key for an S/MIME message, if the keyUsage extension
>is present in the encrypting certificate and is indicated as being
>critical, then the encrypting software MUST ensure that that the
>keyEncipherment bit is set to 1."

X.509, Sec 12.2.2.3, Key Usage Field, states: "If the extension is flagged
critical, then the certificate shall be used only for a purpose for which
the corresponding key usage bit is set to one."  The S/MIME v3 Cert Handling
Spec already states that the keyUsage extension must be critical, if
present.  Therefore, the cert using software MUST check the keyUsage bits
before using the certs.  Therefore, I don't believe that the S/MIME v3 Cert
Handling Spec needs to say anything other than "keyUsage must be critical,
if present". 

Also, please note that the keyAgreement bit will be set to 1 if D-H or KEA
is being used.

>
>What about the criticality flags?  Is the only case where we check the
>keyUsage when the criticality for the extension is set to 1?  I think it
>should always be checked, regardless of its criticality.

Agree.

- John Pawling

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Key usage. No, wait, *extended* key usage
Date: Thu, 5 Feb 1998 13:27:59 -0800
Sender: [email-masked]

On Thursday, February 05, 1998 9:24 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> In an earlier message, I recommended that the S/MIME v3 Cert Handling
I-D,
> 
> Sec 4.2, 1rst para should be modified as follows:  Please add "as per
> [KEYM]" to "Certificate, CRL, and chain validation MUST be
performed...".
> If this comment is incorporated, then I believe that the S/MIME Cert
I-D
> doesn't need to discuss the vast majority of the keyUsage checks that
you
> list in your message because it will refer to the PKIX X.509 Cert and
CRL
> Profile which provides sufficient info for the implementor to
determine
> which keyUsage bits need to be checked in most of the situations that
you
> describe in your message.  

I forgot about this, and I have since added it to the editing pile.  I
paraphrased this as "PKIX part 1 rules apply" in my last message.

> The only keyUsage-related text that I believe is appropriate for
> inclusion
> in the S/MIME Cert Spec is:  "Prior to verifying the signature of an
> S/MIME
> message, if the keyUsage extension is present in the signer's
certificate
> and is indicated as being critical, then the verifying software MUST
> ensure
> that the nonRepudiation bit is set to 1."

Don't we need to explain the keyUsage field for sending an encrypted
message?  It seems that on an outbound message:  "Prior to creating and
encrypted content key for an S/MIME message, if the keyUsage extension
is present in the encrypting certificate and is indicated as being
critical, then the encrypting software MUST ensure that that the
keyEncipherment bit is set to 1."

> I agree with your suggestion to add wording like:  "Prior to using the
> public key included in a certificate to support S/MIME security
services,
> if
> the extendedKeyUsage extension is present in the certificate and is
> indicated as being critical, then the S/MIME software MUST ensure that
> the
> id-kp-emailProtection OID is present.  This check is only required for
> the
> end-entity certificates."

OK.

What about the criticality flags?  Is the only case where we check the
keyUsage when the criticality for the extension is set to 1?  I think it
should always be checked, regardless of its criticality.

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

Date: Thu, 5 Feb 1998 16:29:15 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Key usage. No, wait, *extended* key usage
Sender: [email-masked]

Dave,

I agree with your recommendations.  Please note that the PKIX X.509 Cert and
CRL Profile states that keyUsage should always be critical, if present, and
the S/MIME Cert Handling Spec states that keyUsage MUST be critical, if
present.  

- John Pawling

Date: Thu, 5 Feb 1998 15:43:15 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Key usage. No, wait, *extended* key usage
Sender: [email-masked]

> From: [email-masked] (John Pawling)
> 
> The only keyUsage-related text that I believe is appropriate for inclusion
> in the S/MIME Cert Spec is:  "Prior to verifying the signature of an S/MIME
> message, if the keyUsage extension is present in the signer's certificate
> and is indicated as being critical, then the verifying software MUST ensure
> that the nonRepudiation bit is set to 1."
> 
> I agree with your suggestion to add wording like:  "Prior to using the
> public key included in a certificate to support S/MIME security services, if
> the extendedKeyUsage extension is present in the certificate and is
> indicated as being critical, then the S/MIME software MUST ensure that the
> id-kp-emailProtection OID is present.  This check is only required for the
> end-entity certificates."
> 
> - John Pawling

John,

I agree with the intent of these suggestions, but have a problem with
the interpretation of the critical bit.

I believe that S/MIME software which supports the keyUsage and
extendedKeyUsage extensions MUST always ensure that the above checks
are done, regardless of whether the extensions are marked critical.
The only question is whether the S/MIME cert profile mandates support
for these extensions.

If S/MIME compliant software must support them then the wording would
be simply: "... if the extendedKeyUsage extension is present in the
certificate, then the S/MIME software MUST ensure that the
id-kp-emailProtection OID is present."

If S/MIME compliant software is not required to support the extensions,
then either the MUST can be changed to SHOULD, or the statements can
be omitted entirely, allowing the standard criticality processing to
reject the certificate if the extensions are marked critical but are
not supported by the software.

I recommend that the two suggested texts be included in the S/MIME
Cert Spec, with the phrase "and is indicated as being critical"
deleted from each.

Dave Kemp

Date: Thu, 05 Feb 1998 02:08:46 -0500
To: Bill Buffam <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: CRLs in OriginatorInfo?
Cc: [email-masked]
Sender: [email-masked]

Bill:

PKCS#7 v1.5 OPTIONALLY includes CRLs as part of signed-data.  So the same
approach was taken when originator certificates were added to enveloped-data.

Russ

At 06:58 PM 2/3/98 -0500, Bill Buffam wrote:
>Can someone explain the rationale for including CRLs in OriginatorInfo
>in the EnvelopedData type? Obviously you need the originator's public
>key to decrypt a D-H encrypted content key, and the certificate is a
>convenient way of sending it. But the CRL? If the certificate has been
>revoked (say because the private key was compromised), then an impostor
>may have sent you encrypted mail. But so what? You're not going to treat
>that as a digital signature - that comes from the SignedData type. We're
>talking about a different certificate there.
>
>And surely you're not, in general, going to use the encryption key from
>that certificate to send back encrypted mail without checking some more
>current version of the CRL than the one you just happened to get the
>last time he sent you a message.
>
>-- 
>
>Bill Buffam
>Unisys, Malvern PA
>[email-masked]
> 

Date: Thu, 05 Feb 1998 01:57:26 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: RE: Hashing of CMS signedData objects
Cc: [email-masked]
Sender: [email-masked]

Jim:

Okay, I will leave support for the "old way" out of CMS.

Will these ever be used with the algorithm independent features of CMS?  If
not, we can continue to point to PKCS#7 v1.5 for these legacy items.

Russ

At 04:54 PM 2/2/98 -0800, Jim Schaad (Exchange) wrote:
>I don't see any need to support the ASN for the old way in the current
>CMS spec.  What I want to do is just to document what the old way was
>and give to implementers how verification would be done if they wanted
>to support it.  I don't see any reason to polute the pure CMS spec with
>this.  Putting a reasoning, explication and algorithm in an appendix of
>the CMS document is more than sufficient for me.
>
>I think that the number of people who are going to really want to
>implement this is very small, most people just have either data objects
>or will be using the new version.  I just want to document what is going
>on (if you want to provide alternate ASN thats fine) so that developers
>who run across this old stuff that they cannot tell from the new stuff
>except it does not parse will not die.
>
>jim
>
>
>-----Original Message-----
>From: Russ Housley [mailto:[email-masked]]
>Sent: Sunday, February 01, 1998 11:21 PM
>To: Jim Schaad (Exchange)
>Cc: Ietf-Smime (E-mail)
>Subject: RE: Hashing of CMS signedData objects
>
>
>Jim:
>
>Would this help?
>
>... CHOICE { TheOld Way, TheNewWay }
>
> theOld Way ::= SEQUENCE {
>  contentType ContentType,
>  owContent [0] EXPLICIT ANY DEFINED BY contentType }
>
>theNewWay ::= SEQUENCE {
>  contentType ContentType,
>  nwContent OCTET STRING }
>
>Then, we tell everyone that defines a new content type to follow the New
>Way
>syntax?
>
>I am just brainstorming here.  So, feel free to flame.
>
>Russ
>
>
>At 12:08 AM 1/31/98 +0000, Jim Schaad (Exchange) wrote:
>>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]%5D>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: Thu, 05 Feb 1998 01:35:33 -0500
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: Re: New S/MIME OIDs
Cc: [email-masked]
Sender: [email-masked]

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

Here is the updated OID list.

At 03:10 PM 2/2/98 -0500, John Pawling wrote:
>Paul,
>
>Please add:
>
>id-aa-contentIdentifier       OBJECT IDENTIFIER ::= { id-aa 7 }
>
>to identify the contentIdentifier attribute which is required to fulfill the
>MSP signed content identifier (SCID) requirement.
>
>- John Pawling
> 

= = = = = = = = = =

--=====================_886678533==_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

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

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

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

-- Authenticated and Unauthenticated 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 }
id-aa-encapContentType  OBJECT IDENTIFIER ::= { id-aa 6 }
id-aa-contentIdentifier OBJECT IDENTIFIER ::= { id-aa 7 }

--=====================_886678533==_--

Date: Thu, 5 Feb 1998 11:08:53 -0800
To: "Blake Ramsdell" <[email-masked]>
From: Tim Dierks <[email-masked]>
Subject: Re: Key usage. No, wait, *extended* key usage
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

At 1:04 AM -0800 2/5/98, Blake Ramsdell wrote:
>What to do about extendedKeyUsage?  Do we require that
>id-kp-emailProtection MUST be set if extendedKeyUsage is present,
>otherwise don't use the certificate?  This object identifier seems to
>apply to us.

Based on PKIX, I believe the correct thing to do is to require that
id-kp-emailProtection MUST be set if the extended key usage extension is
marked as critical. If the extension is not marked as critical, the key
purpose values are only advisory, but they are useful for deciding which of
several certificates is the appropriate one for email protection.

 - Tim

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

Date: Thu, 5 Feb 1998 12:24:23 -0500
To: "[email-masked]'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Key usage. No, wait, *extended* key usage
Sender: [email-masked]

Blake,

Thank you for being conscientious about asking the group about the use of
these extensions.  

In an earlier message, I recommended that the S/MIME v3 Cert Handling I-D,
Sec 4.2, 1rst para should be modified as follows:  Please add "as per
[KEYM]" to "Certificate, CRL, and chain validation MUST be performed...".
If this comment is incorporated, then I believe that the S/MIME Cert I-D
doesn't need to discuss the vast majority of the keyUsage checks that you
list in your message because it will refer to the PKIX X.509 Cert and CRL
Profile which provides sufficient info for the implementor to determine
which keyUsage bits need to be checked in most of the situations that you
describe in your message.  

The only keyUsage-related text that I believe is appropriate for inclusion
in the S/MIME Cert Spec is:  "Prior to verifying the signature of an S/MIME
message, if the keyUsage extension is present in the signer's certificate
and is indicated as being critical, then the verifying software MUST ensure
that the nonRepudiation bit is set to 1."

I agree with your suggestion to add wording like:  "Prior to using the
public key included in a certificate to support S/MIME security services, if
the extendedKeyUsage extension is present in the certificate and is
indicated as being critical, then the S/MIME software MUST ensure that the
id-kp-emailProtection OID is present.  This check is only required for the
end-entity certificates."

- John Pawling

Date: Thu, 5 Feb 1998 11:21:45 -0500
To: Russ Housley <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Hashing of CMS signedData objects
Cc: "Jim Schaad (Exchange)" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Sender: [email-masked]

Russ,

I believe that the greatest good for the greatest number of people is
achieved by adopting the San Francisco proposal.  The SF proposal provides a
simple, consistent strategy for hashing the content.  I believe that Jim
agreed with this in his previous msg (enclosed). 

- John

>Return-Path: <[email-masked]>
>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: Mon, 2 Feb 1998 16:54:05 -0800 
>Sender: [email-masked]
>Precedence: bulk
>
>I don't see any need to support the ASN for the old way in the current
>CMS spec.  What I want to do is just to document what the old way was
>and give to implementers how verification would be done if they wanted
>to support it.  I don't see any reason to polute the pure CMS spec with
>this.  Putting a reasoning, explication and algorithm in an appendix of
>the CMS document is more than sufficient for me.
>
>I think that the number of people who are going to really want to
>implement this is very small, most people just have either data objects
>or will be using the new version.  I just want to document what is going
>on (if you want to provide alternate ASN thats fine) so that developers
>who run across this old stuff that they cannot tell from the new stuff
>except it does not parse will not die.
>
>jim
>

At 10:33 PM 2/4/98 -0500, Russ Housley wrote:
>John:
>
>I realize the ramifications.  I am wondering if it is worth the pain to
>support the non-S/MIME implemnattions that previousley used PKCS#7 v1.5 to
>protect arbitrary content types.
>
>Russ
>

Date: Wed, 04 Feb 1998 22:33:26 -0500
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: RE: Hashing of CMS signedData objects
Cc: "Jim Schaad (Exchange)" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Sender: [email-masked]

John:

I realize the ramifications.  I am wondering if it is worth the pain to
support the non-S/MIME implemnattions that previousley used PKCS#7 v1.5 to
protect arbitrary content types.

Russ

At 05:47 PM 2/2/98 -0500, John Pawling wrote:
>Russ,
>
>This leads to the following logic for the receiving agent:
>
>"IF CHOICE == OLD WAY THEN
>
>    IF contentType == id-data THEN hash value field of owContent OCTET STRING
>
>    ELSE hash DER-encoded owContent 
>
>ELSE hash value field of nwContent OCTET STRING"
>
>
>If we went with the proposal in San Francisco (see below), then the content
>is always an OCTET STRING, so the rule is simply: "Always hash value field
>of content OCTET STRING".
>
>
>In summary, 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
>
>
>At 02:20 AM 2/2/98 -0500, Russ Housley wrote:
>>Jim:
>>
>>Would this help?
>>
>>... CHOICE { TheOld Way, TheNewWay }
>>
>> theOld Way ::= SEQUENCE {
>>  contentType ContentType,
>>  owContent [0] EXPLICIT ANY DEFINED BY contentType }
>>
>>theNewWay ::= SEQUENCE {
>>  contentType ContentType,
>>  nwContent OCTET STRING }
>>
>>Then, we tell everyone that defines a new content type to follow the New Way
>>syntax?
>>
>>I am just brainstorming here.  So, feel free to flame.
>>
>>Russ
>>
>>
>>At 12:08 AM 1/31/98 +0000, Jim Schaad (Exchange) wrote:
>>>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]%5D>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.
>>>>
>>>  
>>
> 

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Key usage. No, wait, *extended* key usage
Date: Thu, 5 Feb 1998 01:04:38 -0800
Sender: [email-masked]

Hmm.  From PKIX part 1:

] 4.2.1.14  Extended key usage field
]
] This field indicates one or more purposes for which the certified
] public key may be used, in addition to or in place of the basic
] purposes indicated in the key usage extension field.  This field is
] defined as follows:

Anyone want to take a stab about what action we should take about this
for S/MIME?  This extension is a new one to me...

I should pay more attention in class.

<Grunt, groan.  Putting on my flame retardant suit that seems to have
shrunk.>

I think our cryptographic use of X.509 certificates falls into four
cases.  Someone chime in if there are more:

1. Encrypting a message
2. Verifying a signature for a message
3. Verifying a signature of a certificate
4. Verifying a signature of a CRL

For verifying a signature, the keyUsage extension (if present) MUST have
the nonRepudiation bit set.  No other bit is required to be set for an
S/MIME signature verification certificate, and no other bit needs to be
checked when determining the suitability of a certificate for verifying
an S/MIME signature.

For encrypting a message, the keyUsage extension (if present) MUST have
the keyEncipherment bit set.  No other bit is required to be set for an
S/MIME encrypting certificate, and no other bit needs to be checked when
determining the suitability of a certificate for encrypting an S/MIME
message.

For verifying a signature of a certificate, PKIX part 1 rules apply.  I
presume that this means that exactly the keyCertSign bit must be set,
and no other bit needs to be checked...  You know the drill.

For verifying a signature of a CRL (sorry, cRL), PKIX part 1 rules
apply.  I presume that this means that exactly the cRLSign bit must be
set, and no other bit needs to be checked...  Yadda yadda.  I mean that
sincerely.

What to do about extendedKeyUsage?  Do we require that
id-kp-emailProtection MUST be set if extendedKeyUsage is present,
otherwise don't use the certificate?  This object identifier seems to
apply to us.

Guidance appreciated.

<someone help me out of this suit>

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, 04 Feb 1998 10:01:18 -0500
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: Content Type Attribute Question
Sender: [email-masked]

Russ,

    Sorry about the delayed reply.  Been busy with other lives...

    I guess I'd still rather see an open ended field in the
encapsulatedContentType attribute, but the union of the existing attribute and
contentHints does address much of my concern.  Why do we have two attributes
to describe the encapsulated content rather than one?  If the semantics of
contentHint can be bent as far as MIME content types, then it seems like they
should be the same attribute.

Chris

_________________________

Russ Housley wrote:

> John:
>
> Thanks.  The contentType attribue is defined in CMS, and it already has an
> OID.
>
> I will assign an OID for the encapsulatedContentType attribute.  In fact,
> I'll do it now ... I assigned:
>
>     id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
>             rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
>
>     id-aa   OBJECT IDENTIFIER ::= { id-smime 2 }
>
>     id-aa-encapContentType OBJECT IDENTIFIER ::= { id-aa 6 }
>
> Russ
>
> At 06:42 PM 1/30/98 -0500, John Pawling wrote:
> >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: Tue, 03 Feb 1998 17:15:25 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: 1/28/98 S/MIME V3 Msg Spec Comments
Sender: [email-masked]

At 09:33 AM 2/3/98 -0500, David P. Kemp wrote:

>SHOULD gives developers a guideline, which is better than nothing.=A0 The
>specs contain lots of non-MUST information that nonetheless enhances
>interoperability.
>
>OTOH, if that section is removed, developers will still know by folklore
>what they need to do to achieve interoperability.=A0 I prefer standards
>to be explicit, rather than making developers join the club and learn
>the secret handshake.

I agree fully. However, that's not the case here. Note that the first three
steps have already failed, so the sender didn't include a set of=
 capabilities
and in fact has never sent an encrypted message to the recipient. Saying
"SHOULD use RC2/40" will not guarantee interoperability because lots of
recipients will have clients that don't include RC2/40 due to its weakness.
Looking at the lack of information we have about the recipient at that=
 point,
I'd say any "SHOULD" is overstated.

>The "problems with PKIX" have nothing to do with defining OIDs and
>specifying parameter syntax.

They do: the S/MIME team is waiting for the PKIX specs to finish and don't
know
absolutely what the specs will say.

>Including DH definitions in S/MIME by value
>instead of by reference may be convenient, but you must be absolutely
>sure that you don't introduce inconsistencies.

Precisely why I'm hesitant to do it by value.

>=A0 I think referencing
>PKIX Part 1, when it gets an RFC number, is preferable.

But will possibly delay us unless PKIX part 1 finishes soon. Thus my=
 question
to this group about what we want to do. I'm leaning slightly towards "refer=
 to
PKIX", but want Russ to have other text ready in case of delays, which have=
 so
far appeared quite regularly in the PKIX work.
=20

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 03 Feb 1998 18:58:53 -0500
From: Bill Buffam <[email-masked]>
To: [email-masked]
Subject: CRLs in OriginatorInfo?
Sender: [email-masked]

Can someone explain the rationale for including CRLs in OriginatorInfo
in the EnvelopedData type? Obviously you need the originator's public
key to decrypt a D-H encrypted content key, and the certificate is a
convenient way of sending it. But the CRL? If the certificate has been
revoked (say because the private key was compromised), then an impostor
may have sent you encrypted mail. But so what? You're not going to treat
that as a digital signature - that comes from the SignedData type. We're
talking about a different certificate there.

And surely you're not, in general, going to use the encryption key from
that certificate to send back encrypted mail without checking some more
current version of the CRL than the one you just happened to get the
last time he sent you a message.

-- 

Bill Buffam
Unisys, Malvern PA
[email-masked]

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, <[email-masked]>
Subject: RE: Redundant Cert Mgmt Protocols
Date: Tue, 3 Feb 1998 13:37:03 -0800
Sender: [email-masked]

On Monday, February 02, 1998 3:00 PM, [email-masked]
[SMTP:[email-masked]] wrote:
> This point cannot be stressed strongly enough!  Paul, you are not
> shy about expressing your opinions at IETF meetings.  But other S/MIME
> developers need to send a clear message to our PKI product vendors
> that the lack of a single PKIX standard for PKI management messages
> is getting in the way of business.

I like having multiple certificate request formats.  It keeps me working
to write code for new ones.

Seriously, I am very much behind having a single format that can be
encapsulated and transmitted over an arbitrary channel (for example,
email or HTTP).  I agree with what John Pawling and Jim Schaad have said
in this area.  I have also not been shy about saying that I want only
one standard for this.  It is getting in the way of business.

In any case, I am also for removing any language from the current body
of S/MIME v3 specifications (cert, msg, ess and cms) that has to do with
certificate request formatting, since I have come to the thinking that
this is irrelevant to the task at hand (encapsulation and transmission
of CMS objects using email, or S/MIME).

Harmonize.

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

Date: Tue, 03 Feb 1998 17:30:17 +0000
From: Darren Harter <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Tag type for rfc822name -Reply -Reply
Sender: [email-masked]

>>> Bancroft Scott <[email-masked]> 02/03 4:16 pm >>>
>On Tue, 3 Feb 1998, Darren Harter wrote:
>
>
>> e.g.
>> Test ::= SEQUENCE {
>>  genName [0] IMPLICIT GeneralName OPTIONAL }
>
>This example violates X.680 clause 28.8, (X.208 clause 26.10) which says
>that you cannot use IMPLICIT when tagging a CHOICE type. 
>
>Notice that when CHOICE types and open types are defined as tagged types
>(such as in the example above) they are always explicitly tagged. Further,
>any reference to them must include a tag if the tagging would otherwise be
>ambiguous.  Since in the above example GeneralName, though OPTIONAL,
>cannot be confused with any other type, the [0] tag is not required.

Yes, sorry it was a silly example.  The reason I put that in was to show
that even if an IMPLICIT keyword were accidentally placed with an object
derived from CHOICE, it would be encoded explicitly.

>> The important thing to note in this is that the EXPLCIT for CHOICE rule
>> is not recursive, so the  rfc822Name in GeneralName is NOT explcitly
>> tagged.
>
>I am not sure what is meant by "not recursive", but the conclusion is
>correct.

What I meant by "recursive" is that just because GeneralName is explicitly
encoded doesn't mean that any other tags in subordinate structure will be
explcitly tagged as well.  Hence rfc822 being implicit not explicit.

>> But what does X.208 say?
>
>It says the same thing as X.680,

Good, I ask this ask there are often emails saying things like: "Were using
X.208 not X.680 so that doesn't apply".  I just thought I'd check in this
case as I tend not to use X.208.

Regards,

Darren Harter

p.s. I wonder how long it will be before the Named Bit List encoding queries
surface again? ;-)

Date: Tue, 3 Feb 1998 09:15:49 -0800 (PST)
From: Yahya Al-Salqan <[email-masked]>
Reply-To: Yahya Al-Salqan <[email-masked]>
Subject: Enterprise Security
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Content-MD5: s65u0q6BDLuzuKezUo+VGQ==
Sender: [email-masked]

Dear Colleague,=20

This mail is to direct your attention to the Third International
Workshop on Enterprise Security, to be held on June 17-19, 1998
at Stanford University, California, USA. Deadline for paper=20
submissions is February 27, 1998.=20

Please accept my apologies if you receive this message more than once.

Enclosed is the Call For Papers. Your help in distributing the=20
CFP to interested parties would be greatly appreciated.

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

                           CALL FOR  PAPERS
                          *EXTENSION NOTICE*
                Submission deadline: February 27, 1998

         Third International Workshop on Enterprise Security
                           June 17-19, 1998
                 Stanford University, California, USA

       Sponsored by the IEEE Computer Society and CERC at West
    Virginia University. Hosted by the Center for Design Research,
                         Stanford University.

  This document is also available in HTML and Postscript formats as
           http://www.ida.liu.se/labs/iislab/SECWK/cfp.html
                                and
            http://www.ida.liu.se/labs/iislab/SECWK/cfp.ps

Enterprises are becoming increasingly dependent on their information
systems to support their business and workflow activities.  There is a
need for universal electronic connectivity to support interaction and
cooperation between multiple organizations. This makes enterprise
security and confidentiality more important but at the same time more
difficult to achieve, as the multiple organizations may have
differences in their security policies and may have to interact via an
insecure Internet.

These inter-organizational enterprise systems may be very large,
efficient tools, techniques and methodologies are therefore needed to
support the specification, analysis and implementation of security.
This workshop will focus on the problems and challenges relating to
enterprise security in inter-organizational systems. We aim to bring
together principal players from both the internetwork and the
enterprise security community and will provide plenty of time for
discussion.

Topics to be discussed include:
-------------------------------
Internet security:
* Security protocols for the Internet
* The work and efforts of IETF security groups
* Global key infrastructures

Distribution:
* Distributed database security
* Secure transactions
* Inter- and intra-organizational security
* Security of collaborative applications

Secure infrastructures:
* Secure applications and environments
* Object-oriented and CORBA Security
* Secure enterprise infrastructures
* Security algorithms
* Public key infrastructures

Security management:
* Role-based access control
* Enterprise security policies
* Security in workflow processes

The program committee welcomes both papers and panel proposals
covering these topics. =20

SUBMISSIONS
-----------

Authors should submit six copies of an original paper (not submitted
or published elsewhere) to one of the Program Co-Chairs. Electronic
submissions are also accepted via the World Wide Web. Instructions
and forms are availabe at http://iispc2.ida.liu.se/SECWK/ .

Submissions should include the title of the paper, the name and
affiliation of each author, a 150-word abstract, and no more than 8
keywords. Submissions should not exceed 3000 words in length.  The
name, position, address, telephone number, and if possible, fax number
and e-mail address of the author responsible for correspondence must
be included.

A representative selection of accepted papers will published in the
workshop post-proceedings. Papers accepted for publication in the
proceedings are limited to six pages (about 2000-2500 words) in IEEE
format (two columns, single spaced, 10pt Times). Authors are strongly
encouraged to adhere to this format also when submitting
papers. Detailed information on the IEEE format (together with some
templates) is available at http://www.computer.org/cspress/instruct.htm=20

PANEL PROPOSALS
---------------

Send six copies of panel proposals to the Program Chair. Include a
title, a 150-word scope statement, proposed session chair and
panelists and their affiliations, the organizer's affiliation,
address, telephone and fax number, and e-mail address.

GENERAL CHAIR
-------------

Yahya Al-Salqan
Sun Microsystems
901 San Antonio Rd
Palo Alto, CA 94303
USA
E-mail: [email-masked]

PROGRAM CO-CHAIRS
-----------------

Nahid Shahmehri
Dept. of Computer Science
Link=F6ping University
S-581 83 Link=F6ping
SWEDEN
E-mail: [email-masked]

Douglas Maughan
National Security Agency, R23
9800 Savage Rd.
Ft. Meade, Maryland 20755-6000
USA
E-mail: [email-masked]

WORKSHOP PROGRAM COMMITTEE
--------------------------

Takashi Arno, NTT Corp., Japan
William Cheng-Chung Chu, Feng Chia University, Taiwan
Barbara Davis, Applied Knowledge Group, USA
Mourad Debbabi, Laval University, Canada
Germano Caronni, Computer Engineering and Networks Laboratory,=20
                 ETH-Zentrum, Switzerland
Dima Hamad, Birzeit University, West Bank
Takeo Hamada, Fujitsu, USA
Adel Jaber, Certicom, USA
Takuro Kubo, NTT America Multimedia Communications Lab, USA
Steve Lloyd, Entrust Technologies, Canada
Jeff Parrett, PeopleSoft, USA
Lisa Pretty, Certicom, Canada
Sumitra Reddy, West Virginia University, USA
Vipin Samar, Oracle, USA
Bill Soley, Sun Microsystems, USA
Robert Thomys, BSI (Federal Department of Security in=20
               Information Technology), Germany
Bradley Wood, Sandia National Lab, USA
Felix Wu, North Carolina State University, USA
Qun Zhong, HP, UK
Tatu Yl=F6nen, SSH Communications Security, Finland
Randy Chow, University of Florida, USA

IMPORTANT DATES
---------------

Papers and panel proposals due  February 27, 1998
Authors notified of acceptance  April 6, 1998
Advance Registration            May 17, 1998
Workshop                        June 17-19, 1998
Camera ready manuscripts due    June 30, 1998

INQUIRIES
--------- =20

Pleas send all inquiries regarding this workshop to the General=20
Chair or to one of the co-chairs.

For inquires regarding WET ICE in general, contact=20
[email-masked] or call (U.S.) +1-304-293-7226.

Date: Tue, 03 Feb 1998 09:05:13 -0800
To: <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Redundant Cert Mgmt Protocols
Sender: [email-masked]

At 09:58 PM 2/2/98 -0700, Michael Myers wrote:
>The agreement reached in D.C. clearly pointed to CRS, as documented in the
>minutes.  No objections were raised to the point.

<flame>
It was also agreed that CRS would come out before January 1, and that it would
fully specify what we needed to use in S/MIME v3, and it would be the work of
the PKIX WG, so we could either point directly to it or make a simple profile
of it. Two months later, we haven't seen a single usable draft, and there is
still rampant disagreement among the people working on the solution. Consider
this an objection based on new information.
</flame>

>We further discussed
>details of this task in San Francisco.  Again, no objections were raised on
>the point.

I think most of the people in the room in San Francisco would have taken my
very pointed comments to you about the lateness and incompleteness of CRMF to
be an objection. Certainly, no one accused me of being overly polite to you
about the situation. :-) If you didn't hear my comments as an objection,
let me
try again: I object to S/MIME v3 being possibly delayed waiting for a spec
that
is months late and is mired in political squabbling that all sides agree has
little technical justification and seems to mostly be about installed base
instead of what's best for applications like S/MIME.

If CRS/CRMF/whatever was needed for our protocol, we'd be stuck waiting for an
IETF solution. Fortunately (and I give John Pawling original credit here),
many
of us have realized that we don't need to specify how to do PKI in S/MIME, so
we can cleanly remove this from S/MIME and let the PKIX group take however
long
it wants to specify.

So much for my winning Miss Congeniality this year...

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 3 Feb 1998 11:16:32 -0500 (EST)
From: Bancroft Scott <[email-masked]>
Reply-To: Bancroft Scott <[email-masked]>
To: Darren Harter <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Tag type for rfc822name -Reply
Sender: [email-masked]

On Tue, 3 Feb 1998, Darren Harter wrote:

> >Response B:
> >
> >That is an example of where the "gotcha" rule on IMPLICIT tagging
> >applies :-)
> >
> >X.680 section 28.6:
> >
> >  The tagging construction specifies explict tagging if any of the
> >  following holds:
> >    a) ..
> >    b) ..
> >    c) the "Tag Type" alternative is used an the value of TagDefault for
> >       the module is "IMPLICIT TAGS" or "AUTOMATIC TAGS", but the type
> >       defined by "Type" is a choice type, open type, or a
> >DummyReference.
> >so even in an IMPLICIT TAGS module, GeneralName (a CHOICE) is encoded
> >using explicit tagging, as shown in the PKIX-1 example.
> 
> GeneralName is not explicitly tagged unless it is used within another
> structure and is optional in its usage (i.e. if it is OPTIONAL, a CHOICE
> element, or a SET element).

Right.  

> e.g.
> Test ::= SEQUENCE {
>  genName [0] IMPLICIT GeneralName OPTIONAL }

This example violates X.680 clause 28.8, (X.208 clause 26.10) which says
that you cannot use IMPLICIT when tagging a CHOICE type. 

Notice that when CHOICE types and open types are defined as tagged types
(such as in the example above) they are always explicitly tagged. Further,
any reference to them must include a tag if the tagging would otherwise be
ambiguous.  Since in the above example GeneralName, though OPTIONAL,
cannot be confused with any other type, the [0] tag is not required.
 
> The important thing to note in this is that the EXPLCIT for CHOICE rule
> is not recursive, so the  rfc822Name in GeneralName is NOT explcitly
> tagged.

I am not sure what is meant by "not recursive", but the conclusion is
correct.
 
> But what does X.208 say?

It says the same thing as X.680,

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

Date: Tue, 3 Feb 1998 10:44:41 -0500 (EST)
From: Bancroft Scott <[email-masked]>
Reply-To: Bancroft Scott <[email-masked]>
To: Nilsson Hans <[email-masked]>
Cc: [email-masked], "[email-masked]'" <[email-masked]>
Subject: Re: Tag type for rfc822name
Sender: [email-masked]

On Tue, 3 Feb 1998, Nilsson Hans wrote:

> I am editing the revision a certificate specification for the national
> Swedish Electronic Identity Card (see www.seis.se), to harmonize it with
> the certificate specifications of PKIX-1 and S/MIME. I am also going to
> include examples of DER-coded certificates. In that context I have come
> across different ways of encoding the subjectAltName rfc822Name
> extension. The question is: Should it use IMPLICIT or EXPLICIT tags?
> Below are two extracts from PKIX-1, which uses IMLICIT in one example
> and EXPLICIT in another. 
> 
> [...]
> 
> Response A:
> The Certificate Extensions module uses specifies IMPLICIT tags
> ('DEFINITIONS IMPLICIT TAGS ::= BEGIN ...).  Hence, IMPLICIT tags must
> be used for selecting the 'rfc822Name' (e-mail) choice in the
> 'subjectAltName' extension.

Correct, for the PKIX1 module is defined with IMPLICIT TAGS and
'rfc822Name' is neither an open type nor a CHOICE type.
 
> Response B:
> 
> That is an example of where the "gotcha" rule on IMPLICIT tagging
> applies :-)
> 
> X.680 section 28.6:
> 
>   The tagging construction specifies explict tagging if any of the
>   following holds:
>     a) ..
>     b) ..
>     c) the "Tag Type" alternative is used an the value of TagDefault for
>        the module is "IMPLICIT TAGS" or "AUTOMATIC TAGS", but the type
>        defined by "Type" is a choice type, open type, or a
> DummyReference.
> so even in an IMPLICIT TAGS module, GeneralName (a CHOICE) is encoded
> using explicit tagging, as shown in the PKIX-1 example.

The quote from X.680 is correct, but the conclusion drawn is incorrect
because GeneralName is nowhere used in PKIX1 as a tagged type (You can't
explicitly or implicitly tag a type unless it is a tagged type.) 

In other words, you will notice that in PKIX1 GeneralName is never
referenced as a tagged type, as opposed to GeneralNames which is often
referenced as a tagged type.  Thus, in PKIX1 GeneralName should under no
circumstance be encoded using explicit tagging. 
 
> Response C:
> In the definition of GeneralName we have
> rfc822Name		[1]	IA5String,
> directoryName		[4]	Name,
> 
> And from X.680:
> >     c) the "Tag Type" alternative is used an the value of TagDefault
> for
> >        the module is "IMPLICIT TAGS" or "AUTOMATIC TAGS", but the type
> >        defined by "Type" is a choice type, open type, or a
> DummyReference.
> With rfc822name, the Type is IAString, which means that IMPLICIT should
> be used
> BUT for directoryName the Type is Name, which is a CHOICE, which means
> that EXPLICIT should be used.

This too is correct!

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

Date: Tue, 3 Feb 1998 10:12:33 -0500
To: "Michael Myers" <[email-masked]>, "SMIME -IETF" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Redundant Cert Mgmt Protocols
Sender: [email-masked]

Mike,

The Dec 97 S/MIME WG decided that the certificate management protocol work
should be performed by the PKIX WG.  Specifically, the S/MIME WG decided
that the CRS work should stay in the PKIX WG.  The S/MIME WG rejected the
inclusion of CRS in the S/MIME WG charter.  The 1/28/98 S/MIME v3 Cert Spec
includes a big chunk of the CRS spec (specifically, the Service Indicators
and degenerate signedData).  This is a clear contradiction of the Dec 97
S/MIME WG's decisions.

The Dec 97 S/MIME WG decided that the PKIX WG should define the
IETF-standard, application-independent cert mgmt protocol.  The S/MIME WG
should simply define how those cert mgmt objects are protected in CMS
objects and how the resultant CMS objects are transported via MIME.  The
S/MIME WG should not be defining a redundant cert mgmt protocol.  By
defining the use of Service Indicators in the certificate request and the
use of degenerate signedData for the certificate response, the 1/28/98
S/MIME v3 Cert Spec does indeed define a redundant protocol to the PKIX CMP.

In summary, I believe that once the "harmonized" IETF standard protocols are
completed, then a separate S/MIME WG spec should be drafted which specifies
the use of MIME to communicate CMS-protected "harmonized" cert mgmt protocol
objects as a "MUST implement".  At that point, the new spec could also
define how to transport PKCS #10 objects as a "MAY implement" for the
purposes of backward conpatability with v2 S/MIME MUAs.  

- John Pawling

At 09:58 PM 2/2/98 -0700, Michael Myers wrote:
>John,
>
>The agreement reached in D.C. clearly pointed to CRS, as documented in the
>minutes.  No objections were raised to the point.  We further discussed
>details of this task in San Francisco.  Again, no objections were raised on
>the point.
>
>Mike
>
>
>-----Original Message-----
>From: John Pawling <[email-masked]>
>To: [email-masked] <[email-masked]>
>Date: Monday, February 02, 1998 12:39 PM
>Subject: Re: Redundant Cert Mgmt Protocols
>
>
>>All,
>>
>>I agree with Paul.  His statements are consistent with my position.
>>
>>- John Pawling
>>
>>
>>
>
>
>

Date: Tue, 3 Feb 1998 10:02:08 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked], [email-masked]
Subject: Re: Tag type for rfc822name
Sender: [email-masked]

> From: Nilsson Hans <[email-masked]>

> The question is: Should it use IMPLICIT or EXPLICIT tags?
> Below are two extracts from PKIX-1, which uses IMLICIT in one example
> and EXPLICIT in another. 
> 
> Which way has it been implemented in existing S/MIME products? Can they
> handle both IMPLICIT and EXPLICIT coding of rfc822Name?

There can be only one correct encoding, otherwise DER would not be unique.

> Here are the examples from PKIX-1:
> ------------------------ IMPLICIT TAG:
> ------------------------------------------
> 0606 a3 1d         29: . . [3]
> 0608 30 1b         27: . . . SEQUENCE
> 0610 30 19         25: . . . . SEQUENCE
> 0612 06 03          3: . . . . . OID 2.5.29.17: subjectAltName
> 0617 04 12         18: . . . . . OCTET STRING
>                      : 30 10 81 0e 77 70 6f 6c 6b 40 6e 69 73 74 2e 67
>                      : 6f 76
> 
> 0000 30 10         16: SEQUENCE
> 0002 81 0e         14: . [1]
>                      : 77 70 6f 6c 6b 40 6e 69 73 74 2e 67 6f 76
> Note: This subjectAltName data is IMPLICIT TAGS - is that correct? (this
> note is taken from PKIX-1!)

When I wrote that note in PKIX-1, I intended to call attention to the
fact that there appeared to be an error in the software that generated
that example.  I wasn't confident enough to phrase it as a definite
statement that THIS EXAMPLE IS WRONG, but intended to warn developers
that there might be a problem.

I am confident now that GeneralName must be encoded using EXPLICIT TAGS,
and that the above example is indeed incorrect.  

> I have consulted different experts and of course received different
> reponses:
> 
> Response A:
>     [must be IMPLICIT]
>
> Response B:
>     [must be EXPLICIT]
> 
> Response C:
>     [rfc822Name is IMPLICIT but directoryName is EXPLICIT]

Wow, that response C is really creative!  I like it :-).

But I still hope that ASN.1 experts will step forward to confirm that
Response B is the correct one.

Date: Tue, 3 Feb 1998 09:42:29 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: 1/28/98 S/MIME V3 Msg Spec Comments
Sender: [email-masked]

Paul,

I believe that Russ is planning to write an appendix to CMS regarding the
gory details of using D-H with CMS.  Recoomend that the D-H OID should be
documented in that appendix.  I don't believe that it needs to be included
in the S/MIME v3 Msg Spec.  It could be listed in the S/MIME OIDs document
with a comment referring to the CMS D-H appendix that Russ will be writing.

- John

>>8) Sec H: "Need OIDs for DH":=A0 PKIX X.509 Certificate and CRL Profile,=
 sec
>>7.3.2 defines the use of the ANSI X9.42=A0=A0=A0=A0=A0=A0=A0=
 dhpublicnumber OBJECT
>>IDENTIFIER ::=3D { iso(1) member-body(2) us(840) ansi-x942(10046)
>>number-type(2) 1 } for DH keys in X.509 certs.=A0 Can we use that OID for=
 CMS?
>
>We can either refer to PKIX, or Russ can add this to the CMS spec and I can
>add
>it to the OIDs page. I prefer the latter, due to the problems we're having
>with
>PKIX. What do others want?
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
>

Date: Tue, 3 Feb 1998 09:33:30 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: 1/28/98 S/MIME V3 Msg Spec Comments
Sender: [email-masked]

> From: Paul Hoffman / IMC <[email-masked]>
> 
> At 04:48 PM 2/2/98 -0500, John Pawling wrote:
>   
> >3) Sec 2.6.2.4.  Please change "MUST use RC2/40" to "SHOULD use RC2/40".
> 
> Actually, section 2.6.2.4 should simply be removed. You can't guarantee no
> failed decryption with a SHOULD.

SHOULD gives developers a guideline, which is better than nothing.  The
specs contain lots of non-MUST information that nonetheless enhances
interoperability.

OTOH, if that section is removed, developers will still know by folklore
what they need to do to achieve interoperability.  I prefer standards
to be explicit, rather than making developers join the club and learn
the secret handshake.

> >8) Sec H: "Need OIDs for DH":  PKIX X.509 Certificate and CRL Profile, sec
> >7.3.2 defines the use of the ANSI X9.42        dhpublicnumber OBJECT
> >IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x942(10046)
> >number-type(2) 1 } for DH keys in X.509 certs.  Can we use that OID for CMS?
> 
> We can either refer to PKIX, or Russ can add this to the CMS spec and I can
> add
> it to the OIDs page. I prefer the latter, due to the problems we're having
> with
> PKIX. What do others want?

The "problems with PKIX" have nothing to do with defining OIDs and
specifying parameter syntax.  Including DH definitions in S/MIME by value
instead of by reference may be convenient, but you must be absolutely
sure that you don't introduce inconsistencies.  I think referencing
PKIX Part 1, when it gets an RFC number, is preferable.

Date: Tue, 03 Feb 1998 12:37:47 +0000
From: Darren Harter <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Tag type for rfc822name -Reply
Sender: [email-masked]

>>> Nilsson Hans <[email-masked]> 02/03 10:49 am >>>

snipped...

> ---------------------------------------------------------------
>I have consulted different experts and of course received different
>reponses:
>
>Response A:
>The Certificate Extensions module uses specifies IMPLICIT tags
>('DEFINITIONS IMPLICIT TAGS ::= BEGIN ...).  Hence, IMPLICIT tags must
>be used for selecting the 'rfc822Name' (e-mail) choice in the
>'subjectAltName' extension.

Correct.

>Response B:
>
>That is an example of where the "gotcha" rule on IMPLICIT tagging
>applies :-)
>
>X.680 section 28.6:
>
>  The tagging construction specifies explict tagging if any of the
>  following holds:
>    a) ..
>    b) ..
>    c) the "Tag Type" alternative is used an the value of TagDefault for
>       the module is "IMPLICIT TAGS" or "AUTOMATIC TAGS", but the type
>       defined by "Type" is a choice type, open type, or a
>DummyReference.
>so even in an IMPLICIT TAGS module, GeneralName (a CHOICE) is encoded
>using explicit tagging, as shown in the PKIX-1 example.

GeneralName is not explicitly tagged unless it is used within another
structure and is optional in its usage (i.e. if it is OPTIONAL, a CHOICE
element, or a SET element).
e.g.

Test ::= SEQUENCE {
 genName [0] IMPLICIT GeneralName OPTIONAL }

would be encoded EXPLICITLY as 30 06 A0 04 A4 02 30 00 ... if an "empty"
Name was chosen in the GeneralName. Note the Name is EXPLCITLY tagged also.

The important thing to note in this is that the EXPLCIT for CHOICE rule
is not recursive, so the  rfc822Name in GeneralName is NOT explcitly
tagged.

But what does X.208 say?

>Response C:
>In the definition of GeneralName we have
>rfc822Name  [1] IA5String,
>directoryName  [4] Name,
>
>And from X.680:
>     c) the "Tag Type" alternative is used an the value of TagDefault
for
>        the module is "IMPLICIT TAGS" or "AUTOMATIC TAGS", but the type
>        defined by "Type" is a choice type, open type, or a
>DummyReference.
>With rfc822name, the Type is IAString, which means that IMPLICIT should
>be used
>BUT for directoryName the Type is Name, which is a CHOICE, which means
>that EXPLICIT should be used.

Correct, as I have just described.

>------------------------------------------------------------------------
>------------------------------------
>Looking forward to your help!
>
>Hans Nilsson
>AU-System
>Stockholm, Sweden

Hope this helps...

Darren Harter

From: Nilsson Hans <[email-masked]>
To: [email-masked], "[email-masked]'" <[email-masked]>
Subject: Tag type for rfc822name
Date: Tue, 3 Feb 1998 11:49:21 +0100
Sender: [email-masked]

I am editing the revision a certificate specification for the national
Swedish Electronic Identity Card (see www.seis.se), to harmonize it with
the certificate specifications of PKIX-1 and S/MIME. I am also going to
include examples of DER-coded certificates. In that context I have come
across different ways of encoding the subjectAltName rfc822Name
extension. The question is: Should it use IMPLICIT or EXPLICIT tags?
Below are two extracts from PKIX-1, which uses IMLICIT in one example
and EXPLICIT in another. 

Which way has it been implemented in existing S/MIME products? Can they
handle both IMPLICIT and EXPLICIT coding of rfc822Name?

Here are the examples from PKIX-1:
------------------------ IMPLICIT TAG:
------------------------------------------
0606 a3 1d         29: . . [3]
0608 30 1b         27: . . . SEQUENCE
0610 30 19         25: . . . . SEQUENCE
0612 06 03          3: . . . . . OID 2.5.29.17: subjectAltName
0617 04 12         18: . . . . . OCTET STRING
                     : 30 10 81 0e 77 70 6f 6c 6b 40 6e 69 73 74 2e 67
                     : 6f 76

0000 30 10         16: SEQUENCE
0002 81 0e         14: . [1]
                     : 77 70 6f 6c 6b 40 6e 69 73 74 2e 67 6f 76
Note: This subjectAltName data is IMPLICIT TAGS - is that correct? (this
note is taken from PKIX-1!)
-----------------------EXPLICIT TAG:
----------------------------------------------------
               30 3d
                  id-ce-subjectAltName = { 2 5 29 17 }
                  06 03 55 1d 11
                  by default, critical = FALSE
                  octet string
                  04 36
                     30 34
                        rfc822name
                        a1 1a
                           IA5String "[email-masked]"
                           16 18 65 73 63 65 72 74 2d 75 70 63 40 65 73
63
                           65 72 74 2e 75 70 63 2e 65 73
 ---------------------------------------------------------------
I have consulted different experts and of course received different
reponses:

Response A:
The Certificate Extensions module uses specifies IMPLICIT tags
('DEFINITIONS IMPLICIT TAGS ::= BEGIN ...).  Hence, IMPLICIT tags must
be used for selecting the 'rfc822Name' (e-mail) choice in the
'subjectAltName' extension.

Response B:

That is an example of where the "gotcha" rule on IMPLICIT tagging
applies :-)

X.680 section 28.6:

  The tagging construction specifies explict tagging if any of the
  following holds:
    a) ..
    b) ..
    c) the "Tag Type" alternative is used an the value of TagDefault for
       the module is "IMPLICIT TAGS" or "AUTOMATIC TAGS", but the type
       defined by "Type" is a choice type, open type, or a
DummyReference.
so even in an IMPLICIT TAGS module, GeneralName (a CHOICE) is encoded
using explicit tagging, as shown in the PKIX-1 example.

Response C:
In the definition of GeneralName we have
rfc822Name		[1]	IA5String,
directoryName		[4]	Name,

And from X.680:
>     c) the "Tag Type" alternative is used an the value of TagDefault
for
>        the module is "IMPLICIT TAGS" or "AUTOMATIC TAGS", but the type
>        defined by "Type" is a choice type, open type, or a
DummyReference.
With rfc822name, the Type is IAString, which means that IMPLICIT should
be used
BUT for directoryName the Type is Name, which is a CHOICE, which means
that EXPLICIT should be used.
------------------------------------------------------------------------
------------------------------------
Looking forward to your help!

Hans Nilsson
AU-System
Stockholm, Sweden

From: "Michael Myers" <[email-masked]>
To: "John Pawling" <[email-masked]>, "SMIME -IETF" <[email-masked]>
Subject: Re: Redundant Cert Mgmt Protocols
Date: Mon, 2 Feb 1998 21:58:50 -0700
Sender: [email-masked]

John,

The agreement reached in D.C. clearly pointed to CRS, as documented in the
minutes.  No objections were raised to the point.  We further discussed
details of this task in San Francisco.  Again, no objections were raised on
the point.

Mike

-----Original Message-----
From: John Pawling <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Monday, February 02, 1998 12:39 PM
Subject: Re: Redundant Cert Mgmt Protocols

>All,
>
>I agree with Paul.  His statements are consistent with my position.
>
>- John Pawling
>
>
>

Date: Mon, 02 Feb 1998 16:58:17 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Redundant Cert Mgmt Protocols
Sender: [email-masked]

>> Unfortunately, PKIX part 3, which specifies how to do these actions, i=
s
>> still not around, and I suspect it is many months off due to political
>> hassles in the PKIX WG. The CMP/CRS/CRMF debates seem like so much
>> posturing, given that all parties agree that the other parties have no=
 or
>> few technical problems.
>
>I sincerely hope that this assessment turns out to be pessimistic.

Me too! I thought we had made progress at the DC meeting and came away
hopeful.
I have much less now.

>=A0 We
>(with PKIX hat on here) are working seriously to produce a harmonized
>Certificate Request Message Format (CRMF) document and a companion
>Certificate Management Message Formats (CMMF) document which will
>enable all current CMP and CRS functionality using a common set of PKI
>messages.

This is the first I've heard of CMMF, and I talked to many of the documen=
t
authors last week. I was told by three different people the best we would=
 get
soon was a standardized certificate request without a standardized respon=
se.
You can imagine the tone of my laugh when I heard that.

>We had set an internal deadline of Dec 31 to have a proposal ready
>for presentation to the full PKIX WG, and obviously failed to meet
>that target.=A0 I do still have hope that the proposal (CRMF, CMMF and
>CMP) will be ready for last call within a matter of weeks, not months.
>The CMS-based protection framework should follow sometime thereafter.

This leaves us with three choices:
- mandating the non-CMS framework
- waiting for the CMS framework
- choosing not to do PKI at all
I've been advocating the third one both because I don't believe we'll see
something soon, and because I believe we don't need to specify the PKI in
S/MIME. It's orthogonal to end-to-end secure messaging.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 02 Feb 1998 16:48:05 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: 1/28/98 S/MIME V3 Msg Spec Comments
Sender: [email-masked]

At 04:48 PM 2/2/98 -0500, John Pawling wrote:
>1) Sec 1.1, 2nd para, and Sec 3.7:=20

As we have both agreed, I propose that we just take out all this kruft an=
d say
"You're expected to have a cert. If you need to get one, S/MIME v2 did it=
 this
way and PKIX will do it a different way and you have to agree with your C=
A
about how you will do it with them." Again, I don't think we need to spec=
ify
this in S/MIME since it's not part of end-to-end security.
=A0=20
>3) Sec 2.6.2.4.=A0 Please change "MUST use RC2/40" to "SHOULD use RC2/40=
".

Actually, section 2.6.2.4 should simply be removed. You can't guarantee n=
o
failed decryption with a SHOULD.

Related to this, the paragraph at the beginning of 2.6 should have "Sendi=
ng
and
receiving..." at the beginning of each of the sentences. The "Receiving" =
only
is an artifact from our wigglywaggling in S/MIME v2.

>8) Sec H: "Need OIDs for DH":=A0 PKIX X.509 Certificate and CRL Profile,=
 sec
>7.3.2 defines the use of the ANSI X9.42=A0=A0=A0=A0=A0=A0=A0 dhpublicnum=
ber OBJECT
>IDENTIFIER ::=3D { iso(1) member-body(2) us(840) ansi-x942(10046)
>number-type(2) 1 } for DH keys in X.509 certs.=A0 Can we use that OID fo=
r CMS?

We can either refer to PKIX, or Russ can add this to the CMS spec and I c=
an
add
it to the OIDs page. I prefer the latter, due to the problems we're havin=
g
with
PKIX. What do others want?

--Paul Hoffman, Director
--Internet Mail Consortium

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: Mon, 2 Feb 1998 16:54:05 -0800 
Sender: [email-masked]

I don't see any need to support the ASN for the old way in the current
CMS spec.  What I want to do is just to document what the old way was
and give to implementers how verification would be done if they wanted
to support it.  I don't see any reason to polute the pure CMS spec with
this.  Putting a reasoning, explication and algorithm in an appendix of
the CMS document is more than sufficient for me.

I think that the number of people who are going to really want to
implement this is very small, most people just have either data objects
or will be using the new version.  I just want to document what is =
going
on (if you want to provide alternate ASN thats fine) so that developers
who run across this old stuff that they cannot tell from the new stuff
except it does not parse will not die.

jim

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Sunday, February 01, 1998 11:21 PM
To: Jim Schaad (Exchange)
Cc: Ietf-Smime (E-mail)
Subject: RE: Hashing of CMS signedData objects

Jim:

Would this help?

... CHOICE { TheOld Way, TheNewWay }

 theOld Way ::=3D SEQUENCE {
  contentType ContentType,
  owContent [0] EXPLICIT ANY DEFINED BY contentType }

theNewWay ::=3D SEQUENCE {
  contentType ContentType,
  nwContent OCTET STRING }

Then, we tell everyone that defines a new content type to follow the =
New
Way
syntax?

I am just brainstorming here.  So, feel free to flame.

Russ

At 12:08 AM 1/31/98 +0000, Jim Schaad (Exchange) wrote:
>Yes all of the objects have their own OIDs so that they are
>recognizable.=A0 I would not however wish to enumerate the list and
>special case in that way.
>
>jim
>
>
>-----Original Message-----
>From: Russ Housley
[<mailto:[email-masked]%5D>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.=A0 Do these objects have their own OIDs?=A0 =
If so,
>there may be a straightforward way to support them.=20
>
>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.=A0 At the time I said that I know of none.=A0 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.=A0 Thus I
>>propose the following:
>>
>>We add an appendix to the CMS draft to explain the following items:
>>1.=A0 The difference and reasons for the change in the way that the =
data
>>is encoded.
>>2.=A0 A general way of doing recognition of the two different ways of
>>encoding and how to correctly verify each way
>>3.=A0 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.=A0=20
>>-=A0 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.=A0 The data actually hashed is then
returned
>>as the data block of signedData object.
>>-=A0 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.
>>
> =20

Date: Mon, 02 Feb 1998 18:35:59 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: Russ Housley <[email-masked]>
CC: Blake Ramsdell <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Hashing of CMS signedData objects
Sender: [email-masked]

Russ Housley wrote:

> Phil:
>
> SET uses PKCS#7 v1.6.  S/MIME v2 uses PKCS#7 v1.5.  CMS is derived from
> PKCS#7 v1.5.
>

SET started from the same standards document as S/MIME,the v1.5 version.
Before the SETv1.0 spec was delivered,
RSA agreed to publish a document on PKCSv1.6 so that SET
would have a reference to the (SET OF to SEQUENCE OF)
changes we made, and to allow current v1.5 users a clear
path for migrating from ASN.1:1990 to 1994.

The ASN.1 provided in PKCS #7v1.6 defines both v1.5
and v1.6. It can be easily converted into two distinct
modules, both ASN.1:1994. One module can include
definitions that only support v1.5, and the other v1.6.
This is explicitly allowed in the RSA document. Since
SET chose only to support v1.6, the SET ASN.1 definitions
for v1.5 were not included in that spec.

Both v1.5 and v1.6 default to EXPLICIT tags (though this
is never mentioned in the 1.5 docs, but RSA never really
defined an ASN.1 module until the 1.6 revision was done.

The RSA document states:

"The revision is also intended to “close” the version
1.x series, providing a stable base during development
of the version 2.0 specification and any applications
based on it. We consider that the introduction of PKCS
#7 version 1.6, rather than introducing further
incompatibilities, will stabilize a number of
potentially divergent alternatives and extensions,
thereby increasing interoperability"

> PKCS#7 v1.5 and v1.6 are quite different from an encoding point of view.
>

Yes, v1.6 replaces all SET OFs with SEQUENCE OFs, such
as for Attributes,CRLs, and Certificates, to avoid the
sorting penalty for these types required by DER. So, x31s
change to x30s. But a bigger change was made in regards
to the stripping of tag and length octets.

However, if a specification were to opt to use only
the v1.5 portion of these RSA definitions, it could
easily migrate to ASN.1 1994, yet still rely on the
traditional RSA documents. I just noticed that some
of this effort in providing both v1.5 and v1.6 syntax
in the same module was taken for the benefit of S/MIME
(predating the current work, though)

The RSA Extensions document states:

"Version 1.5 and version 1.6 syntax are distinguished by
a version number field, and the versions should be
considered alternate forms of cryptographic message
protection. Applications supporting either version may
be considered to conform with PKCS #7. Existing
applications based on version 1.5, such as S/MIME,
need not be upgraded to version 1.6. Likewise, version
1.6 applications need not support version 1.5 syntax."

Actually placing both versions (1.5,1.6) in the ASN.1
module was do to Burt Kaliski's wisdom. I recall that
I had only desired to have the SET v1.6 defined. RSA
decided to use the effort to provide a version of 1.5
in ASN.1 1994, since X.208 is slated to eventually loose
its status as a standard. At any rate, it is possible to
do PKCS #7 v1.5 and ASN.1:1994 at the same time.

> Russ
>
> At 11:08 PM 1/30/98 +0000, Phillip H. Griffin wrote:
> >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
> >------------------------------------------------------------

Date: Mon, 2 Feb 1998 18:00:26 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Redundant Cert Mgmt Protocols
Sender: [email-masked]

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

> I think that the S/MIME spec should simply get out of the PKI business.

I agree completely.

> Unfortunately, PKIX part 3, which specifies how to do these actions, is
> still not around, and I suspect it is many months off due to political
> hassles in the PKIX WG. The CMP/CRS/CRMF debates seem like so much
> posturing, given that all parties agree that the other parties have no or
> few technical problems.

I sincerely hope that this assessment turns out to be pessimistic.  We
(with PKIX hat on here) are working seriously to produce a harmonized
Certificate Request Message Format (CRMF) document and a companion
Certificate Management Message Formats (CMMF) document which will
enable all current CMP and CRS functionality using a common set of PKI
messages.  The identical message set will be protected and transported
using either PKIX-3 (CMP) or CMS, depending on the application.

We had set an internal deadline of Dec 31 to have a proposal ready
for presentation to the full PKIX WG, and obviously failed to meet
that target.  I do still have hope that the proposal (CRMF, CMMF and
CMP) will be ready for last call within a matter of weeks, not months.
The CMS-based protection framework should follow sometime thereafter.

> However, they are absolutely getting in the way of S/MIME.

This point cannot be stressed strongly enough!  Paul, you are not
shy about expressing your opinions at IETF meetings.  But other S/MIME
developers need to send a clear message to our PKI product vendors
that the lack of a single PKIX standard for PKI management messages
is getting in the way of business.

Date: Mon, 2 Feb 1998 17:47:35 -0500
To: Russ Housley <[email-masked]>, "Jim Schaad (Exchange)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Hashing of CMS signedData objects
Cc: "Ietf-Smime (E-mail)" <[email-masked]>
Sender: [email-masked]

Russ,

This leads to the following logic for the receiving agent:

"IF CHOICE =3D=3D OLD WAY THEN

    IF contentType =3D=3D id-data THEN hash value field of owContent OCTET=
 STRING

    ELSE hash DER-encoded owContent=20

ELSE hash value field of nwContent OCTET STRING"

If we went with the proposal in San Francisco (see below), then the content
is always an OCTET STRING, so the rule is simply: "Always hash value field
of content OCTET STRING".

In summary, 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 ::=3D  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

At 02:20 AM 2/2/98 -0500, Russ Housley wrote:
>Jim:
>
>Would this help?
>
>... CHOICE { TheOld Way, TheNewWay }
>
> theOld Way ::=3D SEQUENCE {
>  contentType ContentType,
>  owContent [0] EXPLICIT ANY DEFINED BY contentType }
>
>theNewWay ::=3D SEQUENCE {
>  contentType ContentType,
>  nwContent OCTET STRING }
>
>Then, we tell everyone that defines a new content type to follow the New=
 Way
>syntax?
>
>I am just brainstorming here.  So, feel free to flame.
>
>Russ
>
>
>At 12:08 AM 1/31/98 +0000, Jim Schaad (Exchange) wrote:
>>Yes all of the objects have their own OIDs so that they are
>>recognizable.=A0 I would not however wish to enumerate the list and
>>special case in that way.
>>
>>jim
>>
>>
>>-----Original Message-----
>>From: Russ Housley=
 [<mailto:[email-masked]%5D>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.=A0 Do these objects have their own OIDs?=A0 If=
 so,
>>there may be a straightforward way to support them.=20
>>
>>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.=A0 At the time I said that I know of none.=A0 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.=A0 Thus I
>>>propose the following:
>>>
>>>We add an appendix to the CMS draft to explain the following items:
>>>1.=A0 The difference and reasons for the change in the way that the data
>>>is encoded.
>>>2.=A0 A general way of doing recognition of the two different ways of
>>>encoding and how to correctly verify each way
>>>3.=A0 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.=A0=20
>>>-=A0 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.=A0 The data actually hashed is then returned
>>>as the data block of signedData object.
>>>-=A0 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.
>>>
>> =20
>

Date: Mon, 02 Feb 1998 02:20:32 -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:

Would this help?

... CHOICE { TheOld Way, TheNewWay }

 theOld Way ::= SEQUENCE {
  contentType ContentType,
  owContent [0] EXPLICIT ANY DEFINED BY contentType }

theNewWay ::= SEQUENCE {
  contentType ContentType,
  nwContent OCTET STRING }

Then, we tell everyone that defines a new content type to follow the New Way
syntax?

I am just brainstorming here.  So, feel free to flame.

Russ

At 12:08 AM 1/31/98 +0000, Jim Schaad (Exchange) wrote:
>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]%5D>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: Mon, 02 Feb 1998 02:10:58 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Hashing of CMS signedData objects
Cc: Blake Ramsdell <[email-masked]>, "[email-masked]'" <[email-masked]>
Sender: [email-masked]

Phil:

SET uses PKCS#7 v1.6.  S/MIME v2 uses PKCS#7 v1.5.  CMS is derived from
PKCS#7 v1.5. 

PKCS#7 v1.5 and v1.6 are quite different from an encoding point of view.

Russ

At 11:08 PM 1/30/98 +0000, Phillip H. Griffin wrote:
>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
>------------------------------------------------------------
> 

Date: Mon, 2 Feb 1998 16:48:55 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: 1/28/98 S/MIME V3 Msg Spec Comments
Sender: [email-masked]

Blake (and friends),

Thank you for incorporating my previous comments into the "January 28, 1998
S/MIME Version 3 Message Specification" [MSG3].  I have the following
comments regarding the new spec:

1) Sec 1.1, 2nd para, and Sec 3.7: The spec "defines how to create
certification requests that conform to PKCS #10 [PKCS-10], and the
application/pkcs10 MIME type for transporting those requests."  The IETF
PKIX working group is developing a "harmonized", application-independent,
IETF standard set of cert mgmt protocols (see Dec 97 PKIX WG minutes).
IMHO, if [MSG3] mandates any cert mgmt protocols, then those protocols
should be the "harmonized", application-independent IETF standard protocols.
If the S/MIME WG wishes [MSG3] to go to last call before the IETF
"harmonized" protocols are complete, then I recommend that all text should
be removed from [MSG3] that mandates cert mgmt protocols.  Once the
"harmonized" IETF standard protocols are completed, then a separate S/MIME
WG spec could be drafted which specifies the use of MIME to communicate
CMS-protected "harmonized" cert mgmt protocol messages.  At that point, the
new spec could also define how to transport PKCS #10 messages as a MAY
implement for the purposes of backward conpatability with v2 S/MIME MUAs.  

2) Sec 2, intro: Please add "[CMS] provides additional details regarding the
use of the cryptographic algorithms."

3) Sec 2.6.2.4.  Please change "MUST use RC2/40" to "SHOULD use RC2/40".

4) Sec 3, first para: Please replace five occurrences of "PKCS" with "CMS".

5) Sec 3.2, 2nd para states: "The CMS object must always be the BER encoding
of the ASN.1 syntax describing the object."  Why can't the CMS object be a
DER encoding? 

6) Sec 3.7.2, first sentence mandates use of PKCS 10.  Disagree with this
statement as per comment 1.

7) Sec H: "What do we need to do for 4.1 in order to make it
Diffie-Hellman?" and "Section 4.1 needs to talk about DSS and DH minimum key
lengths for strong crypto."  I believe that there should be separate
documents describing the use of SHA-1, DSA and DH with the CMS and ESS
specs.  I don't believe that the details of DH key generation need to be
included in the base S/MIME v3 Message Spec.

8) Sec H: "Need OIDs for DH":  PKIX X.509 Certificate and CRL Profile, sec
7.3.2 defines the use of the ANSI X9.42        dhpublicnumber OBJECT
IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x942(10046)
number-type(2) 1 } for DH keys in X.509 certs.  Can we use that OID for CMS?

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

Date: Mon, 02 Feb 1998 12:40:09 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Question about signing attachments separately
Sender: [email-masked]

At 12:10 PM 2/2/98 -0800, Jonathan Penn wrote:
>the question is whether to allow & how to implement:
>* multiple signatures on a messages

These can be nested to arbitrary depth. See section 3.5 of the -msg spec.

>* different signatures on different parts

It is not required in the spec that a receiving MUA be able to handle anything
other than direct nesting. There are many security reasons for this. Did you
miss Ned Freed's very concise explantion for this? See
<http://www.imc.org/ietf-smime/mail-archive/1079.html>.

That is, nothing prevents you from signing many parts of a multipart message,
but you can't do it securely, so I doubt many implementations will handle it.

>is S/MIME going to be compatible with these simple forms routing examples?

Nothing prevents S/MIME from handling methods such as you have listed, but it
is not required that implementations do so.

--Paul Hoffman, Director
--Internet Mail Consortium

From: Stephen Klump <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: New S/MIME OIDs
Date: Mon, 2 Feb 1998 15:32:41 -0500
Sender: [email-masked]

NSN was Nortel Secure Networks, which spun off of Nortel and became
Entrust.

Cheers,
Stephen - Entrust Technologies

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	Monday, February 02, 1998 2:45 PM
>To: 	[email-masked]
>Subject: 	Re: New S/MIME OIDs
>
>
>Paul,
>  You might want to expand the CAST3 and CAST5 definitions using
>RFC 2144 as a reference:
>
>cast3CBC OBJECT IDENTIFIER ::=
>  {iso(1) member-body(2) us(840) nt(113533) nsn(7) algorithms(66) 3}
>cast5CBC OBJECT IDENTIFIER ::=
>  {iso(1) member-body(2) us(840) nt(113533) nsn(7) algorithms(66) 10}
>
>
>nt stands for Northern Telecom; I don't know what nsn means.
>

Date: Mon, 2 Feb 1998 12:10:04 -0800
To: [email-masked]
From: Jonathan Penn <[email-masked]>
Subject: RE: Question about signing attachments separately
Sender: [email-masked]

i don't see this as an issue of signing the message body vs. not signing it. everyone agrees that it's best to sign everything. 
the question is whether to allow & how to implement:
* multiple signatures on a messages
* different signatures on different parts

both are fundamental for integrating S/MIME into forms routing applications. 
example 1: i have a vacation request. this will get routed and signed by manager, HR, etc. nothing about the document will be changed.
example 2: i have a reimbursement form. this gets routed to my manager, who signs it unchanged, then to accounting, who signs it and adds information such as the check #, the date the check, etc.

is S/MIME going to be compatible with these simple forms routing examples?

At 4:20 PM -0800 1/29/98, Blake Ramsdell wrote:
>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

______________________________________________________
Jonathan Penn
Ferris Research, Inc.
408 Columbus Avenue, Suite #1
San Francisco, CA  94133
Tel: +1 415 986 1414   Fax: +1 415 986 5994
http://www.ferris.com  mailto:[email-masked]

Analysis of messaging, directories, security,
and messaging-related applications.
______________________________________________________

Date: Mon, 2 Feb 1998 15:10:56 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: New S/MIME OIDs
Sender: [email-masked]

Paul,

Please add:

id-aa-contentIdentifier       OBJECT IDENTIFIER ::= { id-aa 7 }

to identify the contentIdentifier attribute which is required to fulfill the
MSP signed content identifier (SCID) requirement.

- John Pawling

Date: Mon, 2 Feb 1998 14:45:54 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: New S/MIME OIDs
Sender: [email-masked]

Paul,
  You might want to expand the CAST3 and CAST5 definitions using
RFC 2144 as a reference:

cast3CBC OBJECT IDENTIFIER ::=
  {iso(1) member-body(2) us(840) nt(113533) nsn(7) algorithms(66) 3}
cast5CBC OBJECT IDENTIFIER ::=
  {iso(1) member-body(2) us(840) nt(113533) nsn(7) algorithms(66) 10}

nt stands for Northern Telecom; I don't know what nsn means.

Date: Mon, 2 Feb 1998 14:39:48 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Redundant Cert Mgmt Protocols
Sender: [email-masked]

All,

I agree with Paul.  His statements are consistent with my position.

- John Pawling

Date: Mon, 2 Feb 1998 14:35:42 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: More cert-01 Comments
Sender: [email-masked]

All,

I have the following comments to the 28 Jan 98 S/MIME v3 Certificate
Handling I-D:

1) General: Internet Mail Addresses in Certs: I agree with Elliots's and
Blake's previous comments that all text stating that S/MIME-compliant certs
"MUST include Internet mail addresses" must be changed to "MAY include
Internet mail addresses".

2) Sec 2.2, first para: Please change "MUST" to "MAY" in "End entity
certificates MUST include an Internet mail address" 

3) Sec 3.1, 5th para:  Please change "MUST" to "MAY" in "End-entity
certificates MUST contain an Internet mail address" 

4) Sec 3.1, 7th para" Please change "MUST" to "MAY" in"Receiving agents MUST
check" and "Receiving agents MUST provide".

5) Sec 3.1, last para: Please change:

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

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

6) Sec 3.2, 2nd para: Please change "Sending agents MUST include the
Internet mail address during
Distinguished Name creation." to "Sending agents SHOULD NOT include the
Internet mail address during
Distinguished Name creation.  If an Internet mail address is requiired in an
end-entity's cert, then it SHOULD be included in the subjectAltName extension."

7) Sec 4.2, 1rst para:  Please add "as per [KEYM]" to "Certificate, CRL, and
chain validation MUST be performed..."

8) Sec 5: Please delete Sec 5 as described in my previous msg, subject:
"Redundant Cert Mgmt Protocols".

9) Sec A.7, Please delete this section because it is redundant to info
contained in PKIX X.509 Cert and CRL Profile.  Also, it includes an obsolete
definition of keyUsage.

10) Sec F, If you eliminate Sec A.7, then eliminate the following text:
"Section A.7 -- bit 7 is encipherOnly, bit 8 is decipherOnly.  Are we going
to use these?"

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

Date: Mon, 02 Feb 1998 11:07:02 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Redundant Cert Mgmt Protocols
Sender: [email-masked]

<html>
<font size=3>I'd like to take a different approach to what John said. I
think that the S/MIME spec should simply get out of the PKI business.
S/MIME v3 tells how to send end-to-end secure messages, and does not need
to deal with how you should talk to your CA. The latest -cert spec shows
how awful the PKI stuff can get.<br>
<br>
A bit of history: S/MIME v2 included two PKI functions:<br>
- enrolling or requesting a cert<br>
- getting a CRL list<br>
<br>
These both use PKCS 10 due to the fact that PKIX wasn't around.
Unfortunately, PKIX part 3, which specifies how to do these actions, is
still not around, and I suspect it is many months off due to political
hassles in the PKIX WG. The CMP/CRS/CRMF debates seem like so much
posturing, given that all parties agree that the other parties have no or
few technical problems. However, they are absolutely getting in the way
of S/MIME.<br>
<br>
It is not clear to me that S/MIME v3 needs to do any PKI. Instead, we can
mandate:<br>
- a sending MUA already has a cert (instead of telling them how to get
one)<br>
- a receiving MUA already know how to get a CRL (instead of telling them
how to get one)<br>
If we make these two assumptions, we can strip out most of the guck that
has appeared in -cert. Of course, we should give guidance about how both
of these were done in the past, as well as saying that it is likely that
PKIX will finish at some point and implementors might want to look at
that for PKI work.<br>
<br>
If there is general agreement on the principle of us not specifying how
to do PKI, I'll draft a list of changes to the current -cert draft and
circulate it here on the list so Blake has a good shot at both what to
take out as well as what suggestions to put in.<br>
</font>
<BR>
<br>
<div>--Paul Hoffman, Director</div>
--Internet Mail Consortium
</html>

Date: Mon, 02 Feb 1998 10:56:57 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: New S/MIME OIDs
Sender: [email-masked]

I've revamped the S/MIME OIDs list. The list is now a separate ASN.1
module. Please take a look at <http://www.imc.org/ietf-smime/oids.html> and
note the large number of changes that have just gone into the list.

Of course, any changes to the list are welcome. I'm particularly interested
in people scrutinizing the algorithm section for parameters. It seems a tad
lame that we went this long without listing the parameters for DES and
tripleDES. This could lead to a bad lack of interoperability.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 2 Feb 1998 13:50:42 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Redundant Cert Mgmt Protocols
Sender: [email-masked]

All,

The 28 Jan 98 S/MIME v3 Certificate Handling I-D, Sec 5 specifies
certificate request and response protocols which are redundant to those
specified as part of the PKIX Working Group Certificate Management Protocol
(CMP).  Sec 5.2 specifies the use of SignedData encapsulating a CRMF object.
The CRMF object is harmonized with the PKIX WG, but the Service Indicators
described in Sec 5.2.1.2 and 5.2.1.3 are redundant to the information
contained in the PKIX CMP PKIHeader.  Furthermore, Sec 5.6 specifies the use
of a degenerate signedData object as the S/MIME-mandatory response protocol.
This protocol is redundant to the CMP PKIHeader and certRepContent.

The IETF PKIX working group is developing a "harmonized",
application-independent, IETF standard set of cert mgmt protocols (see Dec
97 PKIX WG minutes).  IMHO, if the S/MIME Certs I-D mandates any cert mgmt
protocols, then those protocols should be the "harmonized",
application-independent IETF standard protocols.  If the S/MIME WG wishes
the Certs I-D to go to last call before the IETF "harmonized" protocols are
complete, then I recommend that all text should be removed from the Certs
I-D that mandates cert mgmt protocols.  Once the "harmonized" IETF standard
protocols are completed, then a separate S/MIME WG spec could be drafted
which specifies the use of MIME to communicate CMS-protected "harmonized"
cert mgmt protocol messages.

I believe that it would be a mistake for the Certs I-D to mandate
S/MIME-specific cert mgmt protocols (including the degenerate signedData).
I believe that there are a significant number of organizations that would
like to build a common cert mgmt module (CCMM) that can serve all of the
various apps running on a workstation (see below).  I believe that an IETF
standard cert mgmt protocol would make it much easier to develop a standard
CCMM API since the data exchanged between the CCMM and the various apps
would be consistently formatted.  I would hate to see vendors have to
implement multiple cert mgmt protocols which is the path that we are on if
we mandate degenerate signedData in the Certs I-D and PKIX CMP mandates a
different cert response syntax.

I am not opposed to the adoption of degenerate signedData as the IETF
standard cert response protocol.  If degenerate signedData becomes the IETF
standard, then inclusion of that protocol in the S/MIME Certs I-D would be
fine by me.

Consider the following SW modules that could be present (probably not all
simultaneously) on a workstation:

 ------------    -----------    ------------    ---------
| S/MIME app |  | X.400 app |  | S-HTTP app |  | XYZ app |
|   w/CMS    |  |           |  |            |  | NON CMS |
 ------------    -----------    ------------    --------- 
      |               |              |              |
      -----------------------------------------------
                             |
                         Common API
                       --------------
                      | Commom Cert  |
                      | Mgmt Module: |
                      | implements   |
                      | standard     |
                      | PKI protocols|
                       --------------
                              |
                       ---------------
                      |               |
              ---------------    -----------------
             |Common database|  |Crypto module to | 
             |of certs, CRLs |  |generate keys,etc|
              ---------------    -----------------

If the IETF defined a common, application-independent cert mgmt protocol,
then implementors could develop a Common Cert Mgmt Module (CCMM) managing a
common database of certs that could be used by multiple apps running on the
workstation.  For example, when a user using an application with S/MIME
capabilities needs to generate a new key pair, the CCMM would generate the
keys and build a CRMF object that would then be passed to the S/MIME app
which would protect it within a signedData object for mailing to the CA.  As
another example, when a XYZ user without CMS capabilities needs to generate
a new key pair, the CCMM would generate the keys and build a CRMF object
that would then be passed to the XYZ app which would protect it using the
XYZ security heading and transfer it to the CA.  This strategy allows the
CCMM to have a common interface to all app environments.  It also allows the
CA cert mgmt module to be shared by multiple apps (i.e. the same cert mgmt
object can be communicated via S/MIME, XYZ, etc).

I believe that the same strategy should apply to the cert response object.
For example, the S/MIME app receives a cert response object encapsulated in
a signedData object from the CA.  The S/MIME app verifies the signedData
object and then passes the encapsulated cert response object to the CCMM
which then adds the new cert(s) to the common database of certs and performs
related management functions.  As another example, a XYZ app receives a cert
response encapsulated in a XYZ security header from the CA.  The XYZ app
verifies the XYZ object and then passes the encapsulated cert response
object to the CCMM which then adds the new cert(s) to the common database of
certs and performs related management functions.  This strategy allows the
CCM module to have a common interface to all app environments.

This strategy could also be implemented for other types of messages such as
those described in the PKIX CMP I-D.

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

Date: Mon, 02 Feb 1998 12:49:33 -0500
To: "Blake Ramsdell" <[email-masked]>, "'Elliott N Ginsburg'" <[email-masked]>
From: Elliott N Ginsburg <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-cert-01.txt
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

Also in section 3.1, it is still "Receiving agents MUST check" the From
address against the email addresses in certificates. This must be changed
to allow for certificates that don't contain email addresses.

elliott ginsburg

At 02:42 PM 1/30/98 -0800, Blake Ramsdell wrote:
><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
>
>
>

Elliott N Ginsburg

Date: Mon, 2 Feb 1998 10:19:34 -0500
To: Russ Housley <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Comments to CMS-02
Cc: [email-masked]
Sender: [email-masked]

Russ,

My point is that there won't be an issuer DN and serial number to use to
identify the originator's cert in my example (which is allowed by CMS).  In
my example envelopedData, there is not an originatorInfo and there is not an
originatorCert field in the recipientInfo.  Therefore, there is no place
that contains or identifies the originator's cert, so the recipient would be
unable to identify the originator's cert.  My original point was that CMS
should state that if the originator's cert is omitted, then it should be
identified in the originatorCert field in the recipientInfo.  In summary, I
believe that my original comment should be included in CMS.

- John Pawling

At 09:48 PM 2/1/98 -0500, Russ Housley wrote:
>John:
>
>In this case, you use the issuer Dn and serial number.  I assume that
>anyone who would generate such a message lives in a environment where the
>certificates are easily fetched from a repository.
>
>Russ
>
>At 05:44 PM 1/30/98 -0500, John Pawling wrote:
>>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
>>
>>
>

Date: Mon, 2 Feb 1998 10:04:54 -0500
To: Russ Housley <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Hashing of CMS signedData objects
Cc: "Jim Schaad (Exchange)" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Sender: [email-masked]

Russ,

Recommend that CMS Section 4 should be replaced with the following text:

"4  Data Content Type

   The data content type is identified by the following object
   identifier:

      id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }

   The presence of id-data in signedData SignedContentInfo->sigContentType
   indicates that the sigContent OCTET STRING is present and includes
arbitrary data.

   The presence of id-data in ContentInfo->contentType
   indicates that the content field is present and is defined
   as an OCTET STRING including arbitrary data.

   In both cases, the presence of id-data indicates that the  
   OCTET STRING includes arbitrary data, such as ASCII text files;
   the interpretation is left to the application. Such data need
   not have any internal structure (although it may; 
   it could even include DER encoded ASN.1 objects)."

- John Pawling

At 09:06 PM 2/1/98 -0500, Russ Housley wrote:
>I am working on the text for the next draft already...
>
>I have not figured out what to do with the section on the Data content
>type.  The OID is still needed...
>
>Russ
>
>
>At 06:53 PM 1/30/98 -0500, John Pawling wrote:
>>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: Sun, 01 Feb 1998 21:48:10 -0500
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: Re: Comments to CMS-02
Cc: [email-masked]
Sender: [email-masked]

John:

In this case, you use the issuer Dn and serial number.  I assume that
anyone who would generate such a message lives in a environment where the
certificates are easily fetched from a repository.

Russ

At 05:44 PM 1/30/98 -0500, John Pawling wrote:
>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
>
>

Date: Sun, 01 Feb 1998 21:11:06 -0500
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: Re: Content Type Attribute Question
Cc: "Bonatti, Chris" <[email-masked]>, [email-masked]
Sender: [email-masked]

John:

Thanks.  The contentType attribue is defined in CMS, and it already has an
OID.

I will assign an OID for the encapsulatedContentType attribute.  In fact,
I'll do it now ... I assigned:

    id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 
            rsadsi(113549) pkcs(1) pkcs-9(9) 16 }

    id-aa   OBJECT IDENTIFIER ::= { id-smime 2 }

    id-aa-encapContentType OBJECT IDENTIFIER ::= { id-aa 6 }

Russ

At 06:42 PM 1/30/98 -0500, John Pawling wrote:
>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: Sun, 01 Feb 1998 21:06:19 -0500
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: Re: Hashing of CMS signedData objects
Cc: "Jim Schaad (Exchange)" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Sender: [email-masked]

I am working on the text for the next draft already...

I have not figured out what to do with the section on the Data content
type.  The OID is still needed...

Russ

At 06:53 PM 1/30/98 -0500, John Pawling wrote:
>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
>

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: Mon, 2 Feb 1998 10:18:20 -0800
Sender: [email-masked]

I agree with this proposal from Russ.

-----Original Message-----
From: Russ Housley <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Sunday, February 01, 1998 12:53 PM
Subject: Re: Critical Attributes

>All:
>
>Having heard from several implementors that the 
>SEQUENCE { OID, BOOLEAN, SET OF ANY } is not an
>implementation problem, the next draft of CMS will
>include this structure for attributes.
>
>I do not plan to allow unauthenticated attribute to
>be critical.  Since these attribute are not covered
>by the signature, they have no integrity protection.
>This means that an attacker or malicious recipient
>could turn the critical BOOLEAN to FALSE anyway.
>
>Russ

Date: Sun, 01 Feb 1998 03:46:58 -0500
To: "Jim Schaad (Exchange)" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Incorporate some PKCS#7 V2.0 items into CMS
Cc: [email-masked]
Sender: [email-masked]

All:

The only comments that I saw on this came from John Pawling.  So, without
further supportive comments, I assume that there is not concensus for these
changes.

Russ

At 01:56 PM 12/26/97 -0800, Jim Schaad (Exchange) wrote:
>I would like to propose to the WG that we look at adopting some of the
>changes that are being examined in the V2 spec for PKCS#7 and modify the
>CMS document accordingly.  
>
>1.  We should allow for the usage of non X509 certificates in CMS for
>encryption purposes.  This would additionally allow for non-public key
>algorithms to be applied to envelopedData structures.  This proposal
>would change the ASN to the following:
>
>RecipientIdentifier :: = CHOICE {
>	issuerAndSerialNumber	IsuerAndSerialNumber,
>	rKeyId [0] RecipientKeyIdentifier,
>	mlKeyId [1] MailListKeyIdentifier,
>	otherKeyId [2] OtherKeyIdentifier }
>
>OtherKeyIdentifier ::= SEQUENCE {
>	keyIdentifier OBJECT IDENTIFIER,
>	keyInformaton ANY DEFINED BY keyIdentifier OPTIONAL }
>
>This allows for the following two scenarios to be included in the usage
>of CMS:
>1.  PGP certificates could have an OID defined for them and the
>certificate would be the any field.  This allows for PGP certificates to
>be used at the same time as X.509 certificates in encrypting a single
>message.
>2.  This would permit the use of other key agreement algorithms (such as
>the derived password keys in PKCS#12) to be used.  This would be
>especially useful with the new CRS syntaxes to permit a token to be used
>for the purposes of authentication and enveloping the data in the
>certificate request.  In this world identification information about the
>sender could be placed in the UserKeyingMaterials field, and information
>about the encryption of the bulk key would be carried in the
>OtherKeyIdentifier field.  (It would be along the lines of the OID for
>3DES followed by the parameters for 3DES).
>
>
>2.  Apply similar changes to the signedData structures.  This would
>change the ASN as follows:
>
>
>SignerInfo ::= SEQUENCE {
>	version Version,
>	ukm [2] IMPLICIT UserKeyingMaterials OPTIONAL,
>	rid RecipientIdentifier,
>	digestAlgorithm DigestAlgorithmIdentifier,
>	authenticatedAttributes [0] IMPLICIT Attributes OPTIONAL,
>	signatureAlgorithm signatureAlgorithmIdentifier,
>	signature SignatureValue,
>	unauthenticatedAttributes [1] IMPLICIT Attributes OPTIONAL}
>
>
>The switch from IssuerAndSerialNumber to Recipientidentifier allows for
>the use of certificates other than X.509.  Additional
>UserKeyingMaterials will permit the usage of algorithms such as HMAC to
>be used.  Please note that I am intentionally only dealing with the case
>were there are attributes present.  I am not suggesting that this be a
>general purpose solution, rather I am trying to solve the case where we
>are going to do a shared secret authentication message to a RA during
>certificate enrollment.  This means that there are going to be
>attributes present.  It also greatly simplifies the problem to a more
>manageable set of issues.
>
>jim schaad
>
>P.S.  Please refrain from doing correctness passes on the ASN until we
>decide if the problem should be dealt with in the working group.  This
>does not apply to correcting security or algorithm flaws.  
>thanks jls
>

Date: Sun, 01 Feb 1998 01:40:46 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Critical Attributes
Sender: [email-masked]

All:

Having heard from several implementors that the 
SEQUENCE { OID, BOOLEAN, SET OF ANY } is not an
implementation problem, the next draft of CMS will
include this structure for attributes.

I do not plan to allow unauthenticated attribute to
be critical.  Since these attribute are not covered
by the signature, they have no integrity protection.
This means that an attacker or malicious recipient
could turn the critical BOOLEAN to FALSE anyway.

Russ