I am happy with your proposal.
From: William Ottaway <w(_dot_)ottaway(_at_)eris(_dot_)dera(_dot_)gov(_dot_)uk>
To: ietf-smime(_at_)imc(_dot_)org <ietf-smime(_at_)imc(_dot_)org>
Date: Tuesday, April 14, 1998 10:24 AM
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
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
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?
I like this idea of having a default security policy. However, if the
policy is not understood by the recipient the outcome is down to the
recipients security policy. This may result in the message being rejected,
as you suggested, or it may allow the message through but with some
indication that the policy was not understood.
I deliberately referred to "security policy" rather that "security policy
identifier" because I'm not sure that an identifier is required.
Here is my stab at it:
Lets say that a default security policy is stated within SMIME. This policy
will describe a set of eSSSecurityLabel values which can be used in the
majority of general messaging cases.
Now an originator has the choice of using the default policy or some other
policy. This other policy may have additional labels to those in the
default or it may use totally different ones. The non default policy should
only be used when communicating with a recipient which understands this
policy. In all other cases the default should be used.
What a recipient does when he receives SMIME must be covered by that
recipients policy. A typical scenario would be that when an unknown
eSSSecurityLabel is received it is rejected. The recipient does not need to
know what security policy is being used, it just needs to be able to act on
The advantage of having a default policy is in mapping. If a recipient uses
different eSSSecurityLabel internally to the default then incoming default
SMIME eSSSecurityLabel values can be mapped, at the boundary, onto the
domains own labels.
I appologise if I have just reworded the original solution.
William Ottaway, Tel: +44 (0)1684 894079
DERA Malvern, Fax: +44 (0)1684 896113
St. Andrews Road, email:
Worcs, WR14 3PS