Subject: Reference to Applicable Attribute Certificate(s) within the CMS
From: Francois Rousseau <[email-masked]>
To: [email-masked]
Date: Thu, 30 Apr 1998 16:17:18 -0400

Refs: A. ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8: 1997,
Information Technology-Open Systems Interconnections - The Directory:
Authentication Framework
B. ANSI X.9.45, Enhance Management Controls Using Digital Signatures and
Attribute Certificates, November 1996 (Draft)
C. ISO/WD-15782-2, Banking - Certificate Management, Part 2: Attribute
Certificates, October 1997 (Draft)
D. PKCS #7: Cryptographic Message Syntax Standard, Version 1.5, Revised
November 1, 1993
E. "Cryptographic Message Syntax", draft-ietf-smime-cms-04.txt, Work in
Progress, March 1998

As part of a study for the Government of Canada (GoC) on its long term
requirements for an Electronic Authorization and Authentication (EAA)
framework, which would be based on Attribute Certificates as defined in
reference A, we also had to review the structure of digitally signed
business transactions.

References B and C, which are both based on reference D, were a good basis
for such a structure and seemed to provide a mean to convey Attribute
Certificates. However, both references B and C took the approach of
OPTIONALLY conveying Attribute Certificates in the
unauthenticatedAttributes field of each per-signer SignerInfo. CMS (ref E)
is taking instead a more elegant approach of collecting Attribute
Certificates and OPTIONALLY including them in the certificates field of the
SignedData along with public key certificates.

In the future GoC EAA framework, Attribute Certificates will form part of
the solution for controlling access to sensitive services, such as
disbursement of funds. If you assume the following model with these four
components: the Claimant, the Verifier, the Service and the Control policy.
To validate a service request (e.g. S/MIME message), the Verifier MUST
obtain some information including the Claimant's public key, the Claimant's
privilege, encoded in its Attribute Certificate, and the applicable Control
policy. However, as indicated above, public key certificates and Attribute
Certificates do NOT have to be included in the certificates field of the
SignedData. Because the issuerAndSerialNumber field of each per-signer
SignerInfo only specifies the signer's certificate (and thereby the
signer's public key) by issuer distinguished name and issuer-specific
serial number, when certificates are NOT included in the certificates field
of the SignedData, the issuerAndSerialNumber field only allows the
recipient of the SignedData to identify for each claimant the signer's
public key to use to validate the message. This implies there are currently
no mean within CMS to convey to the Verifier which Attribute Certificate
MUST be used for each Claimant.

Should not considerations be given within CMS to use the
authenticatedAttributes field under each per-signer SignerInfo to specify
through new CRITICAL attributes, the applicable claimant's Attribute
Certificate and the applicable Control policy that the Verifier MUST use to
validate the message?

Francois Rousseau
[email-masked]

Date: Wed, 29 Apr 1998 10:57:50 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Attribute Certificates -- love 'em or leave 'em?
Sender: [email-masked]

I agree with John.

Russ

At 06:47 PM 4/28/98 -0400, John Pawling wrote:
>All,
>
>I agree with Dave Kemp that the X.509 Attribute Certificate (AC) syntax
>should be left in the CertificateChoices ASN.1 syntax defined in the CMS
>spec.  There are already major organizations who are planning to use the
>X.509 AC syntax.  For example, the American National Standards Institute,
>Accredited Standards Committee X9, plans to use the X.509 AC syntax in the
>following specifications:
>
>1) X9.57-199x, Public Key Cryptography For The Financial Services Industry:
>Certificate Management
>
>2) X9.45-199x: Enhanced Management Controls Using Digital Signatures and
>Attribute Certificates
>
>
>Recommend that the CERT I-D, Sec 2.3, last para should be changed as follows:
>
>OLD: "Receiving agents SHOULD support X.509 attribute certificates.  At a
>minimum, receiving agents SHOULD at least support the decoding of X.509
>attribute certificates.  Please note that there is no requirement that the
>same CA create both the public key X.509 Certificate and X.509 attribute
>certificate(s) for a user.  Each organization's local policy will define how
>X.509 attribute certificates are validated and used.  The implications of
>performing multiple certification path validations should be considered when
>defining local policy.  Exchanges between a subject and the CA dealing with
>the generation of X.509 attribute certificates are outside the scope of this
>specification."
>
>NEW: "Receiving agents SHOULD support the decoding of X.509 ACs included in
>CMS objects.  All other issues regarding the generation and use of X.509 ACs
>are outside of the scope of this specification."
>
>
>Recommend leaving the definition of AC in the Cert I-D.
>
>================================
>John Pawling, [email-masked]                             
>J.G. Van Dyke & Associates, Inc.   
>www.jgvandyke.com         
>================================
> 

From: Jim McCoy <[email-masked]>
Subject: Re: Using S/MIME to Improve The Acceptance Of Our Work
To: [email-masked] (Robert Frank)
Date: Thu, 30 Apr 1998 12:15:37 -0700 (PDT)
Cc: [email-masked]
Sender: [email-masked]

> Not long ago a new registration for this group was for someone using the
> alias of "happy hacker".  This started me thinking that we ought to
> practice what we preach here, i.e., use S/MIME certificates which can be
> verified through a trusted third party as a prerequisite for posting to
> this forum.  While it may not be necessary for all observers/lurkers to
> possess a valid S/MIME certificate, why should we trust postings from
> individuals who are not willing to accurately identify themselves with
> verifiable S/MIME signatures?
> 

To which someone should ask: why?  What exactly would the point of this
be other than to shut out a potential set of contributors?  While "happy
hacker" may have caused you some alarm it did not bother me any more than
seeing a message with fascist overtones supposedly coming from "Robert
Frank, CEO of Open Commerce" (I guess we all have our own opinion of what
"open" means, don't we Mr. Frank?)

Additionally, at the moment and despite the best efforts of the subscribers
to this list, the selection of S/MIME software is far less ubiquitous than
you suggest.  Most of it is pretty damn ugly to use as well.  I suppose it
would be nice to force people to use some of what they are selling, but it
will not solve the problem which seems to be your concern; you will not end
up subscribed to a list of "true names."  The value of a posting to this list
is not found in the name attributed to it, you will find the value in the
content of the message.  

I will also point out that past efforts to make crypto/security lists practice
what they preach (e.g. PGP-only posting to some lists) ends up being very
counter-productive.  In the end what you will end up with is two lists: one
will be the original list with only S/MIME postings and few subscribers and
the other will be a list which gateways the S/MIME-only list but also allows
subscribers to post non-S/MIME messages.  The latter list will have most of
the traffic and subscribers (and if this proposal is taken seriously I guess
I will volunteer to code up and run the latter list.)

jim mccoy
Minister of Silly Protocols
Yahoo!, Inc.

Date: Thu, 30 Apr 1998 08:51:17 -0700
From: Robert Frank <[email-masked]>
To: smime ietf <[email-masked]>
Subject: Using S/MIME to Improve The Acceptance Of Our Work
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

I am wondering if the ultimate completion and final IETF acceptance of
the work from this very important group would be significantly enhanced
if participants identified themselves using the S/MIME technologies
being proposed for implementation by the global Internet community?

Not long ago a new registration for this group was for someone using the
alias of "happy hacker".  This started me thinking that we ought to
practice what we preach here, i.e., use S/MIME certificates which can be
verified through a trusted third party as a prerequisite for posting to
this forum.  While it may not be necessary for all observers/lurkers to
possess a valid S/MIME certificate, why should we trust postings from
individuals who are not willing to accurately identify themselves with
verifiable S/MIME signatures?

It is now practical to establish such a procedure since we all have low
cost access to S/MIME applications and commercial CA services.  And,
even though much of the current work for this group is coming to a
conclusion, future work in this group (and others within the IETF) could
benefit from using S/MIME to improve the acceptance levels of the end
results.

Robert E. Frank
CEO, Open Commerce, Inc.
San Ramon, CA 94583
http://www.opencommerce.com/company.html

--------------msF0336EB8B9814E2AFAF89D1D
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------msF0336EB8B9814E2AFAF89D1D--

To: [email-masked]
Cc: [email-masked]
Subject: Re: Attribute Certificates -- love 'em or leave 'em? 
Date: Thu, 30 Apr 1998 11:20:41 +0100
From: Stephen Farrell <[email-masked]>
Sender: [email-masked]

I think it'd be a mistake to leave in the 509 AttributeCertificate
syntax. The reason is that an AC itself is often not enough - there
may be a need for application/protocol specific additions, so that
the AC can be validated. This happens for example when an AC
is delegated. (Note - I'm not saying that some other AC syntax
should be used, just that you may need more than the AC to
prevent certain attacks.)

I'd suggest deleting the current option, and either replacing with
an octet hole, or with an understanding (and maybe text) that
AC's (and whatever else is needed) will be carried as unauth or
auth-attributes within CMS.

Regards,
Stephen.

Date: Wed, 29 Apr 1998 08:40:46 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Attribute Certificates -- love 'em or leave 'em?
Sender: [email-masked]

All,

In reference to my last message on this topic:

X9.57 has been superseded by: ISO/CD-15782-1, Banking - Certificate
Management Part 1:  Public Key
Certificates (went to international ballot in Feb)

X9.45 has been superseded by: ISO/WD-15782-2, Banking - Certificate
Management Part 2:  Attribute
Certificates (working group draft)

These new specs will use the X.509 Attribute Certificate syntax, so my
comments included in my previous message still apply.

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

Date: Tue, 28 Apr 1998 18:47:01 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Attribute Certificates -- love 'em or leave 'em?
Sender: [email-masked]

All,

I agree with Dave Kemp that the X.509 Attribute Certificate (AC) syntax
should be left in the CertificateChoices ASN.1 syntax defined in the CMS
spec.  There are already major organizations who are planning to use the
X.509 AC syntax.  For example, the American National Standards Institute,
Accredited Standards Committee X9, plans to use the X.509 AC syntax in the
following specifications:

1) X9.57-199x, Public Key Cryptography For The Financial Services Industry:
Certificate Management

2) X9.45-199x: Enhanced Management Controls Using Digital Signatures and
Attribute Certificates

Recommend that the CERT I-D, Sec 2.3, last para should be changed as follows:

OLD: "Receiving agents SHOULD support X.509 attribute certificates.  At a
minimum, receiving agents SHOULD at least support the decoding of X.509
attribute certificates.  Please note that there is no requirement that the
same CA create both the public key X.509 Certificate and X.509 attribute
certificate(s) for a user.  Each organization's local policy will define how
X.509 attribute certificates are validated and used.  The implications of
performing multiple certification path validations should be considered when
defining local policy.  Exchanges between a subject and the CA dealing with
the generation of X.509 attribute certificates are outside the scope of this
specification."

NEW: "Receiving agents SHOULD support the decoding of X.509 ACs included in
CMS objects.  All other issues regarding the generation and use of X.509 ACs
are outside of the scope of this specification."

Recommend leaving the definition of AC in the Cert I-D.

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

Date: Tue, 28 Apr 1998 10:23:48 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Attribute Certificates -- love 'em or leave 'em?
Sender: [email-masked]

> From: "Blake Ramsdell" <[email-masked]>
> 
> Are attribute certificates getting axed out of the -cert draft?

I agree that attribute certs may be axed from the -cert draft, since
we have nothing in particular to say about their usage.

However, I would *not* recommend removing them from CMS, which allows
them to be contained in SignedData->certificates but does not require
implementations to do anything with them.

The syntax of AttributeCertificate is well defined in X.509; the
semantics is identical to including the attribute(s) from the AC in the
base cert(s) to which it refers.  The unknowns surrounding ACs are
management, not technical, issues (when are ACs advantageous to use,
and when does it make more sense to stuff all the attributes into a
regular certificate).

Leaving the capability of carrying ACs in the CMS syntax costs very
little, and offers valuable flexibility for applications which may
choose to use them.  Axe them from -cert, leave them in -cms.

Dave Kemp

Date: Tue, 28 Apr 1998 10:17:26 -0400
To: "IETF-SMIME WG" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: More on Cert-03.txt and Msg-03.txt
Sender: [email-masked]

All,

I have some responses in-line to Blake's calls for comments:

>> 			k.  Section 3.1, paragraphs 1-4.  Delete or
>relocate
>> 
>> into an appendix.  Rationale:  verbiage seems to be editorial 
>> and/or expository in nature, but not technical per se.
>
>I think that this jabber about DNs is not required -- this language
>predates PKIX.  I recommend that it simply be deleted.  Comments?

[JSP: Agree that Section 3.1, paragraphs 1-4 should be deleted.]

>> 				(2)  Paragraph 1, line 10.  Change
>"minimum
>> required" 
>> to "maximum allowable".  Rationale:  to promote interoperability 
>> despite the v3 extensions "curse," and so that verbiage agrees 
>> with the first sentence in paragraph # 3.
>
>The first sentence in paragraph # 3 does not preclude the inclusion of
>other extensions, but says that if you put them in you SHOULD NOT mark
>them as critical.  The idea is that a v3 S/MIME application may not
>understand extensions that are not profiled here, so marking them as
>critical will make the receiving agent choke, even though it may be a
>compliant S/MIME v3 agent.
>
>I don't want to limit the use of new extensions that may be useful in an
>S/MIME environment by saying that this set is the "maximum allowable".
>However soft that language may be, it is still discouraging.  Comments?

[JSP: I agree with Blake.]

>> 			q.  Section 4.4.3.  How should the "subject
>> alternative 
>> name extension" be marked?
>
>Good question.  Comments?  I recommend critical.  Same goes for
>basicConstraints.

[JSP: I disagree with these comments.  The S/MIME CERT I-D should minimize
the requirements that it places on the construction of certificates.  The
CERT I-D does not need to state whether subjectAltName or basicConstraints
must be critical.  PKIX I provides this information.  The S/MIME CERT I-D
should not duplicate or contradict what is in PKIX I.]

- John Pawling

Date: Tue, 28 Apr 1998 08:02:29 -0400
To: "Blake Ramsdell" <[email-masked]>
From: Elliott Ginsburg <[email-masked]>
Subject: RE: More on Cert-03.txt and Msg-03.txt
Cc: "'Flanigan, Bill'" <[email-masked]>, "IETF-SMIME WG" <[email-masked]>
Sender: [email-masked]

"jabber about DNs is not required" -- I agree.

elliott ginsburg

At 09:59 PM 4/27/98 , Blake Ramsdell wrote:
>On Friday, March 27, 1998 10:19 AM, Flanigan, Bill
>[SMTP:[email-masked]] wrote:
>> 			j.  Section 2.3, paragraph 5, sentences 3-5.
>> Relocate 
>> into first paragraph.  Rationale:  information is too important 
>> to be hidden back there.
>
>I may be missing something.  Paragraph 5 in section 2.3 is only two
>sentences ("Receiving agents MUST support chaining...").  The only
>paragraph around that is regarding attribute certificates (which we may
>end up yanking).  Is that what you are referring to?
>
>> 			k.  Section 3.1, paragraphs 1-4.  Delete or
>relocate
>> 
>> into an appendix.  Rationale:  verbiage seems to be editorial 
>> and/or expository in nature, but not technical per se.
>
>I think that this jabber about DNs is not required -- this language
>predates PKIX.  I recommend that it simply be deleted.  Comments?
>
>> 			l.  Section 3.2.  Relocate paragraph # 2 into
>the
>> last 
>> paragraph of this section.  Replace "emailAddress" with "Email 
>> Address" in last line of last paragraph.
>
>I have moved the paragraph.  However, emailAddress is referring to a
>particular OID, and making it more human will lose the connection to
>that type, won't it?  I will think about this.
>
>> 			n.  Section 4.2.
>> 
>> 				(1)  In line # 1, what does the "and"
>mean?
>> And...what?
>
>The sentence is as follows:
>
>"In creating a user agent for secure messaging, certificate, CRL, and
>certificate chain validation SHOULD be highly automated while still
>acting in the best interests of the user."
>
>How would you reword it?  The intent is to express that in a secure
>messaging user agent, the processing of certificates CRLs and chain
>validation of certificates SHOULD be highly automated while still acting
>in the best interests of the user.  Should I change the language to read
>this way?
>
>> 				(2)  Paragraph 1, line 10.  Change
>"minimum
>> required" 
>> to "maximum allowable".  Rationale:  to promote interoperability 
>> despite the v3 extensions "curse," and so that verbiage agrees 
>> with the first sentence in paragraph # 3.
>
>The first sentence in paragraph # 3 does not preclude the inclusion of
>other extensions, but says that if you put them in you SHOULD NOT mark
>them as critical.  The idea is that a v3 S/MIME application may not
>understand extensions that are not profiled here, so marking them as
>critical will make the receiving agent choke, even though it may be a
>compliant S/MIME v3 agent.
>
>I don't want to limit the use of new extensions that may be useful in an
>S/MIME environment by saying that this set is the "maximum allowable".
>However soft that language may be, it is still discouraging.  Comments?
>
>> 				(3)  Paragraph 3, line 2.  Define the
>term
>> "critical."
>
>Done.  This now reads "Certificates issued for the S/MIME environment
>SHOULD NOT contain any critical extensions (extensions that have the
>critical field set to TRUE) other than those listed here."
>
>> 				(4)  Paragraph 3.  This paragraph is too
>> confusing 
>> (what with "non-critical unless"..."deemed critical"..."SHOULD 
>> NOT be marked as critical", etc.  Recommend complete rewrite or 

>> delete.
>
>Suggested language welcome.
>
>> 			p.  Section 4.4.1.  
>> 
>> 				(1)  Paragraph 2, line 3.  Define
>"end-user 
>> subscriber" vis-a-vis "clients" , "users", "receiving agent", 
>> and "sending agents".
>
>I have changed this to "end-entity", to be consistent with PKIX I.
>
>> 			q.  Section 4.4.3.  How should the "subject
>> alternative 
>> name extension" be marked?
>
>Good question.  Comments?  I recommend critical.  Same goes for
>basicConstraints.
>
>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: "'Paul Hoffman / IMC'" <[email-masked]>, [email-masked]
Subject: RE: Attribute Certificates -- love 'em or leave 'em?
Date: Mon, 27 Apr 1998 20:50:38 -0700
Sender: [email-masked]

I also agree this is the correct approach.

jim

-----Original Message-----
From: Paul Hoffman / IMC [mailto:[email-masked]]
Sent: Monday, April 27, 1998 8:11 PM
To: [email-masked]
Subject: Re: Attribute Certificates -- love 'em or leave 'em?

At 05:45 PM 4/27/98 -0700, Blake Ramsdell wrote:
>1. Find all references to Attribute Certificates (or ACs) in the -cert
>draft
>2. Delete them
>
>Comments?

Sounds right to me. We know nothing about them, and shouldn't be pretending
we do. When the PKIX WG locks them down, we can address them then.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 27 Apr 1998 20:10:44 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Attribute Certificates -- love 'em or leave 'em?
Sender: [email-masked]

At 05:45 PM 4/27/98 -0700, Blake Ramsdell wrote:
>1. Find all references to Attribute Certificates (or ACs) in the -cert
>draft
>2. Delete them
>
>Comments?

Sounds right to me. We know nothing about them, and shouldn't be pretending
we do. When the PKIX WG locks them down, we can address them then.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Blake Ramsdell" <[email-masked]>
To: "'Flanigan, Bill'" <[email-masked]>, "IETF-SMIME WG" <[email-masked]>
Subject: RE: More on Cert-03.txt and Msg-03.txt
Date: Mon, 27 Apr 1998 18:59:16 -0700
Sender: [email-masked]

On Friday, March 27, 1998 10:19 AM, Flanigan, Bill
[SMTP:[email-masked]] wrote:
> 			j.  Section 2.3, paragraph 5, sentences 3-5.
> Relocate 
> into first paragraph.  Rationale:  information is too important 
> to be hidden back there.

I may be missing something.  Paragraph 5 in section 2.3 is only two
sentences ("Receiving agents MUST support chaining...").  The only
paragraph around that is regarding attribute certificates (which we may
end up yanking).  Is that what you are referring to?

> 			k.  Section 3.1, paragraphs 1-4.  Delete or
relocate
> 
> into an appendix.  Rationale:  verbiage seems to be editorial 
> and/or expository in nature, but not technical per se.

I think that this jabber about DNs is not required -- this language
predates PKIX.  I recommend that it simply be deleted.  Comments?

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

I have moved the paragraph.  However, emailAddress is referring to a
particular OID, and making it more human will lose the connection to
that type, won't it?  I will think about this.

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

The sentence is as follows:

"In creating a user agent for secure messaging, certificate, CRL, and
certificate chain validation SHOULD be highly automated while still
acting in the best interests of the user."

How would you reword it?  The intent is to express that in a secure
messaging user agent, the processing of certificates CRLs and chain
validation of certificates SHOULD be highly automated while still acting
in the best interests of the user.  Should I change the language to read
this way?

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

The first sentence in paragraph # 3 does not preclude the inclusion of
other extensions, but says that if you put them in you SHOULD NOT mark
them as critical.  The idea is that a v3 S/MIME application may not
understand extensions that are not profiled here, so marking them as
critical will make the receiving agent choke, even though it may be a
compliant S/MIME v3 agent.

I don't want to limit the use of new extensions that may be useful in an
S/MIME environment by saying that this set is the "maximum allowable".
However soft that language may be, it is still discouraging.  Comments?

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

Done.  This now reads "Certificates issued for the S/MIME environment
SHOULD NOT contain any critical extensions (extensions that have the
critical field set to TRUE) other than those listed here."

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

Suggested language welcome.

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

I have changed this to "end-entity", to be consistent with PKIX I.

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

Good question.  Comments?  I recommend critical.  Same goes for
basicConstraints.

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: "'Flanigan, Bill'" <[email-masked]>, "IETF-SMIME WG" <[email-masked]>
Subject: RE: Cert-03.txt and Msg-03.txt
Date: Mon, 27 Apr 1998 18:27:51 -0700
Sender: [email-masked]

Sorry about the delay, Bill -- I'm in editing mode now.

On Thursday, March 26, 1998 2:35 PM, Flanigan, Bill
[SMTP:[email-masked]] wrote:
> > 
> > 			c.  Section titles starting with Section 2.1.
> > Eliminate the run-on use of words.

These are the ASN.1 identifiers that correspond to the fields in the CMS
specification.  Changing these to be more "human" would lose the
connection to those fields, wouldn't it?

> > 			f.  Recommend that document be given a "PKI
scrub"
> > starting with Section 2.1.

Should I use soap?

How do you mean a PKI scrub?  Remove all references to PKI?

> > 			g.  Section 4.1, line 6-8.  Keep this sentence,
and
> > delete the rest of the Section.

PKIX does not document the frequency of retrieval of CRLs nor does it
recommend local storage practices.  I think this is necessary to
communicate, so we should probably see if there are any more comments.

> > 			h.  Section 5.0, lines 2-3.  It's unclear what
the
> > relationship is between the "S/MIME agent" and "protecting the
user's
> > private key."  Shouldn't the user protect his/her/its private key
> > period?

They should, but I think it's important to call it out as a security
problem if you don't do something like password encrypt the private key.
Other 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

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Attribute Certificates -- love 'em or leave 'em?
Date: Mon, 27 Apr 1998 17:45:32 -0700
Sender: [email-masked]

Are attribute certificates getting axed out of the -cert draft?  JSP's
minutes seem to indicate this:

> 4) Attribute Certificates:  Paul noted that it is an action item for
the
> PKIX WG to define the use of ACs.  David Solo proposed that all
references
> to ACs should be deleted from all of the S/MIME specifications until
the
> syntax and use of ACs are well defined.  Russ and John Pawling made
the
> point that X.509 defines the AC syntax.  However, Paul and Dave
strongly
> believed that ACs should be deleted from the S/MIME specs since their
use is
> not defined and the PKIX AC syntax may be changed.  Nobody objected to
this
> proposal.  The details of this change will be discussed further on the
> S/MIME list.

There are "details" that need to be discussed further, but these seem to
be:

1. Find all references to Attribute Certificates (or ACs) in the -cert
draft
2. Delete them

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: Mon, 27 Apr 1998 18:41:18 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: ESS-05 Comments
Sender: [email-masked]

All,

I believe that Paul has done a masterful job of incorporating the comments
into ESS-05 (11 April 98) upon which the group has reached concurrence.  I
have a few comments:

1) Sec 1.3.4: The table indicates that the signingCertificate attribute will
be defined in CMS.  Is this still true??  

2) Sec 1.3.4: Please add the following text after the table:

"CMS defines authenticatedAttributes as a SET OF AuthAttribute and defines
unAuthenticatedAttributes as a SET OF UnauthAttribute.  ESS defines the
contentHints, contentIdentifier, eSSecurityLabel, msgSigDigest,
mlExpansionHistory and receiptRequest attribute types.  A signerInfo MUST
NOT include multiple instances of any of the attribute types defined in ESS.
Later sections of ESS specify further restrictions that apply to the
receiptRequest, mlExpansionHistory and eSSecurityLabel attribute types.

CMS defines the ASN.1 syntax for the authenticated and unauthenticated
attributes to include attrValues SET OF AttributeValue.  For all of the
attribute types defined in ESS, if the attribute type is present in a
signerInfo, then it MUST only include a single instance of AttributeValue.
In other words, there MUST NOT be zero or multiple instances of
AttributeValue present in the attrValues SET OF AttributeValue."

3) Sec 4.1, last para, 2nd and 3rd sentences:  Please make the following
minor wordsmithing changes to clarify the intent of the statements:

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

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

4) ASN.1 Module: The UTF8String definition needs to be moved so that it
follows the IMPORTS section. 

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

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Should SMIMEEncryptionKeyPreference go in CMS?
Date: Mon, 27 Apr 1998 15:15:00 -0700
Sender: [email-masked]

SMIMEEncryptionKeyPreference seems like an attribute that would be
useful to non-S/MIME CMS applications.  Should this be renamed
CMSEncryptionKeyPreference and put into CMS?

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]>
Subject: Capabilities and where they live
Date: Mon, 27 Apr 1998 15:11:11 -0700
Sender: [email-masked]

The current -msg draft does not document any of the SMIMECapabilities.
These all currently live at http://www.imc.org/ietf-smime/oids.html

Based on the addition of SMIMEVersion as an S/MIME capability, do we
want to continue with this and simply put it into the OID pile, or do we
want to fully document all of the capabilities in the -msg draft or some
other draft?  I personally think that a separate draft is needed to not
only serve as a list of OIDs and syntax, but document their meanings as
well.  This draft will be more of a "living" draft, since the list of
capabilities will change more frequently than the CMS profile defined in
-msg.

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

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: SigningCertificate attribute
Date: Mon, 27 Apr 1998 14:48:54 -0700
Sender: [email-masked]

>From John Pawling's S/MIME WG minutes:

> In a later discussion, this issue was raised again and Russ explained
the
> issue.  Russ asked who believed that the signing-certificate attribute
> should be added to the S/MIME specs.  The vote was 6 to 7 in a room
filled
> with several hundred people.  It was apparent from this vote and from
the
> discussion of the WG members that there was not a consensus regarding
the
> purpose and syntax of the signing-certificate attribute, so the result
of
> the earlier straw poll was overturned.  This issue will be further
discussed
> on the S/MIME mail list.

I know we've all heard this before, but for the record:

1. A user generates a signing keypair
2. The user submits the public part to CA #1, who issues a certificate
covered by a particular CPS
3. The user submits the public part to CA #2, who issues a certificate
covered by a different CPS
4. The user signs an S/MIME message using the private part of the
keypair, and uses the IssuerAndSerialNumber for the certificate issued
by CA #1 in the SignerInfo to identify his certificate
5. At any point someone can replace the IssuerAndSerialNumber (since it
is not cryptographically protected) with another certificate containing
the same public key, and the signature will still be valid.

This may be a bug, or it may be a feature.  I think it's a bug, and
should be fixed with the addition of SigningCertificate as an
authenticated attribute containing the IssuerAndSerialNumber of the
signing certificate.  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: Mon, 27 Apr 1998 13:15:13 -0400
To: "Bonatti, Chris" <[email-masked]>, [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Sender: [email-masked]

All,

I disagree with Chris' proposal because there is no reason to include
different semantically-equivalent eSSSecurityLabels in a single signedData
object because the originator and each recipient can locally translate the
"identical" eSSSecurityLabel to a specific security policy, if required.
Furthermore, ESS MUST prohibit semantically different eSSSecurityLabels from
being included in a single signedData because that creates a significant
possiblity that there will be contradictions between the semantically
different labels that would lead to errorneous or inconsistent access
control decisions applied to a content.  

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

At 10:43 PM 4/25/98 -0400, Bonatti, Chris wrote:
>    This seems to have wound down, but not truly concluded.  While I agree
with David that further discussion of the "multiple labels" question seems
fruitless, I raised a slightly different point in my earlier posting which
has gotten lost amongst the many salvos exchanged.
>
>    In one of my earlier postings, I noted the scenario in which the
originator includes either or both of an "information" or "system" security
label.  If both labels are present, the information label will convey the
"true" label of the content from the originator to the recipient.  The
system label will convey the label of the content to be used for access
control purposes.  In this case, both labels are provided simultaneously by
the same signer, but convey a deliberately different semantic.
>
>    I would like to come to a conclusion that has ESS describe how to
provide this dual-marking.
>
>    In my mind, it would be unnecessarily inefficient to convey each of
these in a separate signerInfo elements since they are both generated by the
same signer.  However, it would be reasonable to use a different attribute
ID for the information label and simply exempt it from ACDF processing
(which is semantically consistent anyway).  What I proposed in my original
post was somewhat more efficient, but separate attributes would keep us off
any slippery slopes.
>
>    Thoughts?
>
>Chris
>
>
> ---------------------------------------------------------------
> |  International Electronic Communication Analysts, Inc.      |
> |  Christopher D. Bonatti                 9010 Edgepark Road  |
> |  Principal Engineer                 Vienna, Virginia 22182  |
> |  [email-masked]   Tel: 301-212-9428   Fax: 703-506-8377  |
> ---------------------------------------------------------------
>
>
>
>
>

Date: Sat, 25 Apr 1998 22:43:49 -0400
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: [email-masked]
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Sender: [email-masked]

    This seems to have wound down, but not truly concluded.  While I agree with David that further discussion of the "multiple labels" question seems fruitless, I raised a slightly different point in my earlier posting which has gotten lost amongst the many salvos exchanged.

    In one of my earlier postings, I noted the scenario in which the originator includes either or both of an "information" or "system" security label.  If both labels are present, the information label will convey the "true" label of the content from the originator to the recipient.  The system label will convey the label of the content to be used for access control purposes.  In this case, both labels are provided simultaneously by the same signer, but convey a deliberately different semantic.

    I would like to come to a conclusion that has ESS describe how to provide this dual-marking.

    In my mind, it would be unnecessarily inefficient to convey each of these in a separate signerInfo elements since they are both generated by the same signer.  However, it would be reasonable to use a different attribute ID for the information label and simply exempt it from ACDF processing (which is semantically consistent anyway).  What I proposed in my original post was somewhat more efficient, but separate attributes would keep us off any slippery slopes.

    Thoughts?

Chris

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

Date: Wed, 22 Apr 1998 09:46:14 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Degenerate certificates only signedData.
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

Steve:

Historically, the degenerate SignedData has bee used to transfer a newly
issued certificate from the CA to the subject of the certificate (following
a PKCS#10 request).

You are proposing a new use.  And, there is a PKIX specification that
covers your idea (without smimeCapabilities).  Please take a look at
draft-ietf-pkix-opp-ftp-http-03.txt.

Russ

At 12:11 AM 4/21/98 +0100, Dr Stephen Henson wrote:
>The V3 CMS specs support the use of degnerate signedData for
>certificates only and thus usable as a means of distributing
>certificates, for example on a web page.
>
>I would suggest that what is also frequently needed is a degenerate form
>that includes the SMIMECapabilities authenticated attribute. The
>reasoning for this is that you not only need the recipients certificate
>you also need their capabilities otherwise you have to guess
>(RC2-40/triple DES) what they can handle.
>
>It has to be authenticated otherwise an attacker could generate a
>certificates only signedData with deliberately weak ciphers.
>
>What would be the suggested way to do this? A dummy message would
>achieve this end. 
>
>Alternatively a "no content with authenticated attributes" form would
>work. This would contain a SignerInfo structure with signed
>authenticated attributes containing signingTime and SMIMECapabilities
>but would exclude the contentType and messageDigest attributes and any
>content. This is currently not permitted by the CMS spec.
>
>Steve.
>-- 
>Dr Stephen N. Henson.
>UK based freelance Cryptographic Consultant. For info see homepage.
>Homepage: http://www.drh-consultancy.demon.co.uk/
>Email: [email-masked]
>PGP key: via homepage.
> 

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: Single-Valued Attributes Proposal
Date: Tue, 21 Apr 1998 11:53:43 -0700
Sender: [email-masked]

This I agree with.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, April 21, 1998 11:53 AM
To: Jim Schaad (Exchange); [email-masked]
Subject: RE: Single-Valued Attributes Proposal

Jim,

I agree with your comments.  What I meant to say was that each current
attribute definition (except for counterSignature) should state: "This
attribute type must have a single attribute value."

- John Pawling

At 11:37 AM 4/21/98 -0700, Jim Schaad (Exchange) wrote:
>I have a problem with this proposal as it appears overly restrictive to me.
>I have no problem with a general statement that all attribute types MUST
>have a single attribute value unless the definition of the attribute
>explicity allows for multiple values to occur.  However I don't like the
>idea of restricting any and all new attributes which are to come in the
>future.
>
>jim
>
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Tuesday, April 21, 1998 11:19 AM
>To: [email-masked]
>Subject: Single-Valued Attributes Proposal
>
>
>All,
>
>CMS defines the syntaxes for attributes as follows:
>
>   AuthAttribute ::= SEQUENCE {
>     attrType OBJECT IDENTIFIER,
>     critical BOOLEAN DEFAULT FALSE,
>     attrValues SET OF AttributeValue }
>
>   UnauthAttribute ::= SEQUENCE {
>     attrType OBJECT IDENTIFIER,
>     attrValues SET OF AttributeValue }
>
>In both cases, attrValues is a SET OF AttributeValue (i.e. ANY).
>
>CMS states that the contentType, messageDigest, and signingTime attributes
>must have a single attribute value.  CMS states that the counterSignature
>attribute may have multiple attribute values.  ESS and MSG don't include
any
>statements for the attributes defined in those specs.
>
>Propose that all attribute types MUST must have a single attribute value
>except for counterSignature (for backwards compatibility purposes). This
>requires additional text to be added to ESS and MSG.  I will include
>detailed comments in my comments to the ESS and MSG specs.
>
>================================
>John Pawling, [email-masked]                             
>J.G. Van Dyke & Associates, Inc.   
>www.jgvandyke.com         
>================================
>
>

Date: Tue, 21 Apr 1998 14:54:41 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: More Single Instance of Attributes Proposal
Sender: [email-masked]

All,

What I meant to say in the first message was that each current attribute
definition (except for counterSignature) should state: "A signerInfo MUST
NOT include multiple instances of this attribute type".

CMS defines authenticatedAttributes as a SET OF AuthAttribute and
unAuthenticatedAttributes as a SET OF UnauthAttribute.  The ESS I-D
specifically states that a signerInfo MUST NOT include multiple instances of
any of the following attributes: mlExpansionHistory, receiptRequest and
eSSSecurityLabel.  Propose that all of the other types of attributes (except
counterSignature) should be limited by the same rules.  This requires
additional text to be added to ESS, CMS and MSG.  I will include detailed
comments in my comments to the next round of these specs.  

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

Date: Tue, 21 Apr 1998 14:53:19 -0400
To: "Jim Schaad (Exchange)" <[email-masked]>, [email-masked]
From: [email-masked] (John Pawling)
Subject: RE: Single-Valued Attributes Proposal
Sender: [email-masked]

Jim,

I agree with your comments.  What I meant to say was that each current
attribute definition (except for counterSignature) should state: "This
attribute type must have a single attribute value."

- John Pawling

At 11:37 AM 4/21/98 -0700, Jim Schaad (Exchange) wrote:
>I have a problem with this proposal as it appears overly restrictive to me.
>I have no problem with a general statement that all attribute types MUST
>have a single attribute value unless the definition of the attribute
>explicity allows for multiple values to occur.  However I don't like the
>idea of restricting any and all new attributes which are to come in the
>future.
>
>jim
>
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Tuesday, April 21, 1998 11:19 AM
>To: [email-masked]
>Subject: Single-Valued Attributes Proposal
>
>
>All,
>
>CMS defines the syntaxes for attributes as follows:
>
>   AuthAttribute ::= SEQUENCE {
>     attrType OBJECT IDENTIFIER,
>     critical BOOLEAN DEFAULT FALSE,
>     attrValues SET OF AttributeValue }
>
>   UnauthAttribute ::= SEQUENCE {
>     attrType OBJECT IDENTIFIER,
>     attrValues SET OF AttributeValue }
>
>In both cases, attrValues is a SET OF AttributeValue (i.e. ANY).
>
>CMS states that the contentType, messageDigest, and signingTime attributes
>must have a single attribute value.  CMS states that the counterSignature
>attribute may have multiple attribute values.  ESS and MSG don't include any
>statements for the attributes defined in those specs.
>
>Propose that all attribute types MUST must have a single attribute value
>except for counterSignature (for backwards compatibility purposes). This
>requires additional text to be added to ESS and MSG.  I will include
>detailed comments in my comments to the ESS and MSG specs.
>
>================================
>John Pawling, [email-masked]                             
>J.G. Van Dyke & Associates, Inc.   
>www.jgvandyke.com         
>================================
>
>

Date: Tue, 21 Apr 1998 14:47:33 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Single Instance of Attributes Proposal
Sender: [email-masked]

All,

CMS defines authenticatedAttributes as a SET OF AuthAttribute and
unAuthenticatedAttributes as a SET OF UnauthAttribute.  The ESS I-D
specifically states that a signerInfo MUST NOT include multiple instances of
any of the following attributes: mlExpansionHistory, receiptRequest and
eSSSecurityLabel.  Propose that all of the other types of attributes (except
counterSignature) should be limited by the same rules.  This requires
additional text to be added to ESS, CMS and MSG.  I will include detailed
comments in my comments to the next round of these specs.  

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

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: Single-Valued Attributes Proposal
Date: Tue, 21 Apr 1998 11:37:34 -0700
Sender: [email-masked]

I have a problem with this proposal as it appears overly restrictive to me.
I have no problem with a general statement that all attribute types MUST
have a single attribute value unless the definition of the attribute
explicity allows for multiple values to occur.  However I don't like the
idea of restricting any and all new attributes which are to come in the
future.

jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, April 21, 1998 11:19 AM
To: [email-masked]
Subject: Single-Valued Attributes Proposal

All,

CMS defines the syntaxes for attributes as follows:

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

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

In both cases, attrValues is a SET OF AttributeValue (i.e. ANY).

CMS states that the contentType, messageDigest, and signingTime attributes
must have a single attribute value.  CMS states that the counterSignature
attribute may have multiple attribute values.  ESS and MSG don't include any
statements for the attributes defined in those specs.

Propose that all attribute types MUST must have a single attribute value
except for counterSignature (for backwards compatibility purposes). This
requires additional text to be added to ESS and MSG.  I will include
detailed comments in my comments to the ESS and MSG specs.

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

Date: Tue, 21 Apr 1998 14:19:25 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Single-Valued Attributes Proposal
Sender: [email-masked]

All,

CMS defines the syntaxes for attributes as follows:

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

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

In both cases, attrValues is a SET OF AttributeValue (i.e. ANY).

CMS states that the contentType, messageDigest, and signingTime attributes
must have a single attribute value.  CMS states that the counterSignature
attribute may have multiple attribute values.  ESS and MSG don't include any
statements for the attributes defined in those specs.

Propose that all attribute types MUST must have a single attribute value
except for counterSignature (for backwards compatibility purposes). This
requires additional text to be added to ESS and MSG.  I will include
detailed comments in my comments to the ESS and MSG specs.

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

Date: Tue, 21 Apr 1998 08:57:27 -0400
To: [email-masked] (David P. Kemp), [email-masked], [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: ESS WG Last Call
Sender: [email-masked]

All,

I agree with Dave Kemp's proposal to include Signed Content Reference
Attribute in ESS.  

- John Pawling

Date: Mon, 20 Apr 1998 18:07:53 -0700
From: [email-masked] (Jeff Weinstein)
To: Paul Hoffman / IMC <[email-masked]>
CC: [email-masked]
Subject: Re: Degenerate certificates only signedData.
Sender: [email-masked]

Jim Schaad brought this up earlier on the mailing list and at the LA
meeting.  He will be writing an internet draft to describe a signed
message with empty content that would be used for securely distributing
certificates and capabilities.

	--Jeff

Date: Mon, 20 Apr 1998 17:32:36 -0700
To: <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Degenerate certificates only signedData.
Sender: [email-masked]

>What would be the suggested way to do this? A dummy message would
>achieve this end. 

Quite well, and with no ambiguity about what the missing content is. I'd say
this makes lots of sense, and trying to create another kind of structure for
this information doesn't.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 21 Apr 1998 00:11:13 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Degenerate certificates only signedData.
Sender: [email-masked]

The V3 CMS specs support the use of degnerate signedData for
certificates only and thus usable as a means of distributing
certificates, for example on a web page.

I would suggest that what is also frequently needed is a degenerate form
that includes the SMIMECapabilities authenticated attribute. The
reasoning for this is that you not only need the recipients certificate
you also need their capabilities otherwise you have to guess
(RC2-40/triple DES) what they can handle.

It has to be authenticated otherwise an attacker could generate a
certificates only signedData with deliberately weak ciphers.

What would be the suggested way to do this? A dummy message would
achieve this end. 

Alternatively a "no content with authenticated attributes" form would
work. This would contain a SignerInfo structure with signed
authenticated attributes containing signingTime and SMIMECapabilities
but would exclude the contentType and messageDigest attributes and any
content. This is currently not permitted by the CMS spec.

Steve.
-- 
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Mon, 20 Apr 1998 17:27:52 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked], [email-masked]
Subject: Re: ESS WG Last Call
Sender: [email-masked]

> From: Russ Housley <[email-masked]>
> 
> The Internet Drafts editor has posted draft-ietf-smime-ess-05.txt. Based on
> the discussions on the list and talking to people at the LA meeting, I
> think it is ready for WG Last Call.
> 
> The other documents (CMS, MSG, and CERT) are not quite ready for last call,
> but I see no problem with ESS progressing to WG Last Call now.  However, it
> will not progress out of the working group without CMS.
> 
> Happy reading,
>   Russ
>   S/MIME WG Chair

Russ,

  ESS draft -05 currently has no description of the contentIdentifier
attribute other than the single sentence in section 1.3:

    ContentIdentifier is an attribute (OCTET STRING) used to carry a unique
    identifier assigned to the message.

The definition of id-aa-contentIdentifier is included under section 2.7
"Receipt Request Syntax", but there is no further discussion of what
the attribute is to be used for or how it is to be constructed.

The only discussion of this attribute I can find is the following message:

> Date: Mon, 2 Feb 1998 15:10:56 -0500
> From: [email-masked] (John Pawling)
> Subject: Re: New S/MIME OIDs
> 
> 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

I request that the following attribute, which is used in conjunction
with id-aa-contentIdentifier, be added to ESS.

In accordance with John Pawling's request to segregate the description
of generic content references from the description of receipts, I
withdraw my suggestion to modify Receipt to maximize its commonality
with this definition.

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

2.11 Signed Content Reference Attribute

The contentReference attribute is a link from one SignedData to
another.  It may be used to link a reply to the original message to
which it refers, or to incorporate by reference one SignedData into
another.  The first SignedData MUST include a contentIdentifier
signed attribute, which SHOULD be constructed as specified in section
2.7.  The second SignedData links to the first by including a
ContentReference signed attribute containing the content type, content
identifier, and signature value from the first SignedData.

ContentReference ::= SEQUENCE {
  contentType ContentType,
  signedContentIdentifier ContentIdentifier,
  originatorSignatureValue OCTET STRING }

id-aa-contentReference   OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 8 }

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

Date: Mon, 20 Apr 1998 13:36:34 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: ESS WG Last Call
Sender: [email-masked]

The Internet Drafts editor has posted draft-ietf-smime-ess-05.txt. Based on
the discussions on the list and talking to people at the LA meeting, I
think it is ready for WG Last Call.

The other documents (CMS, MSG, and CERT) are not quite ready for last call,
but I see no problem with ESS progressing to WG Last Call now.  However, it
will not progress out of the working group without CMS.

Happy reading,
  Russ
  S/MIME WG Chair

Date: Mon, 20 Apr 1998 13:24:42 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: RE: Signed Label (was RE: 'Signature Purpose' attribute?)
Sender: [email-masked]

> From: "Jim Schaad (Exchange)" <[email-masked]>
> 
> I can provide an even better example of this:
> 
> Lets assume that I, being a normally nasty person, places two different
> signatures on a message.  The first signature is a DSS signature which
> contains an unclasified label on it.  The second signature is an RSA
> signature and contains a classified label on it.

Jim,

First and most importantly, I withdraw the proposal to allow signatures
with different labels in the same SignedData.  Not because I'm convinced
that a restriction on label equality is useful, but because further
discussion seems counterproductive at this time.

However, in your scenario, the message had better be unclassified, or
the user is in trouble.  There are probably criminal penalties for
the unauthorized release of {classified/company proprietary} information.
If there are penalties at all for putting a classified/proprietary
label on unrestricted information, they are probably much less severe.

You, being a normally nasty person :-), nonetheless probably aren't a
masochist seeking to be fired or fined, so your message probably doesn't
contain any labels with your signature on them which could get you in
trouble.  If it does, you asked for it.  This has nothing to do with
the label equality question - you'd be in just as much trouble if you
put an RSA signature and a DSA signature with identical unclassified
labels on a message which was classified.

I assume a threat model where:
1) the message originator operates "correctly" (in accordance with the
   protocol specification and applicable security policy), and
2) attackers are active (are able to modify messages in transit) but
   do not possess unauthorized private keys.

The attacker's goal is to convince the recipient, or anyone else, that
the originator said something other than what the originator actually
said.

I contend that in the assumed environment, the restriction that labels
in a single SignedData be identical accomplishes nothing.  If originator
"x" creates a SignerInfo with label "X", and entity "y" creates a
SignerInfo with label "Y", then there is no important* cryptographic
distinction between putting those two SignerInfos in a single SignedData
or in encapsulated SignedData's.  In either case, one or both signatures
can be stripped from the message by an adversary, and one or more signatures
may be created using the adversary's private key(s).

-----
* The cryptographic distinction is that with encapsulated SignedDatas,
"y" binds signature "x" to the original message.  This would be important
if there were a requirement that "a message signed by x is not recognized
as valid unless it is wrapped by y".  Since there is no such requirement,
there is no reason to force SignerInfos with labels X and Y to be in
different SignedDatas.

Again, I withdraw the suggestion to remove the label equality restriction,
despite my belief that the restriction adds no security value to S/MIME.

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Signed Label (was RE: 'Signature Purpose' attribute?)
Date: Sun, 19 Apr 1998 18:44:48 -0700
Sender: [email-masked]

I can provide an even better example of this:

Lets assume that I, being a normally nasty person, places two different
signatures on a message.  The first signature is a DSS signature which
contains an unclasified label on it.  The second signature is an RSA
signature and contains a classified label on it.

Your client receives the message. It understands DSS, but not RSA.  Your
client treats the message as unclassified.

You get a new client which understand both, it now verifies both signatures
and treats the message as classified.

Note that I can get simplier behavior by causing one of the signatures to be
corrupted and leaving the other (or adding a new signature with a new label)
along.

jim schaad

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, April 13, 1998 2:33 PM
To: [email-masked]; [email-masked]
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)

Dave,

>If you could produce an example demonstrating an incorrect access
>control decision, I would be more inclined to believe this assertion.

OK, lets assume that anybody can add whatever eSSSecuritylabel to a
signedData object that they desire.  Assume User A drafts a content, decides
that the content is classified ACME PROPRIETARY and sends the signedData in
which User A's signerInfo includes an ESSSecurityLabel including the ACME
PROPRIETARY security classification.  Assume user B receives user A's
signedData, decodes it, decides that it should really be classified as ACME
PERSONNEL DATA.  User B adds her signerInfo to the original signedData
object in which she includes an ESSSecurityLabel including the ACME
PERSONNEL DATA security classification and sends it off.  User C receives
the signedData from User B.  User C's software verifies User B's signerInfo
and User A's signerInfo.  User C's SW detects one ESSSecurityLabel including
the ACME PROPRIETARY security classification and another ESSSecurityLabel
including the ACME PERSONNEL DATA security classification.  What is the real
classification of the content????   That is the problem.

>My assertion is that the identical decision will be produced from a
>set of semantically different labels regardless of whether the signatures
>are wrapped or parallel.

I disagree.  With the current ESS strategy, a separate decsion is made for
each encapsulated content.  That is an important distinction.

>Consider the following two messages, where the boxes represent SignedData
>structures, and "Label X" and "Label Y" represent semantically different
>eSSSecurityLabels contained in the signed-attributes of two SignerInfo
>structures.  With the current restriction, only the left message is legal.
>If the restriction were eliminated, both the left and the right messages
>would be legal, and the choice of which to use could be based on other
>criteria.
>
>   _____________          _________
>  |  _________  |        | Content |
>  | | Content | |        |- - - - -|
>  | |- - - - -| |        | Label X |
>  | | Label X | |        |- - - - -|
>  | |_________| |        | Label Y |
>  |- - - - - - -|        |_________|
>  |   Label Y   |
>  |_____________|
>
>
>An ACDF operating on Label Y and the recipient's privileges will produce
>a binary access decision "Grant" or "Deny" (True or False).  An ACDF on
>Label X and the recipient's privileges will produce another binary
>decision.  Please explain how those decisions when applied to the left
>message will be correct and consistent, while the same decisions applied
>to the right message might be erroneous or inconsistent.

First, let me add some detail to your left diagram:

   _______________          
  |  ___________  |
  | |           | |
  | | _________ | | 
  | ||  Inner  || |
  | || Content || | 
  | ||- - - - -|| | 
  | || Label X || | 
  | ||_________|| | 
  | |           | | 
  | |   Outer   | |
  | |  Content  | |
  |  -----------  |
  |- - - - - - - -|       
  |    Label Y    |
  |_______________|

My point is that there are two completely independent access control
decisions made.  One decision is based on Label Y which applies to the outer
content.  The other decision is based on Label X which applies to the inner
content.  This "nested signedData" strategy provides the local organization
with the flexibility to generate its security policy such that the actions
taken when an access control failure occurs while processing an outer
signedData are different (if required) than when an access control failure
occurs while processing an inner signedData.  The "nested signedData"
strategy makes this simple to specify and simple to implement.  

In the model on the right, there is a single access control decision
applying to the content that includes Label X and Label Y as inputs.  If
Label X and Label Y are different, what is the real classification of the
content upon which the single access control decsion is to be based????
That is the problem.

>(Remember too that we're discussing recipient-based access control of
>unencrypted data, which is a near-zero-assurance process.  But that's
>another topic altogether.)

We are not talking ONLY about recipient-based access control decisions.  The
current ESS strategy does not limit access control to ONLY being
recipient-based.  An access control strategy MUST include checking a
recipient's authorizations before sending sensitive data to that recipient
to ensure that the recipient's authorizations indicate that the recipient is
allowed to have access to the data.  IMHO, we should not specify access
control strategies in the S/MIME specs.  This should be left to the local
organizations.

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

Date: Fri, 17 Apr 1998 16:36:19 -0400
To: [email-masked]
From: John Lowry <[email-masked]>
Subject: Re: Authenticated Attributes DER vs BER
Sender: [email-masked]

Some ASN.1 compilers understand this problem already and
are prepared to present the data to the application as it
was received or will force a DER encoding.

Ordering of SET OF is old news and not all that hard anyway.  
Can we move on ?

At 01:52 PM 4/17/98 -0400, David P. Kemp wrote:
>> From: "Phillip M Hallam-Baker" <[email-masked]>
>> 
>> I agree with Eric.
>> 
>> If a cannonical encoding is important then it is probably
>> necessary to avoid ASN.1 at all costs, DER is simply too
>> great an overhead for the functionality provided.
>
>I would rephrase that to say "it is probably necessary to avoid
>SET OF at all costs".
>
>However, those of us who wanted to base S/MIME on PKCS#7 v2 were
>overruled by those who wanted backward compatibility with v1.5.
>A non-ASN.1 solution would fail the backward compatibility test
>just as surely as a DER-friendly solution :-).
>
>
>I agree with the rest of what Phil says, but still believe that the
>spec should be silent on receiver reordering.  When it comes time to
>point fingers, it will be easy to demonstrate who's transmitter is
>noncompliant.
>
>

Date: Fri, 17 Apr 1998 14:25:22 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Authenticated Attributes DER vs BER -Reply
Sender: [email-masked]

All,

I agree with Darren.  

- John Pawling

At 07:05 PM 4/17/98 +0100, Darren Harter wrote:
>I think we may have missed the point here slightly.
>
>The issue is that a given attribute in the set of authenticated
>attributes is not recognised by the receiver.  In order to verify the
>sig the receiver needs to have the DER encoding of the unknown
>attributes value part.
>
>It is essential that individual attributes are encoded using DER for
>both signature processing and transmission.
>
>It is essential for the SET OF Attribute(s) to be ordered according to
>DER for sig processing.
>
>It is not essential for the SET OF Attribute(s) to be ordered according
>to DER for transmission as the receiver can reorder them before sig
>processing.
>
>To summarise the SET OF Attribute(s) may be BER encoded for
>transmission, but the value part of each Attribute (SET OF ANY DEFINED
>BY etc) must be ordered and encoded using DER for transmission is
>unknwon attributes are to be verified properly.
>
>Hope this clears things up a bit.
>
>Darren
>
>p.s. If going to be offline until the 27th, so I'll catch up with this
>thread then.
>

Date: Fri, 17 Apr 1998 19:05:53 +0100
From: Darren Harter <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: Authenticated Attributes DER vs BER -Reply
Sender: [email-masked]

I think we may have missed the point here slightly.

The issue is that a given attribute in the set of authenticated
attributes is not recognised by the receiver.  In order to verify the
sig the receiver needs to have the DER encoding of the unknown
attributes value part.

It is essential that individual attributes are encoded using DER for
both signature processing and transmission.

It is essential for the SET OF Attribute(s) to be ordered according to
DER for sig processing.

It is not essential for the SET OF Attribute(s) to be ordered according
to DER for transmission as the receiver can reorder them before sig
processing.

To summarise the SET OF Attribute(s) may be BER encoded for
transmission, but the value part of each Attribute (SET OF ANY DEFINED
BY etc) must be ordered and encoded using DER for transmission is
unknwon attributes are to be verified properly.

Hope this clears things up a bit.

Darren

p.s. If going to be offline until the 27th, so I'll catch up with this
thread then.

Date: Fri, 17 Apr 1998 14:10:17 -0400
To: <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Authenticated Attributes DER vs BER
Sender: [email-masked]

Phillip,

I respectfully disagree with your comments.  At a minimum, the CMS spec must
mandate: "Each individual authenticatedAttribute MUST be DER-encoded and the
SET OF authenticatedAttributes MUST be ordered as per DER when they are
digested to generate or verify the signedData signerInfo signature value.
Furthermore, each individual authenticatedAttribute MUST be DER-encoded when
it is transmitted."

The day is coming when there will be gateways that decode CMS objects, add
fields and then re-encode them.  If we do not specify DER and these gateways
change the order of the authenticatedAttributes, then the recipient will not
be able to re-construct the authenticatedAttributes that were digested by
the signer.  

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

I

Date: Fri, 17 Apr 1998 13:52:48 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Authenticated Attributes DER vs BER
Sender: [email-masked]

> From: "Phillip M Hallam-Baker" <[email-masked]>
> 
> I agree with Eric.
> 
> If a cannonical encoding is important then it is probably
> necessary to avoid ASN.1 at all costs, DER is simply too
> great an overhead for the functionality provided.

I would rephrase that to say "it is probably necessary to avoid
SET OF at all costs".

However, those of us who wanted to base S/MIME on PKCS#7 v2 were
overruled by those who wanted backward compatibility with v1.5.
A non-ASN.1 solution would fail the backward compatibility test
just as surely as a DER-friendly solution :-).

I agree with the rest of what Phil says, but still believe that the
spec should be silent on receiver reordering.  When it comes time to
point fingers, it will be easy to demonstrate who's transmitter is
noncompliant.

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "David P. Kemp" <[email-masked]>, "EKR" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Authenticated Attributes DER vs BER
Date: Fri, 17 Apr 1998 13:46:51 -0400
Sender: [email-masked]

I agree with Eric.

If a cannonical encoding is important then it is probably
necessary to avoid ASN.1 at all costs, DER is simply too
great an overhead for the functionality provided. In most
cases people are simply not interested in re-ordering
parts of signed data.

The big problem with the DER issue is one of scope,
even the requirement that the attributes be DER
encoded is more than flakey IMHO. Consider the
case in which an attribute is defined for convenience
as Octet String even though it is in fact an ASN.1
structure (say the draft editor of the attribute had an
ASN.1 version headache). What is not too obvious
is that this also cuts a hole in the scope of a DER
formatting requirement for the enclosing structure.

As good ideas go the idea of a canonical encoding
has tended to be overated. If people really do take
certificates, break them appart and store the components
in a database with the intention of re-assembly then
fair enough. I tend to think that with disk space at
$50 per Gb that keeping a copy of the original bit
structure arround is much less hassle. And in any case
I don't think that relying on other folk to do DER properly
makes any sense.

This will seriously impact performance and I don't see
any real value that is added.

        Phill

-----Original Message-----
From: EKR <[email-masked]>
To: David P. Kemp <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Friday, April 17, 1998 11:31 AM
Subject: Re: Authenticated Attributes DER vs BER

>[email-masked] (David P. Kemp) writes:
>
>> >From: "Blake Ramsdell" <[email-masked]>
>> >
>> > In the spirit of "being liberal in what you accept" and
>> > interoperability, I think some language is needed.  How about
"receiving
>> > agents SHOULD NOT reorder the SET OF according to DER"?
>>
>> "being liberal in what you accept" leads to the position that receiving
>> agents SHOULD reorder the SET OF, in order to accept the widest variety
>> of input.
>Not necessarily. Let's assume that you receive a message where the
>SET OF IS misordered. There are two possibilities:
>1. The data that was signed is the DER ordered data (I.e. NOT the
>data that was transmitted).
>2. The data that was signed is the data that was transmitted.
>
>In my experience, (2) is the far more likely event.
>
>I appreciate that this defeats the entire purpose of using DER
>but in practice we're not dealing with intermediate
>systems that are likely to reorder DER in transit. However,
>the probability that end systems will (mistakenly) sign BER
>seems a lot higher.
>
>-Ekr
>
>--
>[Eric Rescorla                             Terisa Systems, Inc.]
> "Put it in the top slot."
>

Date: Fri, 17 Apr 1998 12:32:24 -0400
To: EKR <[email-masked]>, [email-masked] (David P. Kemp)
From: [email-masked] (John Pawling)
Subject: Re: Authenticated Attributes DER vs BER
Cc: [email-masked]
Sender: [email-masked]

Eric,

Please see my response to Blake's message.  If an implementation is signing
BER-encoded authenticatedAttributes, then it is broken and it must be fixed.
The other implementations should not have to take special actions to
compensate for broken implementations.  

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

Date: Fri, 17 Apr 1998 12:30:13 -0400
To: <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Authenticated Attributes DER vs BER
Sender: [email-masked]

Blake,

IMHO, the S/MIME specs should not be written with the assumption that
implementations are not going to properly implement the specs.  If an
implementation is signing BER-encoded authenticatedAttributes, then it is
broken and it must be fixed.  The other implementations should not have to
take special actions to compensate for broken implementations.  

Therefore, I agree with Dave Kemp that IF we agree that the entire SET OF
authenticatedAttributes must be tranmitted in a DER-encoded form, THEN the
specs should say nothing about the recipient re-encoding/re-ordering the SET
OF authenticatedAttributes.

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

To: [email-masked] (David P. Kemp)
Cc: [email-masked]
Subject: Re: Authenticated Attributes DER vs BER
From: EKR <[email-masked]>
Date: 17 Apr 1998 08:28:13 -0700
Lines: 30
Sender: [email-masked]

[email-masked] (David P. Kemp) writes:

> >From: "Blake Ramsdell" <[email-masked]>
> >
> > In the spirit of "being liberal in what you accept" and
> > interoperability, I think some language is needed.  How about "receiving
> > agents SHOULD NOT reorder the SET OF according to DER"?
> 
> "being liberal in what you accept" leads to the position that receiving
> agents SHOULD reorder the SET OF, in order to accept the widest variety
> of input.
Not necessarily. Let's assume that you receive a message where the
SET OF IS misordered. There are two possibilities:
1. The data that was signed is the DER ordered data (I.e. NOT the
data that was transmitted).
2. The data that was signed is the data that was transmitted.

In my experience, (2) is the far more likely event. 

I appreciate that this defeats the entire purpose of using DER
but in practice we're not dealing with intermediate
systems that are likely to reorder DER in transit. However,
the probability that end systems will (mistakenly) sign BER
seems a lot higher.

-Ekr

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

Date: Fri, 17 Apr 1998 09:02:41 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: RE: Authenticated Attributes DER vs BER
Sender: [email-masked]

>From: "Blake Ramsdell" <[email-masked]>
>
> In the spirit of "being liberal in what you accept" and
> interoperability, I think some language is needed.  How about "receiving
> agents SHOULD NOT reorder the SET OF according to DER"?

"being liberal in what you accept" leads to the position that receiving
agents SHOULD reorder the SET OF, in order to accept the widest variety
of input.

However, I believe the spec may reasonably be silent on the issue of
receiver reordering - there's no need for a receiver recommendation if the
transmitted SET OF MUST be DER-ordered.  I agree that the transmitter
MUST DER encode the SET OF attributes, and I agree with John that the
receiver spec should not say SHOULD NOT.

Dave Kemp

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, <[email-masked]>
Subject: RE: Authenticated Attributes DER vs BER
Date: Thu, 16 Apr 1998 14:51:49 -0700
Sender: [email-masked]

On Thursday, April 16, 1998 2:01 PM, [email-masked]
[SMTP:[email-masked]] wrote:
> I respectfully disagree for the reasons that I stated before.  There
is
> no
> reason why the receiving agent should not be able to decode the
> signedData
> and re-DER-encode the authenticatedAttributes.  Your proposed text
> strongly
> discourages that behavior.

My points are as follows:

1. This exact problem has happened in the past -- a sending agent has
failed to order the SET OF according to DER.  This is the senders
problem because their code is broken.

2. By saying "SHOULD NOT re-encode the attributes", implementors take
pause and say "Hmm.  It really isn't necessary to recode these as DER.
I won't.", which would solve the problem in 1.

3. By saying "SHOULD NOT re-encode the attributes", we are discouraging
the (IMHO completely unnecessary) behavior, but we are not precluding
it.

Your point has consistently been that "some receiving agents must
re-encode the attributes as DER as a course of normal processing".  My
language does not prohibit that behavior, and will simply illustrate a
potential interoperability problem surrounding the digesting of
authenticated attributes.  As far as strongly discouraging the behavior
-- why is that a problem?  You can still do it if you want, at the risk
of not being able to verify signatures from broken senders that don't
use DER on the authenticatedAttributes.

I don't see my change as harmful at all, and I think the only thing it
will do is enhance interoperability.  Unfortunately, I happen to be on
the losing side, since I would like to propose new language that you
oppose, and there isn't enough interest in the topic for others to take
sides, which causes the new language to automatically lose.  All I can
do is say that this has been an interoperability issue in the past and
it can be addressed without compromise using the language I have
proposed.

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, 16 Apr 1998 14:48:48 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: New version of CMS draft
Sender: [email-masked]

At 08:01 AM 4/16/98 -0700, Paul Hoffman / IMC wrote:
>The -04 version of the CMS draft is now available at
><http://www.imc.org/draft-ietf-smime-cms>. It should appear in the Internet
>Drafts directory shortly, but we thought we'd make it available sooner so
>people can start implementing from the changes.

Well, yes, I said that, but it wasn't true. Somehow, one of the demons that
inhabit mail systems got out and Russ' mail program sent me another copy of
the current draft. The draft I mention above is identical to the draft that
has been around for a while.

In other words, never mind...

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 16 Apr 1998 17:01:23 -0400
To: "Blake Ramsdell" <[email-masked]>, <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Authenticated Attributes DER vs BER
Sender: [email-masked]

Blake,

>In the spirit of "being liberal in what you accept" and
>interoperability, I think some language is needed.  How about "receiving
>agents SHOULD NOT reorder the SET OF according to DER"?

I respectfully disagree for the reasons that I stated before.  There is no
reason why the receiving agent should not be able to decode the signedData
and re-DER-encode the authenticatedAttributes.  Your proposed text strongly
discourages that behavior.

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

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, <[email-masked]>
Subject: RE: Authenticated Attributes DER vs BER
Date: Thu, 16 Apr 1998 13:37:14 -0700
Sender: [email-masked]

On Thursday, April 16, 1998 1:22 PM, [email-masked]
[SMTP:[email-masked]] wrote:
> "CMS should mandate that each individual authenticatedAttribute MUST
be
> DER-encoded and the SET OF authenticatedAttributes MUST be ordered as
> per
> DER when they are digested to generate or verify the signedData
> signerInfo
> signature value.  Furthermore, CMS should mandate that each individual
> authenticatedAttribute MUST be DER-encoded when it is transmiited, but
> the
> SET OF authenticatedAttributes need not be ordered as per DER when
they
> are
> transmitted."  
> 
> The alternative proposal is: "CMS mandates that each individual
> authenticatedAttribute MUST be DER-encoded and the SET OF
> authenticatedAttributes MUST be ordered as per DER when they are
> digested to
> generate or verify the signedData signerInfo signature value AND when
> they
> are transmitted.
> 
> Personally, I don't care which proposal gets accepted.

I vote, er, am in favor of the alternative proposal -- everything is DER
in the authenticatedAttributes.

> I respectfully disagree.  Many S/MIME receiving agents will totally
> decode
> the received CMS signedData and then re-DER-encode the
> authenticatedAttributes to be digested to support a signature
> verification.
> Therefore, when they re-encode the SET OF authenticatedAttributes,
they
> will
> enforce the DER ordering rules.  If everybody is implementing DER
> correctly,
> then this is not a problem.  If somebody's code does DER incorrectly,
> then
> they should fix their code.

In the spirit of "being liberal in what you accept" and
interoperability, I think some language is needed.  How about "receiving
agents SHOULD NOT reorder the SET OF according to DER"?

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, 16 Apr 1998 16:22:06 -0400
To: <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Authenticated Attributes DER vs BER 
Sender: [email-masked]

Blake,

The last time that I talked to Russ, he supports the following proposal:
"CMS should mandate that each individual authenticatedAttribute MUST be
DER-encoded and the SET OF authenticatedAttributes MUST be ordered as per
DER when they are digested to generate or verify the signedData signerInfo
signature value.  Furthermore, CMS should mandate that each individual
authenticatedAttribute MUST be DER-encoded when it is transmiited, but the
SET OF authenticatedAttributes need not be ordered as per DER when they are
transmitted."  

The alternative proposal is: "CMS mandates that each individual
authenticatedAttribute MUST be DER-encoded and the SET OF
authenticatedAttributes MUST be ordered as per DER when they are digested to
generate or verify the signedData signerInfo signature value AND when they
are transmitted.

Personally, I don't care which proposal gets accepted.

>Is there a good reason to have the authenticatedAttributes at the sender
>in DER format for the purpose of calculating the signature, and then
>reorder them to put them in the message?  

Not that I know of.  

>And in the event that we mandate DER encoding on transmission, I propose
>that receiving agents MUST NOT attempt to recode the attributes as DER.

I respectfully disagree.  Many S/MIME receiving agents will totally decode
the received CMS signedData and then re-DER-encode the
authenticatedAttributes to be digested to support a signature verification.
Therefore, when they re-encode the SET OF authenticatedAttributes, they will
enforce the DER ordering rules.  If everybody is implementing DER correctly,
then this is not a problem.  If somebody's code does DER incorrectly, then
they should fix their code.

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

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, <[email-masked]>
Subject: RE: Authenticated Attributes DER vs BER (Was 30 Mar 98 S/MIME WG Minutes)
Date: Thu, 16 Apr 1998 12:44:53 -0700
Sender: [email-masked]

On Thursday, April 16, 1998 6:21 AM, [email-masked]
[SMTP:[email-masked]] wrote:
>  Furthermore,
> CMS should mandate that each individual authenticatedAttribute MUST be
> DER-encoded when it is transmiited, but the SET OF
> authenticatedAttributes
> need not be ordered as per DER when they are transmitted."  In other
> words,
> the authenticatedAttributes can be transmitted in any order and the
> receiving software MUST ensure that they are ordered as per DER before
> digesting them to verify the signature.

Got it.  The text from the minutes is:

>Russ stated that his initial position is to
>mandate DER-encoding of the authenticatedAttributes. This solves the
>problem
>stated by Darren, because the receiving agent can simply hash over the
>transmitted DER-encoded authenticatedAttributes without decoding and
>re-encoding them. This issue will be resolved through messages on the
>S/MIME
>mail list.

Which indicates that Russ's position is that the entire
authenticatedAttributes MUST be DER encoded on transmission, which was
the reason for my original post.  I would think that this would be the
version that went into the draft.

Personally, I like the version that's in the minutes (unless I am
misinterpreting them) -- mandate that the entire authenticatedAttributes
be DER encoded.

Is there a good reason to have the authenticatedAttributes at the sender
in DER format for the purpose of calculating the signature, and then
reorder them to put them in the message?  It seems like that would not
be useful, unless there was a deliberate ordering that the sender was
trying to impress (which flies in the face of using a SET, of course).

And in the event that we mandate DER encoding on transmission, I propose
that receiving agents MUST NOT attempt to recode the attributes as DER.

I may have missed something, however.

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, 16 Apr 1998 11:36:52 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: RE: Rethinking Receipt
Sender: [email-masked]

> From: [email-masked] (John Pawling)
> 
> Rik,
> 
> I respectfully disagree with your proposal to add fields to the ESS signed
> receipt to accomplish MDN functionality.

I don't believe it is necessary to add fields to the receipt syntax
in order to accomplish MDN functionality.

Instead of interpreting proposals literally and picking them apart based
on narrow issues, perhaps it would be more productive for us all to
attempt to understand what the proposer has in mind.
"Read what I meant, not what I wrote" - computers are literal, but humans
are supposed to be able to exercise judgement.

> From: Paul Hoffman / IMC <[email-masked]>
> 
> >reply: user does a reply-to email or news
> 
> Rat hole alert! Megabytes have been wasted on the DRUMS WG mailing list
> about this topic recently. There is no consensus on the topic. To be
> honest, there is violent disagreement. There is no agreement on what
> "reply-to" means.

Paul, respectfully speaking, I don't give a rat's behind about the
specific semantics of an RFC822 Reply-to: email header field.  I used
the term "reply-to" generically, to indicate that a human user has seen
a message and wishes to respond to it in some manner.  Nothing more.

> >and assuming that all four have a requirement to provide an integrity-
> >  protected link from the response back to the original message it is
> >  responding to,
> 
> Wrong. This is not mentioned in DSNs or MDNs.

Has the Security Area Director sufficiently drummed into our heads the
fact that the Security working groups SHALL work more closely with the
Application working groups to accomplish common goals?

I assume that Applications have some requirement for meaningful
security.  I assume that authors of Application RFCs are not necessarily
security experts.  I assume that if we, as security experts, identify
an instance where the security of applications can be improved, it is
up to us to draft both the requirements/security-considerations/vulner-
ability assessments and the proposed solutions for consideration by
the Application folks, and work interactively with them to iterate
down to the best solution.

If our position is "they didn't state it as an unmet requirement in
RFC 1894 or RFC 2298, therefore we have no responsibility to address it",
then fine.  We'll just produce our RFCs, declare victory, and go home.

> >How about the reply case, where the user wants to say "I agree with
> >your proposal" and wants to guarantee that his reply is unambiguous
> >without including the entire original text in the reply?
> 
> This is a new topic, and an interesting one. You are suggesting an
> unambiguous message-identifier that can be inserted in a signed message as
> a reference. You may want to look at draft-fielding-uri-syntax-02.txt and
> see if your proposal fits into that framework.

It could be forced to fit, but doing so would be highly duplicative.

Here's a picture of two scenarios, ESS Receipt and a generic reply:

Scenario 1:
  Message 1:                     Message 2 (ESS Receipt):
  _______________________        _____________________________
 | Content (id-data)     |      | Content (id-ct-receipt)     |
 |- - - - - - - - - - - -|      |  SignedContentID, SigValue  |
 | SignerInfo            |      |- - - - - - - - - - - - - - -|
 |  id-aa-ReceiptRequest |      | SignerInfo                  |
 |   SignedContentID     |      |_____________________________|
 |_______________________|

Scenario 2:
  Message 1:                   Message 2 (response to message 1):
  _____________________        _______________________________
 | Content (id-data)   |      | Content (id-data)             |
 |- - - - - - - - - - -|      |- - - - - - - - - - - - - - - -|
 | SignerInfo          |      | SignerInfo                    |
 |  id-aa-ContentID    |      |  id-aa-SignedContentReference |
 |    ContentURI       |      |   ContentURI, SigValue        |
 |_____________________|      |_______________________________|

If you wanted to use URI syntax, it would have to uniquely identify
the message for retrieval purposes, and be included in the signed
attributes of Message 1 to prevent tampering/substitution.
Draft-fielding-uri-syntax-02.txt lists examples of ftp, gopher, http,
mailto, news, and telnet URIs, but it does not give any examples
of retrieving a message (say via ftp or http) using Message-IDs or
some other unique identifier.   Since ESS currently has a perfectly
good recommendation for the construction of ContentIdentifier, it
seemed reasonable to reuse it.  However, if there is an equivalent
strength spec for the construction of Message-ID:, one could use
it as the ContentIdentifier.  I don't see any benefit in encoding
either the ESS ContentIdentifier or a Message-ID as a URI for use
in a signed attribute, but if you think it would serve a purpose,
I wouldn't strenuously object to URI encoding.

But forget all of the above for a moment.

My proposal is simply to modify the ESS receipt syntax to change it
from a content type to an attribute.  This would have absolutely no
effect on the operation or semantics of Receipt, and is not
dependent upon any other proposals regarding any other message types.

                                 Message 2 (ESS Receipt):
                                 _____________________________
                                | Content (id-data) (absent)  |
                                |- - - - - - - - - - - - - - -|
                                | SignerInfo                  |
                                |  id-aa-receipt              |
                                |   SignedContentID, SigValue |
                                |_____________________________|

To avoid getting wrapped up in rat holes and irrelevancies, lets
just proceed one step at a time, beginning with this simple proposal.

--- Replace ESS Section 2.8
--- and the corresponding ASN.1 in Appendix A with:

  Section 2.8 Receipt Syntax

  Receipts are represented using the Receipt attribute.  The Receipt
  attribute shall have ASN.1 type Receipt.  Receipts must be carried
  in the signedAttributes of a SignerInfo.  The SignedData eContentType
  field is id-data, and the eContent field is absent.

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

  id-aa-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
     rsadsi(113549) pkxs(1) pkcs-9(9) smime(16) id-aa(2) 8 }

Date: Thu, 16 Apr 1998 08:01:55 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: New version of CMS draft
Sender: [email-masked]

The -04 version of the CMS draft is now available at
<http://www.imc.org/draft-ietf-smime-cms>. It should appear in the Internet
Drafts directory shortly, but we thought we'd make it available sooner so
people can start implementing from the changes.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 16 Apr 1998 09:21:18 -0400
To: <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Authenticated Attributes DER vs BER (Was 30 Mar 98 S/MIME WG Minutes)
Sender: [email-masked]

Blake,

I believe that the issue is whether CMS should mandate that the signedData
signerInfo authenticatedAttributes must be ordered as per the DER during
transmission.  There were sidebar discussions at the LA IETF in which some
of us came up with the following proposal:  "CMS should mandate that each
individual authenticatedAttribute MUST be DER-encoded and the SET OF
authenticatedAttributes MUST be ordered as per DER when they are digested to
generate or verify the signedData signerInfo signature value.  Furthermore,
CMS should mandate that each individual authenticatedAttribute MUST be
DER-encoded when it is transmiited, but the SET OF authenticatedAttributes
need not be ordered as per DER when they are transmitted."  In other words,
the authenticatedAttributes can be transmitted in any order and the
receiving software MUST ensure that they are ordered as per DER before
digesting them to verify the signature.

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

At 02:04 PM 4/15/98 -0700, Blake Ramsdell wrote:
>On Wednesday, April 15, 1998 9:40 AM, Darren Harter
>[SMTP:[email-masked]] wrote:
>> I agree with Russ' proposal to mandate the encoding of
>> authenticatedAttributes in DER.
>
>Is it an error to try to re-encode the attributes as DER on an incoming
>message?  Granted you cannot re-encode the attribute values, but the
>outer SET OF can be reordered according to DER.
>
>We may want to point this out in the spec.  I know that our products
>reorder the outer SET OF for an incoming message according to DER (for
>better or worse), and then do the signature validation.  This actually
>led to an incompatibility with another product that got fixed, but we
>can avoid it in the future by saying that receiving applications MUST
>NOT reorder the attributes according to DER.
>
>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, 16 Apr 1998 08:42:31 -0400
To: Rik Drummond <[email-masked]>, "'David P. Kemp'" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Rethinking Receipt
Sender: [email-masked]

Rik,

I respectfully disagree with your proposal to add fields to the ESS signed
receipt to accomplish MDN functionality.  Your proposal combines two very
different concepts into a single ASN.1 syntax and mechanism.  This will be
extremely confusing to the implementors, users and everyone else involved,
and will make the ESS signed receipt processing significantly more complex.

If the originator needs proof that the recipient simply received a message
and was able to verify its signature, then the originator requests a ESS
signed receipt. The concept is that signed receipts are generated
automatically by the receiving software and are sent automatically to the
originating agent to indicate ONLY that the message was received and the
signature was verified.  There is no human intervention required in this
process. 

Many of the services that you are proposing require a human to make
decisions.  This is a very different concept than ESS signed receipts and
should be separated into a different ASN.1 syntax and implemented separately.

You propose to add some fields to the receipt body.  Although these are
minor syntax changes, they are major semantic changes.  The current ESS
signed receipt strategy allows the recipient's security software module to
generate the signed receipt automatically with no actions required by the
user.  If your proposed fields are added, then the ESS signed receipt can no
longer be constructed automatically by the security software because the
user will need to be prompted regarding which fields must be included in the
signed receipt.  This is a major change in the concept and procesing
requirements of ESS signed receipts.

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

At 04:24 PM 4/15/98 -0500, Rik Drummond wrote:
>I disagree with Paul's comment below also. I agree with David's response. 
>Nice job David.
>
>The only difference is that the MDN carries additional status 
>information.... over and above what the ESS receipt carries. With all the 
>work that was done by the EDIINT and the MDN workgroups on receipts, I 
>would have hoped that some of that functionality would have been included 
>in the ESS stuff.
>
>Lack of this functionality makes use of this a lot harder for the EDIINT 
>workgroup, of which SMIME is a base standard, and other groups like the fax 
>group. So please tell me know how to formally get this functionality into 
>the ESS stuff, without causing delays or problems for the authors.   I 
>would think all we need to do is steal from the MDN status codes and This
is a very different concept
than signed receipts and should be separated into a different ASN.1 syntax..
That does not seem hard to 
>me.
>
>Thanks, Rik

Date: Wed, 15 Apr 1998 23:03:02 -0700
To: Rik Drummond <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: RE: Rethinking Receipt
Cc: "'David P. Kemp'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Sender: [email-masked]

At 04:24 PM 4/15/98 -0500, Rik Drummond wrote:
workgroup, of which SMIME is a base standard, and other groups like the fax 
>group. So please tell me know how to formally get this functionality into 

Hmmm.  No doubt another potential rathole, but the need for accuracy
compels me to note that S/MIME has no specific status within the fax work,
other than being mentioned in a non-normative discussion section about
security issues.  PGP is also mentioned.

d/

ps.  On the other hand, the high-bit in this sort of topic IS a plaintive
cry from MIME-based application services for SOME (that is, ANY)
honest-to-goodness, deployed-and-used global security service.  You know,
something that isn't just fun for security experts to play with, but is
actually useful for non-technical users, interacting globally and without
prior arrangement...

__________________________________________________________________________
Dave Crocker                 Brandenburg Consulting        +1 408 246 8253
[email-masked]       675 Spruce Drive        (f) +1 408 249 6205
www.brandenburg.com         Sunnyvale, CA 94086  USA 

Date: Wed, 15 Apr 1998 22:58:59 -0700
To: Paul Hoffman / IMC <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Rethinking Receipt
Cc: [email-masked]
Sender: [email-masked]

At 02:31 PM 4/15/98 -0700, Paul Hoffman / IMC wrote:
>honest, there is violent disagreement. There is no agreement on what
>"reply-to" means.

Interestingly, there seems to be pretty good agreement about the
algorithmic behavior (use the Reply-To contents instead of the From
contents) but your specific choice of word captures exactly where the
problem lies, namely "meaning", in describing the human communication
issues surrounding use of that algorithm.

And I trust that this, thereby, substantiates why you issued a rathole
alert...

d/
__________________________________________________________________________
Dave Crocker                 Brandenburg Consulting        +1 408 246 8253
[email-masked]       675 Spruce Drive        (f) +1 408 249 6205
www.brandenburg.com         Sunnyvale, CA 94086  USA 

Date: Wed, 15 Apr 1998 14:31:23 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Rethinking Receipt
Sender: [email-masked]

At 04:06 PM 4/15/98 -0400, David P. Kemp wrote:
>DSN: server-to-server notification of transit

Close but not exact. DSNs can also be read by the sender. They are in fact
sent back to the sender. In some environments, they are snagged and
processed before the sender reads them.

>MDN: human recipient tells sender what he did with the message

Close but not exact. It can also be machine-generated. There are status
codes in the MDN for whether it came automatically or from a human.

>ESS Receipt: UA-to-UA notification that sender's signature verified

Correct.

>reply: user does a reply-to email or news

Rat hole alert! Megabytes have been wasted on the DRUMS WG mailing list
about this topic recently. There is no consensus on the topic. To be
honest, there is violent disagreement. There is no agreement on what
"reply-to" means.

>Assuming all four of the above message types use integrity and
>  authentication protection provided by CMS/ESS,

I do not understand what you mean here. If you mean CMS/MSG (that is, the
-msg draft), DSNs and MDNs can be protected, and receiving agents that know
about each can do S/MIME verification. ESS receipts are clearly covered by
CMS/MSG. Reply-to is a rat hole.

>and assuming that all four have a requirement to provide an integrity-
>  protected link from the response back to the original message it is
>  responding to,

Wrong. This is not mentioned in DSNs or MDNs.

>then why do you regard using an ESS SignedContentReference (or
>eSSSecurityReceipt) a layering violation for some of the message types
>(DSNs/MDNs) and not for others (ESS Receipts)?

Well, since I disagree with your assumptions, I can't really answer that. 

>How about the reply case, where the user wants to say "I agree with
>your proposal" and wants to guarantee that his reply is unambiguous
>without including the entire original text in the reply?

This is a new topic, and an interesting one. You are suggesting an
unambiguous message-identifier that can be inserted in a signed message as
a reference. You may want to look at draft-fielding-uri-syntax-02.txt and
see if your proposal fits into that framework.

Before continuing the DSN and MDN thread, please read the RFCs on DSNs
<http://www.imc.org/rfc1894> and MDNs <http://www.imc.org/rfc2298> and base
your comments on specifics from those standards. I believe you will see
that plain S/MIME v3 signing, and possibly ESS receipts, can be used with
either of them in fairly easy fashion.

--Paul Hoffman, Director
--Internet Mail Consortium

From: Rik Drummond <[email-masked]>
To: "'David P. Kemp'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Rethinking Receipt
Date: Wed, 15 Apr 1998 16:24:28 -0500
Sender: [email-masked]

I disagree with Paul's comment below also. I agree with David's response. 
Nice job David.

The only difference is that the MDN carries additional status 
information.... over and above what the ESS receipt carries. With all the 
work that was done by the EDIINT and the MDN workgroups on receipts, I 
would have hoped that some of that functionality would have been included 
in the ESS stuff.

Lack of this functionality makes use of this a lot harder for the EDIINT 
workgroup, of which SMIME is a base standard, and other groups like the fax 
group. So please tell me know how to formally get this functionality into 
the ESS stuff, without causing delays or problems for the authors.   I 
would think all we need to do is steal from the MDN status codes and stick 
a couple of new fields into the receipt body. That does not seem hard to 
me.

Thanks, Rik

-----Original Message-----
From:	David P. Kemp [SMTP:[email-masked]]
Sent:	Wednesday, April 15, 1998 3:06 PM
To:	[email-masked]
Subject:	Re: Rethinking Receipt

> From: Paul Hoffman / IMC <[email-masked]>
>
> ESS-style receipts are different than either of these.

Paul,
  I'm not up to speed on DSNs and MDNs, so forgive me for the
possibly stupid question:

DSN: server-to-server notification of transit
MDN: human recipient tells sender what he did with the message
ESS Receipt: UA-to-UA notification that sender's signature verified
reply: user does a reply-to email or news

Assuming all four of the above message types use integrity and
  authentication protection provided by CMS/ESS,
and assuming that all four have a requirement to provide an integrity-
  protected link from the response back to the original message it is
  responding to,
then why do you regard using an ESS SignedContentReference (or
eSSSecurityReceipt) a layering violation for some of the message types
(DSNs/MDNs) and not for others (ESS Receipts)?

How about the reply case, where the user wants to say "I agree with
your proposal" and wants to guarantee that his reply is unambiguous
without including the entire original text in the reply?

Dave Kemp

From: "Blake Ramsdell" <[email-masked]>
To: "'Darren Harter'" <[email-masked]>, <[email-masked]>, "John Pawling" <[email-masked]>
Subject: RE: Authenticated Attributes DER vs BER (Was 30 Mar 98 S/MIME WG Minutes)
Date: Wed, 15 Apr 1998 14:04:20 -0700
Sender: [email-masked]

On Wednesday, April 15, 1998 9:40 AM, Darren Harter
[SMTP:[email-masked]] wrote:
> I agree with Russ' proposal to mandate the encoding of
> authenticatedAttributes in DER.

Is it an error to try to re-encode the attributes as DER on an incoming
message?  Granted you cannot re-encode the attribute values, but the
outer SET OF can be reordered according to DER.

We may want to point this out in the spec.  I know that our products
reorder the outer SET OF for an incoming message according to DER (for
better or worse), and then do the signature validation.  This actually
led to an incompatibility with another product that got fixed, but we
can avoid it in the future by saying that receiving applications MUST
NOT reorder the attributes according to DER.

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, 15 Apr 1998 16:06:01 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Rethinking Receipt
Sender: [email-masked]

> From: Paul Hoffman / IMC <[email-masked]>
> 
> ESS-style receipts are different than either of these.

Paul,
  I'm not up to speed on DSNs and MDNs, so forgive me for the
possibly stupid question:

DSN: server-to-server notification of transit
MDN: human recipient tells sender what he did with the message
ESS Receipt: UA-to-UA notification that sender's signature verified
reply: user does a reply-to email or news

Assuming all four of the above message types use integrity and
  authentication protection provided by CMS/ESS,
and assuming that all four have a requirement to provide an integrity-
  protected link from the response back to the original message it is
  responding to,
then why do you regard using an ESS SignedContentReference (or
eSSSecurityReceipt) a layering violation for some of the message types
(DSNs/MDNs) and not for others (ESS Receipts)?

How about the reply case, where the user wants to say "I agree with
your proposal" and wants to guarantee that his reply is unambiguous
without including the entire original text in the reply?

Dave Kemp

Date: Wed, 15 Apr 1998 13:39:42 -0400
To: John Ross <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Rethinking Receipt
Cc: [email-masked]
Sender: [email-masked]

John:

I do not know about the UK Postal service, but a receipt from the US Postal
Service means that the parcel was delivered.  It does not mean that the
recipient could comprehend the contents.

The digitally signed receipt offers more service than is available in the
physical world today.

Russ

At 09:10 AM 4/15/98 -0700, John Ross wrote:
>In my view part of the problem is in the name. The service provided by ESS
>signed receipts is a proof that the message was delivered, all signature and
>other security services where OK.  It does not imply that the semantics of
>the message as viewed by the user (or user application) are understood.  It
>could still be rubbish as far as an application processing the message is
>concerned.
>
>I do support the need for the two layers of "Receipt",  one at the point of
>delivery and the other at the point of the EDI application processing (or
>human user notification in the case of E-mail).
>
>Perhaps the name  ESS signed receipt can be changed and made more
>descriptive of  the service it is providing, may I proposed "ESS proof of
>delivery".
>
>Regards
>
>John Ross
>-----Original Message-----
>From: Paul Hoffman / IMC <[email-masked]>
>To: [email-masked] <[email-masked]>
>Date: Tuesday, April 14, 1998 12:16 PM
>Subject: RE: Rethinking Receipt
>
>
>>At 08:36 PM 4/13/98 -0500, Rik Drummond wrote:
>>>I believe if you read the RFC for the MDN, which includes how to do
>>>receipts you will find that a signed receipt may contain information such
>>>as "deleted" and "processed".
>>
>>Warning, warning: layering violation! RFC 2298 never talks about signed
>>receipts. And nor should it.
>>
>>The ESS signed receipt has a much narrower focus than RFC 2298 for good
>>reason: it's much simpler for the recipient of the receipt to understand
>>what they get. S/MIME with or without ESS works just fine with RFC 2298
>>messages. The recipient of the RFC2298 message has the option of signing
>>their MDN using plain, ordinary S/MIME without ESS.
>>
>>Please remember that ESS is an optional part of S/MIME v3. I do not want a
>>situation where in order to get a signed copy of the kind of information an
>>MDN gives, both sides must have ESS. That's a protocol layering violation.
>>As long as S/MIME v3 doesn't prohibit MDN messages (which it of course
>>doesn't), we've got all the parts we need. If we duplicate the kind of
>>information in an RFC2298 response, we open ourselves to all sorts of
>>problems, and I doubt we'll get it on standards track with such an obvious
>>layering violation.
>>
>>As for EDIINT, I would strongly urge you to simply have RFC 2298 MDN
>>messages that are signed by S/MIME v3 without ESS. You should add the
>>requirement that the recipient of a receipt request should not sign the
>>response unless they could validate the originator's signature.
>>
>>--Paul Hoffman, Director
>>--Internet Mail Consortium
> 

From: "Darren Harter" <[email-masked]>
To: <[email-masked]>, "John Pawling" <[email-masked]>
Subject: Authenticated Attributes DER vs BER (Was 30 Mar 98 S/MIME WG Minutes)
Date: Wed, 15 Apr 1998 17:40:18 +0100
Sender: [email-masked]

I agree with Russ' proposal to mandate the encoding of
authenticatedAttributes in DER.

Darren

-----Original Message-----
From: John Pawling <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Tuesday, April 14, 1998 09:41
Subject: 30 Mar 98 S/MIME WG Minutes

snipped...

>3) Darren Harter stated that there is a problem if a BER-encoded
>authenticatedAttribute is received by an S/MIME agent that does not
>recognize the OID for the attribute.  In this case, the receiving agent
>can't decode the attribute and re-encode it using DER because the agent
does
>not know the syntax of the attribute.  This may result in a signature
>verification error.  Darren proposed the following options for solving this
>problem: mandate DER encoding of the complete signedData object; or change
>syntax of authenticatedAttribute to use OCTET STRING (similar to v3 X.509
>certificate Extension format).  Russ stated that his initial position is to
>mandate DER-encoding of the authenticatedAttributes. This solves the
problem
>stated by Darren, because the receiving agent can simply hash over the
>transmitted DER-encoded authenticatedAttributes without decoding and
>re-encoding them. This issue will be resolved through messages on the
S/MIME
>mail list.
>
>================================
>John Pawling
>[email-masked]
>J.G. Van Dyke & Associates, Inc.
>================================
>
>

Date: Wed, 15 Apr 1998 09:14:59 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Rethinking Receipt
Sender: [email-masked]

At 09:10 AM 4/15/98 -0700, John Ross wrote:
>Perhaps the name  ESS signed receipt can be changed and made more
>descriptive of  the service it is providing, may I proposed "ESS proof of
>delivery".

One of the wonderful things about the IETF process is that you can have the
same discussion in many Working Groups over a period of years and come to
different conclusions. :-) The term "receipt" has been bandied (and bashed)
about in the IETF mail community for years.

One kind of receipt, an SMTP server saying to another "I got that message",
is called a DSN (Delivery Status Notifications, RFC 1894). This is used for
servers to give each other receipts of message transit but not final
deliver to the recipient. The other kind of receipt, for a recipient to
tell the original sender what they did with the message when they got it,
is called an MDN (Message Delivery Notification, RFC 2298.

ESS-style receipts are different than either of these. Like an MDN, an ESS
receipt says "I got the message". Obviously, if you didn't get the message,
you wouldn't know to send the requested receipt. Where an ESS receipt
differs from an MDN is that it also says "I was able to verify the
signature". This is kind of like the "processed" status of MDNs, but it is
processing on only one part of the message (the signature), not processing
the whole message.

I think "receipt" works well here because it is akin to the postal world.
When you get a receipt request, you usually (but not always) verify that
the message is from someone you know before signing the receipt. What ESS
receipts give you is a verification that you know who sent it to you
because you were able to verify their signature.

Thus, what you get with an ESS receipt is more than the "proof of delivery"
name you are suggesting.

--Paul Hoffman, Director
--Internet Mail Consortium

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-ess-05.txt
Date: Wed, 15 Apr 1998 10:33:52 -0400
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-05.txt
	Pages		: 29
	Date		: 14-Apr-98
	
This document describes three optional security service extensions for
S/MIME. These services provide functionality that is similar to the Message
Security Protocol [MSP4], but are useful in many other environments,
particularly business and finance. The services are:
 - signed receipts
 - security labels
 - secure mailing lists

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-ess-05.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-ess-05.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: ftp.ietf.org
	
	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-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-ess-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-ess-05.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-cert-03.txt
Date: Wed, 15 Apr 1998 10:33:09 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: S/MIME Version 3 Certificate Handling
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-cert-03.txt
	Pages		: 9
	Date		: 14-Apr-98
	
S/MIME (Secure/Multipurpose Internet Mail Extensions), described in
[SMIME-MSG], provides a method to send and receive secure MIME
messages. Before using a public key to provide security services, the
S/MIME agent MUST certify that the public key is valid.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-cert-03.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-cert-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: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-cert-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cert-03.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-msg-03.txt
Date: Wed, 15 Apr 1998 10:33:02 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: S/MIME Version 3 Message Specification
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-msg-03.txt
	Pages		: 24
	Date		: 14-Apr-98
	
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
consistent way to send and receive secure MIME data. Based on the
popular Internet MIME standard, S/MIME provides the following
cryptographic security services for electronic messaging applications:
authentication, message integrity and non-repudiation of origin (using
digital signatures) and privacy and data security (using encryption).

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-msg-03.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-msg-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: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-msg-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-msg-03.txt

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

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

--OtherAccess--

--NextPart--

From: John Ross <[email-masked]>
To: [email-masked], Paul Hoffman / IMC <[email-masked]>
MMDF-Warning:  Parse error in original version of preceding line at post.mail.demon.net
Subject: Re: Rethinking Receipt
Date: Wed, 15 Apr 1998 09:10:34 -0700
Sender: [email-masked]

In my view part of the problem is in the name. The service provided by ESS
signed receipts is a proof that the message was delivered, all signature and
other security services where OK.  It does not imply that the semantics of
the message as viewed by the user (or user application) are understood.  It
could still be rubbish as far as an application processing the message is
concerned.

I do support the need for the two layers of "Receipt",  one at the point of
delivery and the other at the point of the EDI application processing (or
human user notification in the case of E-mail).

Perhaps the name  ESS signed receipt can be changed and made more
descriptive of  the service it is providing, may I proposed "ESS proof of
delivery".

Regards

John Ross
-----Original Message-----
From: Paul Hoffman / IMC <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Tuesday, April 14, 1998 12:16 PM
Subject: RE: Rethinking Receipt

>At 08:36 PM 4/13/98 -0500, Rik Drummond wrote:
>>I believe if you read the RFC for the MDN, which includes how to do
>>receipts you will find that a signed receipt may contain information such
>>as "deleted" and "processed".
>
>Warning, warning: layering violation! RFC 2298 never talks about signed
>receipts. And nor should it.
>
>The ESS signed receipt has a much narrower focus than RFC 2298 for good
>reason: it's much simpler for the recipient of the receipt to understand
>what they get. S/MIME with or without ESS works just fine with RFC 2298
>messages. The recipient of the RFC2298 message has the option of signing
>their MDN using plain, ordinary S/MIME without ESS.
>
>Please remember that ESS is an optional part of S/MIME v3. I do not want a
>situation where in order to get a signed copy of the kind of information an
>MDN gives, both sides must have ESS. That's a protocol layering violation.
>As long as S/MIME v3 doesn't prohibit MDN messages (which it of course
>doesn't), we've got all the parts we need. If we duplicate the kind of
>information in an RFC2298 response, we open ourselves to all sorts of
>problems, and I doubt we'll get it on standards track with such an obvious
>layering violation.
>
>As for EDIINT, I would strongly urge you to simply have RFC 2298 MDN
>messages that are signed by S/MIME v3 without ESS. You should add the
>requirement that the recipient of a receipt request should not sign the
>response unless they could validate the originator's signature.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium

Date: Wed, 15 Apr 1998 08:54:32 +0100
To: [email-masked]
From: William Ottaway <[email-masked]>
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Sender: [email-masked]

Bits removed

>>
>>Cons:
>>
>>1) Don't know which signature to use. This is why the Signature Purpose
>>attribute was proposed. With the signatures tied into a purpose it can be
>>left up to site policy. (Dangerous words I think :-) ).
>
>IMHO, the signaturePurpose attribute should not be used for access control
>purposes.  For example, what happens if every additional signer includes a
>signaturePurpose indicating that she is the original signer???
>

John,

Doesn't your example question the use of signaturePurpose for anything? As
to what happens, well that would be down to the recipients own security
policy. If I received such a packet I would certainly question its worth,
since it would indicate that somebody is not processing the message correctly.

Bill.
_____________________________________________________________________
William Ottaway,             Tel: +44 (0)1684 894079
DERA Malvern,                Fax: +44 (0)1684 896113
St. Andrews Road,            email: [email-masked]
Malvern,
Worcs, WR14 3PS
UK

From: John Ross <[email-masked]>
To: Ietf distribution list <[email-masked]>, Paul Hoffman / IMC <[email-masked]>, John Pawling <[email-masked]>
Subject: Re: The big picture in eSSSecurityLabels
Date: Wed, 15 Apr 1998 08:31:36 -0700
Sender: [email-masked]

John,

As long as the text makes it clear that  the wrapped label may be different
from the inner label and that access control is a local issue, I think this
end the debate on not mandating that security labels at the various wrapping
levels need to be the same.

There is a separate debate about  applying counter signatures at the same
signeddata level and applying wrapping signatures. but that is a separate
issue.
-----Original Message-----
From: John Pawling <[email-masked]>
To: John Ross <[email-masked]>; [email-masked]
<[email-masked]>; Paul Hoffman / IMC <[email-masked]>
Date: Tuesday, April 14, 1998 1:20 PM
Subject: Re: The big picture in eSSSecurityLabels

>John,
>
>The ESS I-D eSSSecurityLabels can be different in the inner and outer
>signedData layers.
>
>
>>Also, as the ESS text is now, my understanding is that the originators
>>security label
>>is mandated
>
>The inclusion of an eSSSecurityLabel is optional.
>
>
>>and must be part of the recipients access control
>>rules even it the label has no semantics in the receiving domain.
>
>ESS does not mandate what action is taken when an access control error
>occurs.  That is a matter of local policy.
>
>>Those are the two issue I am arguing against.
>>
>>JR
>>
>

From: John Ross <[email-masked]>
To: [email-masked], Paul Hoffman / IMC <[email-masked]>, John Pawling <[email-masked]>
MMDF-Warning:  Parse error in original version of preceding line at post.mail.demon.net
Subject: Re: The big picture in eSSSecurityLabels
Date: Wed, 15 Apr 1998 08:28:05 -0700
Sender: [email-masked]

John,

As long as the text makes it clear that  the wrapped label may be different
form the inner label and that access control is a local issue, I think this
end the dabate on matching security lables.

There is a seperate debate about  applying counter signatures at the same
signeddata level and applying wrapping signatures. but that is a seperate
issue.
-----Original Message-----
From: John Pawling <[email-masked]>
To: John Ross <[email-masked]>; [email-masked]
<[email-masked]>; Paul Hoffman / IMC <[email-masked]>
Date: Tuesday, April 14, 1998 1:20 PM
Subject: Re: The big picture in eSSSecurityLabels

>John,
>
>The ESS I-D eSSSecurityLabels can be different in the inner and outer
>signedData layers.
>
>
>>Also, as the ESS text is now, my understanding is that the originators
>>security label
>>is mandated
>
>The inclusion of an eSSSecurityLabel is optional.
>
>
>>and must be part of the recipients access control
>>rules even it the label has no semantics in the receiving domain.
>
>ESS does not mandate what action is taken when an access control error
>occurs.  That is a matter of local policy.
>
>>Those are the two issue I am arguing against.
>>
>>JR
>>
>

Date: Tue, 14 Apr 1998 13:45:14 -0700
To: <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Signed Label (was RE: 'Signature Purpose' attribute?)
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 02:25 PM 4/14/98 -0500, Rik Drummond wrote:
>I have read the ESS document (SMIME V3). It is clearer to me than before 
>that the ESS signed-receipt must be modified to support 
>receipt-status-codes along the lines of RFC2298 before it is allowed to 
>move up the RFC track.

Rik, I can't disagree with you more, and I'm confused by your insistence here.
draft-ietf-ediint-as1 very clearly states that the MDNs used by EDI should be
in MDN format. Further, that draft describes that if a recipient can't sign a
requested receipt, they should send an unsigned receipt back. These two
mechanisms make perfect sense to me.

Now you're saying, "forget MDN format, and forget sending back unsigned
receipts" by demanding this in ESS, and demanding that EDIINT use this
mechanism only. What the heck is wrong with using non-ESS S/MIME v3 to sign
RFC
2298 content?

>It would be no problem to define a new attribute which is carried in the 
>signed-receipt which shows status that could be used by applications. 
>Status such as "deleted", "processed", etc.

Yes it would. We would also have to describe what a recipient should do if
they
receive a message that has an ESS attribute marked "deleted" that is
signing an
MDN that says "processed", and so on. Which takes precedence? This is why I
said that putting the attribute outside the received message is a layering
violation.

>Additionally, the draft should clearly state that the preferred method of 
>signing a document is "multipart/signed" and the PKCS7 signed is optional.

This is not covered in the ESS document: it's covered in the MSG document.
We've debated it endlessly before, and the group concensus was that both have
valid purposes, and neither is always better than the other.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 14 Apr 1998 13:30:06 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: The big picture in eSSSecurityLabels
Sender: [email-masked]

At 08:18 PM 4/14/98 -0700, John Ross wrote:
>It is my understanding that even when the wrapping technique is used
>the S/MIME specification request that all the labels be identical.
>Or have I got that wrong and they may be different in the wrapping case?

Yes, you have it wrong. There's nothing in section 3 of the ESS document
that talks about wrapping, much less restrictions on it.

>Also, as the ESS text is now, my understanding is that the originators
>security label
>is mandated  and must be part of the recipients access control
>rules even it the label has no semantics in the receiving domain.

Errr, I'd suggest you reread the draft again. I can't find anything
remotely like what you're describing. The very first sentence of section 3
says "optionally", and nothing in the main S/MIME v3 message draft requires
any part of ESS. Further, the draft never says that the recipient has to do
anything with the policy it receives.

>Those are the two issue I am arguing against.

Excellent! I think we're finished with this topic, then, since neither of
your understandings are supported in the draft. If you want to continue the
topic, please quote from the specification about the parts you have concern
over.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 14 Apr 1998 16:21:01 -0400
To: John Ross <[email-masked]>, [email-masked], Paul Hoffman / IMC <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: The big picture in eSSSecurityLabels
Sender: [email-masked]

John,

The ESS I-D eSSSecurityLabels can be different in the inner and outer
signedData layers.

>Also, as the ESS text is now, my understanding is that the originators
>security label
>is mandated  

The inclusion of an eSSSecurityLabel is optional. 

>and must be part of the recipients access control
>rules even it the label has no semantics in the receiving domain.

ESS does not mandate what action is taken when an access control error
occurs.  That is a matter of local policy.  

>Those are the two issue I am arguing against.
>
>JR
>

Date: Tue, 14 Apr 1998 16:16:27 -0400
To: John Ross <[email-masked]>, Ietf distribution list <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Sender: [email-masked]

John,

>JR: The point is that security policies may be matched at boundaries,
>they need not be homogeneous across all domains.

I wasn't implying that the security policies must be homogeneous.  The
originator and each entity that processes the message can perform its own
local translation of the common identical security label to the appropriate
security policy for local processing.

>JR: I agree the originators label cannot be changed as that would invalidate
>the signature. That is not what is being proposed,
>what is being proposed is the ability to add signed labels by security
>guards
>at domain boundaries. Which label is then used by the recipient is a matter
>of local security policy.

That requirememt can be met by the current ESS eSSSecurityLabel strategy
such that the recipient can distinguish the eSSSecurityLabel applied by the
original signer from those applied by intermediate entities.

>JR: We agree on this point. But the label added by the gateway may be
>different but have equivalent semantic and handling requirement.
>For example, if the label has any human semantics it may use a different
>language, the orginator uses English, the recipeint French, the gateway
>to the French domain adds the French label.

That requirememt can be met by the current ESS eSSSecurityLabel strategy.

- John

Date: Tue, 14 Apr 1998 16:05:20 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: 30 Mar 98 S/MIME WG Minutes
Sender: [email-masked]

All,

This message includes the minutes of the IETF S/MIME Working Group (WG)
meeting held on 30 March 1998 in Los Angeles, CA.  These minutes have been
coordinated with the briefing presenters.  All briefing slides are stored
at: ftp://ftp.ietf.org/ietf/smime/.

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

Introductions - Russ Housley

Russ stated that the S/MIME version 2 documents are now available as
Informational RFCs.  He reiterated that the IETF S/MIME WG charter is to
develop the S/MIME version 3 documents.
 
Russ reviewed the agenda.  Nobody objected to the agenda.
                   
++++++++++++++++++++++++++++++++++++++++++++++++

CMS Draft Discussion - Russ Housley

Russ presented several briefing slides regarding the CMS open issues.  He
noted that Section 9, Authenticated-Data Content Type needs to be completed
including specifying the strategy for calculating a MAC or HMAC value.  He
will coordinate the proposed text with the WG.

Russ proposed that the text regarding the contentHints attribute be moved
from the ESS I-D to the CMS I-D.  Nobody objected.

Russ stated that Section 12, Supported Algorithms is incomplete, but that
the majority of the information will be straightforward to supply except for
the key management (KM) algorithm section.  Russ stated that he has been
notified that one or more organization(s) have applied for patents that
cover some variants of the Diffie-Hellman (D-H) algorithm specified in the
X9.42 specification.  The current CMS draft cites X9.42 as a reference for
the mandatory-to-implement D-H algorithm variant.  It is still unclear if
the potential patents cover the X9.42 D-H variant intended for use with CMS.
Russ proposed to create an I-D specifying the proposed variant of the X9.42
D-H algorithm.  He will then distribute that I-D with the request that all
organizations state if they have intellectual property that covers the I-D.
If any organizations make any such claims, then the I-D will be modified so
that it avoids the use of the intellectual property while still providing a
strong KM algorithm.  Nobody objected to Russ' plan.

Russ stated that there is no standard method of encrypting a 3DES key with
another 3DES key.  Russ proposed to develop an I-D that specifies a proposed
3DES wrapping algorithm.  The I-D will then be widely distributed for
review.  If required, the I-D will be revised to incorporate comments.
Nobody objected to Russ' plan.

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

MSG Draft Discussion - Paul Hoffman

Paul led the discussion of the following open issues listed in the S/MIME v3
Message Specification I-D:
 
1) Should the MSG I-D list the documents needed to implement the algorithms
supporting S/MIME (X9.42, X9.57, etc).  Paul recommended that the MSG I-D
should refer to the CMS I-D that includes references to the required
algorithm specifications. Nobody objected.

2) Regarding MSG I-D, Section 2.6.1, there is disagreement about the last
two steps in deciding which encryption algorithm to use when creating an
envelopedData.  Paul recommended that the current sections 2.6.1.3 and
2.6.1.4 should be replaced with the following:  "2.6.1.3 Rule 3: Unknown
Capabilities, Unknown Version of S/MIME:  If the sending agent has no
knowledge of the encryption capabilities of the recipient and the sending
agent has no knowledge of the version of S/MIME of the recipient, then the
sending agent SHOULD use tripleDES because it is a stronger algorithm and is
required by S/MIME v3.  If the sending agent chooses not to use tripleDES in
this step, it SHOULD use RC2/40."   Nobody objected.  Paul noted that if an
S/MIME v3 agent is sending an envelopedData to a legacy S/MIME v2 agent,
then RC2/40 SHOULD be used because the S/MIME v2 agent may not have
implemented tripleDES.

A WG member noted that the default encryption algorithm should result in
strong cryptography (i.e. use tripleDES whenever possible, rather than
RC2/40) and that if RC2/40 is used, then the user should be explicitly
notified of that fact.

3) Regarding Section 4.1, key lengths for non-RSA key pair generation
language are needed.  A WG member asked if the WG was going to specify a D-H
"common group" of algorithm parameters.  The WG agreed that this was a good
idea, but the use of the S/MIME WG-defined D-H "common group" would be
optional because some organizations may wish to use locally-defined D-H
"common groups".  Paul recommended that the MSG I-D should refer to the CMS
I-D which covers this topic. Nobody objected.

4) smimeVersion capability:  Paul proposed that the smimeVersion feature
should be added to the SMIMECapabilities list.  This will have a content of
a single integer which will contain the version number of the highest S/MIME
specification understandable by the client. Nobody objected.

Jim Schaad addressed the following MSG I-D issues in later briefings: 

"Add a section for selecting the encrypting X.509 certificate for a
particular recipient"

"SMIMEEncryptionKeyPreference - which key should a sender announce for this?
Also, unambiguous identification of X.509 certificates should be here, too."

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

CERT Draft Discussion - Paul Hoffman

Paul noted that the S/MIME WG, as a general rule, should defer to the PKIX
WG regarding the rules for populating information in X.509 certificates and
CRLs.  This will alleviate interoperability problems that could occur if
S/MIME levies special requirements regarding the contents of X.509
certificates that are above and beyond the generic PKIX requirements.  Paul
led the discussion of the following open issues listed in the S/MIME v3
Certificate Handling I-D:

1) Names for chaining: Paul proposed that the S/MIME CERT I-D should refer
to the PKIX X.509 Certificate and CRL Profile I-D (PKIX I) for specifying
the rules for chaining. Nobody objected.  

2) Use of keyUsage encipherOnly and decipherOnly bits in conjunction with
the use of KM X.509 certificates.  John Pawling read the X.509 description
of the keyUsage encipherOnly and decipherOnly bits.  He stated that he
believes that their use is not clearly defined when a public key is to be
used to form a pairwise key to encrypt or decrypt data.  John proposed the
following: "If the keyUsage keyAgreement bit is set to 1 AND if the public
key is to be used to form a pairwise key to decrypt data, then the S/MIME
agent MUST only use the public key if the keyUsage encipherOnly bit is set
to 0.  If the keyUsage keyAgreement bit is set to 1 AND if the key is to be
used to form a pairwise key to encrypt data, then the S/MIME agent MUST only
use the public key if the keyUsage decipherOnly bit is set to 0."  This
issue will be further discussed on the S/MIME mail list.  

3)  Do we need to further qualify the syntax for rfc822Name (no wildcards or
comments)?  Paul proposed that the S/MIME CERT I-D should refer to PKIX I
regarding this issue.  Nobody objected.

4) Attribute Certificates:  Paul noted that it is an action item for the
PKIX WG to define the use of ACs.  David Solo proposed that all references
to ACs should be deleted from all of the S/MIME specifications until the
syntax and use of ACs are well defined.  Russ and John Pawling made the
point that X.509 defines the AC syntax.  However, Paul and Dave strongly
believed that ACs should be deleted from the S/MIME specs since their use is
not defined and the PKIX AC syntax may be changed.  Nobody objected to this
proposal.  The details of this change will be discussed further on the
S/MIME list.

A WG member stated that he is concerned about the S/MIME specs relying on
the PKIX specs which are still I-Ds.  Jeff Schiller stated that the S/MIME
WG needs to clearly state their dependencies on the PKIX WG to put pressure
on them to finalize the PKIX I spec.  Similarly, other IETF WGs are
dependent on the S/MIME WG finalizing the S/MIME v3 specs.  Paul volunteered
to compile a list of S/MIME dependencies on the PKIX I spec.

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

Authenticated Originator Certificate - John Pawling

John recommended adoption of Jim Schaad's original proposal to add a
signing-certificate authenticatedAttribute to the CMS I-D as follows:

"11.5  Signing Certificate Attribute.  The signing-certificate attribute
type specifies the exact certificate used to sign the signed-data.  This
provides for an authenticated method of linking the certificate used to
create the signed-data object and the signed-data object itself.  If this
attribute is not used and two different certificates are used for the same
keys, it is possible to substitute the certificates without breaking the
signature. It is suggested that the signing-certificate attribute be present
if there are any authenticated attributes present.  The signing-certificate
attribute MAY be critical.  The signing-certificate attribute MUST be
authenticated.  Only one instance of the signing-certificate attribute may
appear in an attribute set.  The following object identifier identifies the
signing-certificate attribute: id-signingCert OBJECT IDENTIFIER ::= <TBD>.
Signing-certificate attribute value has the ASN.1 type IssuerAndSerialNumber."

John presented slides explaining the process by which the originator
composes a signedData object that includes a signing-certificate attribute
and the process by which the recipient validates the signer's certification
path and the signature of the signedData.  The point of the briefing was
that the combination of the IssuerAndSerialNumber info, certification path
validation and verification of the signer's signature of the signedData
object provides sufficient information to reliably identify the signer's
X.509 certificate.  John recommended that the IssuerAndSerialNumber syntax
is appropriate for use for the signing-certificate attribute.  He
recommended that the subjectAltName and a hash of the X.509 certificate
should not be included in the signing-certificate syntax.  
 
Denis Pinkas presented a briefing in which he proposed that issuerAltName
and certificateHash should be added as optional fields to the
signing-certificate syntax.  Denis' briefing slides provide more details.

Dave Solo stated that he did not believe that the signing-certificate
attribute is needed to unambiguously identify the signer's identity.  He
believes that the content of the signedData should include enough semantic
information to unambiguously identify the signer (if that is desired) rather
than relying solely on the information in the signer's X.509 certificate.

Russ asked for a show of hands regarding who believed that the
IssuerAndSerialNumber syntax should be sufficient to unambiguously identify
the signer.  He also asked who believed that the signing-certificate
attribute should include information (such as the subjectAltName and
certificate hash value) in addition to IssuerAndSerialNumber.  Twice as many
hands were raised for the second option as for the first. 

In a later discussion, this issue was raised again and Russ explained the
issue.  Russ asked who believed that the signing-certificate attribute
should be added to the S/MIME specs.  The vote was 6 to 7 in a room filled
with several hundred people.  It was apparent from this vote and from the
discussion of the WG members that there was not a consensus regarding the
purpose and syntax of the signing-certificate attribute, so the result of
the earlier straw poll was overturned.  This issue will be further discussed
on the S/MIME mail list.

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

ESS Draft Discussion - Paul Hoffman

Paul led the discussion of the following open issues related to the ESS I-D:

1) Paul proposed that the text regarding the contentHints attribute be moved
from the ESS I-D to the CMS I-D.  Nobody objected.  

2) Paul explained the proposal for the signature-purpose attribute and that
it should be included in a separate document.  Nobody objected.

3) Paul proposed that the group accept his recommended text for new wording
regarding what to do if a signedData has multiple signerInfos, some of which
don't have mlExpansionHistory attributes.  Paul's e-mail message (Subject:
RE: ESS-04 Comments, 24 Mar 98) to the list describes this proposal.  Paul
explained that his proposal allows gateways to add a signerInfo without an
mlExpansionHistory attribute.  Nobody objected.

4) John Pawling proposed that the ESSSecurityLabel
security-policy-identifier should be changed from optional to mandatory.
Nobody objected to John's proposal.

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

E-Mail Address in Certificates - J.L. Cote

J.L. stated that the Canadian government wants e-mail addresses to be
optional for inclusion in X.509 certificates.  This was addressed in the
last version of the CERT I-D.  J.L. also stated that X.400 addresses should
be documented in addition to RFC822 addresses.  Nobody objected.

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

Signature and Key Management Certificates - Jim Schaad

Jim explained why separate signature and KM keys are required for a single
end entity.  He explained the problems associated with separate keys as
keeping track of the different keys, making associations between the
different keys, publishing the different keys and making it known which of a
user's keys should be used for KM.  He explained that there various methods
of associating the different keys including subject name matching, alternate
subject name matching and others.  The MSG I-D, Section 2.5.3 documents the
SMIMEEncryptionKeyPreference authenticatedAttribute.  Jim proposed that the
following process be documented in the MSG I-D: 

- If an SMIMEEncryptionKeyPreference attribute is found in a signedData
object, this identifies the X.509 certificate that should be associated as
the KM X.509 certificate for the user.

- If an SMIMEEncryptionKeyPreference attribute is not found in a signedData
object, the set of X.509 certificates should be searched for a X.509
certificate with the same subject name as the signing X.509 certificate
which can be used for KM.

- Or use some other method of determining the user's KM key.  If no KM X.509
certificate is found, then encryption cannot be done with the signer of the
message.  If multiple X.509 certificates are found, the S/MIME agent can
make an arbitrary choice between them. 

Jeff Schiller asked why the SMIMEEncryptionKeyPreference attributes is
needed.  Jim answered that it is required to facilitate the bootstrapping of
an encryption exchange.  A signer sends a signedData that includes the
signer's KM X.509 certificate which the recipient can then use to send an
envelopedData back to the signer.

A WG member asked if the user's KM X.509 certificate will be included in the
signedData object.  Jim answered that it should be included, but may be
omitted if the sender knows that the recipient already has it.

Nobody objected to Jim's proposal. 

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

Certificate Distribution - Jim Schaad

Jim outlined the current strategies for publishing X.509 certificates: LDAP
userCertificate; X.500 Directory entry; S/MIME signedData message; CMS
certificate-only attachment; and other methods such as vCard.  Jim said that
the problems with these strategies is that they: do not carry a full
certification path; can only carry a single KM X.509 certificate; and does
not carry any S/MIME capabilities.  Jim proposed that a new inner content
type should be defined as id-ct-publish.  This would indicate that the
signedData: does not include a content; does include authenticatedAttributes
(could include SMIMEEncryptionKeyPreference attribute); and may include
multiple KM X.509 certificates.  Jim proposed that the new content type
could be signed by either an end-entity or X.509 certificate issuer.  He
also proposed the addition of a new LDAP userSMIMECertificate (binary)
schema property.

John Pawling asked how the message digest value would be calculated if the
content was absent.  Jim answered that the digest would be calculated over
the initialization value for the hash algorithm that is being used.

The WG decided that they should pursue Jim's proposals within the S/MIME WG.
The WG also decided that Jim's proposal should be documented in a separate I-D.

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

Other Discussion:

1) Paul Hoffman asked that people use meaningful names in their e-mail
message subject lines when making new proposals or creating a new thread on
the S/MIME mail list.

2) Russ stated that he believes that the ESS, CERT and MSG I-Ds will be
ready for Working Group last call in April 98.  He also stated that his goal
is for the CMS I-D to be ready for Working Group last call in April 1998;
however, the D-H patent issue and 3DES wrapping issue may delay the
schedule.  Since ESS, CERT, and MSG depend on CMS, they cannot go to IESG
last call until CMS is ready to go to IESG last call as well.

3) Darren Harter stated that there is a problem if a BER-encoded
authenticatedAttribute is received by an S/MIME agent that does not
recognize the OID for the attribute.  In this case, the receiving agent
can't decode the attribute and re-encode it using DER because the agent does
not know the syntax of the attribute.  This may result in a signature
verification error.  Darren proposed the following options for solving this
problem: mandate DER encoding of the complete signedData object; or change
syntax of authenticatedAttribute to use OCTET STRING (similar to v3 X.509
certificate Extension format).  Russ stated that his initial position is to
mandate DER-encoding of the authenticatedAttributes. This solves the problem
stated by Darren, because the receiving agent can simply hash over the
transmitted DER-encoded authenticatedAttributes without decoding and
re-encoding them. This issue will be resolved through messages on the S/MIME
mail list.

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

From: Rik Drummond <[email-masked]>
To: "'John Pawling'" <[email-masked]>, William Ottaway <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Signed Label (was RE: 'Signature Purpose' attribute?)
Date: Tue, 14 Apr 1998 14:25:33 -0500
Sender: [email-masked]

I have read the ESS document (SMIME V3). It is clearer to me than before 
that the ESS signed-receipt must be modified to support 
receipt-status-codes along the lines of RFC2298 before it is allowed to 
move up the RFC track.  It will be of little use to applications unless 
this functionality is added.

I would be no problem to define a new attribute which is carried in the 
signed-receipt which shows status that could be used by applications. 
Status such as "deleted", "processed", etc.

Additionally, the draft should clearly state that the preferred method of 
signing a document is "multipart/signed" and the PKCS7 signed is optional.

Best regards,

Rik Drummond
Chair, IETF's EDIINT WG - Secure EDI over Internet Workgroup

Certain attributes should be placed in the inner or outer SignedData
message; some attributes can be in either. Further, some attributes must be
authenticated, while authentication is optional for others. The following
table summarizes the recommendation of this profile.

                  |                             |Inner or  |MUST be
Attribute         |OID                          |outer     |authenticated
------------------|-----------------------------|----------|-------------
contentHints      |id-aa-contentHint [ESS]      |either    |no
contentIdentifier |id-aa-contentIdentifier [ESS]|either    |no
contentType       |id-contentType [CMS]         |either    |yes
counterSignature  |id-countersignature [CMS]    |either    |MUST NOT
eSSSecurityLabel  |id-aa-securityLabel [ESS]    |either    |yes
messageDigest     |id-messageDigest [CMS]       |either    |yes
msgSigDigest      |id-aa-msgSigDigest [ESS]     |inner only|yes
mlExpansionHistory|id-aa-mlExpandHistory [ESS]  |outer only|yes
receiptRequest    |id-aa-receiptRequest [ESS]   |inner only|yes
signingTime       |id-signingTime [CMS]         |either    |yes
smimeCapabilities |sMIMECapabilities [MSG]      |either    |yes

From: John Ross <[email-masked]>
To: [email-masked], Paul Hoffman / IMC <[email-masked]>
MMDF-Warning:  Parse error in original version of preceding line at post.mail.demon.net
Subject: Re: The big picture in eSSSecurityLabels
Date: Tue, 14 Apr 1998 20:18:59 -0700
Sender: [email-masked]

It is my understanding that even when the wrapping technique is used
the S/MIME specification request that all the labels be identical.
Or have I got that wrong and they may be different in the wrapping case?

Also, as the ESS text is now, my understanding is that the originators
security label
is mandated  and must be part of the recipients access control
rules even it the label has no semantics in the receiving domain.

Those are the two issue I am arguing against.

JR

-----Original Message-----
From: Paul Hoffman / IMC <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Tuesday, April 14, 1998 11:45 AM
Subject: The big picture in eSSSecurityLabels

>I think the current debate about where a second signer on a message can put
>their security label may be missing the point. The reason for allowing a
>security label at all is so that the originator of a message can specify a
>desired (but not required) security policy for the recipient. There are
>lots of other things we can do with the labels, but they must not interfere
>with the original purpose of helping the recipient. Security labels do help
>the sender, but they are really there for the recipient who cares about how
>to process the message.
>
>A signer other than the originator might want the recipient to use an
>additional security policy when processing the message. That's fine, but it
>must not negate the policy desires of any other signer, and it must not
>prevent the recipient from knowing the original signer's desires. When
>there are two or more signerInfos in a SignedData block, the recipient has
>no idea who the original signer was. Therefore, the rule we came up with
>for eSSSecurityLabels said "if there's already a label there, you cannot
>put a different one". With this rule, the recipient still doesn't know
>which of the signers was the original, but the recipient does know what the
>original signer's policy intent was.
>
>This is not to say that later signers should not be able to add different
>policies: they should. However, to do so in a fashion that lets the
>recipient still know what the originator's policy desires are, the later
>signers use wrapping. To a recipient, this format of message is
>unambiguous: they know the policy desires of the original signer even if
>there are many signatures on the inside SignedData, and they know what
>different policies were added by someone else.
>
>Using this mechanism allows recipients to have policies that say either
>"act on all policies" or "ignore policies on signatures other than the
>originator". Both of these are perfectly reasonable choices for a receipt
>policy. If we don't give the recipient that choice, we've taken away a very
>important feature for no reason other than smaller message size.
>
>Even if we had a "signature purpose" attribute that said "I'm the
>originator", or even a bit in the eSSSecurityLabel that says "this is the
>originator's label", we can't allow arbitrary signerInfos to have different
>labels. Imagine the case of three signers with three different policies.
>Even if there is a rule that "if an earlier signer has called themselves
>the originator, you can't say you are", the recipient won't know which of
>the other two signed second, but this information could be important to
>them when deciding whether or not to act on a particular policy. We'd still
>be taking away information from them.
>
>In short, the current draft allows every feature that we want the recipient
>and any signer to have. The only downside of the current draft is the size
>of the message for multiple signers who want different policies, but that
>is much less important than having the recipient know exactly what policies
>were applied at different times during the signing of the message.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium

Date: Tue, 14 Apr 1998 12:17:09 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Sender: [email-masked]

At 07:51 PM 4/14/98 -0700, John Ross wrote:
>I think that it is easier to implemented such a facility at a guard, as the
>guard is aware
>of the boundary security requirements. Where as, the point of origination
>will not be aware
>of all the various interworking rules at all the boundaries to the secuity
>domain .

I firmly believe that this is out of scope for the ESS document, or of any
IETF standard. ESS is part of a message protocol: we cannot demand that
there be gateways, guards, and so on, for the messages to be transmitted.
We shouldn't prevent those kinds of things, and we don't. In fact, we help
them exist, by specifying how to use MIME wrapping and having unambiguous
meanings for what a signed MIME wrapping means.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 14 Apr 1998 15:14:49 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Draft 30 Mar S/MIME WG Minutes
Sender: [email-masked]

>From the draft minutes:
CERT Draft Discussion - Paul Hoffman

4) Attribute Certificates:  Paul noted that it is an action item for the 
PKIX WG to define the use of ACs.  David Solo proposed that all references 
to ACs should be deleted from all of the S/MIME specifications until the 
syntax and use of ACs are well defined.  Russ and John Pawling made the 
point that X.509 defines the AC syntax.  However, Paul and Dave strongly 
believed that ACs should be deleted from the S/MIME specs since their use is 
not defined and the PKIX AC syntax may be changed.  Nobody objected to this 
proposal.  The details of this change will be discussed further on the 
S/MIME list. 
Okay, let's have the discussion....

Russ

Date: Tue, 14 Apr 1998 14:47:45 -0400
To: [email-masked] (David P. Kemp)
From: Russ Housley <[email-masked]>
Subject: Re: Rethinking Receipt
Cc: [email-masked]
Sender: [email-masked]

Dave:

Trevor Freeman at Microsoft expressed interest in the use of receipts to
manage work flow.  This seems synergistic with your proposal.

This idea needs some additional work.  I suggest that we proceed with the
receipt as defined and look at siged attributes that can be included in the
receipt SignerInfo to implement enhacements.  Rik Drummond's requirements
can be addressed in the same document.  An additioal document that exteds
reciept capabilities seems like a reasonable approach.

Russ

At 05:53 PM 4/13/98 -0400, David P. Kemp wrote:
>Folks,
>
>ESS Section 2 discusses the operation of ReceiptRequests and Receipts:
>
>  2.1: "The request is indicated by adding a receiptRequest attribute
>  to the signedAttributes field of the SignerInfo object for which the
>  receipt is requested."
>
>and
>
>  2.8: "Receipts are represented using a new content type, Receipt."
>
>  Receipt ::= SEQUENCE {
>      version Version,
>      contentType ContentType,
>      signedContentIdentifier ContentIdentifier,
>      originatorSignatureValue OCTET STRING }
>
>
>A colleague has proposed that the receipt structure would be much more
>useful if it were generalized and represented by an attribute instead
>of by a unique content type.  The attribute could represent the
>existing security receipt, or it could be used to securely link an
>ordinary reply to the message it refers to.  This is such an insightful
>and elegant idea that I wish I had thought of it first!  Thanks, C.A.!
>
>I propose that ESS replace the Receipt structure and id-ct-receipt with
>a new signatureBinding attribute:
>
>  id-aa-signatureBinding OBJECT IDENTIFIER ::= { tbd }
>
>  SignatureBinding ::= SEQUENCE {
>      contentType ContentType,
>      signedContentIdentifier ContentIdentifier,
>      originatorSignatureValue OCTET STRING,
>      bindingPurpose BindingPurpose }
>
>  BindingPurpose ::= INTEGER {
>      receipt          (0),
>      contentReference (1) }
>
>
>For Receipts, the bindingPurpose identifier would have the value
>"receipt", and the encapContentInfo would be treated as in the
>degenerate signed data case: eContentType is id-data, and eContent
>is omitted.
>
>For normal message replies, bindingPurpose would have the value
>contentReference, and encapContentInfo would be the reply message.
>
>In low-bandwidth or large-data applications, it may be useful to have
>messages or attachments pre-signed and cached at both the sender's and
>recipient's locations.  A small message could then use the
>signatureBinding attribute to refer to one of the cached signed
>contents.  Additional bindingPurpose codes, such as
>signatureValidation, could be defined if needed.
>
>Comments?
>
>Dave Kemp
> 

From: John Ross <[email-masked]>
To: [email-masked], William Ottaway <[email-masked]>
MMDF-Warning:  Parse error in original version of preceding line at post.mail.demon.net
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Date: Tue, 14 Apr 1998 19:51:46 -0700
Sender: [email-masked]

William,

I am happy with your proposal.

-----Original Message-----
From: William Ottaway <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Tuesday, April 14, 1998 10:24 AM
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)

>>
>>Possible solution:
>>I wonder, if one way round this problem be to specify a default security
>>policy identifier in the S/MIME specifications which implies the policy
you
>>have in mind. Which I think is something like : (When an originator uses
>>this policy id, it implies that the originators policy must be understood
by
>>the recipient and supersedes any other security label within the same
signed
>>data, if the policy id is not understood by the recipient the message
shall
>>be rejected).
>>
>>If you make the behaviour rules you are looking for dependant upon the
>>security policy in the way proposed above, I think the behaviour you are
>>looking for can be achieved. The above proposal should also meet other
>>domains needs as well, when other policy ids are used.
>>
>>Does anybody else have a view?
>>>
>
>I like this idea of having a default security policy. However, if the
>policy is not understood by the recipient the outcome is down to the
>recipients security policy. This may result in the message being rejected,
>as you suggested, or it may allow the message through but with some
>indication that the policy was not understood.
>
>I deliberately referred to "security policy" rather that "security policy
>identifier" because I'm not sure that an identifier is required.
>
>Here is my stab at it:
>
>Lets say that a default security policy is stated within SMIME. This policy
>will describe a set of eSSSecurityLabel values which can be used in the
>majority of general messaging cases.
>
>Now an originator has the choice of using the default policy or some other
>policy. This other policy may have additional labels to those in the
>default or it may use totally different ones. The non default policy should
>only be used when communicating with a recipient which understands this
>policy. In all other cases the default should be used.
>
>What a recipient does when he receives SMIME must be covered by that
>recipients policy. A typical scenario would be that when an unknown
>eSSSecurityLabel is received it is rejected. The recipient does not need to
>know what security policy is being used, it just needs to be able to act on
>the eSSSecurityLabel.
>
>The advantage of having a default policy is in mapping. If a recipient uses
>different eSSSecurityLabel internally to the default then incoming default
>SMIME eSSSecurityLabel values can be mapped, at the boundary, onto the
>domains own labels.
>
>I appologise if I have just reworded the original solution.
>
>Bill
>
>_____________________________________________________________________
>William Ottaway,             Tel: +44 (0)1684 894079
>DERA Malvern,                Fax: +44 (0)1684 896113
>St. Andrews Road,            email: [email-masked]
>Malvern,
>Worcs, WR14 3PS
>UK
>

From: John Ross <[email-masked]>
To: Ietf distribution list <[email-masked]>, John Pawling <[email-masked]>
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Date: Tue, 14 Apr 1998 19:51:04 -0700
Sender: [email-masked]

See my comments in line....
-----Original Message-----
From: John Pawling <[email-masked]>
To: JOHN ROSS <[email-masked]>; [email-masked] <[email-masked]>
Date: Tuesday, April 14, 1998 10:02 AM
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)

>John,
>
>My comments regarding access control checks were meant to support my
>assertion that multiple different security labels are not required to be
>attached to a single content.  I was not implying that my statements should
>be incorporated into the ESS I-D.
>
>You stated:
>>This means that all originators must know all the recipients security
>>policy. I do not agree that this is practical solution in a global
messaging
>>environment.
>
>That is the only solution.  If an originator does not understand the
>authorizations of a recipient, then she had better not send a sensitive
>message to that recipient.

JR: My point is,  the originating "security domain" needs to make the
decision
if the message can go out of it's security controls and be sent to the
recipients
domain, this may be implemented at the point of origination or may be
policed at the domains security guard, either will do.

I think that it is easier to implemented such a facility at a guard, as the
guard is aware
of the boundary security requirements. Where as, the point of origination
will not be aware
of all the various interworking rules at all the boundaries to the secuity
domain .

>
>
>>This assumes that all recipients will understand security labels from all
>>users in all security domains, and be able to map the security label they
>>receive to one understood under the local security policy.
>
>That is correct.  If you don't understand somebody else's security policy,
>then don't communicate sensitive data with them.
>
JR: The point is that security policies may be matched at boundaries,
they need not be homogeneous across all domains.
>
>>Would it not be
>>more practical to do that mapping just one at security domain boundary?
>
>I believe that the security label values assigned by the human signer are
>sacred and must not be removed, changed, superseded or otherwise corrupted.
>The human signer understands the complete context of the message and the
>security policy rules that apply to labeling that message.  The human
signer
>makes conscious decisions regarding the sensitivity of the content which
may
>be based on subjective or other knowledge that is not available to the
>gateway software.  Therefore, I disagree with your implication that a
>gateway should change the signer's label or include a translated label

JR: I agree the originators label cannot be changed as that would invalidate
the signature. That is not what is being proposed,
what is being proposed is the ability to add signed labels by security
guards
at domain boundaries. Which label is then used by the recipient is a matter
of local security policy.

in
>the signer's signedData object.  If the gateway wants to add an outer
>signedData including a translated label, then that is fine because the GW
is
>the signer of that signedData and can populate the security label with the
>appropriate values.  The recipient will be able to easily distinguish
>between the GW's outer signedData and human signer's inner signedData.

JR: We agree on this point. But the label added by the gateway may be
different but have equivalent semantic and handling requirement.
For example, if the label has any human semantics it may use a different
language, the orginator uses English, the recipeint French, the gateway
to the French domain adds the French label.
>
>>
>>If I understand correctly your main concern, it is the possibility of
>>inconsistency between semantics of the security label as known and
generated
>>by the originator and the semantics of other security labels (which may be
>>added later in the message path).  My view is the semantics of a security
>>label  and how it is processed on receipt is dictated by the security
policy
>>in the receiving domain and not the originating domain.
>
>I disagree.  It is a function of all of the security policies involved with
>the message transaction.  If a GW strips out the signer's security label
(or
>otherwise supersedes it), then the recipient's software never gets a chance
>to see the human signer's label.

JR: I agree with you that the originators label is retained with the
message, it must be to preserve the signature, so the recipient
will be able to see the human signer's label.

However, I can predict that there will  be scenarios and security domains
which will strip out all external security at a boundary and re-instate
there
own,  but that is a different issue and nothing we do can stop that. The
issue
we are discussing is what is sensible to put into the S/MIME
document.
>
>
>I disagree with all of the following text because it is too detailed for
>inclusion in the ESS spec.  This should be up to the local organizations.
>
>>I think what you are in fact trying to achieved is a global security
policy,
>>which in itself is a commendable goal.
>>
>>Possible solution:
>>I wonder, if one way round this problem be to specify a default security
>>policy identifier in the S/MIME specifications which implies the policy
you
>>have in mind. Which I think is something like : (When an originator uses
>>this policy id, it implies that the originators policy must be understood
by
>>the recipient and supersedes any other security label within the same
signed
>>data, if the policy id is not understood by the recipient the message
shall
>>be rejected).
>>
>>If you make the behaviour rules you are looking for dependant upon the
>>security policy in the way proposed above, I think the behaviour you are
>>looking for can be achieved. The above proposal should also meet other
>>domains needs as well, when other policy ids are used.
>>
>>Does anybody else have a view?
>>>
>>
>>
>
>

Date: Tue, 14 Apr 1998 11:49:48 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Rethinking Receipt
Sender: [email-masked]

At 08:36 PM 4/13/98 -0500, Rik Drummond wrote:
>I believe if you read the RFC for the MDN, which includes how to do 
>receipts you will find that a signed receipt may contain information such 
>as "deleted" and "processed".

Warning, warning: layering violation! RFC 2298 never talks about signed
receipts. And nor should it.

The ESS signed receipt has a much narrower focus than RFC 2298 for good
reason: it's much simpler for the recipient of the receipt to understand
what they get. S/MIME with or without ESS works just fine with RFC 2298
messages. The recipient of the RFC2298 message has the option of signing
their MDN using plain, ordinary S/MIME without ESS.

Please remember that ESS is an optional part of S/MIME v3. I do not want a
situation where in order to get a signed copy of the kind of information an
MDN gives, both sides must have ESS. That's a protocol layering violation.
As long as S/MIME v3 doesn't prohibit MDN messages (which it of course
doesn't), we've got all the parts we need. If we duplicate the kind of
information in an RFC2298 response, we open ourselves to all sorts of
problems, and I doubt we'll get it on standards track with such an obvious
layering violation.

As for EDIINT, I would strongly urge you to simply have RFC 2298 MDN
messages that are signed by S/MIME v3 without ESS. You should add the
requirement that the recipient of a receipt request should not sign the
response unless they could validate the originator's signature.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 14 Apr 1998 14:49:43 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: The big picture in eSSSecurityLabels
Sender: [email-masked]

All,

I agree with Paul's conclusion that the current ESS eSSSecurityLabel
strategy meets the requirements stated by the group such that the recipient
can distinguish the eSSSecurityLabel applied by the original signer from
those applied by intermediate entities.

- John Pawling

Date: Tue, 14 Apr 1998 11:12:30 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: The big picture in eSSSecurityLabels
Sender: [email-masked]

I think the current debate about where a second signer on a message can put
their security label may be missing the point. The reason for allowing a
security label at all is so that the originator of a message can specify a
desired (but not required) security policy for the recipient. There are
lots of other things we can do with the labels, but they must not interfere
with the original purpose of helping the recipient. Security labels do help
the sender, but they are really there for the recipient who cares about how
to process the message.

A signer other than the originator might want the recipient to use an
additional security policy when processing the message. That's fine, but it
must not negate the policy desires of any other signer, and it must not
prevent the recipient from knowing the original signer's desires. When
there are two or more signerInfos in a SignedData block, the recipient has
no idea who the original signer was. Therefore, the rule we came up with
for eSSSecurityLabels said "if there's already a label there, you cannot
put a different one". With this rule, the recipient still doesn't know
which of the signers was the original, but the recipient does know what the
original signer's policy intent was.

This is not to say that later signers should not be able to add different
policies: they should. However, to do so in a fashion that lets the
recipient still know what the originator's policy desires are, the later
signers use wrapping. To a recipient, this format of message is
unambiguous: they know the policy desires of the original signer even if
there are many signatures on the inside SignedData, and they know what
different policies were added by someone else. 

Using this mechanism allows recipients to have policies that say either
"act on all policies" or "ignore policies on signatures other than the
originator". Both of these are perfectly reasonable choices for a receipt
policy. If we don't give the recipient that choice, we've taken away a very
important feature for no reason other than smaller message size.

Even if we had a "signature purpose" attribute that said "I'm the
originator", or even a bit in the eSSSecurityLabel that says "this is the
originator's label", we can't allow arbitrary signerInfos to have different
labels. Imagine the case of three signers with three different policies.
Even if there is a rule that "if an earlier signer has called themselves
the originator, you can't say you are", the recipient won't know which of
the other two signed second, but this information could be important to
them when deciding whether or not to act on a particular policy. We'd still
be taking away information from them.

In short, the current draft allows every feature that we want the recipient
and any signer to have. The only downside of the current draft is the size
of the message for multiple signers who want different policies, but that
is much less important than having the recipient know exactly what policies
were applied at different times during the signing of the message.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 14 Apr 1998 13:19:36 -0400
To: William Ottaway <[email-masked]>, [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Sender: [email-masked]

All,

The problem with trying to define a default security policy is getting
everybody to agree on the semantics of the security-classification and
security-category values.  The X.411 editors attempted to define a default
secuirty policy by defining standard security-classification values.  The
problem is that no two organizations can agree on what those
security-classifcation values really mean.  Each organization demands the
right to specify their own security rules.  In summary, I believe that the
definition of a default security policy is way beyond the scope of the
S/MIME WG.

- John Pawling

At 06:00 PM 4/14/98 +0100, William Ottaway wrote:
>>
>>Possible solution:
>>I wonder, if one way round this problem be to specify a default security
>>policy identifier in the S/MIME specifications which implies the policy you
>>have in mind. Which I think is something like : (When an originator uses
>>this policy id, it implies that the originators policy must be understood by
>>the recipient and supersedes any other security label within the same signed
>>data, if the policy id is not understood by the recipient the message shall
>>be rejected).
>>
>>If you make the behaviour rules you are looking for dependant upon the
>>security policy in the way proposed above, I think the behaviour you are
>>looking for can be achieved. The above proposal should also meet other
>>domains needs as well, when other policy ids are used.
>>
>>Does anybody else have a view?
>>>
>
>I like this idea of having a default security policy. However, if the
>policy is not understood by the recipient the outcome is down to the
>recipients security policy. This may result in the message being rejected,
>as you suggested, or it may allow the message through but with some
>indication that the policy was not understood.
>
>I deliberately referred to "security policy" rather that "security policy
>identifier" because I'm not sure that an identifier is required.
>
>Here is my stab at it:
>
>Lets say that a default security policy is stated within SMIME. This policy
>will describe a set of eSSSecurityLabel values which can be used in the
>majority of general messaging cases.
>
>Now an originator has the choice of using the default policy or some other
>policy. This other policy may have additional labels to those in the
>default or it may use totally different ones. The non default policy should
>only be used when communicating with a recipient which understands this
>policy. In all other cases the default should be used.
>
>What a recipient does when he receives SMIME must be covered by that
>recipients policy. A typical scenario would be that when an unknown
>eSSSecurityLabel is received it is rejected. The recipient does not need to
>know what security policy is being used, it just needs to be able to act on
>the eSSSecurityLabel.
>
>The advantage of having a default policy is in mapping. If a recipient uses
>different eSSSecurityLabel internally to the default then incoming default
>SMIME eSSSecurityLabel values can be mapped, at the boundary, onto the
>domains own labels.
>
>I appologise if I have just reworded the original solution.
>
>Bill
>   
>_____________________________________________________________________
>William Ottaway,             Tel: +44 (0)1684 894079
>DERA Malvern,                Fax: +44 (0)1684 896113
>St. Andrews Road,            email: [email-masked]
>Malvern,
>Worcs, WR14 3PS
>UK
>
>

Date: Tue, 14 Apr 1998 13:14:50 -0400
To: William Ottaway <[email-masked]>, [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Sender: [email-masked]

Bill,

>1) Not sure about this, I'm on shakey ground. Is there a problem if the
>message is not processed by any guards before arriving at the recipient?
>This would be the case where the recipients security policy is "I don't
>care". He would have to work his way down through the nesting until he got
>to the level which contained the initial originators message. Would the
>recipient actually do this? or would he expect the initial originators
>message to be at the top level?

These are not problems if the receiving S/MIME SW is properly implementing
the ESS I-D.  It will work its way through the layers.

>No Nesting:
>Pros:
>
>1) Everything is at the top level (easily accessable).

And ambiguous.

>
>Cons:
>
>1) Don't know which signature to use. This is why the Signature Purpose
>attribute was proposed. With the signatures tied into a purpose it can be
>left up to site policy. (Dangerous words I think :-) ).

IMHO, the signaturePurpose attribute should not be used for access control
purposes.  For example, what happens if every additional signer includes a
signaturePurpose indicating that she is the original signer???

>When I hear nesting I start thinking lots of overhead. All that infomation
>just to encapsulate a chunk of data. Whereas "sliding" another signature in
>seems a lot neater, though I am curious as to how easy it would be to do this.

The layering of the signedData objects does add bytes to the wire, but the
price paid is well worth the benefit of ensuring that there are not
inconsistent or contradictory ESSSecurityLabels applied to the same content.
Mandating that all ESSSecurityLabels included in a single signedData must be
identical ensures that all ESSSecurityLabels applied to a content are
consistent.  This ensures that there is no confusion regarding the
sensitivity of the content and that an access control decision can be made
in an unambiguous manner.

>Therefore, I'm interested in which option would require least processing
>both at the adding the third party signature and at the recipient ends
>(assuming third party sigs. have not been stripped off before reaching the
>end recipient).

Regarding this issue, I believe that the most important factor is making the
correct access control decision.  Allowing multiple different security
labels applied to a content endanger that goal.

>
>Bill.
>_____________________________________________________________________
>William Ottaway,             Tel: +44 (0)1684 894079
>DERA Malvern,                Fax: +44 (0)1684 896113
>St. Andrews Road,            email: [email-masked]
>Malvern,
>Worcs, WR14 3PS
>UK
>
>

Date: Tue, 14 Apr 1998 13:06:07 -0400
To: [email-masked] (David P. Kemp), [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Sender: [email-masked]

Dave,

You stated:
>But if your purpose is to identify which signature/label is applied by
>the originator and which by a gateway / MTA / etc, then a lightweight,
>flexible mechanism which allows parallel signatures should be an
>option.  That was Chris Bonnatti's original point.  One mechanism is
>the "Signature Purpose" attribute referred to in the subject line which
>would identify one signature as the originator's.

IMHO, the signaturePurpose attribute should not be used for access control
purposes.  For example, what happens if every additional signer includes a
signaturePurpose indicating that she is the original signer???

>Another mechanism is
>for the gateway's certificate to restrict it's signature from being
>interpreted as a message originator's.

This is a huge assumption about people agreeing on how to populate
certificates.  It is too much detail for inclusion in the S/MIME specs.
This should be a matter  of local policy.

>The point is that if:
>  1) you don't have/support a suitable signature purpose mechanism, and
>  2) your security policy requires you to identify the originator's label
>     in order to give it special treatment over all other labels,
>then you can still use the left message with signature wrapping to
>identify the originator.  If either of those is false, then you are
>able to use either wrapped or parallel signatures.  There is no need
>for an arbitrary "labels must be identical" restriction which as a side
>effect forces you to always use wrapped signatures.

I disagree.  There is no need to attach multiple different security labels
to a single content.  Please see my previous messages for my supporting logic.

>Note: even with the left message, there is no way to determine the
>message originator if multiple signatures contain identical labels.
>So the Signature Purpose attribute is useful even with the label
>restriction.

If all security labels are identical, then it doesn't matter.  That is the
point.

- John Pawling

Date: Tue, 14 Apr 1998 12:58:50 -0400
To: "JOHN ROSS" <[email-masked]>, <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Sender: [email-masked]

John,

My comments regarding access control checks were meant to support my
assertion that multiple different security labels are not required to be
attached to a single content.  I was not implying that my statements should
be incorporated into the ESS I-D. 

You stated:
>This means that all originators must know all the recipients security
>policy. I do not agree that this is practical solution in a global messaging
>environment.

That is the only solution.  If an originator does not understand the
authorizations of a recipient, then she had better not send a sensitive
message to that recipient.

>This assumes that all recipients will understand security labels from all
>users in all security domains, and be able to map the security label they
>receive to one understood under the local security policy.

That is correct.  If you don't understand somebody else's security policy,
then don't communicate sensitive data with them.

>Would it not be
>more practical to do that mapping just one at security domain boundary?

I believe that the security label values assigned by the human signer are
sacred and must not be removed, changed, superseded or otherwise corrupted.
The human signer understands the complete context of the message and the
security policy rules that apply to labeling that message.  The human signer
makes conscious decisions regarding the sensitivity of the content which may
be based on subjective or other knowledge that is not available to the
gateway software.  Therefore, I disagree with your implication that a
gateway should change the signer's label or inlcude a translated label in
the signer's signedData object.  If the gateway wants to add an outer
signedData including a translated label, then that is fine because the GW is
the signer of that signedData and can populate the security label with the
appropriate values.  The recipient will be able to easily distinguish
between the GW's outer signedData and human signer's inner signedData.

>
>If I understand correctly your main concern, it is the possibility of
>inconsistency between semantics of the security label as known and generated
>by the originator and the semantics of other security labels (which may be
>added later in the message path).  My view is the semantics of a security
>label  and how it is processed on receipt is dictated by the security policy
>in the receiving domain and not the originating domain.

I disagree.  It is a function of all of the security policies involved with
the message transaction.  If a GW strips out the signer's security label (or
otherwise supersedes it), then the recipient's software never gets a chance
to see the human signer's label.

I disagree with all of the following text because it is too detailed for
inclusion in the ESS spec.  This should be up to the local organizations.

>I think what you are in fact trying to achieved is a global security policy,
>which in itself is a commendable goal.
>
>Possible solution:
>I wonder, if one way round this problem be to specify a default security
>policy identifier in the S/MIME specifications which implies the policy you
>have in mind. Which I think is something like : (When an originator uses
>this policy id, it implies that the originators policy must be understood by
>the recipient and supersedes any other security label within the same signed
>data, if the policy id is not understood by the recipient the message shall
>be rejected).
>
>If you make the behaviour rules you are looking for dependant upon the
>security policy in the way proposed above, I think the behaviour you are
>looking for can be achieved. The above proposal should also meet other
>domains needs as well, when other policy ids are used.
>
>Does anybody else have a view?
>>
>
>

Date: Tue, 14 Apr 1998 18:00:28 +0100
To: [email-masked]
From: William Ottaway <[email-masked]>
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Sender: [email-masked]

>
>Possible solution:
>I wonder, if one way round this problem be to specify a default security
>policy identifier in the S/MIME specifications which implies the policy you
>have in mind. Which I think is something like : (When an originator uses
>this policy id, it implies that the originators policy must be understood by
>the recipient and supersedes any other security label within the same signed
>data, if the policy id is not understood by the recipient the message shall
>be rejected).
>
>If you make the behaviour rules you are looking for dependant upon the
>security policy in the way proposed above, I think the behaviour you are
>looking for can be achieved. The above proposal should also meet other
>domains needs as well, when other policy ids are used.
>
>Does anybody else have a view?
>>

I like this idea of having a default security policy. However, if the
policy is not understood by the recipient the outcome is down to the
recipients security policy. This may result in the message being rejected,
as you suggested, or it may allow the message through but with some
indication that the policy was not understood.

I deliberately referred to "security policy" rather that "security policy
identifier" because I'm not sure that an identifier is required.

Here is my stab at it:

Lets say that a default security policy is stated within SMIME. This policy
will describe a set of eSSSecurityLabel values which can be used in the
majority of general messaging cases.

Now an originator has the choice of using the default policy or some other
policy. This other policy may have additional labels to those in the
default or it may use totally different ones. The non default policy should
only be used when communicating with a recipient which understands this
policy. In all other cases the default should be used.

What a recipient does when he receives SMIME must be covered by that
recipients policy. A typical scenario would be that when an unknown
eSSSecurityLabel is received it is rejected. The recipient does not need to
know what security policy is being used, it just needs to be able to act on
the eSSSecurityLabel.

The advantage of having a default policy is in mapping. If a recipient uses
different eSSSecurityLabel internally to the default then incoming default
SMIME eSSSecurityLabel values can be mapped, at the boundary, onto the
domains own labels.

I appologise if I have just reworded the original solution.

Bill
   
_____________________________________________________________________
William Ottaway,             Tel: +44 (0)1684 894079
DERA Malvern,                Fax: +44 (0)1684 896113
St. Andrews Road,            email: [email-masked]
Malvern,
Worcs, WR14 3PS
UK

Date: Tue, 14 Apr 1998 12:33:26 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Sender: [email-masked]

> From: Paul Hoffman / IMC <[email-masked]>
>
> In your scenario, the processing software
> has no idea which label was applied by the original signer.

If your purpose is for an outer signature to "notarize" and bind an
inner signature/label to inner content, then you must use wrapped
signatures.  I've never seen such a requirement in the context of label
processing.

But if your purpose is to identify which signature/label is applied by
the originator and which by a gateway / MTA / etc, then a lightweight,
flexible mechanism which allows parallel signatures should be an
option.  That was Chris Bonnatti's original point.  One mechanism is
the "Signature Purpose" attribute referred to in the subject line which
would identify one signature as the originator's.  Another mechanism is
for the gateway's certificate to restrict it's signature from being
interpreted as a message originator's.

The point is that if:
  1) you don't have/support a suitable signature purpose mechanism, and
  2) your security policy requires you to identify the originator's label
     in order to give it special treatment over all other labels,
then you can still use the left message with signature wrapping to
identify the originator.  If either of those is false, then you are
able to use either wrapped or parallel signatures.  There is no need
for an arbitrary "labels must be identical" restriction which as a side
effect forces you to always use wrapped signatures.

Note: even with the left message, there is no way to determine the
message originator if multiple signatures contain identical labels.
So the Signature Purpose attribute is useful even with the label
restriction.

Date: Tue, 14 Apr 1998 12:12:31 -0400
To: [email-masked] (David P. Kemp), [email-masked]
From: [email-masked] (John Pawling)
Subject: SignedContentReference (was Re: Rethinking Receipt)
Sender: [email-masked]

Dave,

The ESS signed receipt concept and syntax has been designed to meet a
specific purpose which is to simply indicate that the original message was
received and the signature was verified.  Your proposal includes services
that go well beyond that scope.  I am not saying that your proposal is not a
valid requirement, but I am saying that it includes requirements that are
significantly different than the security services provided by the ESS
signed receipt and should be implemented in a separate mechanism.  I am
opposed to proposals that overload the current ESS signed receipt concept
and syntax.  Please re-formulate your proposal so that it is independent of
the ESS signed receipt concept and syntax.  For example, you could propose
the addition of a "signedContentReference" authenticated attribute which
requests that the recipient perform the services that you discuss in your
message.  Your proposal should also propose a strategy for implementing the
"signedContentReference" mechanism.

I am opposed to the following idea because of the aforementioned reasons:

>OK, how about using attribute IDs to distinguish purpose.  Come to
>think of it, I like this better than the original proposal anyway.
>
>
>  id-aa-receipt  OBJECT IDENTIFIER ::= { ... }
>     -- with syntax SignedContentReference
>
>  id-aa-reference OBJECT IDENTIFIER ::= { ... }
>     -- with syntax SignedContentReference
>
>  SignedContentReference ::= SEQUENCE {
>     contentType ContentType,
>     signedContentIdentifier ContentIdentifier,
>     originatorSignatureValue OCTET STRING }
>

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

Date: Tue, 14 Apr 1998 11:41:16 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Rethinking Receipt
Sender: [email-masked]

> From: [email-masked] (John Pawling)
> 
> Dave,
> 
> I strongly disagree with your proposal because it combines two very
> different concepts into a single ASN.1 syntax.  This will be extremely
> confusing to the implementors, users and everyone else involved.

The common concept is that one message (a receipt or a reply) is
cryptographically linked to another (the original message).  The
common function can and should be represented by a common syntax.

The differences you point out, human interaction vs. automated response,
reply content vs. no returned content, need to be distinguished
somehow.  I'm not really concerned about the syntax used to make
the distinction; I'm concerned about identifying and reusing
syntax applicable to the area of commonality.

> Please re-formulate your proposal so that it does relate to the signed
> receipt concept.

OK, how about using attribute IDs to distinguish purpose.  Come to
think of it, I like this better than the original proposal anyway.

  id-aa-receipt  OBJECT IDENTIFIER ::= { ... }
     -- with syntax SignedContentReference

  id-aa-reference OBJECT IDENTIFIER ::= { ... }
     -- with syntax SignedContentReference

  SignedContentReference ::= SEQUENCE {
     contentType ContentType,
     signedContentIdentifier ContentIdentifier,
     originatorSignatureValue OCTET STRING }

From: "JOHN ROSS" <[email-masked]>
To: <[email-masked]>, "John Pawling" <[email-masked]>
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Date: Tue, 14 Apr 1998 16:08:44 +0100
Sender: [email-masked]

John (P)

I think I now understand your key assumption:

You state:" The originator should ensure that the single eSSSecurityLabel
includes values that are either defined under the recipient's security
policy"

This means that all originators must know all the recipients security
policy.

I do not agree that this is practical solution in a global messaging
environment.

Also you state:"Another reason that I disagree with your scenarios is
because there is no reason to include different semantically-equivalent
eSSSecurityLabels in a single signedData object because the originator and
each recipient can locally translate the "identical" eSSSecurityLabel to a
specific security policy, if required."

This assumes that all recipients will understand security labels from all
users in all security domains, and be able to map the security label they
receive to one understood under the local security policy.  Would it not be
more practical to do that mapping just one at security domain boundary?

If I understand correctly your main concern, it is the possibility of
inconsistency between semantics of the security label as known and generated
by the originator and the semantics of other security labels (which may be
added later in the message path).  My view is the semantics of a security
label  and how it is processed on receipt is dictated by the security policy
in the receiving domain and not the originating domain.

I think what you are in fact trying to achieved is a global security policy,
which in itself is a commendable goal.

Possible solution:
I wonder, if one way round this problem be to specify a default security
policy identifier in the S/MIME specifications which implies the policy you
have in mind. Which I think is something like : (When an originator uses
this policy id, it implies that the originators policy must be understood by
the recipient and supersedes any other security label within the same signed
data, if the policy id is not understood by the recipient the message shall
be rejected).

If you make the behaviour rules you are looking for dependant upon the
security policy in the way proposed above, I think the behaviour you are
looking for can be achieved. The above proposal should also meet other
domains needs as well, when other policy ids are used.

Does anybody else have a view?
>

Date: Tue, 14 Apr 1998 15:53:23 +0100
To: [email-masked]
From: William Ottaway <[email-masked]>
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Sender: [email-masked]

The way I see it.

There is a requirement to allow for third party signatures to be attached
to a SMIME message. An example of a third party would be a mail guard
stamping its own signature onto the SMIME as it leaves the originators
domain. Please note that during the lifetime of the message more than one
third party may add its signature.

There have been two possible solutions discussed on this list.

1) Nesting: encapsulating the CMS object in an outer signedData object in
which the third party can include its eSSSecuritylabel.

2) No Nesting: Signature is added alongside other signatures. (Daves
righthand example).

Pros and cons:

Nesting:
Pros.

1) Nothing needs to change.

Cons:

1) Not sure about this, I'm on shakey ground. Is there a problem if the
message is not processed by any guards before arriving at the recipient?
This would be the case where the recipients security policy is "I don't
care". He would have to work his way down through the nesting until he got
to the level which contained the initial originators message. Would the
recipient actually do this? or would he expect the initial originators
message to be at the top level?

No Nesting:
Pros:

1) Everything is at the top level (easily accessable).

Cons:

1) Don't know which signature to use. This is why the Signature Purpose
attribute was proposed. With the signatures tied into a purpose it can be
left up to site policy. (Dangerous words I think :-) ).

2) Not compatible with previous drafts.

Additional Pros/Cons welcome.
Comments expected.

When I hear nesting I start thinking lots of overhead. All that infomation
just to encapsulate a chunk of data. Whereas "sliding" another signature in
seems a lot neater, though I am curious as to how easy it would be to do this.

Therefore, I'm interested in which option would require least processing
both at the adding the third party signature and at the recipient ends
(assuming third party sigs. have not been stripped off before reaching the
end recipient).

Bill.
_____________________________________________________________________
William Ottaway,             Tel: +44 (0)1684 894079
DERA Malvern,                Fax: +44 (0)1684 896113
St. Andrews Road,            email: [email-masked]
Malvern,
Worcs, WR14 3PS
UK

Date: Tue, 14 Apr 1998 10:35:40 -0400
To: Rik Drummond <[email-masked]>, "[email-masked]'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Reply Requested Proposal (was RE: Rethinking Receipt)
Sender: [email-masked]

Rik,

In my opinion, your proposal is mixing apples and oranges.  The ESS signed
receipt concept and syntax has been designed to meet a specific purpose
which is to simply indicate that the original message was received and the
signature was verified.  Your proposal includes services that go well beyond
that scope.  I am not saying that your proposal is not a valid requirement,
but I am saying that it includes requirements that are significantly
different than the security services provided by the ESS signed receipt and
should be implemented in a separate mechanism.  For example, you could
propose the addition of a "replyRequested" authenticated attribute which
requests that the recipient perform the services that you discuss in your
message.  Your proposal could also propose a strategy for implementing the
"replyRequested" mechanism.

Also, your previous message mentioned: "The disposition-mode,
disposition-type and disposition-modifier may be spelled in any combination
of upper and lower case characters."  Are you stating RFC 2298 does not use
ASN.1??  This is even more of an argument why it should be discussed
separately than the ESS signed receipt strategy (which uses ASN.1).

In summary, your proposal can and should be independent of the ESS signed
receipt mechanism.

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

At 09:06 AM 4/14/98 -0500, Rik Drummond wrote:
>It can't be independent of the signed-receipt.
>
>A signed-receipt which only gives status information that it got there and 
>the signature was readable is not good enough for many 
>application-to-application implementation. They often need to know more 
>than that.  The signed-receipt (or just receipt) should convey the type of 
>information that these applications need to automate the process. The 
>status codes should be expanded to allow things like "deleted" or 
>"processed" .
>
>A tremendous amount of work went into this area over the last two years the 
>groups should at least look at it to understand why I am saying what I am 
>saying.
>
>The IETF's EDIINT WG which has I-D out on how to do secure EDI over 
>internet would some day like to use the work you are doing. We can't unless 
>we have additional status codes in the signed-receipt.
>
>Thanks for your help, Rik
>
>

From: Rik Drummond <[email-masked]>
To: "'John Pawling'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Rethinking Receipt
Date: Tue, 14 Apr 1998 09:06:51 -0500
Sender: [email-masked]

It can't be independent of the signed-receipt.

A signed-receipt which only gives status information that it got there and 
the signature was readable is not good enough for many 
application-to-application implementation. They often need to know more 
than that.  The signed-receipt (or just receipt) should convey the type of 
information that these applications need to automate the process. The 
status codes should be expanded to allow things like "deleted" or 
"processed" .

A tremendous amount of work went into this area over the last two years the 
groups should at least look at it to understand why I am saying what I am 
saying.

The IETF's EDIINT WG which has I-D out on how to do secure EDI over 
internet would some day like to use the work you are doing. We can't unless 
we have additional status codes in the signed-receipt.

Thanks for your help, Rik

-----Original Message-----
From:	John Pawling [SMTP:[email-masked]]
Sent:	Tuesday, April 14, 1998 8:28 AM
To:	Rik Drummond; [email-masked]'
Subject:	RE: Rethinking Receipt

Rik,

You are proposing to add a security service to ESS that is very different
than the services provided by the ESS signed receipt.  I am not oppossed to
you proposing new features to be added to ESS.  I am opposed to proposals
that overload the current ESS signed receipt concept and syntax.  Please
re-formulate your proposal so that it is independent of the ESS signed
receipt concept and syntax.

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

At 07:45 AM 4/14/98 -0500, Rik Drummond wrote:
>Then I suggest we relook at what applies and what does not, because if you 
>don't implement "reply-status" functionality such as in the RFC 2298, then 
>you are greatly reducing the applicability of S/MIME v3 for
>application-to-application implementations. I-Ds are not authoritative
>sources.... that is why they are called Internet-Drafts......and my
>comments apply....
>
>The best regards, Rik
>

Date: Tue, 14 Apr 1998 09:27:40 -0400
To: Rik Drummond <[email-masked]>, "[email-masked]'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Rethinking Receipt
Sender: [email-masked]

Rik,

You are proposing to add a security service to ESS that is very different
than the services provided by the ESS signed receipt.  I am not oppossed to
you proposing new features to be added to ESS.  I am opposed to proposals
that overload the current ESS signed receipt concept and syntax.  Please
re-formulate your proposal so that it is independent of the ESS signed
receipt concept and syntax. 

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

At 07:45 AM 4/14/98 -0500, Rik Drummond wrote:
>Then I suggest we relook at what applies and what does not, because if you 
>don't implement "reply-status" functionality such as in the RFC 2298, then 
>you are greatly reducing the applicability of S/MIME v3 for 
>application-to-application implementations. I-Ds are not authoritative 
>sources.... that is why they are called Internet-Drafts......and my 
>comments apply....
>
>The best regards, Rik
>

Date: Tue, 14 Apr 1998 09:22:04 -0400
To: "JOHN ROSS" <[email-masked]>, <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Sender: [email-masked]

John,

With all due respect, your message is a great example of why I oppose the
proposal to allow different eSSSecurityLabels to be present in a single
signedData object.  Your message is full of assumptions about the way
organizations are going to perform access control.  It implies adding
greater complexity at every stage of the processing.  It assumes that there
are guards present that are going to perform various types of security
services.  This is too much complexity to try to gain consensus to add to
the ESS spec.  The ESS spec should leave these details to the local
organizations.

Your proposal also implies that the receiving agent will simply ignore
eSSSecurityLabels that it does not understand.  This is unacceptable because
the entity that applied that security label did it for a purpose.  If you
ignore that security label, you run the risk of ignoring important guidance
requested by the originator or one of the intermediate processing agents.  I
believe that there should be one common eSSSecurityLabel that applies to a
single content.  If the receiving agent does not understand the security
policy in the common eSSSecurityLabel, then the receiving agent should
reject the message.  In most cases, the originator will have already
performed access control checks to ensure that the recipient has the proper
authorizations to receive the message.  The originator should ensure that
the single eSSSecurityLabel includes values that are either defined under
the recipient's security policy or can be locally translated by the
recipient to her security policy.

Another reason that I disagree with your scenarios is because there is no
reason to include different semantically-equivalent eSSSecurityLabels in a
single signedData object because the originator and each recipient can
locally translate the "identical" eSSSecurityLabel to a specific security
policy, if required.  Furthermore, ESS MUST prohibit semantically different
eSSSecurityLabels from being included in a single signedData because that
creates a significant possiblity that there will be contradictions between
the semantically different labels that would lead to errorneous or
inconsistent access control decisions applied to a content. Therefore, since
different, semantically-equivalent eSSSecurityLabels are not required and
semantically-different eSSSecurityLabels MUST be prohibited, then the
current ESS text is correct to mandate that all eSSSecurityLabel attributes
present in a signedData object must be identical.

- John Pawling

At 09:47 AM 4/14/98 +0100, JOHN ROSS wrote:
>I agree with David, because the access control  decision process within the
>recipients security domain will depend on which security policy is supported
>(i,.e. is it Label x or Label y policy).
>
>If the security policy of the recipients domain supports both label
>policies, then both labels will be used irrespective of nesting.
>
>However, if only one of the two security label policies is supported then
>that is the label the recipients domain will use. Again this will be
>irrespective of nesting (i.e it may or may not be nested labels).
>
>I agree that the originators view of the classification (or other marking)
>of the message should be respected by the recipient domain, but that is
>achieved by guards at domain boundaries which do not let messages pass out
>of a security domain into a security domain they do not trust will respect
>the semantics of the originators label.
>
>Once a security domain "releases" a message out of it's domain and control,
>it must trust recipients domain will do the honourable thing and respect the
>label semantics (irrespective of the syntax and which label is supported in
>the recipients domain, which may be : x , y or both).  If a security domain
>does not trust another security domain, it should not let the message pass
>between the domains, this would be achieved by a suitable guard function.
>
>-----Original Message-----
>From: Paul Hoffman / IMC <[email-masked]>
>To: [email-masked] <[email-masked]>
>Date: 13 April 1998 23:35
>Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
>
>
>>At 03:08 PM 4/13/98 -0400, David P. Kemp wrote:
>>>   _____________          _________
>>>  |  _________  |        | Content |
>>>  | | Content | |        |- - - - -|
>>>  | |- - - - -| |        | Label X |
>>>  | | Label X | |        |- - - - -|
>>>  | |_________| |        | Label Y |
>>>  |- - - - - - -|        |_________|
>>>  |   Label Y   |
>>>  |_____________|
>>>
>>
>>This is a great picture of the problem with your advocacy of the scenario
>>on the right. On the left, the security processing software knows exactly
>>who the originator of the content is and can choose whether or not to honor
>>Label Y based on that knowledge. In your scenario, the processing software
>>has no idea which label was applied by the original signer.
>>
>>Assume that the recipient's processing software has a policy that says "if
>>you don't understand a security label, toss the message if that label was
>>issued by the sender but ignore the label if it was added somewhere else".
>>In human terms, this says "ignore outer security information but pay
>>attention to the sender's wishes". This works fine for wrapping and fails
>>completely with signerInfo stuffing.
>>
>>Basically, we have to trust the sender to specify their wishes.
>>
>>--Paul Hoffman, Director
>>--Internet Mail Consortium
>
>

From: Rik Drummond <[email-masked]>
To: "'John Pawling'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Rethinking Receipt
Date: Tue, 14 Apr 1998 07:45:38 -0500
Sender: [email-masked]

Then I suggest we relook at what applies and what does not, because if you 
don't implement "reply-status" functionality such as in the RFC 2298, then 
you are greatly reducing the applicability of S/MIME v3 for 
application-to-application implementations. I-Ds are not authoritative 
sources.... that is why they are called Internet-Drafts......and my 
comments apply....

The best regards, Rik

-----Original Message-----
From:	John Pawling [SMTP:[email-masked]]
Sent:	Tuesday, April 14, 1998 7:38 AM
To:	Rik Drummond; [email-masked]'
Subject:	RE: Rethinking Receipt

Rik,

The S/MIME v3 ESS I-D is the authoritative source for the syntax and
semantics of the ESS signed receipt.  ESS is not implementing RFC 2298, so
your comments do not apply to this issue.

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

Date: Tue, 14 Apr 1998 08:38:05 -0400
To: Rik Drummond <[email-masked]>, "[email-masked]'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Rethinking Receipt
Sender: [email-masked]

Rik,

The S/MIME v3 ESS I-D is the authoritative source for the syntax and
semantics of the ESS signed receipt.  ESS is not implementing RFC 2298, so
your comments do not apply to this issue. 

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

From: "JOHN ROSS" <[email-masked]>
To: <[email-masked]>, "Paul Hoffman / IMC" <[email-masked]>
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Date: Tue, 14 Apr 1998 09:47:20 +0100
Sender: [email-masked]

I agree with David, because the access control  decision process within the
recipients security domain will depend on which security policy is supported
(i,.e. is it Label x or Label y policy).

If the security policy of the recipients domain supports both label
policies, then both labels will be used irrespective of nesting.

However, if only one of the two security label policies is supported then
that is the label the recipients domain will use. Again this will be
irrespective of nesting (i.e it may or may not be nested labels).

I agree that the originators view of the classification (or other marking)
of the message should be respected by the recipient domain, but that is
achieved by guards at domain boundaries which do not let messages pass out
of a security domain into a security domain they do not trust will respect
the semantics of the originators label.

Once a security domain "releases" a message out of it's domain and control,
it must trust recipients domain will do the honourable thing and respect the
label semantics (irrespective of the syntax and which label is supported in
the recipients domain, which may be : x , y or both).  If a security domain
does not trust another security domain, it should not let the message pass
between the domains, this would be achieved by a suitable guard function.

-----Original Message-----
From: Paul Hoffman / IMC <[email-masked]>
To: [email-masked] <[email-masked]>
Date: 13 April 1998 23:35
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)

>At 03:08 PM 4/13/98 -0400, David P. Kemp wrote:
>>   _____________          _________
>>  |  _________  |        | Content |
>>  | | Content | |        |- - - - -|
>>  | |- - - - -| |        | Label X |
>>  | | Label X | |        |- - - - -|
>>  | |_________| |        | Label Y |
>>  |- - - - - - -|        |_________|
>>  |   Label Y   |
>>  |_____________|
>>
>
>This is a great picture of the problem with your advocacy of the scenario
>on the right. On the left, the security processing software knows exactly
>who the originator of the content is and can choose whether or not to honor
>Label Y based on that knowledge. In your scenario, the processing software
>has no idea which label was applied by the original signer.
>
>Assume that the recipient's processing software has a policy that says "if
>you don't understand a security label, toss the message if that label was
>issued by the sender but ignore the label if it was added somewhere else".
>In human terms, this says "ignore outer security information but pay
>attention to the sender's wishes". This works fine for wrapping and fails
>completely with signerInfo stuffing.
>
>Basically, we have to trust the sender to specify their wishes.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium

From: Rik Drummond <[email-masked]>
To: "'John Pawling'" <[email-masked]>, "'David P. Kemp'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Rethinking Receipt
Date: Mon, 13 Apr 1998 20:36:48 -0500
Sender: [email-masked]

I believe if you read the RFC for the MDN, which includes how to do 
receipts you will find that a signed receipt may contain information such 
as "deleted" and "processed". So your statement that "and are sent 
automatically to the originating agent to indicate ONLY that the message 
was received and the signature was verified"....is not correct. Please look 
at:

	R. Fajman, "An Extensible Message Format
	for Message Disposition Notifications",
	RFC 2298, March 1998.

These type of status codes are important to many applications and convey a 
lot more than just " received and signature verified".

See excerpt of RFC 2298 below:

   The syntax for the Disposition field is:

     disposition-field = "Disposition" ":" disposition-mode ";"
                         disposition-type
                         [ '/' disposition-modifier
                           *( "," disposition-modifier ) ]

     disposition-mode = action-mode "/" sending-mode

     action-mode = "manual-action" / "automatic-action"

     sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"

     disposition-type = "displayed"
                      / "dispatched"
                      / "processed"
                      / "deleted"
                      / "denied"
                      / "failed"

     disposition-modifier = ( "error" / "warning" )
                          / ( "superseded" / "expired" /
                              "mailbox-terminated" )
                          / disposition-modifier-extension

     disposition-modifier-extension = atom

   The disposition-mode, disposition-type and disposition-modifier may
   be spelled in any combination of upper and lower case characters.

-----Original Message-----
From:	John Pawling [SMTP:[email-masked]]
Sent:	Monday, April 13, 1998 5:45 PM
To:	David P. Kemp; [email-masked]
Subject:	Re: Rethinking Receipt

Dave,

I strongly disagree with your proposal because it combines two very
different concepts into a single ASN.1 syntax.  This will be extremely
confusing to the implementors, users and everyone else involved.

Returning a signed receipt provides to the originator proof of delivery of 
a
message, and allows the originator to demonstrate to a third party that the
recipient was able to verify the signature of the original message.  That 
is
the ONLY purpose of the signed receipt.  The concept is that signed 
receipts
are generated automatically by the receiving software and are sent
automatically to the originating agent to indicate ONLY that the message 
was
received and the signature was verified.  The concept is that there is no
human intervention in this process.  The app should indicate to the user
that a signed receipt was sent to the requesting party on the recipient's
behalf, but that should be the only human interaction.

The proposed contentReference implies significant human interaction that 
the
user makes one or more decisions regarding whether or not the response is
sent and what the response means, etc.  This is a very different concept
than signed receipts and should be separated into a different ASN.1 syntax.

Please re-formulate your proposal so that it does relate to the signed
receipt concept.

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

At 05:53 PM 4/13/98 -0400, David P. Kemp wrote:
>Folks,
>
>ESS Section 2 discusses the operation of ReceiptRequests and Receipts:
>
>  2.1: "The request is indicated by adding a receiptRequest attribute
>  to the signedAttributes field of the SignerInfo object for which the
>  receipt is requested."
>
>and
>
>  2.8: "Receipts are represented using a new content type, Receipt."
>
>  Receipt ::= SEQUENCE {
>      version Version,
>      contentType ContentType,
>      signedContentIdentifier ContentIdentifier,
>      originatorSignatureValue OCTET STRING }
>
>
>A colleague has proposed that the receipt structure would be much more
>useful if it were generalized and represented by an attribute instead
>of by a unique content type.  The attribute could represent the
>existing security receipt, or it could be used to securely link an
>ordinary reply to the message it refers to.  This is such an insightful
>and elegant idea that I wish I had thought of it first!  Thanks, C.A.!
>
>I propose that ESS replace the Receipt structure and id-ct-receipt with
>a new signatureBinding attribute:
>
>  id-aa-signatureBinding OBJECT IDENTIFIER ::= { tbd }
>
>  SignatureBinding ::= SEQUENCE {
>      contentType ContentType,
>      signedContentIdentifier ContentIdentifier,
>      originatorSignatureValue OCTET STRING,
>      bindingPurpose BindingPurpose }
>
>  BindingPurpose ::= INTEGER {
>      receipt          (0),
>      contentReference (1) }
>
>
>For Receipts, the bindingPurpose identifier would have the value
>"receipt", and the encapContentInfo would be treated as in the
>degenerate signed data case: eContentType is id-data, and eContent
>is omitted.
>
>For normal message replies, bindingPurpose would have the value
>contentReference, and encapContentInfo would be the reply message.
>
>In low-bandwidth or large-data applications, it may be useful to have
>messages or attachments pre-signed and cached at both the sender's and
>recipient's locations.  A small message could then use the
>signatureBinding attribute to refer to one of the cached signed
>contents.  Additional bindingPurpose codes, such as
>signatureValidation, could be defined if needed.
>
>Comments?
>
>Dave Kemp
>

Date: Mon, 13 Apr 1998 17:47:45 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: SecureConnect 1 announcement
Sender: [email-masked]

IMC's popular series of interoperability events for developers continues
with SecureConnect 1 for S/MIME v2, S/MIME v3, PGP/MIME, and OpenPGP.
SecureConnect 1 will be held July 23 and 24, and will cover end-to-end mail
security, specifically using S/MIME v2, S/MIME v3, PGP/MIME, and OpenPGP.
The market for mail clients using these technologies continues to grow, and
the S/MIME v3 and OpenPGP specs are nearing completion. Now is the time for
the industry to make sure that shipping and soon-to-be-shipping products
interoperate. Signed messages require the presence of certificates, and
SecureConnect 1 will also be a place for certificate Authority (CA) vendors
to test the interoperability of the certificates generated by their
products. Further, user agent vendors at SecureConnect 1 will be able to
make sure that their products can create and verify messages that come with
certificates from participating CAs.

More information about SecureConnect 1 can be found at
<http://www.imc.org/imc-secureconnect/>.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 13 Apr 1998 18:44:38 -0400
To: [email-masked] (David P. Kemp), [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Rethinking Receipt
Sender: [email-masked]

Dave,

I strongly disagree with your proposal because it combines two very
different concepts into a single ASN.1 syntax.  This will be extremely
confusing to the implementors, users and everyone else involved.

Returning a signed receipt provides to the originator proof of delivery of a
message, and allows the originator to demonstrate to a third party that the
recipient was able to verify the signature of the original message.  That is
the ONLY purpose of the signed receipt.  The concept is that signed receipts
are generated automatically by the receiving software and are sent
automatically to the originating agent to indicate ONLY that the message was
received and the signature was verified.  The concept is that there is no
human intervention in this process.  The app should indicate to the user
that a signed receipt was sent to the requesting party on the recipient's
behalf, but that should be the only human interaction.

The proposed contentReference implies significant human interaction that the
user makes one or more decisions regarding whether or not the response is
sent and what the response means, etc.  This is a very different concept
than signed receipts and should be separated into a different ASN.1 syntax.

Please re-formulate your proposal so that it does relate to the signed
receipt concept.

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

At 05:53 PM 4/13/98 -0400, David P. Kemp wrote:
>Folks,
>
>ESS Section 2 discusses the operation of ReceiptRequests and Receipts:
>
>  2.1: "The request is indicated by adding a receiptRequest attribute
>  to the signedAttributes field of the SignerInfo object for which the
>  receipt is requested."
>
>and
>
>  2.8: "Receipts are represented using a new content type, Receipt."
>
>  Receipt ::= SEQUENCE {
>      version Version,
>      contentType ContentType,
>      signedContentIdentifier ContentIdentifier,
>      originatorSignatureValue OCTET STRING }
>
>
>A colleague has proposed that the receipt structure would be much more
>useful if it were generalized and represented by an attribute instead
>of by a unique content type.  The attribute could represent the
>existing security receipt, or it could be used to securely link an
>ordinary reply to the message it refers to.  This is such an insightful
>and elegant idea that I wish I had thought of it first!  Thanks, C.A.!
>
>I propose that ESS replace the Receipt structure and id-ct-receipt with
>a new signatureBinding attribute:
>
>  id-aa-signatureBinding OBJECT IDENTIFIER ::= { tbd }
>
>  SignatureBinding ::= SEQUENCE {
>      contentType ContentType,
>      signedContentIdentifier ContentIdentifier,
>      originatorSignatureValue OCTET STRING,
>      bindingPurpose BindingPurpose }
>
>  BindingPurpose ::= INTEGER {
>      receipt          (0),
>      contentReference (1) }
>
>
>For Receipts, the bindingPurpose identifier would have the value
>"receipt", and the encapContentInfo would be treated as in the
>degenerate signed data case: eContentType is id-data, and eContent
>is omitted.
>
>For normal message replies, bindingPurpose would have the value
>contentReference, and encapContentInfo would be the reply message.
>
>In low-bandwidth or large-data applications, it may be useful to have
>messages or attachments pre-signed and cached at both the sender's and
>recipient's locations.  A small message could then use the
>signatureBinding attribute to refer to one of the cached signed
>contents.  Additional bindingPurpose codes, such as
>signatureValidation, could be defined if needed.
>
>Comments?
>
>Dave Kemp
>

Date: Mon, 13 Apr 1998 15:19:45 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Sender: [email-masked]

At 03:08 PM 4/13/98 -0400, David P. Kemp wrote:
>   _____________          _________
>  |  _________  |        | Content |
>  | | Content | |        |- - - - -|
>  | |- - - - -| |        | Label X |
>  | | Label X | |        |- - - - -|
>  | |_________| |        | Label Y |
>  |- - - - - - -|        |_________|
>  |   Label Y   |
>  |_____________|
>

This is a great picture of the problem with your advocacy of the scenario
on the right. On the left, the security processing software knows exactly
who the originator of the content is and can choose whether or not to honor
Label Y based on that knowledge. In your scenario, the processing software
has no idea which label was applied by the original signer.

Assume that the recipient's processing software has a policy that says "if
you don't understand a security label, toss the message if that label was
issued by the sender but ignore the label if it was added somewhere else".
In human terms, this says "ignore outer security information but pay
attention to the sender's wishes". This works fine for wrapping and fails
completely with signerInfo stuffing.

Basically, we have to trust the sender to specify their wishes.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 13 Apr 1998 17:53:26 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Rethinking Receipt
Sender: [email-masked]

Folks,

ESS Section 2 discusses the operation of ReceiptRequests and Receipts:

  2.1: "The request is indicated by adding a receiptRequest attribute
  to the signedAttributes field of the SignerInfo object for which the
  receipt is requested."

and

  2.8: "Receipts are represented using a new content type, Receipt."

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

A colleague has proposed that the receipt structure would be much more
useful if it were generalized and represented by an attribute instead
of by a unique content type.  The attribute could represent the
existing security receipt, or it could be used to securely link an
ordinary reply to the message it refers to.  This is such an insightful
and elegant idea that I wish I had thought of it first!  Thanks, C.A.!

I propose that ESS replace the Receipt structure and id-ct-receipt with
a new signatureBinding attribute:

  id-aa-signatureBinding OBJECT IDENTIFIER ::= { tbd }

  SignatureBinding ::= SEQUENCE {
      contentType ContentType,
      signedContentIdentifier ContentIdentifier,
      originatorSignatureValue OCTET STRING,
      bindingPurpose BindingPurpose }

  BindingPurpose ::= INTEGER {
      receipt          (0),
      contentReference (1) }

For Receipts, the bindingPurpose identifier would have the value
"receipt", and the encapContentInfo would be treated as in the
degenerate signed data case: eContentType is id-data, and eContent
is omitted.

For normal message replies, bindingPurpose would have the value
contentReference, and encapContentInfo would be the reply message.

In low-bandwidth or large-data applications, it may be useful to have
messages or attachments pre-signed and cached at both the sender's and
recipient's locations.  A small message could then use the
signatureBinding attribute to refer to one of the cached signed
contents.  Additional bindingPurpose codes, such as
signatureValidation, could be defined if needed.

Comments?

Dave Kemp

Date: Mon, 13 Apr 1998 17:32:38 -0400
To: [email-masked] (David P. Kemp), [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Sender: [email-masked]

Dave,

>If you could produce an example demonstrating an incorrect access
>control decision, I would be more inclined to believe this assertion.

OK, lets assume that anybody can add whatever eSSSecuritylabel to a
signedData object that they desire.  Assume User A drafts a content, decides
that the content is classified ACME PROPRIETARY and sends the signedData in
which User A's signerInfo includes an ESSSecurityLabel including the ACME
PROPRIETARY security classification.  Assume user B receives user A's
signedData, decodes it, decides that it should really be classified as ACME
PERSONNEL DATA.  User B adds her signerInfo to the original signedData
object in which she includes an ESSSecurityLabel including the ACME
PERSONNEL DATA security classification and sends it off.  User C receives
the signedData from User B.  User C's software verifies User B's signerInfo
and User A's signerInfo.  User C's SW detects one ESSSecurityLabel including
the ACME PROPRIETARY security classification and another ESSSecurityLabel
including the ACME PERSONNEL DATA security classification.  What is the real
classification of the content????   That is the problem.

>My assertion is that the identical decision will be produced from a
>set of semantically different labels regardless of whether the signatures
>are wrapped or parallel.

I disagree.  With the current ESS strategy, a separate decsion is made for
each encapsulated content.  That is an important distinction.

>Consider the following two messages, where the boxes represent SignedData
>structures, and "Label X" and "Label Y" represent semantically different
>eSSSecurityLabels contained in the signed-attributes of two SignerInfo
>structures.  With the current restriction, only the left message is legal.
>If the restriction were eliminated, both the left and the right messages
>would be legal, and the choice of which to use could be based on other
>criteria.
>
>   _____________          _________
>  |  _________  |        | Content |
>  | | Content | |        |- - - - -|
>  | |- - - - -| |        | Label X |
>  | | Label X | |        |- - - - -|
>  | |_________| |        | Label Y |
>  |- - - - - - -|        |_________|
>  |   Label Y   |
>  |_____________|
>
>
>An ACDF operating on Label Y and the recipient's privileges will produce
>a binary access decision "Grant" or "Deny" (True or False).  An ACDF on
>Label X and the recipient's privileges will produce another binary
>decision.  Please explain how those decisions when applied to the left
>message will be correct and consistent, while the same decisions applied
>to the right message might be erroneous or inconsistent.

First, let me add some detail to your left diagram:

   _______________          
  |  ___________  |
  | |           | |
  | | _________ | | 
  | ||  Inner  || |
  | || Content || | 
  | ||- - - - -|| | 
  | || Label X || | 
  | ||_________|| | 
  | |           | | 
  | |   Outer   | |
  | |  Content  | |
  |  -----------  |
  |- - - - - - - -|       
  |    Label Y    |
  |_______________|

My point is that there are two completely independent access control
decisions made.  One decision is based on Label Y which applies to the outer
content.  The other decision is based on Label X which applies to the inner
content.  This "nested signedData" strategy provides the local organization
with the flexibility to generate its security policy such that the actions
taken when an access control failure occurs while processing an outer
signedData are different (if required) than when an access control failure
occurs while processing an inner signedData.  The "nested signedData"
strategy makes this simple to specify and simple to implement.  

In the model on the right, there is a single access control decision
applying to the content that includes Label X and Label Y as inputs.  If
Label X and Label Y are different, what is the real classification of the
content upon which the single access control decsion is to be based????
That is the problem.

>(Remember too that we're discussing recipient-based access control of
>unencrypted data, which is a near-zero-assurance process.  But that's
>another topic altogether.)

We are not talking ONLY about recipient-based access control decisions.  The
current ESS strategy does not limit access control to ONLY being
recipient-based.  An access control strategy MUST include checking a
recipient's authorizations before sending sensitive data to that recipient
to ensure that the recipient's authorizations indicate that the recipient is
allowed to have access to the data.  IMHO, we should not specify access
control strategies in the S/MIME specs.  This should be left to the local
organizations.

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

Date: Mon, 13 Apr 1998 15:08:20 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Sender: [email-masked]

> From: [email-masked] (John Pawling)
>
> Mandating that all eSSSecurityLabels must be
> identical in a signedData ensures that only a single semantic label is bound
> with the content and that significantly simplifies the access control problem.

John,

I don't disagree with the requirement; I do disagree that the
"identical label" restriction simplifies the access control problem.

> Furthermore, ESS MUST prohibit semantically different eSSSecurityLabels from
> being included in a single signedData because that creates a significant
> possiblity that there will be contradictions between the semantically
> different labels that would lead to errorneous or inconsistent access
> control decisions.

If you could produce an example demonstrating an incorrect access
control decision, I would be more inclined to believe this assertion.
My assertion is that the identical decision will be produced from a
set of semantically different labels regardless of whether the signatures
are wrapped or parallel.

Consider the following two messages, where the boxes represent SignedData
structures, and "Label X" and "Label Y" represent semantically different
eSSSecurityLabels contained in the signed-attributes of two SignerInfo
structures.  With the current restriction, only the left message is legal.
If the restriction were eliminated, both the left and the right messages
would be legal, and the choice of which to use could be based on other
criteria.

   _____________          _________
  |  _________  |        | Content |
  | | Content | |        |- - - - -|
  | |- - - - -| |        | Label X |
  | | Label X | |        |- - - - -|
  | |_________| |        | Label Y |
  |- - - - - - -|        |_________|
  |   Label Y   |
  |_____________|

An ACDF operating on Label Y and the recipient's privileges will produce
a binary access decision "Grant" or "Deny" (True or False).  An ACDF on
Label X and the recipient's privileges will produce another binary
decision.  Please explain how those decisions when applied to the left
message will be correct and consistent, while the same decisions applied
to the right message might be erroneous or inconsistent.

Remember, we aren't talking about EnvelopedData, where double or triple
wrapping is necessary (and meaningful); we're talking about a
restriction which (IMHO unnecessarily) forces wrapping of a SignedData
within another SignedData.

(Remember too that we're discussing recipient-based access control of
unencrypted data, which is a near-zero-assurance process.  But that's
another topic altogether.)

Date: Mon, 13 Apr 1998 13:49:53 -0400
To: [email-masked] (David P. Kemp), [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Sender: [email-masked]

Dave,

Let me summarize my position (and the position of many others with whom I
have discussed this issue).  The current ESS strategy (all eSSSecurityLabels
in a signedData MUST be identical) meets all of the requirements that some
have argued should be met by including different, semantically-equivalent
eSSSecurityLabels in a single signedData object.   This is true because the
originator and each recipient can locally translate the "identical"
eSSSecurityLabel to a specific security policy, if required. 

Furthermore, ESS MUST prohibit semantically different eSSSecurityLabels from
being included in a single signedData because that creates a significant
possiblity that there will be contradictions between the semantically
different labels that would lead to errorneous or inconsistent access
control decisions.

Therefore, since different, semantically-equivalent eSSSecurityLabels are
not required and semantically-different eSSSecurityLabels MUST be
prohibited, then the current ESS text is correct to mandate that all
eSSSecurityLabel attributes present in a signedData object must be identical.

>You cite the
>access control requirement, which is of course not satisfied by
>SignedData nesting any more than it is by using parallel SignerInfos,
>and is therefore not an argument for or against either method. 

I disagree with everything after "of course".  The ESS "nested signedData"
strategy provides the local organization with the flexibility to generate
its security policy such that the actions taken when an access control
failure occurs while processing an outer signedData are different (if
required) than when an access control failure occurs while processing an
inner signedData.  The "nested signedData" strategy makes this simple to
specify and simple to implement.  This facilitates a simple strategy by
which a recipient can distinguish "outer" gateway-applied security labels
from the "inner" security label applied by the original signer who made the
original decisions regarding the sensitivity of the content.  This
granuluarity is more complicated to specify and to implement in the
processing of parallel signerInfos in a single signedData that contain
different eSSSecurityLabels.  Mandating that all eSSSecurityLabels must be
identical in a signedData ensures that only a single semantic label is bound
with the content and that significantly simplifies the access control problem.

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

Date: Mon, 13 Apr 1998 09:35:49 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: cert-03 - signature validation failure
Sender: [email-masked]

> From: Paul Hoffman / IMC <[email-masked]>
> 
> At 09:50 AM 4/10/98 -0400, John Pawling wrote:
> >The reporting of cert
> >path validation errors is not specific to S/MIME.  It is a topic that
> >belongs in the PKIX WG, not S/MIME WG.
> 
> I agree with John here. I think that this topic should be brought up in
> PKIX, where there is a document on cert policies (that has gone without
> almost any discussion as far as I can tell).

I agree with Paul and John on the narrow issue of cert path validation
errors.  However, the specific error codes which might result from any
particular processing module (and ASN.1 syntax for status reporting)
are the twigs on a tree; Elliott is looking at the forest.

S/MIME should say more than it now says to encourage vendors to allow
customers to configure products.  Recommending that the results of cert
path validation (PKIX-specific) or ESSSecurityLabel processing
(S/MIME-specific) be made available in a form that allows customers
to implement their own security policies is a step in the right
direction.

> From: Elliott Ginsburg <[email-masked]>
>
> My suggestion of having a set of identified
> errors was an attempt to push products in this direction.
> 
> I'm certainly open to any suggestions of how to proceed. I've considered
> the possibility of, rather than requiring anything, instead including a
> good discussion in the security section to at least make sure this issue is
> well inderstood.

Eminently reasonable.

Date: Mon, 13 Apr 1998 08:39:38 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Sender: [email-masked]

> From: [email-masked] (John Pawling)
> 
> Chris,
> 
> I still respectfully disagree with your proposal.  I admit that the layering
> of the signedData objects does add bytes to the wire, but the price paid is
> well worth the benefit of ensuring that there are not inconsistent or
> contradictory ESSSecurityLabels applied to the same content.  Mandating that
> all ESSSecurityLabels included in a single signedData must be identical
> ensures that all ESSSecurityLabels applied to a content are consistent.
> This ensures that there is no confusion regarding the sensitivity of the
> content and that an access control decision can be made in an unambiguous
> manner.

John,

  A few weeks ago I agreed with your position (that distinct labels
must appear only in distinct SignedData's), but I have since been
convinced that this provides little or no benefit.

The only cryptographic result of nesting SignedDatas is that the outer
signer (e.g. a gateway) binds the inner label to the inner content; AFAIK
there is no user requirement to provide this function.  You cite the
access control requirement, which is of course not satisfied by
SignedData nesting any more than it is by using parallel SignerInfos,
and is therefore not an argument for or against either method.  Any
access control rule operating on nested signatures will pass or fail
each signature in turn, working from outermost to innermost.  Any access
control rule operating on parallel signatures will pass or fail each
signature, but the order of processing is not necessarily specified.
The end result in either case is an AND of all the individual decisions,
which doesn't depend on the order of evaluation.  And in both cases,
each label is uniquely tied to the signer which applied it.

If someone comes up with a real requirement to specify an order in
which signatures are applied to a content, then as Chris said, a less
inefficient and inflexible means of satisfying it (for example an integer
"precedence" field in the label attribute, or a SignaturePurpose
attribute) should be used.

If there is a real requirement for an outer signer to bind inner
signatures to content, then nested SignedDatas can be used.  But ESS,
by imposing an arbitrary restriction of label equality, should not
force nesting when it is not otherwise required.

Dave Kemp

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Triple-DES Key Wrapping
Reply-To: [email-masked]
Date: Sat, 11 Apr 1998 20:55:31 (NZST)
Sender: [email-masked]

[Followup list trimmed somewhat]
 
>S/MIME 3 requires a function to encrypt one Triple-DES key in another. Below, 
>I propose such a function, and I am writing to request review of that function.
>
>I was unable to find a standard for the encryption of one Triple-DES key in 
>another Triple-DES key.  The obvious encryption of the three DES keys in ECB 
>mode does not seem sufficient to me.  This method would allow an attacker to 
>rearrange the three blocks and the recipient could not detect the problem 
>until  the entire message we decrypted.  So, I have proposed a technique that 
>provides confidentiality and integrity.
 
I ran into the same problem a few years back, and solved it by treating the 
encrypted key as just another type of PKCS #7 wrapping (well, not literally, 
but logically). 
 
The wrapped data used to communicate the session key is:
 
KeyInformation ::= SEQUENCE {
  algorithm     AlgorithmIdentifier,  
  key           OCTET STRING (SIZE(5..CRYPT_MAX_KEYSIZE)),
  cookie        KeyCookie,              
  padding       OCTET STRING OPTIONAL
  }
 
The algorithm and key specify the algorithm and session key to use for 
encrypting the remaining data.  The cookie is a truncated SHA-1 hash of the 
algorithm and key fields which (1) protects them from modification and (2) 
allows checking that the correct decryption key was used (to generate it you 
encode a KeyInformation without the cookie and padding and hash it).  The 
padding hides the length of the inner content to foil traffic analysis (the 
whole thing is always padded out to a multiple of 64 bytes).
 
The whole thing is then encrypted with the KEK:
 
EncryptedKey ::= SEQUENCE {
  algorithm     AlgorithmIdentifier,  
  iv            OCTET STRING (SIZE(1..CRYPT_MAX_IVSIZE)),
  encryptedKey  ENCRYPTED{KeyInformation}
  }
 
This scheme is independant of algorithm and encryption mode used for both KEK 
and session key, and protects the contents from modification using the 
encrypted hash.  It's also, IMHO, quite a bit simpler than the proposed 
solution and therefore easier to get right for implementors.
 
What makes this useful is that it's completely general-purpose (you can use 
any algorithm to exchange a key for any other algorithm), and has the added 
benefit that since the session key + algorithm used is hidden, you can get a 
little extra security by not using the same algorithm for both types of 
encryption (for example if you randomly choose the session key algorithm from 
{ IDEA, 3DES, Blowfish, CAST-128, and RC5 } it makes things a little harder 
for an attacker, and reduces your exposure if one of these is later broken).
 
>Please do not propose improvements that are covered by any issued or pending 
>patents.
 
Perish the thought :-).
 
Peter.

From: "Blake Ramsdell" <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, <[email-masked]>
Subject: RE: cert-03 - signature validation failure
Date: Fri, 10 Apr 1998 15:51:38 -0700
Sender: [email-masked]

On Friday, April 10, 1998 8:37 AM, Paul Hoffman / IMC
[SMTP:[email-masked]] wrote:
> At 09:50 AM 4/10/98 -0400, John Pawling wrote:
> >The reporting of cert
> >path validation errors is not specific to S/MIME.  It is a topic that
> >belongs in the PKIX WG, not S/MIME WG.
> 
> I agree with John here. I think that this topic should be brought up
in
> PKIX, where there is a document on cert policies (that has gone
without
> almost any discussion as far as I can tell).

I agree with John and Paul (and myself, I guess) that the PKIX part
should be in PKIX.

There seems like there is a "and George and Ringo" joke in here
somewhere, but I imagine that it wouldn't be funny.

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, 10 Apr 1998 08:37:11 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: cert-03 - signature validation failure
Sender: [email-masked]

At 09:50 AM 4/10/98 -0400, John Pawling wrote:
>The reporting of cert
>path validation errors is not specific to S/MIME.  It is a topic that
>belongs in the PKIX WG, not S/MIME WG.

I agree with John here. I think that this topic should be brought up in
PKIX, where there is a document on cert policies (that has gone without
almost any discussion as far as I can tell).

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 10 Apr 1998 09:50:41 -0400
To: Elliott Ginsburg <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: cert-03 - signature validation failure
Cc: [email-masked]
Sender: [email-masked]

Elliott,

IMHO, the purpose of protocol specifications is to provide the minimum
amount of information necessary to ensure that independent organizations can
build products that are interoperable.  IMHO, your error reporting proposal
is not required for interoperability.  The S/MIME specs should not mandate
design constraints that are not required for interoperability.  The customer
should be allowed to make those decisions.  If a vendor does not properly
implement error processing, then the customer should not buy that product.  

I believe that there is sufficient information in the X.509 Recommendation
and PKIX I specs from which the local organization can determine the optimal
error-handling strategy for their environment, so I disagree with the
addition of your proposed text.  The S/MIME CERT spec should only include
info that is unique to S/MIME message processing.  The reporting of cert
path validation errors is not specific to S/MIME.  It is a topic that
belongs in the PKIX WG, not S/MIME WG.

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

At 08:12 AM 4/10/98 -0400, Elliott Ginsburg wrote:
>I understand your objections and those of others, and I'm not at all sure
>what is appropriate to put in a standard. However, I'm still concerned that
>what we've got so far is not sufficient. In your response, you say you
>believe that local organizations should decide what actions to take. I
>AGREE COMPLETELY WITH THIS. My point is, the spec doesn't say anything
>about leaving these decisions to the customers; it says that the products
>must do something. I way trying to find a way to assure that customers
>would be able to implement their own policies, rather than having the
>products hardwire the actions to take. For example, if a product rejects
>any message whose signature does not validate, this is implementing a
>particular policy. 
>
>I think we all agree that we'd like to have products that allow customers
>(recipients or system admins) to configure policy. The question is, what,
>if anything, do we put in the standard to assure we get products that allow
>this in one way or another? My suggestion of having a set of identified
>errors was an attempt to push products in this direction.
>
>I'm certainly open to any suggestions of how to proceed. I've considered
>the possibility of, rather than requiring anything, instead including a
>good discussion in the security section to at least make sure this issue is
>well inderstood.
>
>Suggestions?
>
>elliott ginsburg

Date: Fri, 10 Apr 1998 08:12:39 -0400
To: [email-masked] (John Pawling)
From: Elliott Ginsburg <[email-masked]>
Subject: Re: cert-03 - signature validation failure
Cc: [email-masked]
Sender: [email-masked]

I understand your objections and those of others, and I'm not at all sure
what is appropriate to put in a standard. However, I'm still concerned that
what we've got so far is not sufficient. In your response, you say you
believe that local organizations should decide what actions to take. I
AGREE COMPLETELY WITH THIS. My point is, the spec doesn't say anything
about leaving these decisions to the customers; it says that the products
must do something. I way trying to find a way to assure that customers
would be able to implement their own policies, rather than having the
products hardwire the actions to take. For example, if a product rejects
any message whose signature does not validate, this is implementing a
particular policy. 

I think we all agree that we'd like to have products that allow customers
(recipients or system admins) to configure policy. The question is, what,
if anything, do we put in the standard to assure we get products that allow
this in one way or another? My suggestion of having a set of identified
errors was an attempt to push products in this direction.

I'm certainly open to any suggestions of how to proceed. I've considered
the possibility of, rather than requiring anything, instead including a
good discussion in the security section to at least make sure this issue is
well inderstood.

Suggestions?

elliott ginsburg

At 07:03 PM 4/9/98 , John Pawling wrote:
>Elliott,
>
>I respectfully disagree with your proposal because I believe that it is too
>detailed for inclusion in the S/MIME Cert I-D.  I believe that the local
>organizations should decide what specific actions should be taken in the
>case of cert path and signature validation errors.  I believe that there is
>sufficient information in the X.509 Recommendation and PKIX X.509
>Certificate/CRL Profile (PKIX I) from which the local organization can
>determine the optimal error-processing strategy for their environment.    
>
>You stated:
>>I also proposed a return status mechanism which can be used both for
>>configuration and by automated processes. Because it is specified in the
>>spec, it is interoperable. 
>
>I especially disagree with the inclusion of the PKIStatusInfo SEQUENCE in
>the S/MIME CERT I-D because I don't believe that there is a requirement for
>this error info to be communicated between applications, so IMHO there is
>not an interoperability requirement.  This error information is only used
>locally by the application, so there is no reason to mandate a standard
>ASN.1 syntax to hold the info.  It makes sense in the CMP I-D because the
>error info will be communicated between platforms on a regular basis, but
>this is not needed in the case of an S/MIME agent encountering an error.  
>
>In summary, I believe that the S/MIME CERT I-D should be left as is.  If
>anything, we should delete the last three paragraphs of CERT, Section 5
>because that text is redundant to X.509 and PKIX I.
>
>================================
>John Pawling, [email-masked]                             
>J.G. Van Dyke & Associates, Inc.   
>www.jgvandyke.com         
>================================
> 

Date: Fri, 10 Apr 1998 01:08:26 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Re: Reducing signature sizes.
Sender: [email-masked]

Blake Ramsdell wrote:
> 
> Now part of that is because I'm a jerk, but part of that is because it's
> the reactionary "aaah!  It's new and scary and will make the world a
> worse place!"  The TNEF I apologize for, and I have fixed -- the other
> ones I had to suffer through until people didn't complain.
> 

Yes I agree there is an element of suspicion of anything new. However
there is also the jusifiable argument that some MUA's produce needlessly
large signatures.

> I do apply selective judgement as to what messages to sign, however,
> since the non-repudiation, integrity and authenticity attributes are not
> necessary in most of my communications.  This was something that Paul
> pointed out also, I believe.
> 

I suppose it depends to some extent on whether you think people signing
a higher proportion of their messages a good thing(TM). 

> People have come to accept the
> 
> > ---- BEGIN PGP SIGNED MESSAGE ----
> > <signed stuff>
> > ---- BEGIN PGP SIGNATURE ----
> > <signature stuff>
> > ---- END PGP SIGNATURE ----
> > ---- END PGP SIGNED MESSAGE ----
> 
> block in the middle of their text (which may phase out with the use of
> PGP/MIME), much as they have come to accept
> 

Well yes. They would be much less willing to accept it if it included
several K of data in the middle.

> > I would support the specification stating that an S/MIME agent either
> > SHOULD (or even MUST) give the user the option to not include
> > certificates in signed messages.
> 
> I would support MAY or SHOULD give the user the option.
> 

So we would agree on SHOULD then :-)

Note I'm most certainly not anti-S/MIME, quite the reverse. (I am anti
some of the earlier broken standards and weak acceptance criteria but
that's nothing to do with IETF).

A solution analagous to PGP is possible with some MUA's now in that you
can exclude all your certificates and (optionally) just include a URL in
your signature to point to them. All well and good (if you have the
option). Making the process more automatic would be better (hence my
proposal).

Given that it should (or should that be SHOULD) be necessary to also
check the revocation status of a signers certificate to get a better
degree of assurance and that this necessitates (barring the inclusion of
a potentially large CRL) some repository access of some sort you might
as well get the certificate at the same time.

Steve.
-- 
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant.
Email: [email-masked]
PGP key: http://www.drh-consultancy.demon.co.uk/key.asc

Date: Thu, 9 Apr 1998 16:35:38 -0400
To: John Ross <[email-masked]>, "Bonatti, Chris" <[email-masked]>, Ietf distribution list <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Sender: [email-masked]

John,

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

Notice that these are SHOULDs, not MUSTs.  The local organization still has
the freedom to formulate their own security policy requirements.

I agree that the ESSSecurityLabel security-policy-identifier must be
mandatory.  That was approved at the 30 Mar S/MIME WG meeting.

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

At 07:42 PM 3/27/98 -0800, John Ross wrote:
>What happens if a recipient receives a forwarded message that include a
>security policy in the eSSSecurityLabel  that he/she in does not understand,
>is that still an error?
>
>I think the proposed text will mislead implementations to always discarding
>the message if a security policy is unknown.  I do not think that is right.
>
>All I think needs to be done is to leave such decisions to local policy;
>Thus reword your text as..
>
>"Receiving agents SHOULD have a local policy which specifies
>what action is taken when an eSSSecurityLabel is received which
>includes a security-policy-identifier that the processing software
>does not recognize."
>
>
>If think there is a need to specify default handling, then It should be to
>ignore
>security labels when the policy is not understood.
>
>Also, I still think that the security policy should not be optional.
>
>

Date: Thu, 9 Apr 1998 16:54:29 -0400
To: "Bonatti, Chris" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

Chris,

I still respectfully disagree with your proposal.  I admit that the layering
of the signedData objects does add bytes to the wire, but the price paid is
well worth the benefit of ensuring that there are not inconsistent or
contradictory ESSSecurityLabels applied to the same content.  Mandating that
all ESSSecurityLabels included in a single signedData must be identical
ensures that all ESSSecurityLabels applied to a content are consistent.
This ensures that there is no confusion regarding the sensitivity of the
content and that an access control decision can be made in an unambiguous
manner.

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

At 11:16 PM 3/27/98 -0500, Bonatti, Chris wrote:
>John,
>
>    This is a GROSSLY inefficient means of addressing this requirement.  In
the common case where both labels are applied by the originating user, this
means double signature generation operations, double signature verification
operations, plus a bunch of extra attribute and ASN.1 overhead.  All that is
required to address this is either:

Date: Thu, 9 Apr 1998 17:57:47 -0400
To: William Ottaway <[email-masked]>, [email-masked]
From: [email-masked] (John Pawling)
Subject: RE: 'Signature Purpose' attribute?
Sender: [email-masked]

Bill,

Your requirements can be met be the gateway encapsulating the CMS object in
an outer signedData object in which the gateway can include its
eSSSecuritylabel.  This preserves the originator's signature and
eSSSecurityLabel end-to-end.  This strategy makes it much simpler for the
receiving gateway (that you mention) to strip off the outer signedData
applied by the gateway that previously processed the CMS object.  It also
makes it simpler for the recipient to distinguish between the signedData
constructed by the original signer (inner) and that constructed by the
gateway (outer) (in the event that the GW's outer signedData was not
stripped by the receiving GW).  In summary, I believe that the
ESSSecurityLabel strategy should remain as is.

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

At 09:16 AM 4/9/98 +0100, William Ottaway wrote:
>Russ:
>
>Here is my two penneths worth.
>
>I agree that signatures are end-to-end and therfore the originator
>signature  must not be removed. A gateway may put its own signature on,
>which may contain a label which maps to the originators label.
>
>The signature applied by the gateway could be stripped off by a receiving
>gateway. In the case of no receiving gateway the end recipient then has the
>choice as to which signature to use. This could be none, one or more. In
>which case the recipient would need to be able to identify which signature
>is the originators and which, if any, belongs to a third party. 
>

Date: Thu, 9 Apr 1998 19:03:46 -0400
To: Elliott Ginsburg <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: cert-03 - signature validation failure
Cc: [email-masked]
Sender: [email-masked]

Elliott,

I respectfully disagree with your proposal because I believe that it is too
detailed for inclusion in the S/MIME Cert I-D.  I believe that the local
organizations should decide what specific actions should be taken in the
case of cert path and signature validation errors.  I believe that there is
sufficient information in the X.509 Recommendation and PKIX X.509
Certificate/CRL Profile (PKIX I) from which the local organization can
determine the optimal error-processing strategy for their environment.    

You stated:
>I also proposed a return status mechanism which can be used both for
>configuration and by automated processes. Because it is specified in the
>spec, it is interoperable. 

I especially disagree with the inclusion of the PKIStatusInfo SEQUENCE in
the S/MIME CERT I-D because I don't believe that there is a requirement for
this error info to be communicated between applications, so IMHO there is
not an interoperability requirement.  This error information is only used
locally by the application, so there is no reason to mandate a standard
ASN.1 syntax to hold the info.  It makes sense in the CMP I-D because the
error info will be communicated between platforms on a regular basis, but
this is not needed in the case of an S/MIME agent encountering an error.  

In summary, I believe that the S/MIME CERT I-D should be left as is.  If
anything, we should delete the last three paragraphs of CERT, Section 5
because that text is redundant to X.509 and PKIX I.

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

From: "Blake Ramsdell" <[email-masked]>
To: "'Elliott Ginsburg'" <[email-masked]>, <[email-masked]>
Subject: RE: cert-03 - signature validation failure
Date: Thu, 9 Apr 1998 16:10:03 -0700
Sender: [email-masked]

On Tuesday, April 07, 1998 9:47 AM, Elliott Ginsburg
[SMTP:[email-masked]] wrote:
> 
> I want to propose a change to how signature validation failure is
> handled. In
> the current draft, it essentially says that the user agent must do
> something
> when signature validation fails, but what it does is up to the
> implementation.
> I don't think it is acceptable to leave this decision unspecified;
here
> is
> some
> of my rationale:

This is an interesting point, and I think that the validation failures
can be summarized as follows:

1. Processing the signature requires that the signing certificate be
used to unprotect a protected hash.  If the hash cannot be unprotected
with that certificate, or the unprotected hash does not match the
received message hash, these are unique error conditions.

2. Creating the certificate chain for the purpose of determining the
suitability of a certificate to validate a signature can fail at a
number of points.  These are unique error conditions.

3. If the certificate violates some other rules of the -cert draft,
these are unique error conditions.

However, I don't know how specific we can get as to what these error
conditions are, and whether they will evolve as PKIX evolves.  It seems
that the errors that relate to the certificate chaining would belong in
PKIX.  The remaining errors (regarding failure to unprotect the hash or
failure on hash comparison) should be in -msg.  As you point out, most
of these need to be identified and listed.

I think that the listing of these errors is useful, but I think that the
PKIX ones (dealing with certificate chaining, CRL checking, etc.) should
be in PKIX, and the ones specific to S/MIME should be in S/MIME.  Even
having a list without actions to be taken could be useful.

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: Reducing signature sizes.
Date: Thu, 9 Apr 1998 15:41:04 -0700
Sender: [email-masked]

On Thursday, April 09, 1998 5:42 AM, Dr Stephen Henson
[SMTP:[email-masked]] wrote:
> This can give S/MIME a bad reputation and discourage people from
> signing
> anything. All too frequently a new user's first experience of S/MIME
is
> being flamed for wasting bandwidth by signing everything in a public
> mailing list or newsgroup. By contrast the more compact PGP signatures
> seem to be tolerated more.

I think that this is as a result of the persistence and patience of the
sending PGP user, and the patience of the receiving non-PGP user.  There
is no argument that the actual signature data requires fewer bytes, but
PGP had the same problems in its infancy that S/MIME and HTTP enjoy now.
Based on my limited experience with the Internet, I've been flamed for:

1. Having a .signature with more than one line in 1986
2. Using MIME in 1992
3. Sending TNEF in 1993
4. Using PGP signatures in 1994
5. Using S/MIME signatures in 1996

Now part of that is because I'm a jerk, but part of that is because it's
the reactionary "aaah!  It's new and scary and will make the world a
worse place!"  The TNEF I apologize for, and I have fixed -- the other
ones I had to suffer through until people didn't complain.

I do apply selective judgement as to what messages to sign, however,
since the non-repudiation, integrity and authenticity attributes are not
necessary in most of my communications.  This was something that Paul
pointed out also, I believe.

People have come to accept the

> ---- BEGIN PGP SIGNED MESSAGE ----
> <signed stuff>
> ---- BEGIN PGP SIGNATURE ----
> <signature stuff>
> ---- END PGP SIGNATURE ----
> ---- END PGP SIGNED MESSAGE ----

block in the middle of their text (which may phase out with the use of
PGP/MIME), much as they have come to accept

> --
> Joe Smith
> Any Company
> 123 Main St
> Boston, MA 02134
> 
> "He who makes long signature is doomed to be flamed" -- Unknown

at the bottom of messages.  I don't see any reason why people won't come
to accept S/MIME and PGP/MIME signatures in the same way.

> I would support the specification stating that an S/MIME agent either
> SHOULD (or even MUST) give the user the option to not include
> certificates in signed messages.

I would support MAY or SHOULD give the user the option.

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, 09 Apr 1998 20:38:59 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Re: Reducing signature sizes.
Sender: [email-masked]

Paul Hoffman / IMC wrote:
> 
> >All too frequently a new user's first experience of S/MIME is
> >being flamed for wasting bandwidth by signing everything in a public
> >mailing list or newsgroup.
> 
> Well, people shouldn't sign something unless there is value in being able
> to authenticate the sender. 

Some would argue that authenticating the sender always adds some value:
but not when this has to be weighed against bandwidth considerations.

> 
> S/MIME signatures could be very small, indeed, if the CAs would pare down
> what they toss into the signatures. So far, most of the flames have been
> aimed at people with bloated VeriSign certs. I've seen much smaller certs
> from other CAs.
> 

Yes I would agree that Verisign exacerbates the problem. I'm waiting for
the first CA to offer free certificates paid for by embedded
advertising.

Nevertheless even a compact certificate or chain can at least double the
size of the signature.

> >I would support the specification stating that an S/MIME agent either
> >SHOULD (or even MUST) give the user the option to not include
> >certificates in signed messages.
> 
> We cannot specify how an MUA interacts with a human user; that's out of
> scope for a spec like this. At most, we might put in a sentence saying "A
> sending MUA may want to consider the size of certs being added to a message
> when it decides (or lets the sender decide) whether or not to include a
> cert in the message."
> 

Well as long as it conveys the impression that it is desirable to
support the (automatic or manual) omisssion of (some or all)
certificates the wording isn't too important.

Steve.
-- 
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant.
Email: [email-masked]
PGP key: http://www.drh-consultancy.demon.co.uk/key.asc

Date: Thu, 9 Apr 1998 15:57:57 -0400
To: "Flanigan, Bill" <[email-masked]>, IETF-SMIME WG <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: More on Cert-03.txt and Msg-03.txt
Sender: [email-masked]

Bill,

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

I disagree with your comment because v3 certificate extensions in addition
to those listed in the S/MIME CERT I-D may be included in v3 certs used by
S/MIME apps.

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

I disagree with these comments.  PKIX I answers these questions.  The S/MIME
CERT I-D should not duplicate what is in PKIX I.

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

Date: Thu, 9 Apr 1998 14:10:29 -0400
To: John Ross <[email-masked]>, [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: security label
Sender: [email-masked]

John,

The ESSSecurityLabel Version2SecurityLabel meets your requirement to
communicate the same data as is communicated in the X.411 security label.
The existing access control mechanisms implemented for the X.411 security
label can be used in conjunction with the ESSSecurityLabel
Version2SecurityLabel.  Even though the ESSSecurityLabel
Version2SecurityLabel and X.411 security label syntaxes are slightly
different, they still carry the same data fields which result in the same
decoded data being presented to the access control software.

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

At 06:51 PM 4/9/98 -0700, John Ross wrote:
>John (too many of us with that name)
>
>I am aware that there may be many attributes that are signed over using CMS
>signed data, I am aware that this requires major modification to the non-CMS
>implementation.  However, I respectfully disagree with you that if you use
>CMS as the security protocol that backward compatibility with the X.411
>security label is not an issue.  In particular, environments that may want
>to use a CMS security label are the same environments that may be using the
>X.411 label, and have built and implemented access control based on decoded
>data using the X.411 syntax.
>
>However, seem pointless continuing a debate if you do not accept that
>premise.
>
>As to the issue on origination, I believe can easily be solved the X.411
>label syntax should be used unless the extended character set is required.
>
>Hope you have a good Easter holiday.
>
>Regards
>
>-----Original Message-----
>From: John Pawling <[email-masked]>
>To: John Ross <[email-masked]>; [email-masked]
><[email-masked]>
>Date: Thursday, April 09, 1998 9:39 AM
>Subject: Re: security label
>
>
>>John,
>>
>>I respectfully disagree with your proposal because it adds significant
>>complexity to the ESSSecurityLabel syntax which I believe is not needed.
>>IMHO, S/MIME should only adopt the Version2SecurityLabel.  It provides the
>>equivalent capabilities as the X.411 security label.  That was the goal of
>>ESS.
>>
>>IMHO,there is no requirement for bits-on-the-wire backwards compatibility
>>with the X.411 security label.  There are not any S/MIME v2 agents using
>>X.411 securityLabels so backwards compatibily is not an issue.
>>
>>You stated:
>>>The above should mean that any signature that signs over the x.411 label
>>>will operate end to end even if it has to cross a gateway between  a
>domian
>>>that only suppports the X.411 securty label and a domain that supportes
>both
>>>the X.411 and version2 labels.
>>
>>I respectfully disagree with your conclusion.  Please see my message to the
>>S/MIME mail list dated Fri, 27 Mar 1998 08:34:23 -0500, subject: "Re:
>>Comment on ESS and Privacy Marks" for a detailed explanation of why I
>>believe that your conclusion is impractical.  I am not going to repeat all
>>of that text here, but I want to reiterate the following point.  The
>>ESSSecurityLabel is not separately signed as part of CMS.  It is digested
>>along with the other CMS signedData signerInfo authenticatedAttributes as
>>part of the CMS signature generation process.  Therefore, if the signature
>>over the ESSSecurityLabel was to be preserved, then a non-CMS app would
>need
>>to be able to hash the original signedData signerInfo
>authenticatedAttibutes
>>and the content to verify the original CMS signature.  This will require
>>major modifications to the non-CMS apps.  If people are considering such
>>major modifications, then they should just consider implementing CMS as
>>their standard security heading.
>>
>>In summary, I disagree with your proposal because it adds significant
>>complexity to the ESSSecurityLabel format which I believe is not required
>>because the CMS-to-non-CMS translating software can accommodate any
>>differences between the ESSSecurityLabel and X.411 security label
>>representations.
>>
>>Furthermore, if your proposal is accepted, how would an originator know
>>which ESSSecuirtyLabel choice to use???  She would need to determine which
>>flavor that the recipient prefers.  What if some of the recipients prefer
>>X.411 and some prefer version2???  Would you then send two separate
>>messages???  This adds more and more complexity.
>>
>>================================
>>John Pawling, [email-masked]
>>J.G. Van Dyke & Associates, Inc.
>>www.jgvandyke.com
>>===============================
>>
>>
>>At 10:32 AM 3/29/98 +0100, John Ross wrote:
>>>As per pevious comments on compatiblity between X.411 security label and
>the
>>>eSSScecurityLable, I think the following would offer more compatibility
>and
>>>allow for the extended character set:
>>>
>>>eSSSecurityLable::= Choice{
>>>    x411-security-label  Security label,
>>>    version2-security-label Version2Securitylabel}
>>>
>>>SecurityLabel ::= SET {
>>> security-policy-identifier SecurityPolicyIdentifier OPTIONAL,
>>> security-classification SecurityClassification OPTIONAL,
>>> privacy-mark PrivacyMark OPTIONAL,
>>> security-categories SecurityCategories OPTIONAL }
>>>
>>>Version2SecurityLabel ::= SET {
>>> security-policy-identifier SecurityPolicyIdentifier,
>>> security-classification SecurityClassification OPTIONAL,
>>> privacy-mark  ExtendedPrivacyMark OPTIONAL,
>>> security-categories SecurityCategories OPTIONAL }
>>>
>>>ExtendedPrivacyMark ::= UTC-8 STRING.
>>>
>>>
>>>Then rules can be specified, that mandate the X.411 label is generated
>>>unless the extended character set is required, then version 2 security
>label
>>>shall be generated.
>>>
>>>The above should mean that any signature that signs over the x.411 label
>>>will operate end to end even if it has to cross a gateway between  a
>domian
>>>that only suppports the X.411 securty label and a domain that supportes
>both
>>>the X.411 and version2 labels.
>>>
>>>I also think that maintains structual compatibility between the X.411 and
>>>version2 signatures.
>>>
>>>Any comments?
>>>
>>>John Ross
>>>
>>>
>>>
>>
>
>

From: John Ross <[email-masked]>
To: [email-masked], John Pawling <[email-masked]>
MMDF-Warning:  Parse error in original version of preceding line at post.mail.demon.net
Subject: Re: security label
Date: Thu, 9 Apr 1998 18:51:26 -0700
Sender: [email-masked]

John (too many of us with that name)

I am aware that there may be many attributes that are signed over using CMS
signed data, I am aware that this requires major modification to the non-CMS
implementation.  However, I respectfully disagree with you that if you use
CMS as the security protocol that backward compatibility with the X.411
security label is not an issue.  In particular, environments that may want
to use a CMS security label are the same environments that may be using the
X.411 label, and have built and implemented access control based on decoded
data using the X.411 syntax.

However, seem pointless continuing a debate if you do not accept that
premise.

As to the issue on origination, I believe can easily be solved the X.411
label syntax should be used unless the extended character set is required.

Hope you have a good Easter holiday.

Regards

-----Original Message-----
From: John Pawling <[email-masked]>
To: John Ross <[email-masked]>; [email-masked]
<[email-masked]>
Date: Thursday, April 09, 1998 9:39 AM
Subject: Re: security label

>John,
>
>I respectfully disagree with your proposal because it adds significant
>complexity to the ESSSecurityLabel syntax which I believe is not needed.
>IMHO, S/MIME should only adopt the Version2SecurityLabel.  It provides the
>equivalent capabilities as the X.411 security label.  That was the goal of
>ESS.
>
>IMHO,there is no requirement for bits-on-the-wire backwards compatibility
>with the X.411 security label.  There are not any S/MIME v2 agents using
>X.411 securityLabels so backwards compatibily is not an issue.
>
>You stated:
>>The above should mean that any signature that signs over the x.411 label
>>will operate end to end even if it has to cross a gateway between  a
domian
>>that only suppports the X.411 securty label and a domain that supportes
both
>>the X.411 and version2 labels.
>
>I respectfully disagree with your conclusion.  Please see my message to the
>S/MIME mail list dated Fri, 27 Mar 1998 08:34:23 -0500, subject: "Re:
>Comment on ESS and Privacy Marks" for a detailed explanation of why I
>believe that your conclusion is impractical.  I am not going to repeat all
>of that text here, but I want to reiterate the following point.  The
>ESSSecurityLabel is not separately signed as part of CMS.  It is digested
>along with the other CMS signedData signerInfo authenticatedAttributes as
>part of the CMS signature generation process.  Therefore, if the signature
>over the ESSSecurityLabel was to be preserved, then a non-CMS app would
need
>to be able to hash the original signedData signerInfo
authenticatedAttibutes
>and the content to verify the original CMS signature.  This will require
>major modifications to the non-CMS apps.  If people are considering such
>major modifications, then they should just consider implementing CMS as
>their standard security heading.
>
>In summary, I disagree with your proposal because it adds significant
>complexity to the ESSSecurityLabel format which I believe is not required
>because the CMS-to-non-CMS translating software can accommodate any
>differences between the ESSSecurityLabel and X.411 security label
>representations.
>
>Furthermore, if your proposal is accepted, how would an originator know
>which ESSSecuirtyLabel choice to use???  She would need to determine which
>flavor that the recipient prefers.  What if some of the recipients prefer
>X.411 and some prefer version2???  Would you then send two separate
>messages???  This adds more and more complexity.
>
>================================
>John Pawling, [email-masked]
>J.G. Van Dyke & Associates, Inc.
>www.jgvandyke.com
>===============================
>
>
>At 10:32 AM 3/29/98 +0100, John Ross wrote:
>>As per pevious comments on compatiblity between X.411 security label and
the
>>eSSScecurityLable, I think the following would offer more compatibility
and
>>allow for the extended character set:
>>
>>eSSSecurityLable::= Choice{
>>    x411-security-label  Security label,
>>    version2-security-label Version2Securitylabel}
>>
>>SecurityLabel ::= SET {
>> security-policy-identifier SecurityPolicyIdentifier OPTIONAL,
>> security-classification SecurityClassification OPTIONAL,
>> privacy-mark PrivacyMark OPTIONAL,
>> security-categories SecurityCategories OPTIONAL }
>>
>>Version2SecurityLabel ::= SET {
>> security-policy-identifier SecurityPolicyIdentifier,
>> security-classification SecurityClassification OPTIONAL,
>> privacy-mark  ExtendedPrivacyMark OPTIONAL,
>> security-categories SecurityCategories OPTIONAL }
>>
>>ExtendedPrivacyMark ::= UTC-8 STRING.
>>
>>
>>Then rules can be specified, that mandate the X.411 label is generated
>>unless the extended character set is required, then version 2 security
label
>>shall be generated.
>>
>>The above should mean that any signature that signs over the x.411 label
>>will operate end to end even if it has to cross a gateway between  a
domian
>>that only suppports the X.411 securty label and a domain that supportes
both
>>the X.411 and version2 labels.
>>
>>I also think that maintains structual compatibility between the X.411 and
>>version2 signatures.
>>
>>Any comments?
>>
>>John Ross
>>
>>
>>
>

Date: Thu, 9 Apr 1998 12:39:44 -0400
To: John Ross <[email-masked]>, [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: security label
Sender: [email-masked]

John,

I respectfully disagree with your proposal because it adds significant
complexity to the ESSSecurityLabel syntax which I believe is not needed.
IMHO, S/MIME should only adopt the Version2SecurityLabel.  It provides the
equivalent capabilities as the X.411 security label.  That was the goal of
ESS.  

IMHO,there is no requirement for bits-on-the-wire backwards compatibility
with the X.411 security label.  There are not any S/MIME v2 agents using
X.411 securityLabels so backwards compatibily is not an issue.

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

I respectfully disagree with your conclusion.  Please see my message to the
S/MIME mail list dated Fri, 27 Mar 1998 08:34:23 -0500, subject: "Re:
Comment on ESS and Privacy Marks" for a detailed explanation of why I
believe that your conclusion is impractical.  I am not going to repeat all
of that text here, but I want to reiterate the following point.  The
ESSSecurityLabel is not separately signed as part of CMS.  It is digested
along with the other CMS signedData signerInfo authenticatedAttributes as
part of the CMS signature generation process.  Therefore, if the signature
over the ESSSecurityLabel was to be preserved, then a non-CMS app would need
to be able to hash the original signedData signerInfo authenticatedAttibutes
and the content to verify the original CMS signature.  This will require
major modifications to the non-CMS apps.  If people are considering such
major modifications, then they should just consider implementing CMS as
their standard security heading. 

In summary, I disagree with your proposal because it adds significant
complexity to the ESSSecurityLabel format which I believe is not required
because the CMS-to-non-CMS translating software can accommodate any
differences between the ESSSecurityLabel and X.411 security label
representations.

Furthermore, if your proposal is accepted, how would an originator know
which ESSSecuirtyLabel choice to use???  She would need to determine which
flavor that the recipient prefers.  What if some of the recipients prefer
X.411 and some prefer version2???  Would you then send two separate
messages???  This adds more and more complexity.

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

At 10:32 AM 3/29/98 +0100, John Ross wrote:
>As per pevious comments on compatiblity between X.411 security label and the
>eSSScecurityLable, I think the following would offer more compatibility and
>allow for the extended character set:
>
>eSSSecurityLable::= Choice{
>    x411-security-label  Security label,
>    version2-security-label Version2Securitylabel}
>
>SecurityLabel ::= SET {
> security-policy-identifier SecurityPolicyIdentifier OPTIONAL,
> security-classification SecurityClassification OPTIONAL,
> privacy-mark PrivacyMark OPTIONAL,
> security-categories SecurityCategories OPTIONAL }
>
>Version2SecurityLabel ::= SET {
> security-policy-identifier SecurityPolicyIdentifier,
> security-classification SecurityClassification OPTIONAL,
> privacy-mark  ExtendedPrivacyMark OPTIONAL,
> security-categories SecurityCategories OPTIONAL }
>
>ExtendedPrivacyMark ::= UTC-8 STRING.
>
>
>Then rules can be specified, that mandate the X.411 label is generated
>unless the extended character set is required, then version 2 security label
>shall be generated.
>
>The above should mean that any signature that signs over the x.411 label
>will operate end to end even if it has to cross a gateway between  a domian
>that only suppports the X.411 securty label and a domain that supportes both
>the X.411 and version2 labels.
>
>I also think that maintains structual compatibility between the X.411 and
>version2 signatures.
>
>Any comments?
>
>John Ross
>
>
>

Date: Thu, 09 Apr 1998 09:17:03 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Reducing signature sizes.
Sender: [email-masked]

>All too frequently a new user's first experience of S/MIME is
>being flamed for wasting bandwidth by signing everything in a public
>mailing list or newsgroup.

Well, people shouldn't sign something unless there is value in being able
to authenticate the sender. Nor should the HTML-encode things for which
formatting adds no value.

>By contrast the more compact PGP signatures
>seem to be tolerated more.

The PGP world tolerates more than the non-PGP world.

S/MIME signatures could be very small, indeed, if the CAs would pare down
what they toss into the signatures. So far, most of the flames have been
aimed at people with bloated VeriSign certs. I've seen much smaller certs
from other CAs.

>I would support the specification stating that an S/MIME agent either
>SHOULD (or even MUST) give the user the option to not include
>certificates in signed messages.

We cannot specify how an MUA interacts with a human user; that's out of
scope for a spec like this. At most, we might put in a sentence saying "A
sending MUA may want to consider the size of certs being added to a message
when it decides (or lets the sender decide) whether or not to include a
cert in the message."

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 9 Apr 1998 10:08:52 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Reducing signature sizes.
Sender: [email-masked]

> From: Dr Stephen Henson <[email-masked]>
> 
> Jeff Weinstein wrote:
> > 
> > Also keep in mind that many users will not have access to such a
> > repository, either because they have e-mail only connectivity, or
> > they are running offline when reading their mail.  It seems like
> > a bad idea to build the assumption into S/MIME that everyone is
> > always connected to the global internet.
> 
> This can give S/MIME a bad reputation and discourage people from signing
> anything. All too frequently a new user's first experience of S/MIME is
> being flamed for wasting bandwidth by signing everything in a public
> mailing list or newsgroup. By contrast the more compact PGP signatures
> seem to be tolerated more.

The annoyance factor is crucial - Jeff may not believe it, but some
Luddite users (myself included) object to receiving HTML copies of
mail list / newsgroup traffic that could be conveyed just as clearly
in plain old ASCII.

With regards to connectivity, omitting certificates (optionally, of course)
does not lead to the assumption that everyone is always connected:

1) IMAP software could retreive certificates from a repository at the
  same time messages are retreived from the message store.  Since the
  S/MIME Bag `o Certs isn't signed, clients wouldn't even need to know
  whether the certs in a message were included by the sender or inserted
  by an S/MIME-capable IMAP/POP server.

2) Most mail list, newsgroup, or personal messages are not first-time
  postings.  If you have received a signed message from someone before,
  his/her certificate could already be in your local cache.  In fact,
  it is much more likely that a person's signing certificate
  has already been seen than his encryption certificate and algorithm
  capabilities/preferences.

Security must be as unobtrusive as possible, or it will be
laughed/cursed at, then discarded.

Date: Thu, 09 Apr 1998 13:42:06 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Re: Reducing signature sizes.
Sender: [email-masked]

Jeff Weinstein wrote:
> 
> Also keep in mind that many users will not have access to such a
> repository, either because they have e-mail only connectivity, or
> they are running offline when reading their mail.  It seems like
> a bad idea to build the assumption into S/MIME that everyone is
> always connected to the global internet.
> 

Well I for one use a dial up line so I can sympathise with the many
features that assume that one has a fast cheap permanent internet
connection and provide no offline browsing facilities.

However it should also be borne in mind that offline use also has
restricted bandwidth, not all users have S/MIME and of those that do not
all care if every message they receive is signed. For these a
significant amount of the data they receive (and money they expend on
the internet connection) is wasted. 

This can give S/MIME a bad reputation and discourage people from signing
anything. All too frequently a new user's first experience of S/MIME is
being flamed for wasting bandwidth by signing everything in a public
mailing list or newsgroup. By contrast the more compact PGP signatures
seem to be tolerated more.

My initial proposal was not intended to make omitting certificates
compulsory. However since the v3 and v2 specifications allow them to be
omitted but don't provide an automatic or semi-automatic method to
retrieve them (other than a previous message including the certificate)
such a thing would be useful IMHO.

I would support the specification stating that an S/MIME agent either
SHOULD (or even MUST) give the user the option to not include
certificates in signed messages.

This need not imply that the recipient is online permanently or has
access to a permanent connection. Several options could be provided such
as automated retrieval when a user is online or semi-manual retrieval by
for example clicking on a "retrieve certificate" box. Alternatively
there is the possibility of an automated mailer for this purpose.

An often neglected aspect of S/MIME (and certificate use in general) is
that a signed message is only part of the story. The revocation status
of the signers certificates must also be checked. How many CA's provide
the facility to check revocation status offline? How many even
distribute CRLs and of those that do which include their distribution
point in certificate extensions? Precious few.

However no one (I hope!) is suggesting that every signed mail contain a
huge CRL to cater for this.

Steve.
-- 
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant.
Email: [email-masked]
PGP key: http://www.drh-consultancy.demon.co.uk/key.asc

Date: Thu, 09 Apr 1998 09:16:37 +0100
To: [email-masked]
From: William Ottaway <[email-masked]>
Subject: RE: 'Signature Purpose' attribute?
Sender: [email-masked]

At 22:00 07/04/98 GMT, you wrote:
>
>John:
>
>I am strongly opposed to any label mapping.  Signatures are end-to-end.  If
>a gateway wants to alter the label, then it must remove the originator
>signature and put on a new one.
>
>Russ
>

Russ:

Here is my two penneths worth.

I agree that signatures are end-to-end and therfore the originator
signature  must not be removed. A gateway may put its own signature on,
which may contain a label which maps to the originators label.

The signature applied by the gateway could be stripped off by a receiving
gateway. In the case of no receiving gateway the end recipient then has the
choice as to which signature to use. This could be none, one or more. In
which case the recipient would need to be able to identify which signature
is the originators and which, if any, belongs to a third party. 

Bill.
"The Information contained in this E-Mail and any subsequent
correspondence is private and is intended solely for the intended
recipient(s).  For those other than the intended recipient any
disclosure, copying, distribution, or any action taken or omitted to
be taken in reliance on such information is prohibited and may be
unlawful."
____________________________________________________________
William Ottaway,             Tel: (01684) 894079
DERA Malvern,                Fax: (01684) 896113
St. Andrews Road,            email: [email-masked]
Malvern,
Worcs,

WR14 3PS

All opinions are my own.

Date: Wed, 08 Apr 1998 22:36:48 -0700
From: [email-masked] (Jeff Weinstein)
To: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: Reducing signature sizes.
Sender: [email-masked]

Also keep in mind that many users will not have access to such a
repository, either because they have e-mail only connectivity, or
they are running offline when reading their mail.  It seems like
a bad idea to build the assumption into S/MIME that everyone is
always connected to the global internet.

	--Jeff

David P. Kemp wrote:
> 
> > From: Dr Stephen Henson <[email-masked]>
> >
> > In the minimal case the user's certificate will not be provided. Also
> > since some of the CA's include the large disclaimers in the user
> > certificate this wont always help.
> 
> I agree with Steve.  The issuer name and serial number contained in
> SignerInfo is sufficient to retrieve the user's certificate from
> a repository.  If there were a global repository nothing more would
> be needed.  However, there isn't.
> 
> It would be useful to define an S/MIME "subjectCertRepository"
> attribute: a URI with syntax IA5String (as used in GeneralName).
> This attribute, along with issuer/serial and a suitable amount of
> handwaving would allow the user's cert to be retrieved using
> LDAP, ftp, http, etc.

Date: Wed, 08 Apr 1998 12:17:27 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Reducing signature sizes.
Sender: [email-masked]

I absolutely agree.

I'm working away from the office, and my connectivity is limited or=20
else I would check the CMP and PKIX Part 1-7 draft. =20

Obviously S/MIME has to put the location of the certificate=20
somewhere associated with the digital signature, and I would suggest CMP,
in hopes that other protocols will use the same mechanism.

However, we also need the same mechanism, using precisely
the same attribute syntax and OID, within the certificate itself,
just as CRLDistributionPoint was provided.

Unless this has crept in while I wasn't looking, I'd suggest that you,
David, reprise this discusssion on both the PKIX and Federal PKI
list, and that we try to define and adopt such an attribute as quickly as
possible.

I'm not in as much of a hurry to gt this in S/MIME as I am to include it =
in
PKIX.

What would the syntax of the URI look like for an LDAP query?
The others I know.

Bob

>> From: Dr Stephen Henson <[email-masked]>
>>=20
>> In the minimal case the user's certificate will not be provided. Also
>> since some of the CA's include the large disclaimers in the user
>> certificate this wont always help.
>
>
>I agree with Steve.  The issuer name and serial number contained in
>SignerInfo is sufficient to retrieve the user's certificate from
>a repository.  If there were a global repository nothing more would
>be needed.  However, there isn't.
>
>It would be useful to define an S/MIME "subjectCertRepository"
>attribute: a URI with syntax IA5String (as used in GeneralName).
>This attribute, along with issuer/serial and a suitable amount of
>handwaving would allow the user's cert to be retrieved using
>LDAP, ftp, http, etc.
>

Date: Wed, 8 Apr 1998 12:19:24 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Reducing signature sizes.
Sender: [email-masked]

> From: Dr Stephen Henson <[email-masked]>
> 
> In the minimal case the user's certificate will not be provided. Also
> since some of the CA's include the large disclaimers in the user
> certificate this wont always help.

I agree with Steve.  The issuer name and serial number contained in
SignerInfo is sufficient to retrieve the user's certificate from
a repository.  If there were a global repository nothing more would
be needed.  However, there isn't.

It would be useful to define an S/MIME "subjectCertRepository"
attribute: a URI with syntax IA5String (as used in GeneralName).
This attribute, along with issuer/serial and a suitable amount of
handwaving would allow the user's cert to be retrieved using
LDAP, ftp, http, etc.

Date: Wed, 08 Apr 1998 12:26:11 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Re: Reducing signature sizes.
Sender: [email-masked]

Russ Housley wrote:
> 
> Steve:
> 
> The PKIX Working Group is responsible for the certificate.  They are
> addressing certificate extensions that provide some of the stuff you are
> talking about.  Thus, if the user's certificate is provided, it should be
> enough to get the rest of the certificates needed to get the whole chain.
> 

In the minimal case the user's certificate will not be provided. Also
since some of the CA's include the large disclaimers in the user
certificate this wont always help.

Equally certificate extensions are all very well, but you are then at
the mercy of the individual CA to support them.

The problem occurs quite often. Frequent flames in mailing lists or
newsgroups about wasted bandwidth discourage new users from signing mail
or encourage them to use PGP instead of S/MIME.

Steve.
-- 
Dr Stephen N. Henson.
Freelance Cryptographic Consultant.
Email: [email-masked]
PGP key: http://www.drh-consultancy.demon.co.uk/key.asc

Date: Wed, 8 Apr 98 02:27 CET DST
From: [email-masked] (Bodo Moeller)
To: [email-masked]
Subject: Re: Diffie-Hellman vs. ElGamal
Organization: =?ISO-8859-1?B?SW5zdGl0dXQgPT9JU08tODg1OS0xP1E/Zj1GQ3JfdmVyc2Nodz1GNnJ1bmdzdGhlb3JldGlzY2hlPz0gSW5mb3JtYXRpaw==?=
Sender: [email-masked]

Tim Dierks <[email-masked]>:

[...]
> - The only substantial difference is that in ElGamal, the sender
>   uses a temporary key, while in my description of Diffie-Hellman,
>   that key must be authenticated.

The mechanism which Diffie-Hellman described in their famous published
_paper_ involves a "public directory" which contains everyone's
parameters. All users share the same prime and generator.

The _patent_ (which actually lists Diffie, Hellman and Merkle as
inventors; so a more correct name for the cryptographic operation
appears to be Diffie-Hellman-Merkle) does not mention this variant.
It describes Diffie-Hellman exchange (where each side create a
_fresh_ exponent  x_i  and sends  g^x_i  to the other one) and also
includes the scheme which ElGamal encryption is based on: The
recipient's key  y_R = g ^ x_R  is known and fixed, and only the
sender's exponent  x_S  (and thus also the transmitted value  g ^ x_S)
is ephemeral.  The resulting value  K = y_R ^ x_S = (g ^ x_S) ^ x_R
can then be used as a key for some symmetric encryption algorithm
(which, according to the Diffie-Hellman-Merkle patent's text, results
in "authentication" of the recipient -- today we'd call this whole
process "public key encryption").  Typically, you'd select the
lowest 56, 64, 128 or ... bits (as needed) and use them as symmetric
key or -- better -- use a hash of  K.

ElGamal's idea amounts in doing Vernam encryption with key  K
(one might prefer the name "pseudo-Vernam", because  K  is not really
random when all the transmitted values become known; also, possible
valuse for  K  are usually restricted to a _sub_group of  (Z/pZ)*).
Typically Vernam encryption -- the "one-time pad" -- is associated
with XOR, but any finite group works just as well; in the case of
ElGamal, the group is either (Z/pZ)*  or  (Z/pZ),  the former being
more common.

> Based on this, I believe ElGamal to be a better alternative than
> Diffie-Hellman.

ElGamal encryption is just a certain application of Diffie-Hellman.
The name "Diffie-Hellman" alone does not reveal how key  K  will
be used later in the protocol. 

Date: Tue, 07 Apr 1998 16:46:21 -0400
To: John Ross <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: 'Signature Purpose' attribute?
Cc: [email-masked]
Sender: [email-masked]

John:

I am strongly opposed to any label mapping.  Signatures are end-to-end.  If
a gateway wants to alter the label, then it must remove the originator
signature and put on a new one.

Russ

At 11:13 AM 3/25/98 -0800, John Ross wrote:
>Russ, 
>
>The problem with your proposal of removing the originator signature an
replace it with a new signature, is that many international/boundary
gateways may want to perform label mapping and still require the
originators signatures to go end to end (i.e pass through gateways
unaltered). 
>
>I also I think there is a problem with the outer-signature (double
wrapping) proposal and the current S/MIME access control rules.  Under the
double wrapping  proposals, an international/boundary gateway will need to
generate an outer-signature which would includes the national/domain
specific eSSSecuritylabel, this may be in addition to (and different from)
the eSSSecuritylabel in the originators signature. However, if I understand
the current access control rules of s/mime correctly, it is mandatory that
both the originators eSSSecuritylabel, and the outer wrapped gateway
eSSSecuritylabel shall be processed by the recipient. (i.e. local recipient
access control must be based on all labels).  The problem is that, the
inner eSSSecuritylabel may have no semantics in the recipients environment.
 So the access control decision can only be based on the outer
eSSSecuritylabel which as generated by the gateway. 
>
>Thus I think, the access control rules in s/mime need to be made dependant
on the security policy identifier (which is part of the eSSSecuritylabel).
This would allow the access control decision to be made based on all
eSSSecuritylabel were the policy identifier is understood and supported by
the recipient.  Any eSSSecuritylabel present at any  level (originators,
wrapped or triple wrapped) may be ignore (as to the enforcement of access
control rules) if the policy identifier is not understood or supported 
>
>I think the above rule, must still be subject to the criticality rules.
The implementation implications of both rules would be to enforce correctly
process the policy identifier  and hence determine if the eSSSecuritylabel
was applicable or not for local access control processing.
>
>John Ross
>
>-----Original Message-----
>From:	Russ Housley [SMTP:[email-masked]]
>Sent:	Tuesday, March 24, 1998 11:21 AM
>To:	Tim Dean
>Cc:	[email-masked]
>Subject:	RE: 'Signature Purpose' attribute?
>
>Tim:
>
>If a security authority wants to change the label, then it must remove the
>originator signature an replace it with a new signature.
>
>User agent processing will become overly complex if we allow there to be
>multiple labels on a content.
>
>Russ
>
>
>At 11:48 AM 3/23/98 +0000, Tim Dean wrote:
>>John,
>>
>>>>3) I like the text in ESS as it stands now, but there may be suggestions
>>>to modify the syntax and operation of eSSSecurityLabel to accommodate other
>>>requirements.  If ESS were changed, the example might apply.
>>
>>>[JSP: IMHO, the ESS text must stand.  Your example is a good reason why it
>>>must stand.  If the original signer included an eSSSecurityLabel in the
>>>original signedData object then additional signer's of that original
>>>signedData object MUST not be allowed to include different security labels
>>>in signerInfos within the same signedData object.  If that were to be

>>>allowed, then there would be mass confusion and room for contradiction
when
>>>different labels are processed by the recipient as part of the same
>>>cumulative access control decision applied to the individual signedData
>>>object.  Furthermore, if the original signer did not include an
>>>eSSSecurityLabel in the original signedData object, then the original
signer
>>>made the decision that the content did not need to be labeled and that
>>>access control is not required to access the content.  In all cases, all
>>>intermediate entities MUST respect the original signer's wishes regarding
>>>the eSSSecurityLabel that she included in the signedData that she
created or
>>>else she is not receiving the security services that she requested when she
>>>originally signed the content.]
>>
>>I must respectfully disagree that in all cases, all intermediate entities
>must respect the original signer's
>>wishes regarding the label.  In many environments, such as ours, security
>authorities have the power of
>>veto over any label created by an originator.  In electronic (S/MIME)
>terms, my 'environment' will
>>probably create the label automatically for me.  That 'environment' could
>be the current enclave/domain
>>where I am working, or the machine I am currently logged onto, or even the
>client software on the
>>machine, e.g. on a Compartmented Mode Workstation.  In certain cases the
>labelling authority will be a
>>human-being acting as a 'release authority'.  This signed label will
>probably be checked by the Guard
>>before onward transmission.
>>
>>In short, I want to create and sign messages as an originator; some third
>party will counter-sign and label
>>them for me.  I am very much hoping that ESS and S/MIME in general will
>accommodate this model as
>>well as other security policies.  As a general principle, I believe ESS
>and S/MIME should be security-
>>policy neutral wherever possible.  I am very much hoping that with the
>addition of sig-purpose attribute
>>'content Reviewer', my particular policy could be supported.  For this
>reason, I would very much like all
>>of Dave Kemp's original examples, including security label, to remain.
>>
>>Tim 
>>
>>----------
>>From:  John Pawling [SMTP:[email-masked]]
>>Sent:  Thursday, March 19, 1998 10:34 PM
>>To:  David P. Kemp; [email-masked]
>>Subject:  Re: 'Signature Purpose' attribute?
>>
>>Dave,
>>
>>Please see my responses in-line:
>>
>>
>>At 04:30 PM 3/19/98 -0500, David P. Kemp wrote:
>>>> From: [email-masked] (John Pawling)
>
>>>> 
>>>> The contentReviewer is only allowed to
>>>> include an eSSSecurityLabel authenticated attribute in the signerInfo
that
>>>> she signs if there was already an eSSSecurityLabel attribute present in
>the
>>>> signerInfo(s) already included in the original signedData object.
>>>
>>>
>>>John,
>>>
>>>  It was just an example, but thanks for pointing out the restrictions on
>>>eSSSecurityLabel.  I can think of three rebuttals:
>>>
>>>1) the above quoted sentence isn't necessarily true in all cases, because
>>>a security gateway could take a message (either signed or plain old email)
>>>and wrap it in a new signedData.

>>
>>[JSP: I agree that an intermediate entity can encapsulate the original
>>signedData object within a new outer signedData object.  The intermediate
>>entity can then include the appropriate eSSSecurityLabel attribute, if
>>required, in the signerInfo within the new outer signedData object.  The
>>intermediate entity's eSSSecurityLabel attribute may be different than that
>>included in the inner signedData object.  IMHO, that is acceptable because
>>the recipient MUST make a separate access control decision for each of the
>>signedData layers.  The recipient MUST process the eSSSecurityLabel in each
>>signedData object that it verifies.  Because the recipient will verify both
>>the outer and inner signedData objects, then it MUST process the
>>eSSSecurityLabel attribute in each of the signedData objects.  Therefore,
>>both the original signer's and intermediate entity's eSSSecurityLabels are
>>processed by the recipient.  An important point to note is that the
>>recipient software makes a separate access control decision for each
>>signedData object.  IMHO, that is the primary difference between processing
>>eSSSecurityLabels included in layered signedData objects versus those
>>included in multiple signerInfos included in the same signedData object.  In
>>the latter case, all eSSSecurityLabels included in the various signerInfos
>>(that are verified) are checked as part of the same cumulative access
>>control decision process applied to the individual signedData object.  
>>
>>To get back to your original rebuttal, if the intermediate entity adds the
>>outer signedData, then IMHO it is not a contentReviewer, it is a
>>contentOriginator because it is creating a new signedData object.
>>Therefore, I believe that my comment still stands.]
>>
>>
>>>2) eSSSecurityLabel is defined in the ESS document, whereas
signaturePurpose
>>>has been proposed for inclusion in CMS.  CMS may be used in non-S/MIME
>>>applications which have different compliance requirements than S/MIME and
>>>which do not refer to ESS at all.
>>
>>[JSP: One of the major goals of ESS is to define standard attributes for use
>>with CMS.  The CMS spec MUST NOT make statements (such as your example IMHO)
>>that are contradictory to the principles of ESS (which CMS currently does
>>not).  The best strategy would be for CMS not to mention security labels at
>>all (which it currently does not).  Therefore, I recommend that you should
>>either remove the security label example or move the signaturePurpose
>>attribute to ESS and discuss eSSSecurityLabels.  Furthermore, applications
>
>>that use eSSSecurityLabels attributes MUST set the attributes to be critical
>>so if an application needs to use security labels it would be best if it
>>were to implement eSSSecurityLabels to avoid interoperability problems with
>>those applications that are implementing the standard eSSSecurityLabels.]  
>>
>>
>>>3) I like the text in ESS as it stands now, but there may be suggestions
>>>to modify the syntax and operation of eSSSecurityLabel to accommodate other
>>>requirements.  If ESS were changed, the example might apply.
>>

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

Date: Tue, 07 Apr 1998 15:47:15 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Reducing signature sizes.
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

Steve:

The PKIX Working Group is responsible for the certificate.  They are
addressing certificate extensions that provide some of the stuff you are
talking about.  Thus, if the user's certificate is provided, it should be
enough to get the rest of the certificates needed to get the whole chain.

Russ

At 03:26 AM 4/7/98 +0100, Dr Stephen Henson wrote:
>One of the criticisms frequently applied to S/MIME in mailing lists and
>newsgroups is the size of the signatures. When there are lots of two
>line messages with >4K signatures one can perhaps sympathize.
>
>The vast bulk of the signature is the certificate chain: frequently
>containing large legal statements and discliamers from the issuing CA.
>
>Neither the v2 nor the v3 specs require that the whole chain is included
>with each message: if the recipient already has the senders certificate.
>The resultant "certificate-less" signature is much more compact.
>
>However it is not always realistic in a mailing list or newsgroup to
>assume that each subscriber has the senders certificate stored locally.
>
>A manual solution to this problem would be to include a method in the
>(non digital) signature with details of how to obtain the certificate:
>as is done with PGP.
>
>The process could be automated by including a user settable
>authenticated attribute giving the receiving agent details of how to
>obtain the certificate. Does such an attribute exist? If not what are
>peoples feelings about adding one?
>
>Steve.
>-- 
>************************************************************
>* Dr Stephen N. Henson.                                    *
>* Freelance Cryptographic Consultant.                      *
>* Email: [email-masked]                               *
>* PGP key: http://www.drh-consultancy.demon.co.uk/key.asc  * 
>************************************************************
> 

Date: Tue, 07 Apr 1998 11:12:41 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: cert-03 - signature validation failure
Sender: [email-masked]

>Does anyone feel we can make configurability mandatory?

I certainly don't. We can suggest it, but even making it a SHOULD is too
strong for a protocol such as this.

>* The validation module MUST return the status of the validation and, for any
>failure, the reason for the failure. 

Return to whom? We can't specify an API for the receiving agent. I would be
OK with this as a SHOULD.

>To accomplish this, I propose that we define a status return for the
>validation module...

I disagree. This should be up to the implementation.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 07 Apr 1998 13:40:58 -0400
To: [email-masked] (Bob Relyea)
From: Elliott Ginsburg <[email-masked]>
Subject: Re: cert-03 - signature validation failure
Cc: [email-masked]
Sender: [email-masked]

I stated that I didn't think we should specify a particular security
policy, but that we also shouldn't just leave it unspecified. My proposal
has a SHOULD for configurability (by a system administrator, as you
suggested), but failing that, has as neutral a policy as possible (i.e.,
let the recipient decide). Some environments are large enough that they get
products trailored to their requirements, but most of us just have to
choose from what's available in the marketplace. If we leave it
unspecified, then some implementors may hardcode one or another particular
decision, which is in effect hardcoding a particular security policy. At
least, if the recipient is allowed to decide, then it supports a procedural
security policy.

I also proposed a return status mechanism which can be used both for
configuration and by automated processes. Because it is specified in the
spec, it is interoperable. 

Does anyone feel we can make configurability mandatory?

elliott ginsburg

At 01:21 PM 4/7/98 , Bob Relyea wrote:
>
>
>Elliott Ginsburg wrote:
>
>> I want to propose a change to how signature validation failure is
handled. In
>> the current draft, it essentially says that the user agent must do
something
>> when signature validation fails, but what it does is up to the
implementation.
>> I don't think it is acceptable to leave this decision unspecified; here is
>> some
>> of my rationale:
>
>Your rationale, it seems to me, argues for leaving the action unspecified
in the
>spec. If we pick a particular security policy in the spec, we preclude the
use of
>S/MIME in shops which have different security policy.
>
>Some products targeted for specific environments will implement a policy
>consistant with that environment. Many products will provide flexible
validation
>policies that can be configured by a system administrater. All of these
argue for
>*NOT* specifying these semantics in the spec. Validation belongs to some
other
>working group as it goes well beyond just checking email signatures.
>
>bob
> 

Date: Tue, 07 Apr 1998 10:21:26 -0700
From: [email-masked] (Bob Relyea)
To: Elliott Ginsburg <[email-masked]>
CC: [email-masked]
Subject: Re: cert-03 - signature validation failure
Sender: [email-masked]

Elliott Ginsburg wrote:

> I want to propose a change to how signature validation failure is handled. In
> the current draft, it essentially says that the user agent must do something
> when signature validation fails, but what it does is up to the implementation.
> I don't think it is acceptable to leave this decision unspecified; here is
> some
> of my rationale:

Your rationale, it seems to me, argues for leaving the action unspecified in the
spec. If we pick a particular security policy in the spec, we preclude the use of
S/MIME in shops which have different security policy.

Some products targeted for specific environments will implement a policy
consistant with that environment. Many products will provide flexible validation
policies that can be configured by a system administrater. All of these argue for
*NOT* specifying these semantics in the spec. Validation belongs to some other
working group as it goes well beyond just checking email signatures.

bob

Date: Tue, 07 Apr 1998 12:47:13 -0400
To: [email-masked]
From: Elliott Ginsburg <[email-masked]>
Subject: re: cert-03 - signature validation failure
Sender: [email-masked]

I want to propose a change to how signature validation failure is handled. In
the current draft, it essentially says that the user agent must do something
when signature validation fails, but what it does is up to the implementation.
I don't think it is acceptable to leave this decision unspecified; here is
some
of my rationale:

* A valid signature on a message serves the purpose of creating for the
recipient an enhanced level of trust in the origin and the integrity of the
message.  The actual level of trust which a user assigns depends on many
things, including the trust in the certificate issuer, the algorithms used,
the
availability of current revocation status, etc.; it also depends on the
importance the user places on the message (the user's context).

* Because the user's context cannot be known, it is not possible to create a
fixed set of actions which the validating software must take upon encountering
these failures. For example, for one message a recipient may be willing to
accept that revocation could not be verified, where for a 'more important'
message, the recipient may not accept anything except successful validation.
* As another example, a recipient may receive a message where the signature
does not validate; however, the user may consider the subject important enough
that s/he may want to use out-of-band means to verify the content; to do this,
the user has to be able to receive the message itself.

* In some domains these actions may be dictated by the  security policicy, and
leaving the implementation up to chance will create the situation where no
available products are usable.

I also realize that there is a major problem that must be overcome:

* There are three general classes of recipients that must be accommodated:
human users, security gateways, and automatic message processors.

I propose that we specify the following behavior for a user agent performing
signature validation:

* The validation module MUST return the status of the validation and, for any
failure, the reason for the failure. 

* The user agent SHOULD make it possible to configure the actions it takes
upon
signature validation failure; this SHOULD be settable depending on the reason
for the failure. In the absence of this configurability, the default is that
the user agent MUST make this status available to the recipient and MUST make
it possible to receive the message with the invalid signature.

To accomplish this, I propose that we define a status return for the
validation
module, consisting of an integer status code, a textual string, and supporting
information. It could be similar to the one in the CMP document:

PKIStatusInfo ::= SEQUENCE{
 status Integer,
 statusString string OPTIONAL,
 statusInfo StatusInfo OPTIONAL }

To do this, we would need to agree on what the possible returns are; for
example, 

 * success
 * no Internet mail addresses in a certificate match the sender of a message
 * no certificate chain leads to a trusted CA
 * no ability to check the CRL for a certificate
 * an invalid CRL was received
 * the CRL being checked is expired
 * the certificate is expired
 * the certificate has been revoked

UAs for human users could either display the textual status or map the integer
to a response. Security gateways and automatic message processors could use
the
integer code to determine their action. If configuration is available, it
could
be specified according to the return status.

If we can agree on something like this, I will propose the precise wording
changes to the CERT document.

elliott ginsburg

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cms-04.txt
Date: Tue, 07 Apr 1998 10:05:14 -0400
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-04.txt
	Pages		: 36
	Date		: 06-Apr-98
	
   This document describes the Cryptographic Message Syntax.  This
   syntax is used to digitally sign, digest, authenticate, or encrypt
   arbitrary messages.
 
   The Cryptographic Message Syntax is derived from PKCS #7 version 1.5.
   Wherever possible, backward compatibility is preserved; however,
   changes were necessary to accommodate attribute certificate transfer
   and key agreement techniques for key management.
 
   This draft is being discussed on the ''ietf-smime'' mailing list.  To
   join the list, send a message to <[email-masked]> with
   the single word ''subscribe'' in the body of the message.  Also, there
   is a Web site for the mailing list at <http://www.imc.org/ietf-
   smime/>.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-cms-04.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-cms-04.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	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-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cms-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-cms-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Date: Tue, 07 Apr 1998 03:26:18 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Reducing signature sizes.
Sender: [email-masked]

One of the criticisms frequently applied to S/MIME in mailing lists and
newsgroups is the size of the signatures. When there are lots of two
line messages with >4K signatures one can perhaps sympathize.

The vast bulk of the signature is the certificate chain: frequently
containing large legal statements and discliamers from the issuing CA.

Neither the v2 nor the v3 specs require that the whole chain is included
with each message: if the recipient already has the senders certificate.
The resultant "certificate-less" signature is much more compact.

However it is not always realistic in a mailing list or newsgroup to
assume that each subscriber has the senders certificate stored locally.

A manual solution to this problem would be to include a method in the
(non digital) signature with details of how to obtain the certificate:
as is done with PGP.

The process could be automated by including a user settable
authenticated attribute giving the receiving agent details of how to
obtain the certificate. Does such an attribute exist? If not what are
peoples feelings about adding one?

Steve.
-- 
************************************************************
* Dr Stephen N. Henson.                                    *
* Freelance Cryptographic Consultant.                      *
* Email: [email-masked]                               *
* PGP key: http://www.drh-consultancy.demon.co.uk/key.asc  * 
************************************************************

Date: Tue, 07 Apr 1998 03:04:06 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Re: Diffie-Hellman vs. ElGamal
Sender: [email-masked]

Tim Dierks wrote:
> 
> 
> What are the differences?
> 
>         - The only substantial difference is that in ElGamal, the sender uses a
>                 temporary key, while in my description of Diffie-Hellman, that key
>                 must be authenticated.
>         - In Diffie-Hellman, the sender and all recipients must have keys in the
>                 same group in order to communicate. In ElGamal, the keys can be in
>                 any group and the sender need not have a certificate.
>         - In Diffie-Hellman, the identity of the sender must be known and correct
>                 in order to correctly unwrap the key K. Let us assume that K can be
>                 validated as correct. However, this does not mean that the message,
>                 encrypted with K, is intact; it could be modified in any number of
>                 ways. Thus, this cannot serve in place of a signature.
>           Because the sending key is temporary in ElGamal, it neither gives this
>                 benefit nor suffers from this restriction.
> 

I queried the DH mechanism before. The two keys need not belong to the
same group if a temporary DH key is generated in each recipients group
and the public key stored somewhere (in RecipientInfo presumably). The
recipients DH key would be authenticated (e.g. part of a certificate).

If the sending agent wanted to read the encrypted message the it would
also generate a temporary DH key in its own group and put the info into
another RecipientInfo structure.

I'm not sure if it has been decided to do this but IMHO the alternative
of forcing all parties to use static keys in the same group with static
wrapping keys and implied signatures is too restrictive. As you pointed
out.

Steve.
-- 
************************************************************
* Dr Stephen N. Henson.                                    *
* Freelance Cryptographic Consultant.                      *
* Email: [email-masked]                               *
* PGP key: http://www.drh-consultancy.demon.co.uk/key.asc  * 
************************************************************

Date: Mon, 6 Apr 1998 15:56:36 -0800
To: Russ Housley <[email-masked]>
From: Tim Dierks <[email-masked]>
Subject: Diffie-Hellman vs. ElGamal
Cc: [email-masked]
Sender: [email-masked]

At 7:00 PM -0400 4/3/98, Russ Housley wrote:
>Tim:
>
>>1) I know this is a stupid question because this has been accepted as a
>>given by the WG for quite a bit of time, but why is S/MIME using the
>>Diffie-Hellman algorithm, which requires a bit of wedging to work as a
>>store-and-forward key transport algorithm, rather than ElGamal? Note that
>>this proposal is basically identical to ElGamal, only it uses 3DES and a
>>checksum instead of modular multiplication and PKCS#1-style padding.
>
>With ElGamal, I do not think that the originator has a static public value
>that can be placed in a certificate.  With the proposed variant of
>Diffie-Hellman, the originator uses a static component that is included in
>a certificate, and therefore, the recipient knows who the other party is
>that holds the pariwise key.

Knowing who the other party is does not ensure the entegrity of the
message. If the pairwise key can be validated as correct, all it means is
that the sender sent the recipient a message at some point.

Here's my understanding of the current Diffie-Hellman proposal. Note that
this is all a giant guess based on comments, because I can't find any
description of this in the current CMS draft or the message specification.
Maybe I am actually the first to write this all down in detail.

	Originator (Alice) has a certified Diffie-Hellman public key:
		(p, g, g^x) [the private key is x]

	Recipient 1 (Bob) has a certified Diffie-Hellman key in the same group:
		(p, g, g^y1) [the private key is y1]
	Recipient 2 (Chuck) has a certified Diffie-Hellman key in the same group:
		(p, g, g^y2) [the private key is y2]

	Alice generates a random symmetric key K and uses it to encrypt the body
	of the message, m, with a symmetric key, yielding M, the encrypted message.
		M = E(m, K)

	Alice generates the following Diffie-Hellman results:
		r1 = (g^y1)^x
		r2 = (g^y2)^x

	Alice uses r1 and r2 to wrap K for the individual recipients using some
	wrapping algorithm W() (Russ's proposal for W involves 3DES):
		w1 = W(K, r1)
		w2 = W(K, r2)

	The message is composed of:
		M, w1, w2
	and appropriate headers and other information for decoding purposes.

	Bob can receive the message by calculating:
		r1 = (g^x)^y1
	(Bob will need Alice's certificate; it can either be sent with the message
	or acquired elsewhere).
	and unwrapping K from w1 using this result:
		K = UW(w1, r1)
	K can then be used to decrypt M.

	Chuck can receive the message in the same fashion.

Here's classic ElGamal:

	Instead of needing a certified public key in the same group as Bob
	and Chuck, Alice generates a temporary public key in the same group
	as the recipient's certified keys:
		(p, g, g^t) [the private key is t]

	Alice then generates K and uses it to encrypt the message as above,
	then generates the r1 and r2 values, only using t instead of x as her
	private key. She then wraps r1 and r2 as above, only modular multiplication
	is used as a wrapping mechanism rather than 3DES.

	The message is composed of:
		M, g^t, w1, w2

	Bob and Chuck can unwrap K and decrypt the message in the same fashion as
	above. Instead of using Alice's certified public key, they use the
	temporary public value sent with the message.

	If Bob and Chuck have certified keys in different groups, Alice need only
	generate a temporary key pair for each recipient group; the rest of the
	algorithm is the same. (They can share the same value of K and thus
	receive the same message, even if they are in different groups).

What are the differences?

	- The only substantial difference is that in ElGamal, the sender uses a
		temporary key, while in my description of Diffie-Hellman, that key
		must be authenticated.
	- In Diffie-Hellman, the sender and all recipients must have keys in the
		same group in order to communicate. In ElGamal, the keys can be in
		any group and the sender need not have a certificate.
	- In Diffie-Hellman, the identity of the sender must be known and correct
		in order to correctly unwrap the key K. Let us assume that K can be
		validated as correct. However, this does not mean that the message,
		encrypted with K, is intact; it could be modified in any number of
		ways. Thus, this cannot serve in place of a signature.
	  Because the sending key is temporary in ElGamal, it neither gives this
		benefit nor suffers from this restriction.

Based on this, I believe ElGamal to be a better alternative than
Diffie-Hellman.

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

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, Tim Dierks <[email-masked]>
Cc: [email-masked]
Subject: RE: Triple-DES Key Wrapping
Date: Sun, 5 Apr 1998 16:57:32 -0700 
Sender: [email-masked]

Russ,

The below item just triggered off a possible interop problem in my mind.  Am
I going to have a problem exporting this product if I am wrapping the key
with 3DES?  Would I need to have a smaller (i.e. RC2/40) algorithm for doing
this wraping for export purposes?

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Friday, April 03, 1998 3:01 PM
To: Tim Dierks
Cc: [email-masked]
Subject: Re: Triple-DES Key Wrapping

I am not necessarily opposed to such a structure, but there are other
policy concerns too.  For example, can a strong key be encrypted with a
weaker one (e.g., 3DES wrapped by DES)?  Should such policy be addressed?

Defining a 3DES specific key wrap allows a more efficient (fewer bits)
solution does not not delay the S/MIME 3 while policy issues are discussed.

Russ

Date: Fri, 03 Apr 1998 19:50:57 -0400
To: Scott Hollenbeck <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: ESS-04 ESSSecurityLabel Tags
Cc: "'IETF S/MIME'" <[email-masked]>
Sender: [email-masked]

Scott:

Good catch.  I think that we should make the label a SEQUENCE to fix this
problem.  Also, if we want to tag one of the INTEGERs, I would prefer to
tag version.

Russ

At 10:27 AM 3/30/98 -0800, Scott Hollenbeck wrote:
>The ESSSecurityLabel structure includes two INTEGER types:
>
>  version Version DEFAULT v1
>
>and
>  security-classification SecurityClassification OPTIONAL
>
>when an optional security classification is present, don't we have
>a tagging problem within the ESSSecurityLabel SET?  Shouldn't one of
>these INTEGER types include a context specific tag, such as
>
>  security-classification [0] SecurityClassification OPTIONAL
>
>I believe we do have an ambiguous tag situation, and would propose
>that the security-classification definition be changed to include
>a context specific tag as defined above.
>
>----->
>Scott Hollenbeck (mailto:[email-masked])
>Xerox Special Information Systems
>Arlington, Virginia, USA
> 

Date: Fri, 03 Apr 1998 19:00:42 -0400
To: Tim Dierks <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Triple-DES Key Wrapping
Cc: [email-masked]
Sender: [email-masked]

Tim:

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

With ElGamal, I do not think that the originator has a static public value
that can be placed in a certificate.  With the proposed variant of
Diffie-Hellman, the originator uses a static component that is included in
a certificate, and therefore, the recipient knows who the other party is
that holds the pariwise key.

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

Others have recommended a generic key wrap mechanism too.  And, over the
last week I have given this a fair amount of thought.  While I am not
opposed to such a scheme, it is quire a few more larger than necessary.  In
fact it would probably have to have a structure similar to:

	EncryptAlgId, IV, ENCRYPT ( Salt, KeyAlgId, Key, IntegrityAlgId,
IntegrityValue, Pad )

Steve Farrell suggested the addition of a salt to the scheme I described,
and it certainly cannot hurt.

I am not necessarily opposed to such a structure, but there are other
policy concerns too.  For example, can a strong key be encrypted with a
weaker one (e.g., 3DES wrapped by DES)?  Should such policy be addressed?

Defining a 3DES specific key wrap allows a more efficient (fewer bits)
solution does not not delay the S/MIME 3 while policy issues are discussed.

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

This is one of the areas where I was looking for review.  On the FORTEZZA
card, when an 80 bit SKIPJACK key is wrapped, the result is 96 bits long.
So, if 16 bits is sufficient for an 80 bit key, I figured it was in the
right ballpark. especially with the parity bits associated with each octet.

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

An example in the final document should resolve this concern, since it is
well known which bit int the DES key octets are used for parity.

Russ

Date: Fri, 03 Apr 1998 18:05:51 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: DH mechanism?
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

Steve:

Yes, I understood.  If the originator uses a static component that is
included in a certificate, then the recipient knows who the other party is
that holds the pariwise key.

Russ

At 12:18 PM 4/2/98 +0000, Dr Stephen Henson wrote:
>Russ Housley wrote:
>> 
>> Yes, but then you do not get any authentication.  Using a static key in a
>> certificate provides authentication.
>> 
>
>What I meant was that the sender uses the recipients static key and a
>random key. Since the sender may also want to read the data later it
>will also include its own static key and a random key.
>
>This has the addional requirement that the public key of the random key
>must be included in the RecipientInfo structure.
>
>This method has several advantages.
>
>1. Both sides do not have to share the same DH parameters in their
>static keys.
>2. The "key agreement key" is different each time (otherwise it would be
>the same with the same pair of users).
>3. The message generation does not require any private key material.
>
>I consider (3) important because otherwise any DH encrypted data has an
>"implied signature". This is not always desirable: you should be able to
>send encrypted data without signing it (implied or otherwise) as you can
>in the case with RSA key exchange.
>
>Steve.
>-- 
>************************************************
>* Dr Stephen N. Henson.                        *
>* Freelance Cryptographic Consultant.          *
>* Email: [email-masked]                   * 
>************************************************
> 

From: "Darren Harter" <[email-masked]>
To: "John Ross" <[email-masked]>, <[email-masked]>
Subject: Re: security label
Date: Sat, 4 Apr 1998 12:39:32 -0000
Sender: [email-masked]

John,

I agree.

Darren

From: David Hemsath <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: CMS API standard
Date: Thu, 2 Apr 1998 13:14:16 -0500
Sender: [email-masked]

By way of introduction, I've been working with Greg Clark of DASCOM, Inc., who
spoke with the CAT-WG last Monday on the use of CMS (Cryptographic Message
Syntax) with Kerberos PK-INIT.

I couldn't help but notice, when looking at the upcoming S/MIME Freeware
Library, that its CMS APIs bear a striking resemblence to IDUP-GSS-API.  Is
there any joint work planned between the CAT and S/MIME WGs to make
IDUP-GSS-API the standard APIs for generating and consuming CMS messages?

David K. Hemsath, IBM Security Architecture

Date: Thu, 02 Apr 1998 08:19:08 -0700
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: Critical flag processing (was: Re: RE: Signed Label )
Sender: [email-masked]

Russ,

I just recently joined this list, and I am not at all up to speed with the =
context, but=20
I believe that throwing out all Critical attributes, either in certificates=
 or=20
elsewhere, would be like throwing the baby out with the bath water.

My view of the Critical flag is that it important to protect the interests =
of the CA=20
or the signer of a message, or both, against unwarranted assumptions of=20
validity made on the basis of software which does not implement some
particular attribute. (Since NONE of the ietf standards in this area have =
done=20
a very good job of defining minimally, average, and fully compliant suites =
of=20
functions, implementors who cannot swallow everything whole all at once=20
are forced to pick and choose features without much guidance. And=20
unfortunately, the one or two ubiquitous browsers end up setting de =
facto=20
standards.  Hopefully now that Netscape has released their source code=20
into the public domain, some of these incompatibility issues can be=20
resolved more quickly.)

In particular, the various constraints, together with the CPS and user =
notice fields,
serve a very important purpose -- they are the equivalent of a legal =
notice or=20
caveat -- sort of a Miranda warning to the relying party.

In addition to the 'standard' attributes (which are confusing and =
sometimes=20
fluid enough), there is also the issue of propritetary attributes which =
may be=20
defined by some organization, and may or may not ever be well accepted=20
by the general vendor population. Without the Critical flag, a user who=20
believes that some attribute was particuarly important has no legal =
defense=20
against a relying party whose software ignores that attribute.

Take a Reliance Limit, of example.  I don't intend to get into a debate as =
to
whether that is a good concept or not, but its use in enshrined in =
several=20
state's statutes, and in the forthcoming release of Novell's PKIS (Public =
Key=20
Infrastructure Services) product we intend to define and support such an =
attribute
under our own OID, unless or until such time as the ietf cares to =
standardize such
a use.

The subscriber can either include the attributre or not, and if included, =
mark it
Critical or not, recognizing the potential interoperability problems that =
may cause.

But if the Reliance Limit is deemed to be quite important for that user's =
piece of
mind, interoperability problems IS PRECISELY WHAT IS DESIRED.

If someone's browser doesn't recognize the extension, it should reject =
the=20
certificate. The relying party can then decide whether to proceed with =
the=20
transaction, but the burden of proof and the burden of liability presumably=
=20
will have shifted to the relying party in that case, even if the orignator =
had been
unforgivably careless with his keys, for example.

It seems to me that the same would apply to a security label or other =
construct
in S/MIME. The originator is essentially telling the recipient, and =
perhaps=20
more importantly the user's agent, "If you can't understand and agree to =
my terms,
don't read, or at least don't believe my message."

I don't see how you can reasonably do without such a construct.

A random poll of ietf attendees is not sufficient justification for =
removing a critical=20
(no pun intended) feature. It IS sufficient justification to demand that =
we fix=20
the sloppy syntax and semantics that has been created between the X.509 =
v3,=20
PKIX, and S/MIME doucments.

Please pardon my cross-posting to both lists, but I think the issue is =
important=20
to both groups, and I don't know how many people are members of both.

Bob

>
>>>> Russ Housley <[email-masked]> 04/01 7:03 PM >>>
>Tim:
>
>Your note has a huge impact.  You point out that the message originator
>cannot ensure that the recipient will honor any attributbes in SignerInfo,=

>even if they are marked critical.  For example, the recipient can ignore
>the critical attribute containing the security label.
>
>Here at the IETF meeting, I have asked several people about the usefulness=

>of critical attributes.  Of the people that I polled, no one supports =
them.
> At this point, I am planning to remove critical attributes from the next
>draft of the CMS document.
>
>Russ
>
>At 10:28 AM 3/31/98 +0100, Tim Dean wrote:
>>Russ,
>>>>What happens if a recipient receives a forwarded message that include =
a
>>>>security policy in the eSSSecurityLabel  that he/she in does not
>understand,
>>>>is that still an error?
>>
>>>Absolutely.  The security label must be marked critical, so the =
inability
>>>to process the critical attribute must cause an error to be reported to =
the
>>>user.
>>
>>>>I think the proposed text will mislead implementations to always =
discarding
>>>>the message if a security policy is unknown.  I do not think that is =
right.
>>
>>>We disagree.  Rule-based access control cannot be enforced if the =
recipient
>>>is allowed to ignore the security label.
>>
>>Two thoughts:
>>
>>1.  Insisting that the UA software parse and understand the label before
>showing the message to the user=20
>>raises serious denial-of-service issues.  There are many circumstances
>when operational necessity=20
>>demands label-based access control is over-ridden - certainly on =
reception
>in a distributed system. =20
>>There are likely to be many, many label formats floating around out =
there,
>and systems should not stop=20
>>working just because they don't recognise all of them.=20
>>
>>2. I am somewhat doubtful that access control in the recipient's user
>agent is going to add a jot of Real=20
>>Security in practice.  It would surely be extremely unwise to place any
>kind of reliance on it.  Any=20
>>Computer Scientist worth his salt is quickly going to figure how to
>by-pass this check and read=20
>>everything which arrives in his computer.  (And he is probably the kind =
of
>person you didn't want to=20
>>unintentionally send a message to anyway!)
>>
>>Therefore I think I must agree with John R's suggestion on this: or at
>least make the it a configurable=20
>>option dependent on security policy.  Also, ESS should probably contain =
a
>health warning about relying=20
>>on recipient side access control processing.  By all means check message
>labels on transmission and at=20
>>points along the path: for example just before the message is about to
>exit your organisation.  Hopefully=20
>>the label semantics are understood at least that far.  After that I
>suspect it may be too late.
>>
>>Tim
>>
>>-----------------------------------------------
>>Tim Dean
>>Defence Evaluation & Research Agency
>>Malvern
>>United Kingdom
>>telephone:      +44-1684-894239
>>facsimile:      +44-1684-896113
>>e-mail:         [email-masked]=20
>>----------------------------------------------------
>>
>>
>>
>>
>>John Ross wrote:
>>>What happens if a recipient receives a forwarded message that include a
>>>security policy in the eSSSecurityLabel  that he/she in does not =
understand,
>>>is that still an error?
>>
>>Absolutely.  The security label must be marked critical, so the =
inability
>>to process the critical attribute must cause an error to be reported to =
the
>>user.
>>
>>>I think the proposed text will mislead implementations to always =
discarding
>>>the message if a security policy is unknown.  I do not think that is =
right.
>>
>>We disagree.  Rule-based access control cannot be enforced if the =
recipient
>>is allowed to ignore the security label.
>>
>
>>>All I think needs to be done is to leave such decisions to local =
policy;
>>>Thus reword your text as..
>>>
>>>"Receiving agents SHOULD have a local policy which specifies
>>>what action is taken when an eSSSecurityLabel is received which
>>>includes a security-policy-identifier that the processing software
>>>does not recognize."
>>>
>>>
>>>If think there is a need to specify default handling, then It should be =
to
>>>ignore security labels when the policy is not understood.
>>
>>Completely disagree!
>>
>>>Also, I still think that the security policy should not be optional.
>>
>>Wow.  We agree on this one.  The syntax that we are using comes from =
X.411.
>> In X.411, this field is optional, and we are trying to maintain
>>compatibility.  I suggest that we use english text to state that the
>>security policy must be present.
>>
>>-- Russ
>>=20

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree,=20
although a step in the right direction, will not prove=20
to be very helpful."

"The most dangerous strategy is to cross a chasm in two jumps."

Date: Thu, 02 Apr 1998 12:18:26 +0000
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: Russ Housley <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: DH mechanism?
Sender: [email-masked]

Russ Housley wrote:
> 
> Yes, but then you do not get any authentication.  Using a static key in a
> certificate provides authentication.
> 

What I meant was that the sender uses the recipients static key and a
random key. Since the sender may also want to read the data later it
will also include its own static key and a random key.

This has the addional requirement that the public key of the random key
must be included in the RecipientInfo structure.

This method has several advantages.

1. Both sides do not have to share the same DH parameters in their
static keys.
2. The "key agreement key" is different each time (otherwise it would be
the same with the same pair of users).
3. The message generation does not require any private key material.

I consider (3) important because otherwise any DH encrypted data has an
"implied signature". This is not always desirable: you should be able to
send encrypted data without signing it (implied or otherwise) as you can
in the case with RSA key exchange.

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

Date: Thu, 02 Apr 1998 01:58:15 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: DH mechanism?
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

Yes, but then you do not get any authentication.  Using a static key in a
certificate provides authentication.  

Russ

At 01:13 PM 4/1/98 +0000, Dr Stephen Henson wrote:
>Russ Housley wrote:
>> 
>> This part of the specification is still being written.
>> 
>> Russ
>> 
>
>OK. There are some advantages in using a one time session key over both
>sides using their permanent keypairs. For example they don't have to
>share the same parameters and there is no "implied signature".
>
>Steve.
>-- 
>************************************************
>* Dr Stephen N. Henson.                        *
>* Freelance Cryptographic Consultant.          *
>* Email: [email-masked]                   * 
>************************************************
> 

Date: Wed, 01 Apr 1998 21:03:40 -0500
To: Tim Dean <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Signed Label (was RE: 'Signature Purpose' attribute?)
Cc: [email-masked]
Sender: [email-masked]

Tim:

Your note has a huge impact.  You point out that the message originator
cannot ensure that the recipient will honor any attributbes in SignerInfo,
even if they are marked critical.  For example, the recipient can ignore
the critical attribute containing the security label.

Here at the IETF meeting, I have asked several people about the usefulness
of critical attributes.  Of the people that I polled, no one supports them.
 At this point, I am planning to remove critical attributes from the next
draft of the CMS document.

Russ

At 10:28 AM 3/31/98 +0100, Tim Dean wrote:
>Russ,
>>>What happens if a recipient receives a forwarded message that include a
>>>security policy in the eSSSecurityLabel  that he/she in does not
understand,
>>>is that still an error?
>
>>Absolutely.  The security label must be marked critical, so the inability
>>to process the critical attribute must cause an error to be reported to the
>>user.
>
>>>I think the proposed text will mislead implementations to always discarding
>>>the message if a security policy is unknown.  I do not think that is right.
>
>>We disagree.  Rule-based access control cannot be enforced if the recipient
>>is allowed to ignore the security label.
>
>Two thoughts:
>
>1.  Insisting that the UA software parse and understand the label before
showing the message to the user 
>raises serious denial-of-service issues.  There are many circumstances
when operational necessity 
>demands label-based access control is over-ridden - certainly on reception
in a distributed system.  
>There are likely to be many, many label formats floating around out there,
and systems should not stop 
>working just because they don't recognise all of them. 
>
>2. I am somewhat doubtful that access control in the recipient's user
agent is going to add a jot of Real 
>Security in practice.  It would surely be extremely unwise to place any
kind of reliance on it.  Any 
>Computer Scientist worth his salt is quickly going to figure how to
by-pass this check and read 
>everything which arrives in his computer.  (And he is probably the kind of
person you didn't want to 
>unintentionally send a message to anyway!)
>
>Therefore I think I must agree with John R's suggestion on this: or at
least make the it a configurable 
>option dependent on security policy.  Also, ESS should probably contain a
health warning about relying 
>on recipient side access control processing.  By all means check message
labels on transmission and at 
>points along the path: for example just before the message is about to
exit your organisation.  Hopefully 
>the label semantics are understood at least that far.  After that I
suspect it may be too late.
>
>Tim
>
>-----------------------------------------------
>Tim Dean
>Defence Evaluation & Research Agency
>Malvern
>United Kingdom
>telephone:      +44-1684-894239
>facsimile:      +44-1684-896113
>e-mail:         [email-masked]
>----------------------------------------------------
>
>
>
>
>John Ross wrote:
>>What happens if a recipient receives a forwarded message that include a
>>security policy in the eSSSecurityLabel  that he/she in does not understand,
>>is that still an error?
>
>Absolutely.  The security label must be marked critical, so the inability
>to process the critical attribute must cause an error to be reported to the
>user.
>
>>I think the proposed text will mislead implementations to always discarding
>>the message if a security policy is unknown.  I do not think that is right.
>
>We disagree.  Rule-based access control cannot be enforced if the recipient
>is allowed to ignore the security label.
>

>>All I think needs to be done is to leave such decisions to local policy;
>>Thus reword your text as..
>>
>>"Receiving agents SHOULD have a local policy which specifies
>>what action is taken when an eSSSecurityLabel is received which
>>includes a security-policy-identifier that the processing software
>>does not recognize."
>>
>>
>>If think there is a need to specify default handling, then It should be to
>>ignore security labels when the policy is not understood.
>
>Completely disagree!
>
>>Also, I still think that the security policy should not be optional.
>
>Wow.  We agree on this one.  The syntax that we are using comes from X.411.
> In X.411, this field is optional, and we are trying to maintain
>compatibility.  I suggest that we use english text to state that the
>security policy must be present.
>
>-- Russ
> 

Date: Wed, 01 Apr 1998 13:13:57 +0000
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: Russ Housley <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: DH mechanism?
Sender: [email-masked]

Russ Housley wrote:
> 
> This part of the specification is still being written.
> 
> Russ
> 

OK. There are some advantages in using a one time session key over both
sides using their permanent keypairs. For example they don't have to
share the same parameters and there is no "implied signature".

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