ietf-smime
[Top] [All Lists]

Re: Signed Label (was RE: 'Signature Purpose' attribute?)

1998-04-13 05:39:48
From: jsp(_at_)jgvandyke(_dot_)com (John Pawling)

Chris,

I still respectfully disagree with your proposal.  I admit that the layering
of the signedData objects does add bytes to the wire, but the price paid is
well worth the benefit of ensuring that there are not inconsistent or
contradictory ESSSecurityLabels applied to the same content.  Mandating that
all ESSSecurityLabels included in a single signedData must be identical
ensures that all ESSSecurityLabels applied to a content are consistent.
This ensures that there is no confusion regarding the sensitivity of the
content and that an access control decision can be made in an unambiguous
manner.


John,

  A few weeks ago I agreed with your position (that distinct labels
must appear only in distinct SignedData's), but I have since been
convinced that this provides little or no benefit.

The only cryptographic result of nesting SignedDatas is that the outer
signer (e.g. a gateway) binds the inner label to the inner content; AFAIK
there is no user requirement to provide this function.  You cite the
access control requirement, which is of course not satisfied by
SignedData nesting any more than it is by using parallel SignerInfos,
and is therefore not an argument for or against either method.  Any
access control rule operating on nested signatures will pass or fail
each signature in turn, working from outermost to innermost.  Any access
control rule operating on parallel signatures will pass or fail each
signature, but the order of processing is not necessarily specified.
The end result in either case is an AND of all the individual decisions,
which doesn't depend on the order of evaluation.  And in both cases,
each label is uniquely tied to the signer which applied it.

If someone comes up with a real requirement to specify an order in
which signatures are applied to a content, then as Chris said, a less
inefficient and inflexible means of satisfying it (for example an integer
"precedence" field in the label attribute, or a SignaturePurpose
attribute) should be used.

If there is a real requirement for an outer signer to bind inner
signatures to content, then nested SignedDatas can be used.  But ESS,
by imposing an arbitrary restriction of label equality, should not
force nesting when it is not otherwise required.

Dave Kemp