[Top] [All Lists]

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

1998-04-14 11:56:13
See my comments in line....
-----Original Message-----
From: John Pawling <jsp(_at_)jgvandyke(_dot_)com>
To: JOHN ROSS <ross(_at_)secstan(_dot_)com>; ietf-smime(_at_)imc(_dot_)org 
Date: Tuesday, April 14, 1998 10:02 AM
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)


My comments regarding access control checks were meant to support my
assertion that multiple different security labels are not required to be
attached to a single content.  I was not implying that my statements should
be incorporated into the ESS I-D.

You stated:
This means that all originators must know all the recipients security
policy. I do not agree that this is practical solution in a global

That is the only solution.  If an originator does not understand the
authorizations of a recipient, then she had better not send a sensitive
message to that recipient.

JR: My point is,  the originating "security domain" needs to make the
if the message can go out of it's security controls and be sent to the
domain, this may be implemented at the point of origination or may be
policed at the domains security guard, either will do.

I think that it is easier to implemented such a facility at a guard, as the
guard is aware
of the boundary security requirements. Where as, the point of origination
will not be aware
of all the various interworking rules at all the boundaries to the secuity
domain .

This assumes that all recipients will understand security labels from all
users in all security domains, and be able to map the security label they
receive to one understood under the local security policy.

That is correct.  If you don't understand somebody else's security policy,
then don't communicate sensitive data with them.

JR: The point is that security policies may be matched at boundaries,
they need not be homogeneous across all domains.

Would it not be
more practical to do that mapping just one at security domain boundary?

I believe that the security label values assigned by the human signer are
sacred and must not be removed, changed, superseded or otherwise corrupted.
The human signer understands the complete context of the message and the
security policy rules that apply to labeling that message.  The human
makes conscious decisions regarding the sensitivity of the content which
be based on subjective or other knowledge that is not available to the
gateway software.  Therefore, I disagree with your implication that a
gateway should change the signer's label or include a translated label

JR: I agree the originators label cannot be changed as that would invalidate
the signature. That is not what is being proposed,
what is being proposed is the ability to add signed labels by security
at domain boundaries. Which label is then used by the recipient is a matter
of local security policy.

the signer's signedData object.  If the gateway wants to add an outer
signedData including a translated label, then that is fine because the GW
the signer of that signedData and can populate the security label with the
appropriate values.  The recipient will be able to easily distinguish
between the GW's outer signedData and human signer's inner signedData.

JR: We agree on this point. But the label added by the gateway may be
different but have equivalent semantic and handling requirement.
For example, if the label has any human semantics it may use a different
language, the orginator uses English, the recipeint French, the gateway
to the French domain adds the French label.

If I understand correctly your main concern, it is the possibility of
inconsistency between semantics of the security label as known and
by the originator and the semantics of other security labels (which may be
added later in the message path).  My view is the semantics of a security
label  and how it is processed on receipt is dictated by the security
in the receiving domain and not the originating domain.

I disagree.  It is a function of all of the security policies involved with
the message transaction.  If a GW strips out the signer's security label
otherwise supersedes it), then the recipient's software never gets a chance
to see the human signer's label.

JR: I agree with you that the originators label is retained with the
message, it must be to preserve the signature, so the recipient
will be able to see the human signer's label.

However, I can predict that there will  be scenarios and security domains
which will strip out all external security at a boundary and re-instate
own,  but that is a different issue and nothing we do can stop that. The
we are discussing is what is sensible to put into the S/MIME

I disagree with all of the following text because it is too detailed for
inclusion in the ESS spec.  This should be up to the local organizations.

I think what you are in fact trying to achieved is a global security
which in itself is a commendable goal.

Possible solution:
I wonder, if one way round this problem be to specify a default security
policy identifier in the S/MIME specifications which implies the policy
have in mind. Which I think is something like : (When an originator uses
this policy id, it implies that the originators policy must be understood
the recipient and supersedes any other security label within the same
data, if the policy id is not understood by the recipient the message
be rejected).

If you make the behaviour rules you are looking for dependant upon the
security policy in the way proposed above, I think the behaviour you are
looking for can be achieved. The above proposal should also meet other
domains needs as well, when other policy ids are used.

Does anybody else have a view?

<Prev in Thread] Current Thread [Next in Thread>