Greetings. Well, that should teach those of use using antique broken
gateways to upgrade. :-) Because it was hard to follow what happened
yesterday, I've collected unrepeated copies of all of the messages and
reproduced them below.
Please do *not* reply to this message. Instead, if you want to reply to one
part of what was said, start a new thread with a descriptive subject line.
Doing this will greatly enhance the discussion. Thanks!
--Paul Hoffman, Director
--Internet Mail Consortium
==============================
Date: Wed, 5 Nov 1997 09:31:29 -0500
From: dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil (David P. Kemp)
To: ietf-smime(_at_)imc(_dot_)org
Subject: Re: Comments To ESS-00 - OIDs
X-Sun-Charset: US-ASCII
Sender: owner-ietf-smime(_at_)imc(_dot_)org
From: "Phillip H. Griffin" <asn1(_at_)mindspring(_dot_)com>
In all of the following OBJECT IDENTIFIER values, US is invalid
since it does not begin with a lowercase letter. Same for S in
SMIMECapabilities.
2.8 Receipt Request Syntax
receiptRequest OBJECT IDENTIFIER ::=
{iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9)
SMIMECapabilities(15) 3}
I think a little common sense is required when interpreting capitalization
conventions. Can you cite a reference that REQUIRES the initial letter
of OID arcs to be lower case? And if you want to change US to uS, I think
you'll have to petition ISO, not the S/MIME working group - country codes
were defined long ago in a forum far far away.
It is helpful to have a convention that distinguishes between structure
element names (initial lower) and the syntax definitions they refer to
(initial upper). But as far as I know, there is no ASN.1 module which
defines a syntax associated with any of the iso or joint country codes,
thus there is no danger of confusion or collision between name and
syntax.
Date: Wed, 05 Nov 1997 11:12:53 -0500
From: "Phillip H. Griffin" <asn1(_at_)mindspring(_dot_)com>
Reply-To: asn1(_at_)mindspring(_dot_)com
Organization: Griffin Consulting
X-Mailer: Mozilla 3.0 (Win95; U)
To: "David P. Kemp" <dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil>
CC: ietf-smime(_at_)imc(_dot_)org
Subject: Re: Comments To ESS-00 - OIDs
Sender: owner-ietf-smime(_at_)imc(_dot_)org
David P. Kemp wrote:
From: "Phillip H. Griffin" <asn1(_at_)mindspring(_dot_)com>
In all of the following OBJECT IDENTIFIER values, US is invalid
since it does not begin with a lowercase letter. Same for S in
SMIMECapabilities.
2.8 Receipt Request Syntax
receiptRequest OBJECT IDENTIFIER ::=
{iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9)
SMIMECapabilities(15) 3}
I think a little common sense is required when interpreting capitalization
conventions. Can you cite a reference that REQUIRES the initial letter
of OID arcs to be lower case? And if you want to change US to uS, I think
you'll have to petition ISO, not the S/MIME working group - country codes
were defined long ago in a forum far far away.
In the context of an ASN.1 value of type OBJECT IDENTIFIER, "us"
really has nothing to do with country codes. It is merely an ASN.1
identifier, the name of some value. (ref below)
It is helpful to have a convention that distinguishes between structure
element names (initial lower) and the syntax definitions they refer to
(initial upper). But as far as I know, there is no ASN.1 module which
defines a syntax associated with any of the iso or joint country codes,
thus there is no danger of confusion or collision between name and
syntax.
X.680 provides the following definition of values of type OBJECT
IDENTIFIER. In the NameAndNumberForm, each arc has an ASN.1 identifier,
which must begin with a lowercase letter, followed by the constraint
notation applied to a number or a defined value. In the NameForm, just
a valid ASN.1 identifier is present...
ObjectIdentifierType ::= OBJECT IDENTIFIER
ObjectIdentifierValue ::= "{" ObjIdComponentList "}" |
"{" DefinedValue ObjIdComponentList "}"
ObjIdComponentList ::= ObjIdComponent |
ObjIdComponent ObjIdComponentList
ObjIdComponent ::= NameForm |
NumberForm |
NameAndNumberForm
NameForm ::= identifier
NumberForm ::= number | DefinedValue
NameAndNumberForm ::= identifier "(" NumberForm ")"
Either "uS" or "us" is correct.
Phil
--
Phillip H. Griffin
ASN.1-SET-Java-Security Griffin Consulting
asn1(_at_)mindspring(_dot_)com 1625 Glenwood Avenue
919.828.7114 Raleigh, North Carolina 27608 USA
------------------------------------------------------------
Visit http://www.fivepointsfestival.com
------------------------------------------------------------
From: hollenbe(_at_)east(_dot_)xsis(_dot_)xerox(_dot_)com
X-Mailer: ccMail Link to SMTP R6.0
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <jsp(_at_)jgvandyke(_dot_)com>, <ietf-smime(_at_)imc(_dot_)org>
Subject: RE: Comments To ESS-00
Sender: owner-ietf-smime(_at_)imc(_dot_)org
-----Original Message-----
From: John Pawling [SMTP:jsp(_at_)jgvandyke(_dot_)com]
Sent: Wednesday, November 05, 1997 2:51 PM
To: Scott Hollenbeck; 'IETF S/MIME'
Subject: Re: Comments To ESS-00
All,
I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo. They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation. They are most useful in SignerInfos that do not
request signed receipts. I agree with Scott's comments that OIDs must be
defined for these attributes.
[SAH] OK, now I recall where they came from. That being the case,
ContentIdentifier needs to be defined. How about this:
ContentIdentifier ::= OCTET STRING
Then, the following should happen:
Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.
Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.
I think that closes the loop.
Scott
Date: Wed, 5 Nov 1997 12:45:26 -0500
From: dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil (David P. Kemp)
To: asn1(_at_)mindspring(_dot_)com
Subject: Re: Comments To ESS-00 - OIDs
Cc: ietf-smime(_at_)imc(_dot_)org
X-Sun-Charset: US-ASCII
Sender: owner-ietf-smime(_at_)imc(_dot_)org
From: "Phillip H. Griffin" <asn1(_at_)mindspring(_dot_)com>
X.680 provides the following definition of values of type OBJECT
IDENTIFIER. In the NameAndNumberForm, each arc has an ASN.1 identifier,
which must begin with a lowercase letter, ...
I stand corrected. It's right there in black and white, X.680
section 9.3.
Learn something every day. Thanks.
Date: Wed, 5 Nov 1997 14:06:14 -0500
X-Sender: jsp(_at_)ajsn101
X-Mailer: Windows Eudora Version 1.4.4
To: ietf-smime(_at_)imc(_dot_)org
From: jsp(_at_)jgvandyke(_dot_)com (John Pawling)
Subject: Re: Comments To ESS-00 - SET OF
Sender: owner-ietf-smime(_at_)imc(_dot_)org
Phil,
The X.411 SecurityLabel syntax is included in ESS-00 because it is an
international standard representation of security label and it is used by
many existing programs. The X.411 SecurityLabel syntax includes
SecurityCategories as a SET OF SecurityCategory. To maintain compatibility
with X.411, it should not be changed.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================
At 08:20 PM 11/4/97 -0500, asn1(_at_)mindspring(_dot_)com wrote:
The type defined as
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
SecurityCategory
requires sorting under DER that would not be required if the
type were defined as a SEQUENCE OF.
X.690, which defines DER restrictions in section 11, "Restrictions
on BER employed by both CER and DER", states that for components of
type SET OF, "The encodings of the component values of a set-of
value shall appear in ascending order, the encodings being compared
as octet strings."
Under DER, with SEQUENCE OF, the sender can control the order
of components, but with SET OF, the final sort requirement rules,
and sometimes may add unanticipated overhead to message processing.
It was primarily for this reason, the the SET specification is
based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
types like
Certificates ::= SEQUENCE OF Certificate
and avoid sorting what (hopefully) might be efficiently
organized certificate chains in SignedData. Same for the CRLs
and Attributes definitions.
Phil
--
Phillip H. Griffin
ASN.1-SET-Java-Security Griffin Consulting
asn1(_at_)mindspring(_dot_)com 1625 Glenwood Avenue
919.828.7114 Raleigh, North Carolina 27608 USA
------------------------------------------------------------
Visit http://www.fivepointsfestival.com
------------------------------------------------------------
Date: Wed, 5 Nov 1997 14:50:39 -0500
X-Sender: jsp(_at_)ajsn101
X-Mailer: Windows Eudora Version 1.4.4
To: Scott Hollenbeck <hollenbe(_at_)east(_dot_)xsis(_dot_)xerox(_dot_)com>,
"'IETF S/MIME'" <ietf-smime(_at_)imc(_dot_)org>
From: jsp(_at_)jgvandyke(_dot_)com (John Pawling)
Subject: Re: Comments To ESS-00
Sender: owner-ietf-smime(_at_)imc(_dot_)org
All,
I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo. They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation. They are most useful in SignerInfos that do not
request signed receipts. I agree with Scott's comments that OIDs must be
defined for these attributes.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================
At 11:04 AM 11/4/97 PST, Scott Hollenbeck wrote:
Thanks, Paul, for taking the draft document this far. Let the fun begin!
Section 1.3.4:
The attribute names should reflect the name associated with the attribute
OID, not the syntax of the attribute value. In general, this means that
the named attribute should begin with a lower case letter. So, I suggest
these changes:
ContentHints -> contentHints
ReceiptRequest -> receiptRequest
SecurityLabel -> securityLabel
Also, I don't believe that (signed?) ContentIdentifier and
EncapsulatedContentType are intended to be used as attributes. They're
part of the receiptRequest attribute and are copied to a Receipt structure.
If I missed something on this point then the OIDs for these "attributes" are
missing...
Section 2.10
The last line of the DirectoryString definition includes an extra double
quote character (") after the closing brace.
Section 3.2
An OID for the securityLabel attribute is missing.
Section 4.3
The syntax for EntityIdentifier is missing. When I wrote the first cut
at this text we put this definition in the EnvelopedData2 spec that Russ
Housley was writing, but it ought to be included here for completeness.
EntityIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber, -- From PKCS #7
subjectKeyIdentifier KeyIdentifier }
KeyIdentifier ::= OCTET STRING
----->
Scott Hollenbeck (mailto: hollenbe(_at_)east(_dot_)xsis(_dot_)xerox(_dot_)com)
Xerox Special Information Systems
Arlington, Virginia, USA
Date: Wed, 5 Nov 1997 14:58:42 -0500
X-Sender: jsp(_at_)ajsn101
X-Mailer: Windows Eudora Version 1.4.4
To: ietf-smime(_at_)imc(_dot_)org
From: jsp(_at_)jgvandyke(_dot_)com (John Pawling)
Subject: CMS-00 ASN.1 Module
Sender: owner-ietf-smime(_at_)imc(_dot_)org
All,
An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
that consolidates all of the ASN.1 syntaxes defined throughout the spec.
For example, The OriginatorInfo SEQUENCE includes two tags that are marked
IMPLICIT and a third that is not marked IMPLICIT. I believe that the intent
is for all tags to be IMPLICIT. This situation is resolved by including all
syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
That would mandate that all tags in the module are IMPLICIT.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================
From: Scott Hollenbeck <hollenbe(_at_)east(_dot_)xsis(_dot_)xerox(_dot_)com>
To: "'John Pawling'" <jsp(_at_)jgvandyke(_dot_)com>, "'IETF S/MIME'"
<ietf-smime(_at_)imc(_dot_)org>
Subject: RE: Comments To ESS-00
Date: Wed, 5 Nov 1997 12:05:32 PST
Sender: owner-ietf-smime(_at_)imc(_dot_)org
-----Original Message-----
From: John Pawling [SMTP:jsp(_at_)jgvandyke(_dot_)com]
Sent: Wednesday, November 05, 1997 2:51 PM
To: Scott Hollenbeck; 'IETF S/MIME'
Subject: Re: Comments To ESS-00
All,
I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo. They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation. They are most useful in SignerInfos that do not
request signed receipts. I agree with Scott's comments that OIDs must be
defined for these attributes.
[SAH] OK, now I recall where they came from. That being the case,
ContentIdentifier needs to be defined. How about this:
ContentIdentifier ::= OCTET STRING
Then, the following should happen:
Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.
Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.
I think that closes the loop.
Scott
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
From: "Blake Ramsdell" <BlakeR(_at_)deming(_dot_)com>
To: "'ietf-smime(_at_)imc(_dot_)org'" <ietf-smime(_at_)imc(_dot_)org>,
"'Paul Hoffman (E-mail)'" <phoffman(_at_)imc(_dot_)org>
Subject: OIDs for ESS
Date: Wed, 5 Nov 1997 12:11:35 -0800
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version
4.0.993.5
X-WSS-ID: 187E0D7243180-187E0D7243181-01
receiptRequest, receipt, contentHints and mlExpansionHistory should all
be under the SMIME (pkcs-9 16) arc, not the SMIMECapabilities (pkcs-9
15) arc.
Paul, are you going to be managing the OIDS page at IMC with the new
SMIME arc on it also? I'd say we can use the same page as the
SMIMECapabilities. Russ has the current list, I believe.
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
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
From: "Blake Ramsdell" <BlakeR(_at_)deming(_dot_)com>
To: "'jsp(_at_)jgvandyke(_dot_)com'" <jsp(_at_)jgvandyke(_dot_)com>,
"'ietf-smime(_at_)imc(_dot_)org'"
<ietf-smime(_at_)imc(_dot_)org>
Subject: RE: CMS-00 ASN.1 Module
Date: Wed, 5 Nov 1997 12:12:29 -0800
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version
4.0.993.5
X-WSS-ID: 187E0CA443196-187E0CA443200-01
Sender: owner-ietf-smime(_at_)imc(_dot_)org
On Wednesday, November 05, 1997 11:59 AM, jsp(_at_)jgvandyke(_dot_)com
[SMTP:jsp(_at_)jgvandyke(_dot_)com] wrote:
An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
that consolidates all of the ASN.1 syntaxes defined throughout the spec.
For example, The OriginatorInfo SEQUENCE includes two tags that are marked
IMPLICIT and a third that is not marked IMPLICIT. I believe that the intent
is for all tags to be IMPLICIT. This situation is resolved by including all
syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
That would mandate that all tags in the module are IMPLICIT.
I think we need to do the same thing for ESS, right?
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, 5 Nov 1997 15:23:51 -0500
X-Sender: jsp(_at_)ajsn101
X-Mailer: Windows Eudora Version 1.4.4
To: Scott Hollenbeck <hollenbe(_at_)east(_dot_)xsis(_dot_)xerox(_dot_)com>,
"'IETF S/MIME'" <ietf-smime(_at_)imc(_dot_)org>
From: jsp(_at_)jgvandyke(_dot_)com (John Pawling)
Subject: RE: Comments To ESS-00
Sender: owner-ietf-smime(_at_)imc(_dot_)org
All,
I agree with Scott's recommendations.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================
At 12:05 PM 11/5/97 PST, Scott Hollenbeck wrote:
-----Original Message-----
From: John Pawling [SMTP:jsp(_at_)jgvandyke(_dot_)com]
Sent: Wednesday, November 05, 1997 2:51 PM
To: Scott Hollenbeck; 'IETF S/MIME'
Subject: Re: Comments To ESS-00
All,
I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo. They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation. They are most useful in SignerInfos that do not
request signed receipts. I agree with Scott's comments that OIDs must be
defined for these attributes.
[SAH] OK, now I recall where they came from. That being the case,
ContentIdentifier needs to be defined. How about this:
ContentIdentifier ::= OCTET STRING
Then, the following should happen:
Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.
Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.
I think that closes the loop.
Scott
Date: Wed, 5 Nov 1997 15:25:13 -0500
X-Sender: jsp(_at_)ajsn101
X-Mailer: Windows Eudora Version 1.4.4
To: "Blake Ramsdell" <BlakeR(_at_)deming(_dot_)com>,
"'ietf-smime(_at_)imc(_dot_)org'" <ietf-smime(_at_)imc(_dot_)org>
From: jsp(_at_)jgvandyke(_dot_)com (John Pawling)
Subject: RE: CMS-00 ASN.1 Module
Sender: owner-ietf-smime(_at_)imc(_dot_)org
Blake,
Yes.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================
At 12:12 PM 11/5/97 -0800, Blake Ramsdell wrote:
On Wednesday, November 05, 1997 11:59 AM, jsp(_at_)jgvandyke(_dot_)com
[SMTP:jsp(_at_)jgvandyke(_dot_)com] wrote:
An ASN.1 module needs to be added to the "Cryptographic Message Syntax"
spec
that consolidates all of the ASN.1 syntaxes defined throughout the spec.
For example, The OriginatorInfo SEQUENCE includes two tags that are marked
IMPLICIT and a third that is not marked IMPLICIT. I believe that the
intent
is for all tags to be IMPLICIT. This situation is resolved by including
all
syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
That would mandate that all tags in the module are IMPLICIT.
I think we need to do the same thing for ESS, right?
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, 05 Nov 1997 16:00:18 -0500
From: "Phillip H. Griffin" <asn1(_at_)mindspring(_dot_)com>
Reply-To: asn1(_at_)mindspring(_dot_)com
Organization: Griffin Consulting
X-Mailer: Mozilla 3.0 (Win95; U)
To: ietf-smime(_at_)imc(_dot_)org
Subject: ESS-00 Integers
Sender: owner-ietf-smime(_at_)imc(_dot_)org
The following integer value definitions...
ub-integer-options ::= 256
ub-privacy-mark-length ::= 128
ub-security-categories ::= 64
should be
ub-integer-options INTEGER ::= 256
ub-privacy-mark-length INTEGER ::= 128
ub-security-categories INTEGER ::= 64
Phil
--
Phillip H. Griffin
ASN.1-SET-Java-Security Griffin Consulting
asn1(_at_)mindspring(_dot_)com 1625 Glenwood Avenue
919.828.7114 Raleigh, North Carolina 27608 USA
------------------------------------------------------------
Visit http://www.fivepointsfestival.com
------------------------------------------------------------
Date: Wed, 05 Nov 1997 16:20:57 -0500
From: "Phillip H. Griffin" <asn1(_at_)mindspring(_dot_)com>
Reply-To: asn1(_at_)mindspring(_dot_)com
Organization: Griffin Consulting
X-Mailer: Mozilla 3.0 (Win95; U)
To: John Pawling <jsp(_at_)jgvandyke(_dot_)com>
CC: ietf-smime(_at_)imc(_dot_)org
Subject: Re: Comments To ESS-00 - SET OF
Sender: owner-ietf-smime(_at_)imc(_dot_)org
John Pawling wrote:
Phil,
The X.411 SecurityLabel syntax is included in ESS-00 because it is an
international standard representation of security label and it is used by
many existing programs. The X.411 SecurityLabel syntax includes
SecurityCategories as a SET OF SecurityCategory. To maintain compatibility
with X.411, it should not be changed.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================
I agree that no change should be made that breaks backwards
compatibility, but it would be possible, if accompanied with
a change in version, to alter the definition to
SecurityCategories ::= CHOICE {
setOf SET SIZE (1..ub-security-categories) OF
SecurityCategory,
seqOf SEQUENCE SIZE (1..ub-security-categories) OF
SecurityCategory
}
ub-security-categories INTEGER ::= 64
so that no additional tagging were needed to distinguish
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't
be worth the effort.
At 08:20 PM 11/4/97 -0500, asn1(_at_)mindspring(_dot_)com wrote:
The type defined as
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
SecurityCategory
requires sorting under DER that would not be required if the
type were defined as a SEQUENCE OF.
X.690, which defines DER restrictions in section 11, "Restrictions
on BER employed by both CER and DER", states that for components of
type SET OF, "The encodings of the component values of a set-of
value shall appear in ascending order, the encodings being compared
as octet strings."
Under DER, with SEQUENCE OF, the sender can control the order
of components, but with SET OF, the final sort requirement rules,
and sometimes may add unanticipated overhead to message processing.
It was primarily for this reason, the the SET specification is
based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
types like
Certificates ::= SEQUENCE OF Certificate
and avoid sorting what (hopefully) might be efficiently
organized certificate chains in SignedData. Same for the CRLs
and Attributes definitions.
Phil
Phil
--
Phillip H. Griffin
ASN.1-SET-Java-Security Griffin Consulting
asn1(_at_)mindspring(_dot_)com 1625 Glenwood Avenue
919.828.7114 Raleigh, North Carolina 27608 USA
------------------------------------------------------------
Visit http://www.fivepointsfestival.com
------------------------------------------------------------
From: asn1(_at_)mindspring(_dot_)com
X-Mailer: ccMail Link to SMTP R6.0
Date: Wed, 05 Nov 97 16:20:57 -0500
To: <jsp(_at_)jgvandyke(_dot_)com>
Cc: <ietf-smime(_at_)imc(_dot_)org>
Subject: Re: Comments To ESS-00 - SET OF
Sender: owner-ietf-smime(_at_)imc(_dot_)org
John Pawling wrote:
Phil,
The X.411 SecurityLabel syntax is included in ESS-00 because it is an
international standard representation of security label and it is used by
many existing programs. The X.411 SecurityLabel syntax includes
SecurityCategories as a SET OF SecurityCategory. To maintain compatibility
with X.411, it should not be changed.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================
I agree that no change should be made that breaks backwards
compatibility, but it would be possible, if accompanied with
a change in version, to alter the definition to
SecurityCategories ::= CHOICE {
setOf SET SIZE (1..ub-security-categories) OF
SecurityCategory,
seqOf SEQUENCE SIZE (1..ub-security-categories) OF
SecurityCategory
}
ub-security-categories INTEGER ::= 64
so that no additional tagging were needed to distinguish
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't
be worth the effort.
At 08:20 PM 11/4/97 -0500, asn1(_at_)mindspring(_dot_)com wrote:
The type defined as
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
SecurityCategory
requires sorting under DER that would not be required if the
type were defined as a SEQUENCE OF.
X.690, which defines DER restrictions in section 11, "Restrictions
on BER employed by both CER and DER", states that for components of
type SET OF, "The encodings of the component values of a set-of
value shall appear in ascending order, the encodings being compared
as octet strings."
Under DER, with SEQUENCE OF, the sender can control the order
of components, but with SET OF, the final sort requirement rules,
and sometimes may add unanticipated overhead to message processing.
It was primarily for this reason, the the SET specification is
based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
types like
Certificates ::= SEQUENCE OF Certificate
and avoid sorting what (hopefully) might be efficiently
organized certificate chains in SignedData. Same for the CRLs
and Attributes definitions.
Phil
Phil
--
Phillip H. Griffin
ASN.1-SET-Java-Security Griffin Consulting
asn1(_at_)mindspring(_dot_)com 1625 Glenwood Avenue
919.828.7114 Raleigh, North Carolina 27608 USA
------------------------------------------------------------
Visit http://www.fivepointsfestival.com
------------------------------------------------------------
Date: Wed, 5 Nov 1997 16:39:37 -0500
X-Sender: jsp(_at_)ajsn101
X-Mailer: Windows Eudora Version 1.4.4
To: asn1(_at_)mindspring(_dot_)com
From: jsp(_at_)jgvandyke(_dot_)com (John Pawling)
Subject: Re: Comments To ESS-00 - SET OF
Cc: ietf-smime(_at_)imc(_dot_)org
Sender: owner-ietf-smime(_at_)imc(_dot_)org
Phil,
IMHO, it is not worth the added complexity of defining a CHOICE for
SecurityCategories. There is no way to predict how securityCategories will
be used within organizations' security policies, so I can't tell you that
they will always be small sets or easy to sort. However, S/MIME-enabled
applications must be capable of implementing DER anyway, so I don't believe
that the securityCategories SET OF adds a new requirement. If this were the
only occurrence of "SET" or "SET OF" in the required ASN.1 syntaxes, then I
would have a different opinion. However, there are other occurrences of SET
and SET OF in syntaxes such as in the Attribute, RDN and GeneralName
ORAddress components.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================
At 04:20 PM 11/5/97 -0500, asn1(_at_)mindspring(_dot_)com wrote:
John Pawling wrote:
Phil,
The X.411 SecurityLabel syntax is included in ESS-00 because it is an
international standard representation of security label and it is used by
many existing programs. The X.411 SecurityLabel syntax includes
SecurityCategories as a SET OF SecurityCategory. To maintain compatibility
with X.411, it should not be changed.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================
I agree that no change should be made that breaks backwards
compatibility, but it would be possible, if accompanied with
a change in version, to alter the definition to
SecurityCategories ::= CHOICE {
setOf SET SIZE (1..ub-security-categories) OF
SecurityCategory,
seqOf SEQUENCE SIZE (1..ub-security-categories) OF
SecurityCategory
}
ub-security-categories INTEGER ::= 64
so that no additional tagging were needed to distinguish
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't
be worth the effort.
At 08:20 PM 11/4/97 -0500, asn1(_at_)mindspring(_dot_)com wrote:
The type defined as
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
SecurityCategory
requires sorting under DER that would not be required if the
type were defined as a SEQUENCE OF.
X.690, which defines DER restrictions in section 11, "Restrictions
on BER employed by both CER and DER", states that for components of
type SET OF, "The encodings of the component values of a set-of
value shall appear in ascending order, the encodings being compared
as octet strings."
Under DER, with SEQUENCE OF, the sender can control the order
of components, but with SET OF, the final sort requirement rules,
and sometimes may add unanticipated overhead to message processing.
It was primarily for this reason, the the SET specification is
based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
types like
Certificates ::= SEQUENCE OF Certificate
and avoid sorting what (hopefully) might be efficiently
organized certificate chains in SignedData. Same for the CRLs
and Attributes definitions.
Phil
Phil
--
Phillip H. Griffin
ASN.1-SET-Java-Security Griffin Consulting
asn1(_at_)mindspring(_dot_)com 1625 Glenwood Avenue
919.828.7114 Raleigh, North Carolina 27608 USA
------------------------------------------------------------
Visit http://www.fivepointsfestival.com
------------------------------------------------------------
Date: Wed, 5 Nov 1997 18:47:54 -0500
X-Sender: jsp(_at_)ajsn101
X-Mailer: Windows Eudora Version 1.4.4
To: ietf-smime(_at_)imc(_dot_)org
From: jsp(_at_)jgvandyke(_dot_)com (John Pawling)
Subject: ESS-00 Multiple Signed Receipts Issue
Sender: owner-ietf-smime(_at_)imc(_dot_)org
All,
The "Enhanced Security Services for S/MIME" Internet Draft (ESS-00)
describes the process of an originator requesting signed receipts and a
recipient returning signed receipts. There can be multiple SignerInfos
present within a SignedData object. Each SignerInfo can include
authenticatedAttributes. Therefore, a single SignedData object may include
multiple SignerInfos each of which include a receiptRequest attribute. I
believe that this should be allowed and should be documented in the ESS.
For example, if an originator desires to send a signed message requesting
signed receipts to a set of users composed of RSA-only and DSA-only users.
The originator's software can include one SignerInfo that includes an RSA
signature value and a receiptRequest attribute. The same SignedData object
could include another SignerInfo that includes a DSA signature value and a
receiptRequest attribute. In this example, the RSA-capable recipients would
return an RSA signed receipt to the originator and the DSA-capable
recipients would return a DSA signed receipt to the originator.
I believe that the general processing rules in ESS should state that a
receiving agent should build a signed receipt for each SignerInfo in the
SignedData object for which it verifies the signature and which requests a
signed receipt. This may result in multiple signed receipts being
constructed and returned for a single SignedData object.
I also believe that we should add a restriction that only one receiptRequest
attribute can be included in the authenticatedAttributes of a SignerInfo.
I will include specific comments to ESS-00 in a follow-up message, but I
wanted to raise this issue separately because I beleive that it deserves
special attention.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
From: "Blake Ramsdell" <BlakeR(_at_)deming(_dot_)com>
To: "'ietf-smime(_at_)imc(_dot_)org'" <ietf-smime(_at_)imc(_dot_)org>
Subject: S/MIME Version 3 Message Specification draft is now available
Date: Wed, 5 Nov 1997 16:22:23 -0800
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version
4.0.993.5
X-WSS-ID: 187FD24A1518-187FD24A1519-01
Sender: owner-ietf-smime(_at_)imc(_dot_)org
The first draft of "S/MIME Version 3 Message Specification" is now
available at
<ftp://ietf.org/internet-drafts/draft-ramsdell-smime-msg-00.txt> (Paul
will copy it to the IMC site later. This draft describes the S/MIME v3
usage of the Cryptographic Message Syntax draft. There is an appendix
with the changes from S/MIME v2.
Have at it. Here are the open issues that I know about, and any insight
would be welcome.
Section 2.5.2 Add certs as an authenticatedAttribute
[DH] is undefined in section 2.3
[DH-DSS] is undefined in section 2.2
Need OIDs for Diffie-Hellman and Diffie-Hellman/DSS
Is the terminology correct for Diffie-Hellman for encryption vs.
signing?
What do we need to do for 4.1 in order to make it Diffie-Hellman?
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, 5 Nov 1997 19:52:00 -0500
X-Sender: jsp(_at_)ajsn101
X-Mailer: Windows Eudora Version 1.4.4
To: ietf-smime(_at_)imc(_dot_)org
From: jsp(_at_)jgvandyke(_dot_)com (John Pawling)
Subject: Very Sorry For the Looping
Sender: owner-ietf-smime(_at_)imc(_dot_)org
All,
I apologize for the inconvenience caused by my company's mail system. Our
system admin staff is working on this problem right now. The ccMail gateway
at our company seems to be repeating the message that I sent.
Sorry,
John Pawling
Return-Path: <BlakeR(_at_)deming(_dot_)com>
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
From: "Blake Ramsdell" <BlakeR(_at_)deming(_dot_)com>
To: "'jsp(_at_)jgvandyke(_dot_)com'" <jsp(_at_)jgvandyke(_dot_)com>
Subject: FW: CMS-00 ASN.1 Module
Date: Wed, 5 Nov 1997 16:05:40 -0800
Return-Receipt-To: <BlakeR(_at_)deming(_dot_)com>
X-Wss-Id: 187FD65C1338-187FD65C1339-01
You mail server seems to be freaking out a bit -- I have seen several
copies of my message come through, with headers as follows:
Received: from host9.deming.com by cane.deming.com with SMTP (Microsoft
Exchange Internet Mail Connector Version 4.0.993.5)
id Z3XTSAFN; Wed, 5 Nov 1997 15:55:30 -0800
Received: from 206.86.127.224 by cane.deming.com with SMTP (WorldSecure
Server SMTP Relay v2.01); Wed, 05 Nov 97 15:55:29 -0800
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: (from majordomo(_at_)localhost) by mail.proper.com (8.8.7/8.7.3) id
PAA09991 for ietf-smime-bks; Wed, 5 Nov 1997 15:42:01 -0800 (PST)
Received: from mail3.access.digex.net (mail3.access.digex.net
[205.197.247.4]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id
PAA09987 for <ietf-smime(_at_)imc(_dot_)org>; Wed, 5 Nov 1997 15:41:57
-0800 (PST)
From: <BlakeR(_at_)deming(_dot_)com>
Received: from apollo (apollo.jgvandyke.com [158.189.10.100]) by
mail3.access.digex.net (8.8.5/8.8.5) with SMTP id SAA05572 for
<ietf-smime(_at_)imc(_dot_)org>; Wed, 5 Nov 1997 18:41:52 -0500 (EST)
Received: from vda-gateway.jgvandyke.com by apollo (5.x/SMI-SVR4) id
AA00951; Wed, 5 Nov 1997 18:55:50 -0500
Received: from POP3 Client by vda-gateway.jgvandyke.com (ccMail Link to
SMTP R6.0) id AA878773376; Wed, 05 Nov 97 18:43:03 -0500
Message-ID:
<9711058787(_dot_)AA878773376(_at_)vda-gateway(_dot_)jgvandyke(_dot_)com>
X-Mailer: ccMail Link to SMTP R6.0
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <jsp(_at_)jgvandyke(_dot_)com>, <ietf-smime(_at_)imc(_dot_)org>
Subject: RE: CMS-00 ASN.1 Module
MIME-Version: 1.0
Sender: <owner-ietf-smime(_at_)imc(_dot_)org>
Precedence: bulk
X-WSS-ID: 187FD8E41202-187FD8E41203-01
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: 7bit
This seems to indicate that your ccMail gateway is doing something a
little whacky with the message.
Let me know if you have any insight.
Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103 Fax +1 425 882 8060
-----Original Message-----
From: Blake Ramsdell
Sent: Wednesday, November 05, 1997 9:12 AM
To: jsp(_at_)jgvandyke(_dot_)com; ietf-smime(_at_)imc(_dot_)org
Subject: RE: CMS-00 ASN.1 Module
On Wednesday, November 05, 1997 11:59 AM, jsp(_at_)jgvandyke(_dot_)com
[SMTP:jsp(_at_)jgvandyke(_dot_)com] wrote:
An ASN.1 module needs to be added to the "Cryptographic Message Syntax"
spec
that consolidates all of the ASN.1 syntaxes defined throughout the spec.
For example, The OriginatorInfo SEQUENCE includes two tags that are marked
IMPLICIT and a third that is not marked IMPLICIT. I believe that the
intent
is for all tags to be IMPLICIT. This situation is resolved by including
all
syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
That would mandate that all tags in the module are IMPLICIT.
I think we need to do the same thing for ESS, right?
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
X-Sender: phoffman(_at_)mail(_dot_)imc(_dot_)org
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 05 Nov 1997 17:57:31 -0800
To: "Blake Ramsdell" <BlakeR(_at_)deming(_dot_)com>,
"'ietf-smime(_at_)imc(_dot_)org'" <ietf-smime(_at_)imc(_dot_)org>
From: Paul Hoffman / IMC <phoffman(_at_)imc(_dot_)org>
Subject: Re: S/MIME Version 3 Message Specification draft is now
available
Sender: owner-ietf-smime(_at_)imc(_dot_)org
The first draft of "S/MIME Version 3 Message Specification" is now
available at
<ftp://ietf.org/internet-drafts/draft-ramsdell-smime-msg-00.txt> (Paul
will copy it to the IMC site later.
Jeez, give me a minute or two to get it up on the IMC site! :-) It's now
available as <http://www.imc.org/draft-ramsdell-smime-msg>. For those of
you new to the IMC way of doing things, we don't include the "-00.txt" in
the names. When a new version of any draft comes out, it is automatically
updated on the site, so you don't need to know which version is the most
recent.
--Paul Hoffman, Director
--Internet Mail Consortium
Original-Encoded-Information-Types: IA5-Text
Date: Thu, 6 Nov 97 2:56:20 +0000
From: "Jim Craigie" TEL +44-1635-202124
<Jim(_dot_)Craigie(_at_)net-tel(_dot_)co(_dot_)uk>
To: asn1(_at_)mindspring(_dot_)com, ietf-smime(_at_)imc(_dot_)org
Subject: Re: ESS-00 Mixing X.208 and X.680
Sender: owner-ietf-smime(_at_)imc(_dot_)org
Such ASN.1 usage will certainly break tools that correctly implement
the ASN.1 standards. I'm not sure why there's so much reluctance to
migrate to ASN.1:1994. It's a better tool, in my opinion, for designing
specifications than X.208-X.209.
Is the reluctance simply fear of the unknown? Anyone who has invested the
effort to understand the 1994 version of ASN.1 realises that it provides a
significantly more powerful tool which creates much more precise syntactic
specifications. To illustrate this I will produce modules conforming to the
1994 ASN.1 version, and circulate these to this list.
Jim
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
From: "Blake Ramsdell" <BlakeR(_at_)deming(_dot_)com>
To: "Blake Ramsdell" <BlakeR(_at_)deming(_dot_)com>,
"'ietf-smime(_at_)imc(_dot_)org'"
<ietf-smime(_at_)imc(_dot_)org>,
"'Paul Hoffman (E-mail)'" <phoffman(_at_)imc(_dot_)org>
Subject: RE: OIDs for ESS
Date: Wed, 5 Nov 1997 20:45:28 -0800
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version
4.0.993.5
X-WSS-ID: 187F94E12916-187F94E12917-01
Sender: owner-ietf-smime(_at_)imc(_dot_)org
On Wednesday, November 05, 1997 12:12 PM, Blake Ramsdell wrote:
Paul, are you going to be managing the OIDS page at IMC with the new
SMIME arc on it also? I'd say we can use the same page as the
SMIMECapabilities. Russ has the current list, I believe.
Ah, it appears that I am a moron. These are already up on
http://www.imc.org/ietf-smime/oids.html
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, 6 Nov 1997 07:45:39 -0500
X-Sender: jsp(_at_)ajsn101
X-Mailer: Windows Eudora Version 1.4.4
To: ietf-smime(_at_)imc(_dot_)org
From: jsp(_at_)jgvandyke(_dot_)com (John Pawling)
Subject: Shutting Down ccMail GW
Sender: owner-ietf-smime(_at_)imc(_dot_)org
All,
Again, I aplogize for the looping messages sent by the ccMail gateway
installed at our company. Our system admin people are now shutting down our
ccMail gateway (which they should have done last night). The messages
should be stopping any minute now.
Again, I apologize for this extreme inconvenience
- John Pawling
--Paul Hoffman, Director
--Internet Mail Consortium