Russ Housley | 3 Aug 16:53 1998

Re: Question on adding an eSSSecurity Label

Yes, I think this shoud be true.

Russ

At 02:11 PM 7/29/98 +0100, William Ottaway wrote:
>Hi,
>
>In section 3.1.1 of ESS-06 it states :-
>
>"If any of the SignerInfos included in a SignedData object include an
>eSSSecurityLabel attribute, then all of the SignerInfos in that SignedData
>object MUST include an eSSSecurityLabel attribute and the value of each
>MUST be identical."
>
>Is this true even if a signerInfo does not have any signed attributes?
>
>For example, if the first SignerInfo does not have any signedAttrs and a
>second SignerInfo is added which contains an eSSSecurityLabel, the first
>SignerInfo must have an eSSSecurityLabel added, and therefore a contentType
>and messageDigest atrribute, and the signature recalculated.
>
>Bill
>
>
>_____________________________________________________________________
>William Ottaway,             Tel: +44 (0)1684 894079
>DERA Malvern,                Fax: +44 (0)1684 896113
>St. Andrews Road,            email: w.ottaway <at> eris.dera.gov.uk
>Malvern,
>Worcs, WR14 3PS
(Continue reading)

Blake Ramsdell | 4 Aug 03:30 1998

Summary of final changes to CERT draft

These are the changes that I am going to make to the -CERT draft for
this last cut.

1. References to X.509 changed to PKIX (Denis Pinkas and Russ Housley)

There was a little discussion about name chaining and constraints, but I
believe that the current language reflects the consensus of the WG.
Also, there was some mumbling about attribute certificates, but I
believe that the current language is sufficient to use them if the need
ever arises.

Flames welcome.  New draft submitted Wednesday AM if no complaints.

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

Blake Ramsdell | 4 Aug 03:44 1998

Summary of final changes to MSG draft

These are the changes that I am going to make to the -MSG draft for this
last cut.

1. SMIMECapabilities MUST be an authenticated attribute and MUST NOT be
unauthenticated, and there must only be one instance (John Pawling)
2. Ditto for SMIMEEncryptionKeyPreference (John Pawling)
3. RSA keylength minimums / maximums need to move to CMS (John Pawling)
4. SMIMECapabilities acceptance criteria cleanup (Stephen Henson)
5. List of supported CMS types (data, signed-data, enveloped-data) moved
back into MSG (John Pawling)
6. Slight wording changes in section 3.1 ("removed" becomes "processed")
for security services (Paul Hoffman and offline comments)
7. Mention risks of data integrity with enveloped-data (ciphertext
modifications are undetected) (Paul Hoffman and offline comments)
8. Signed and encrypted vs. encrypted and signed warnings (related to 7
above) (Paul Hoffman and offline comments)
9. Our broken version of ASN.1 is further broken by the omission of an
equalsign in CBCParameter (Paul Hoffman)

This list is a bit longer than the -CERT draft.

Flames welcome.  New draft submitted Wednesday AM if no complaints.

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

(Continue reading)

John Pawling | 3 Aug 21:14 1998

CMS-06 Comments

Attachment: application/octet-stream, 3298 bytes
John Pawling | 4 Aug 14:26 1998

ESS-06 Comments

All,

I have the following comments to ESS-06:

1) Sec 1.3.4, 2nd para:  Please make the following editorial change:

OLD: "CMS defines signedAttrs as a SET OF SignedAttributes and defines
unsignedAttributes as a SET OF UnsignedAttributes. ESS defines the
contentHints, contentIdentifier, eSSecurityLabel, msgSigDigest,
mlExpansionHistory and receiptRequest attribute types."

NEW: "CMS defines signedAttrs as a SET OF Attributes and defines
unsignedAttributes as a SET OF Attributes. ESS defines the
contentHints, contentIdentifier, eSSecurityLabel, msgSigDigest,
mlExpansionHistory, receiptRequest, contentReference and
equivalentLabels attribute types."

2) Sec 1.3.4, 5th para:  Please make the following editorial change:

OLD: "Note that the inner and outer signatures are for different 
senders, so that the same attribute in the two signatures could lead 
to very different consequences."

NEW:  "Note that the inner and outer signatures are usually for 
different senders.  The same attribute in the two signatures could 
lead to very different consequences."

3) Sec 3.4, 2nd para:  Please make the following change:

OLD: "Receiving agents will not process an equivalent label in a 
message if the agent does not trust the signer of that attribute to 
specify an equivalent security policy. Some receiving agents will not 
process any equivalent labels at all, and will only process 
eSSSecurityLabels. All receiving agents SHOULD recognize equivalent 
labels even if they do not process them."

NEW: "Receiving agents MUST NOT process an equivalentLabels attribute 
in a message if the agent does not trust the signer of that attribute 
to translate the original eSSSecurityLabel values to the security 
policy included in the equivalentLabels attribute.  It is an optional 
requirement for receiving agents to process equivalentLabels 
attributes.  It is acceptable for a receiving agent to only process 
eSSSecurityLabels. All receiving agents SHOULD recognize 
equivalentLabels attributes even if they do not process them."

4) Sec 3.4.1, 5th para: Please make the following editorial change:

OLD: "CMS defines signedAttributes as a SET OF SignedAttribute."

NEW: "CMS defines signedAttributes as a SET OF Attribute."

3) Sec 3.4.2, 2nd para:  Please make the following change:

OLD:  "A receiving agent MUST NOT act on an EquivalentLabels attribute 
for which the signature could not be validated, and MUST NOT act on an 
EquivalentLabels attribute unless that attribute is signed by an
entity trusted to add or change access policies."

NEW: "A receiving agent MUST NOT act on an equivalentLabels attribute 
for which the signature could not be validated, and MUST NOT act on an 
equivalentLabels attribute unless that attribute is signed by an 
entity trusted to to translate the original eSSSecurityLabel values to 
to the security policy included in the equivalentLabels attribute."

4) Sec 3.4.2, 2nd para:  Recommend deleting: "If a message has more 
than one EquivalentLabels attribute, the receiving agent SHOULD 
process the first one that it reads and validates."

================================
John Pawling, jsp <at> jgvandyke.com                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

John Pawling | 4 Aug 15:09 1998

Re: CMS Section 12, take 3

All,

I have a few comments/questions regarding CMS Section 12:

1) Sec 12.1, intro, last sent: Please change "Message Digest authenticated
attribute" to "Message Digest signed attribute".

2) Sec 12.2.1: Please change "The algorithm identifier for DSA is:" to "The
algorithm identifier for DSA used in conjunction with SHA-1 is:".  I assume
that if an organization requires DSA to be used with a hashing algorithm
other than SHA-1, then they will define their own OID in a separate document.

3) Sec 12.3.3.1: Please change "Distribution of the key material used to
encryption the message encryption" to "Distribution of the key material used
to encrypt the message encryption".

4) Sec 12.4, 3rd para states: "Triple-DES may be an exception here; the same
identifier is used for both 2-key and 3-key Triple DES.  This is probably
easily handled by always wrapping three keys, even if the first and third
keys match."  These sentences need to be clarified.  The words "may" and
"probably" set off interoperability alarm bells in my mind.  We need to
resolve this issue and clearly state the solution in the CMS spec.  

5) Sec 12.4: Please delete: "{{{I am going to assume that this was suppose
to be a random padding.}}}"

================================
John Pawling, jsp <at> jgvandyke.com                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

Francesco.Zambon | 4 Aug 15:47 1998
Picon

Strong signature - weak cryptography


Hi,

yet another question for non-north americans !

Anybody knows if the following sequence of crypto algorithms is subject to the 
US export restictions?

- signature DSS  key-length > 512 ; since it can be used for the signature
- crypto rc4/40 :(by example) weak cryptography only 
- Sha:  digest

Since a strong signature is more critical than strong cryptography of the 
message this sequence could be more acceptable than todays export versions of 
S/mime.

regards , francesco zambon

<francesco.zambon <at> ieee.org>

John Pawling | 4 Aug 16:39 1998

CMS-06 Comments

All,

I have a few minor comments to CMS-06:

1) Sec 9.2, MAC Generation:  A few months ago, the "Message Digest 
Calculation Process" section of CMS was updated to reflect the change 
from "ContentInfo" to "EncapsulatedContentInfo" in the signedData 
syntax.  Similar changes need to be made to the "MAC Generation" 
section of CMS to reflect the inclusion of "EncapsulatedContentInfo" 
in the authenticatedData syntax.  Recommend that the first 5 
paragraphs of the MAC Generation section of CMS should be changed to 
read as follows:

"9.2 MAC Generation

The MAC calculation process computes a message authentication code 
(MAC) on either the content being authenticated or the content 
together with the originator's authenticated attributes.  In either 
case, the initial input to the MAC calculation process is the "value" 
of the encapsulated content being authenticated.  Specifically, the 
initial input is the   encapContentInfo eContent OCTET STRING to which 
the authentication process is applied.  Only the octets comprising the 
value of the eContent OCTET STRING are input to the MAC algorithm, not 
the tag or the length octets.

The result of the MAC calculation process depends on whether the 
authenticatedAttributes field is present.  When the field is absent, 
the result is just the MAC of the content as described above.  When 
the field is present, however, the result is   the MAC of the complete 
DER encoding of the authenticatedAttributes value contained in the 
AuthAttributes field. Since the authenticatedAttributes value, when 
present, must contain the content-type and mac-value attributes, those 
values are indirectly included in the result.  A separate encoding of 
the authenticatedAttributes field is performed for MAC calculation.  
The IMPLICIT [0] tag in the authenticatedAttributes field is not used 
for the DER encoding, rather an EXPLICIT SET OF tag is used.  That is, 
the DER encoding of the SET OF tag, rather than of the IMPLICIT [0] 
tag, is to be included in the MAC calculation along with the length 
and content octets of the authenticatedAttributes value.

When the authenticatedAttributes field is absent, then only the octets 
comprising the value of the authenticatedData encapContentInfo 
eContent OCTET STRING (e.g., the contents of a file) are input to the 
MAC calculation.  This has the advantage that the length of the 
content being authenticated need not be known in advance of the MAC 
generation process.

Although the encapContentInfo eContent OCTET STRING tag and length 
octets are not included in the MAC calculation, they are still 
protected by other means.  The length octets are protected by the 
nature of the MAC algorithm since it is  computationally infeasible to 
find any two distinct messages of any length that have the same MAC."

2) Sec 11.1, Content Type: Please change as follows:

OLD: "A content-type attribute must have a single attribute value."

NEW: "The SignedAttributes and AuthAttributes syntaxes are each 
defined as a SET OF Attributes.  The SignedAttributes in a signerInfo 
MUST NOT include multiple instances of the content-type attribute.  
Similarly, the AuthAttributes in an AuthenticatedData MUST NOT include 
multiple instances of the content-type attribute.  The Attribute 
syntax defines attrValues as a SET OF AttributeValue.  A content-type 
attribute MUST only include a single instance of AttributeValue. There 
MUST NOT be zero or multiple instances of AttributeValue present in 
the attrValues SET OF AttributeValue."

3) Sec 11.2, Message Digest: Please change as follows:

OLD: "A message-digest attribute must have a single attribute value."

NEW: "The SignedAttributes syntax is defined as a SET OF Attributes.  
The SignedAttributes in a signerInfo MUST NOT include multiple 
instances of the message-digest attribute.  The Attribute syntax 
defines attrValues as a SET OF AttributeValue.  A message-digest 
attribute MUST only include a single instance of AttributeValue. There 
MUST NOT be zero or multiple instances of AttributeValue present in 
the attrValues SET OF AttributeValue."

4) Sec 11.3, Signing Time: Please change as follows:

OLD: "A signing-time attribute must have a single attribute value."

NEW: "The SignedAttributes syntax is defined as a SET OF Attributes.  
The SignedAttributes in a signerInfo MUST NOT include multiple 
instances of the signing-time attribute.  The Attribute syntax defines 
attrValues as a SET OF AttributeValue.  A signing-time attribute MUST 
only include a single instance of AttributeValue. There MUST NOT be 
zero or multiple instances of AttributeValue present in the attrValues 
SET OF AttributeValue."

5) Sec 11.4, Countersignature: Please change as follows:

OLD: "A countersignature attribute can have multiple attribute values."

NEW: "The UnsignedAttributes syntax is defined as a SET OF Attributes.  
The UnsignedAttributes in a signerInfo MAY include multiple instances 
of the countersignature attribute.  The Attribute syntax defines 
attrValues as a SET OF AttributeValue.  A countersignature attribute 
MUST only include a single instance of AttributeValue. There MUST NOT 
be zero or multiple instances of AttributeValue present in the 
attrValues SET OF AttributeValue."

   
6) Sec 11.5, MAC Value: Please change as follows:

OLD: "A MAC-value attribute must have a single attribute value."

NEW: "The AuthAttributes syntax is defined as a SET OF Attributes.  
The AuthAttributes in an AuthenticatedData MUST NOT include multiple 
instances of the MAC-value attribute.  The Attribute syntax defines 
attrValues as a SET OF AttributeValue.  A MAC-value attribute MUST 
only include a single instance of AttributeValue. There MUST NOT be 
zero or multiple instances of AttributeValue present in the attrValues 
SET OF AttributeValue."

 
================================
John Pawling, jsp <at> jgvandyke.com                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

Brian Korver | 4 Aug 18:45 1998

Re: CMS-06 Comments

John,

One minor nit....

John Pawling writes:
[snip]
> The result of the MAC calculation process depends on whether the 
> authenticatedAttributes field is present.  When the field is absent, 
> the result is just the MAC of the content as described above.  When 
> the field is present, however, the result is   the MAC of the complete 
> DER encoding of the authenticatedAttributes value contained in the 
> AuthAttributes field. Since the authenticatedAttributes value, when 
> present, must contain the content-type and mac-value attributes, those 
> values are indirectly included in the result.  A separate encoding of 
> the authenticatedAttributes field is performed for MAC calculation.  
> The IMPLICIT [0] tag in the authenticatedAttributes field is not used 
> for the DER encoding, rather an EXPLICIT SET OF tag is used.  That is, 

I know what you mean, but "EXPLICIT SET OF" looks almost like ASN.1.
I'd suggest dropping EXPLICIT.  If it isn't clear enough, maybe we
should parenthetically state the actual tag byte (0x31).

> the DER encoding of the SET OF tag, rather than of the IMPLICIT [0] 
> tag, is to be included in the MAC calculation along with the length 
> and content octets of the authenticatedAttributes value.
[snip]

brian
briank <at> terisa.com

Paul Hoffman / IMC | 4 Aug 20:36 1998
Picon

Re: ESS-06 Comments

I agree with all of John's suggested new wording, but am iffy on the
following:

>4) Sec 3.4.2, 2nd para:  Recommend deleting: "If a message has more 
>than one EquivalentLabels attribute, the receiving agent SHOULD 
>process the first one that it reads and validates."

I think we should give advice to a recipient about what to do if multiple
(possibly conflicting) EquivalentLabels are in a message, although I'm also
OK with deleting this. What do others think?

--Paul Hoffman, Director
--Internet Mail Consortium


Gmane