ietf-smime
[Top] [All Lists]

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

1998-03-27 21:15:53
John Pawling wrote:

Chris,

I respectfully disagree with your proposal.  The two different labels that
you require can be implemented by including each label in a separate
signedData layer of the message.  The original signer could include the
"information label" in the original, inner signedData layer.  The "system
label" could be included in an outer signedData layer that encapsulates the
original, inner signedData layer.  This is the optimal strategy because the
recipient MUST make a separate access control decision for each of the
signedData layers.

John,

    This is a GROSSLY inefficient means of addressing this requirement.  In the 
common case where both labels are applied by the originating user, this means 
double signature generation operations, double signature verification 
operations, plus a bunch of extra attribute and ASN.1 overhead.  All that is 
required to address this is either:

        a)    An identical label attribute, with a distinct OID.
               Said attribute to be ignored for the purpose of
               access control.

        b)    A more complex structure WITHIN the existing
                label attribute that would allow the information
                label to be conveyed (and ignored).

What I proposed in my original submission was (b) above, but I really don't 
have a strong preference.

    Also, applying an access control check for the information label is not 
required or even useful.  In the system-high scenario to which this applies, 
the information security label will always be dominated by the system security 
label.


The recipient MUST process the eSSSecurityLabel in each
signedData object that it verifies.  Because the recipient will verify both
the outer and inner signedData objects, then it MUST process the
eSSSecurityLabel attribute in each of the signedData objects.  Therefore,
both the "system" and "information" eSSSecurityLabels are processed by the
recipient.  An important point to note is that the recipient software makes
a separate access control decision for each signedData object.  IMHO, that
is the primary difference between processing
eSSSecurityLabels included in layered signedData objects versus those
included in multiple signerInfos included in the same signedData object.

    I am not even convinced that you need to have the two labels in different 
signerInfo elements.  Provided that they are both applied by the originator, 
then there is no need for a second signature.

In the latter case, all eSSSecurityLabels included in the various signerInfos
(that are verified) are checked as part of the same cumulative access
control decision process applied to the individual signedData object.  If
multiple eSSSecurityLabels were allowed in the same signerInfo or same
signedData, then there would be mass confusion and room for contradiction
when different labels are processed by the recipient as part of the same
cumulative access control decision applied to the individual signedData
object.

    Again, you are assuming that the information label would be part of the 
ACDF.  I'm not convinced that this is necessary.

I believe that it is impractical to try to force the S/MIME
community into accepting a complicated access control decision strategy such
as would be required to define the rules to process multiple
eSSSecurityLabels included in the same signerInfo or same signedData.

IMHO, the cost in efficiency of requiring nested signedData objects to
convey multiple, different eSSSecurityLabels is well worth the clarity gained.

In summary, I believe that the ESSSecurityLabel should remain as is.

Chris sends...