Russ,
I just recently joined this list, and I am not at all up to speed with the
context, but
I believe that throwing out all Critical attributes, either in certificates or
elsewhere, would be like throwing the baby out with the bath water.
My view of the Critical flag is that it important to protect the interests of
the CA
or the signer of a message, or both, against unwarranted assumptions of
validity made on the basis of software which does not implement some
particular attribute. (Since NONE of the ietf standards in this area have done
a very good job of defining minimally, average, and fully compliant suites of
functions, implementors who cannot swallow everything whole all at once
are forced to pick and choose features without much guidance. And
unfortunately, the one or two ubiquitous browsers end up setting de facto
standards. Hopefully now that Netscape has released their source code
into the public domain, some of these incompatibility issues can be
resolved more quickly.)
In particular, the various constraints, together with the CPS and user notice
fields,
serve a very important purpose -- they are the equivalent of a legal notice or
caveat -- sort of a Miranda warning to the relying party.
In addition to the 'standard' attributes (which are confusing and sometimes
fluid enough), there is also the issue of propritetary attributes which may be
defined by some organization, and may or may not ever be well accepted
by the general vendor population. Without the Critical flag, a user who
believes that some attribute was particuarly important has no legal defense
against a relying party whose software ignores that attribute.
Take a Reliance Limit, of example. I don't intend to get into a debate as to
whether that is a good concept or not, but its use in enshrined in several
state's statutes, and in the forthcoming release of Novell's PKIS (Public Key
Infrastructure Services) product we intend to define and support such an
attribute
under our own OID, unless or until such time as the ietf cares to standardize
such
a use.
The subscriber can either include the attributre or not, and if included, mark
it
Critical or not, recognizing the potential interoperability problems that may
cause.
But if the Reliance Limit is deemed to be quite important for that user's piece
of
mind, interoperability problems IS PRECISELY WHAT IS DESIRED.
If someone's browser doesn't recognize the extension, it should reject the
certificate. The relying party can then decide whether to proceed with the
transaction, but the burden of proof and the burden of liability presumably
will have shifted to the relying party in that case, even if the orignator had
been
unforgivably careless with his keys, for example.
It seems to me that the same would apply to a security label or other construct
in S/MIME. The originator is essentially telling the recipient, and perhaps
more importantly the user's agent, "If you can't understand and agree to my
terms,
don't read, or at least don't believe my message."
I don't see how you can reasonably do without such a construct.
A random poll of ietf attendees is not sufficient justification for removing a
critical
(no pun intended) feature. It IS sufficient justification to demand that we fix
the sloppy syntax and semantics that has been created between the X.509 v3,
PKIX, and S/MIME doucments.
Please pardon my cross-posting to both lists, but I think the issue is
important
to both groups, and I don't know how many people are members of both.
Bob
Russ Housley <housley(_at_)spyrus(_dot_)com> 04/01 7:03 PM >>>
Tim:
Your note has a huge impact. You point out that the message originator
cannot ensure that the recipient will honor any attributbes in SignerInfo,
even if they are marked critical. For example, the recipient can ignore
the critical attribute containing the security label.
Here at the IETF meeting, I have asked several people about the usefulness
of critical attributes. Of the people that I polled, no one supports them.
At this point, I am planning to remove critical attributes from the next
draft of the CMS document.
Russ
At 10:28 AM 3/31/98 +0100, Tim Dean wrote:
Russ,
What happens if a recipient receives a forwarded message that include a
security policy in the eSSSecurityLabel that he/she in does not
understand,
is that still an error?
Absolutely. The security label must be marked critical, so the inability
to process the critical attribute must cause an error to be reported to the
user.
I think the proposed text will mislead implementations to always discarding
the message if a security policy is unknown. I do not think that is right.
We disagree. Rule-based access control cannot be enforced if the recipient
is allowed to ignore the security label.
Two thoughts:
1. Insisting that the UA software parse and understand the label before
showing the message to the user
raises serious denial-of-service issues. There are many circumstances
when operational necessity
demands label-based access control is over-ridden - certainly on reception
in a distributed system.
There are likely to be many, many label formats floating around out there,
and systems should not stop
working just because they don't recognise all of them.
2. I am somewhat doubtful that access control in the recipient's user
agent is going to add a jot of Real
Security in practice. It would surely be extremely unwise to place any
kind of reliance on it. Any
Computer Scientist worth his salt is quickly going to figure how to
by-pass this check and read
everything which arrives in his computer. (And he is probably the kind of
person you didn't want to
unintentionally send a message to anyway!)
Therefore I think I must agree with John R's suggestion on this: or at
least make the it a configurable
option dependent on security policy. Also, ESS should probably contain a
health warning about relying
on recipient side access control processing. By all means check message
labels on transmission and at
points along the path: for example just before the message is about to
exit your organisation. Hopefully
the label semantics are understood at least that far. After that I
suspect it may be too late.
Tim
-----------------------------------------------
Tim Dean
Defence Evaluation & Research Agency
Malvern
United Kingdom
telephone: +44-1684-894239
facsimile: +44-1684-896113
e-mail: t(_dot_)dean(_at_)eris(_dot_)dera(_dot_)gov(_dot_)uk
----------------------------------------------------
John Ross wrote:
What happens if a recipient receives a forwarded message that include a
security policy in the eSSSecurityLabel that he/she in does not understand,
is that still an error?
Absolutely. The security label must be marked critical, so the inability
to process the critical attribute must cause an error to be reported to the
user.
I think the proposed text will mislead implementations to always discarding
the message if a security policy is unknown. I do not think that is right.
We disagree. Rule-based access control cannot be enforced if the recipient
is allowed to ignore the security label.
All I think needs to be done is to leave such decisions to local policy;
Thus reword your text as..
"Receiving agents SHOULD have a local policy which specifies
what action is taken when an eSSSecurityLabel is received which
includes a security-policy-identifier that the processing software
does not recognize."
If think there is a need to specify default handling, then It should be to
ignore security labels when the policy is not understood.
Completely disagree!
Also, I still think that the security policy should not be optional.
Wow. We agree on this one. The syntax that we are using comes from X.411.
In X.411, this field is optional, and we are trying to maintain
compatibility. I suggest that we use english text to state that the
security policy must be present.
-- Russ
Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
bjueneman(_at_)novell(_dot_)com
"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."
"The most dangerous strategy is to cross a chasm in two jumps."