[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: updated Signed Directory Operations Draft <draft-ietf-ldapext -sigops-02.txt>



David,

Thanks for the suggestion.  Your ASN.1 construct is MUCH better than mine.
I'll update the draft.

Bruce

> -----Original Message-----
> From:	David Chadwick [SMTP:d.w.chadwick@iti.salford.ac.uk]
> Sent:	Monday, August 31, 1998 1:27 AM
> To:	Bruce Greenblatt; ietf-ldapext@netscape.com
> Subject:	Re: updated Signed Directory Operations Draft
> <draft-ietf-ldapext-sig	ops-02.txt>
> 
> > 
> >      SignedOperation ::= CHOICE {
> >           signbyServer   [0] BOOLEAN,
> >           signatureIncluded   [1] OCTET STRING
> >      }
> > 
> > 
> >      If the SignatureIncluded CHOICE is used, then the OCTET string is
> > just an S/MIME message of the multipart/signed variety, that is composed
> > of a single piece, that is the signature of the directory operation.
> > Multipart/signed MIME objects are defined in [3].  If the SignbyServer
> > CHOICE us used, then the LDAP server creates the signature on behalf of
> 
> Bruce,
> 
> the ASN.1 construct for Signed Operation seems awkward to me. In a choice,
> 
> either parameter can be chosen, and the chosen one then takes the 
> appropriate values for that parameter. In your construct you effectively
> have 3 
> outcomes
> 
> i) signed by server TRUE
> ii) signed by server FALSE
> iii) signature included, an OCTET STRING.
> 
> I dont think this is what you intended, and your descriptive text
> certainly only 
> caters for two options, i) and iii) above, and not for ii).
> 
> May I suggest the following alternative ASN.1 constructs for you to
> consider
> 
>       SignedOperation ::= SEQUENCE {
>          signbyServer    BOOLEAN DEFAULT FALSE,
>          signatureIncluded   OCTET STRING OPTIONAL  --only present if
> 
>                                                           -- signByServer
> is FALSE
>          }
> 
> With this construct, values would either consist of
> i) a TRUE value, or
> ii) an OCTET STRING
> 
> which I think is what you wanted.
> 
> Note that the tags are not needed because the two types are different and 
> cannot be confused by the recipient.
> 
> 
> David
> 
> ***************************************************
> 
> David Chadwick
> IT Institute, University of Salford, Salford M5 4WT
> Tel +44 161 295 5351  Fax +44 161 745 8169
> Mobile +44 370 957 287
> Email D.W.Chadwick@iti.salford.ac.uk
> Home Page  http://www.salford.ac.uk/its024/chadwick.htm
> Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
> 
> ***************************************************