RE: Signed Directory Operations

[Bruce Greenblatt <Bgreenblatt@rsa.com>]

Thanks for reading Thomas.  I'll answer inline...

> Can you provide some clarification/rationale on these points:
> 1. What's the advantage of S/MIME formatted signature, rather than an
> ASN.1 bit string ?
> 
[> ]  Using multipart/signed allows you to have the ldap operation in the
clear form, followed by the signature of the operation.  PKCS #7 would put a
wrapper around both of them.  So, with multipart/signed you get:

MIME boundary

LDAP Operation

MIME boundary

raw PKCS #7 detached signature

MIME boundary

So, this way the PKCS #7 object only has the signature in it.  I think that
using S/MIME and multipart/signed simplifies things somewhat.  Also, I
wanted to use the base object as a starting point for the "journal", and the
MIME content type for directory information gives a good way to
semi-canonicalize the initial directory object.  Since we're starting from a
MIME object, and you have to have a MIME reader to browse the object, I
don't think that using multipart/signed adds any more complexity to the
journal browser.  For the creation of the signed operation, you only have to
insert the MIME headers and boundary tags, you don't have to translate the
LDAP operation or the computed PKCS #7 signature, just just plop them in
binary.

> 2. How is the signature computed on the Ldap operation?  Do you DER
> encode the operation without the SignedOperation control, compute the
> signature, add the control with signature, then re-encode the operation?
[> ]  I don't think that it matters how you compute the signature on the
operation, since using multipart/signed has the object that was signed right
next to the signature.  So, you don't have to DER encode the operation
before hand.

> 3. What good is the signature if the LDAP server doesn't verify it?  Why
> isn't the LDAP server required to verify the signature?
[> ]  This allows us to keep the bar low for entry here.  I'd certainly
suggest that it would be a good thing that the server verify the signature
on the signed operation.  But, not requiring this allows the server to just
copy in the value of the control.  Also, it doesn't require the LDAP server
know about every possible certificate extension, or the latest variant on
certificate chain validation.  Also, it isn't necessarily important that the
LDAP server be able to verify the signature in the control.  It is important
that the subsequent LDAP clients that are reading the attribute are able to
verify the signature.  The integrity of the operation is guaranteed by the
underlying transport, e.g. TLS.  Thus, there is no need at the application
layer to further guarantee the integrity of the operation (IMHO).
> 4.How about some examples of the Changes attribute?  What does the
> SignedOperation look like?
[> ]  Good suggestion.  Examples will be added to a subsequent version.  The
signed operation looks like the multipart/signed thing above.
> 5. There's no discussion of how this auxiliary class, signedAuditTrail,
> is used.  Does every object modified by a signed operation get a Changes
> attribute?  Does the server maintain the sequence number ?
[> ]  Yes to both questions.
> 6. Is it expected that some LDAP servers would disallow non-signed
> operations?  If so, this should be specified, and there should be a
> root-dse attribute indicating it.  If not, what's the point of signing
> some operations if anyone can come along and undo the changes with an
> unsigned operation?
[> ]  Good points.  Presumably, if an unsigned operation were to come along,
the server could sign the operation itself, in order to guarantee the
continuity of the audit trail.
> 7. signatureSpan seems to be undefined.
> 8. Why do you say "The SignedResult control MUST not be marked
> CRITICAL."?  It seems reasonable for a client to say "If the server
> can't sign it, I don't want it"
[> ]  If the SignedResult were marked critical when it is sent from the LDAP
server to an LDAP client that didn't know about SignedResult's, it would be
forced to disregard the entire LDAPMessage.  But, the client can mark the
DemandSignedResult control as CRITICAL, and the client could gain the result
that you mention.  I was trying to give the results that you were looking
for.  I'll try and remedy the lack of clarity.  I don't know that it is
clear that there are two separate controls being discussed in Section 2.