RE: I-Draft on signed operations

["Salter, Thomas A" <Thomas.Salter@unisys.com>]

1. I'm unclear as to how the actual signing process must proceed.
Section 2 says:
   "The value of the encrypted field is computed over the entire
LDAPMessage with the encrypted field set to NULL (i.e. absent)."

Does this mean that you create the message, encode it as BER, and
compute the encrypted field.  Then you recreate the message with the
encrypted field set as computed and regenerate the BER?  It seems you
must recreate the BER because the length of the message changes when you
insert the encrypted bit string.

If so, then to validate the signature, you must do the opposite: extract
the encrypted field and regenerate the BER, then compute the signature
and compare them.  This requires that the same BER be generated by both
client and server.  The current Ldap requirements are not strict enough
to ensure this.  You would need to require DER, or at least require
minimum-length length fields.


2. Section 1 says, "A disadvantage of this approach is that it would be
necessary to define a new Extended Request/Response pair for each basic
operation that should be signed. "

I believe it only requires a single Extended Request/Response pair.  Its
requestValue would be a SEQUENCE containing the signature, and a
complete LdapMessage.  The SecurityParameters could remain as a control
in the embedded LdapMessage.  By wrapping an entire message in a
sequence, it would be clear what the signature applied to and it would
not be necessary to reencode the BER, effectively removing the
requirement for DER encoding of the entire LdapMessage.

In fact, unless I'm totally confused about my first point above, I'd
recommend that the document be changed to use an Extended operation as
I've just described.


3. In Section 2, SecurityParameters are defined as a SET.  I'd recommend
changing it to a SEQUENCE so that you don't need to add the DER ordering
rule for set members.


4. How is 'none' used as a value for target ?


5. Section 3.3 says "If the time and random field of the control are
used in an appropriate way, ..."  Perhaps there should be a reference to
a document (x.509 ?) that defines "appropriate".


> ----------
> From: 	Vesna Hassler[SMTP:hassler@infosys.tuwien.ac.at]
> Sent: 	Monday, March 30, 1998 8:30 AM
> To: 	ldap@umich.edu; ietf-ldapext@netscape.com
> Subject: 	I-Draft on signed operations
> 
> <<File: ATT86830.txt>>
> Hi,
> 
> Some weeks ago I submitted a draft on signed operations (Individual
> Submission):
> 
> ftp://ftp.ietf.org/internet-drafts/draft-hassler-ldapv3-secparam-00.tx
> t
> 
> In this mail please find attached a slightly improved (not yet
> submitted) version with
> - the changed ASN.1 for controlValue
> - generalizedTime instead of UTCTime (Ellen Stokes' comment)
> - the remark on BER encoding of the controlValue field (Mark Wahl's
> comment)
> 
> Any comments are greatly appreciated.
> 
> Vesna Hassler
>