ietf-smime
[Top] [All Lists]

Re: Comments To ESS-00 - SET OF

1997-11-06 02:20:54





















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