>From: solo(_at_)BBN(_dot_)COM
>Subject: Re: X.509 v3 Standard Extensions PDAM
>Date: Fri, 10 Feb 95 09:29:02 -0500
>
>Peter,
>
>It is interesting that we are drawing notably different
>conclusions on the intent of some of the policy capabilities
>of the certificate PDAM.
Thanks Dave.
>I think the basis of our disagreement is that you are coupling
>usage information (which I view as guidance) with authorization
>management (which I believe is external to the certificate).
Its this word "usage" which is so problematic.
In various portions of the PDAM mechanisms are introduced to indicate
intent or constrain usage.
1) Usage - as in security mechanism - is hinted at in the KeyUsage
field; the notion is one of "approval".
2) Usage - as in acceptable confidence level indication for the
bindings - is constrained by the policy-identifier
3) Usage - as in application purpose - is also possibly constained by
the policy-identifier.
Lets consider the possible ambiguity of (3) Ive raised.
Now to authorization information. Of course, this is distinct, when
one consider well-understood schemes likes PACs and clearances.
But take the example of DMS - its "privilege" fields indicates
mandatory DMS MESSAGING APPLICATION constraints. Fred cannot
rekey MTAs, fred cannot be an organization-signer, fred can
read his bosses mail when boss is on vacation, fred can sign
messages individually.
Im assuming that these MSP/DMS specific indications are examples
of usage class 3. If I am Fred, the secretary of General Freda, perhaps
authorization controls will constrain me further to only be
able to read only her unclassified mail in her absence. But this
is a constraint indicated by other than type 3 usage constraints.
Now, its the privilege notion as application-specific authorization
control, which Im finding confusing: do I use (3) for this function, or
not. Or is this another private extension. If I do, (and if this is
consistent with the intent of the mechanism) then Im hoping to use the
Qualifier field in the policy-indication to bear this signal. "Yes,
subject may do anything a person with a high-assurance key binding may
do with such a credential, but note this generality is then qualified
specifically to policy/application-defined functions X,Y and Z."
Now one can defined n OIDs to represent each application-level
policy-sub-defined function; however this seems clumsy.