Subject: Re: ASN.1-SIZE floating

From: [email-masked] (John Pawling)
Date: Mon, 14 Sep 1998 17:30:31 -0400

All,

I disagree with Bengt's assignment of 4 to 'MAX' in ESS.  This value is much
too low.  The following are the ASN.1 syntaxes in ESS that include 'MAX'.  

ContentHints ::= SEQUENCE {
  contentDescription UTF8String SIZE (1..MAX) OPTIONAL,
  contentType ContentType }

ESSPrivacyMark ::= CHOICE {
    pString      PrintableString SIZE (1..ub-privacy-mark-length),
    utf8String   UTF8String SIZE (1..MAX)
}

MLReceiptPolicy ::= CHOICE {
  none [0] NULL,
  insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
  inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }

I believe that ESS should remain as is so that it can provide sufficient
flexibility to support a variety of user organization requirements.  

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

At 08:59 AM 8/31/98 +0100, [email-masked] wrote:
>Comments on draft-ietf-smime-ess-07.txt
>
>Clause 2.9
>Using the SIZE constraints (1..MAX), where the implementor can chose MAX
will course interoperability problems. Nor only due to possible loss of
attributes, but to the fact that an implementation design with a lower MAX
than received, should reject the message as a protocol violation. 
>We shall assign a fixed number to MAX. 
>4 is a reasonable value, since I by this has to propose a figure.
>

---

From: "Darren Harter" <[email-masked]>
Date: Tue, 15 Sep 1998 18:49:32 -0000

Please see embedded comments....

-----Original Message-----
From: John Pawling <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Monday, September 14, 1998 10:40
Subject: Re: ASN.1-SIZE floating

>I disagree with Bengt's assignment of 4 to 'MAX' in ESS.  This value is
much

I agree, John.

>flexibility to support a variety of user organization requirements.

Perhaps we could compromise with a statement that MUSTs a minimum MAX for
ESS compliance.

Darren

---

From: "Darren Harter" <[email-masked]>
Date: Wed, 16 Sep 1998 07:03:51 +0100

Peter,

The use of GeneralNames originates from this field's use in MSP.  Originally ORName was used, and when the MSP implementors board discussed replacing ORName with GeneralName, I suggested that GeneralNames be used instead for the following reason.

ORName is (IIRC) a SEQUENCE of an OPTIONAL Name and an OPTIONAL ORAddress.  Whereas GeneralName is a simple CHOICE that includes Name and ORAddress as options.

This meant that an existing application that relied on both optional elements of the ORName would not be able to work with GeneralName. The only way to allow these applications to work would be to use GeneralNames.

So all occurences of ORName in MSP were replaced with GeneralNames.  Clearly the bits on the wire changed due to the tags in the GeneralName CHOICE, but the semantics for previous ORName functionality were retained.

I agree with you that for S/MIME in the pure Internet community GeneralName should be acceptable, but CMS and ESS go way beyond S/MIME.  They are being implemented in X.400 environments and full support for ORName fields is therefore necessary, IMO.

Darren

Darren Harter
CASM Programme Office
CESG
[email-masked]

>>> Peter Gutmann <[email-masked]> 09/16/98 09:49am >>>
Since GeneralNames is already a SEQUENCE SIZE (1...someone-elses-MAX) OF 
GeneralName, shouldn't these fields be GeneralName (without the 's')?  
Alternatively, just use GeneralNames (without the SEQUENCE OF), since it's 
already defined elsewhere.  This problem (using GeneralNames instead of 
GeneralName) occurs in various other places as well...
 
While I'm commenting on MLReceiptPolicy, the tagging on the NULL isn't 
necessary, since it's distinct from the two SEQUENCEs - all you need is [0] 
and [1] to distinguish the SEQUENCEs.
 
Peter.

---

From: [email-masked] (John Pawling)
Date: Wed, 16 Sep 1998 08:51:53 -0400

All,

Darren is correct, the MLReceiptPolicy insteadOf and inAdditionTo fields
must each be a SEQUENCE OF GeneralNames (not GeneralName) in order for
S/MIME to provide functionality that is equivalent to MSP and ACP120.  Each
GeneralNames represents an entity to which the S/MIME message recipient
should send a signed receipt, if appropriate.  To represent an entity's
O/RName in which both the ORAddress and DN are present, the GeneralNames
SEQUENCE will contain one GeneralName with the entity's x400Address present
followed by another GeneralName with the entity's directoryName present.