RE: Comment on ESS and Privacy Marks

The PKIX WG is using [UNIVERSAL xx] to include types that were defined
after publication of 1988 ASN.1.  S/MIME is following their lead.

Russ


At 01:05 PM 3/3/98 -0800, Bruce Greenblatt wrote:
> I generally agree with the Comments made by Bancroft Scott, and would
> strongly prefer to not see the use of UNIVERSAL tagging in the ESS
> document.  The specification of the Privacy Mark in the ESS-02 is legal
> ASN.1, will work, and I've not seen any compelling reason to use
> anything different.  The definition:
>
> ESSPrivacyMark ::= CHOICE {
>  pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
>  utf8String   OCTET STRING
>  -- If utf8String is used, the contents must be in UTF-8 [UTF8]
>
> }
>
> uses precisely the same mechanism that has already been used in the LDAP
> v3 (RFC 2251) standards track document in the definition of Directory
> String.  Can someone (maybe Paul) explain the compelling reason that the
> current ESS spec is wrong?
>
> Thanks,
>
> Bruce 
>
> > -----Original Message-----
> > From:        Russ Housley [SMTP:housley(_at_)spyrus(_dot_)com]
> > Sent:        Monday, March 02, 1998 7:02 PM
> > To:  Christian Rinderknecht
> > Cc:  ietf-smime(_at_)imc(_dot_)org
> > Subject:     Re: Comment on ESS and Privacy Marks
> >
> > Christian:
> >
> > Since S/MIME and PKIX are using the 1988 ASN.1, we need to use the
> > [UNIVERSAL xx] trick to support any types that have been defined in
> > the
> > subsequent releases of ASN.1.  Several implementations of 1988 ASN.1
> > support the use of [UNIVERSAL xx].
> >
> > Russ
> >
> > At 03:22 PM 3/2/98 +0100, Christian Rinderknecht wrote:
> > > On Mon, 2 Mar 1998, Russ Housley wrote:
> > >
> > > > > I agree with Bancroft Scott that ESSPrivacyMark should be
> > re-defined
> > > +as follows:
> > > > > > ESSPrivacyMark ::= CHOICE {
> > > > > >    pString      PrintableString (SIZE
> > > +(1..ub-privacy-mark-length)),
> > > > > >    utf8String   [0] IMPLICIT UTF8String (SIZE
> > > +(1..ub-privacy-mark-length))
> > > > > > }
> > > > >
> > > > > Note Bancroft's point as follows:
> > > > >
> > > > > Another
> > > > > benefit is that if someone is using a tool that does not support
> > > > > UTF8String they can simply change it to "[0] OCTET STRING" and get
> > > +the
> > > > > same encoding.
> > > > I do not agree. I think we should use the UNIVERSAL tag.  This will
> > > > align us with the correct implementation of UTF8 in the future,
> > > +rather 
> > > > than creating an octet hole to carry a UTF8.
> > >
> > > An "octet hole" is use of an OCTET STRING type to carry data of some
> > > other type, so [0] IMPLICIT UTF8String is not an octet hole for the
> > > type of the value is clearly specified as UTF8String.  The suggestion
> > > below to define the utf8String component with an IMPLICIT tag is a
> > > good idea, for it does not put an octet hole in the standard, while
> > at
> > > the same time gives implementors the freedom to use octet holes if
> > > that is how they would like to support UTF8String.
> > >
> > > At most there should be a comment:
> > >
> > >  --        UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
> > >  
> > > Doing so does not break the 1988 and 1997 standards which both forbid
> > > the use of UNIVERSAL tags in type definitions in ASN.1 modules, it
> > > makes it clear how this type is formally defined for those people who
> > > don't know that the tag is UNIVERSAL 12, and it is convenient for
> > > anyone whose tool does not support UTF8String to simply remove the
> > > "--" if doing so helps their tool to properly handle UTF8String.
> > >
> > >
> > >
> > > Christian
> > >
> > > ---
> > >
> > > Christian Rinderknecht       Alcatel Alsthom Corporate Research
> > Center
> > > Object Architectures Unit    Tel : +33 (0) 1 69 63 17 60
> > > Route de Nozay               Fax : +33 (0) 1 69 63 17 69
> > > 91460 Marcoussis, France     
> > > mailto:Christian(_dot_)Rinderknecht(_at_)aar(_dot_)alcatel-alsthom(_dot_)fr