The problem with trying to define a default security policy is getting
everybody to agree on the semantics of the security-classification and
security-category values. The X.411 editors attempted to define a default
secuirty policy by defining standard security-classification values. The
problem is that no two organizations can agree on what those
security-classifcation values really mean. Each organization demands the
right to specify their own security rules. In summary, I believe that the
definition of a default security policy is way beyond the scope of the
- John Pawling
At 06:00 PM 4/14/98 +0100, William Ottaway wrote:
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 you
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 by
the recipient and supersedes any other security label within the same signed
data, if the policy id is not understood by the recipient the message shall
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