>From: "warwick (w.s.) ford" <wford(_at_)bnr(_dot_)ca>
>Subject: Re: X.509 v3 Standard Extensions PDAM
>Date: Tue, 31 Jan 1995 13:15:00 -0500
>Peter:
>
>If bits were added to CAKeyUsage for "transactionKeyEncipherment" and
>"transactionKeyAgreement", would this satisfy your requirement? This would
seem
>reasonable to me.
>
>Warwick
Yes. Thanks. This cleans up matters for the case where a CA's signing
key is also used to support key exchange and/or agreement. This is the
case for 1422. A given CA will have multiple signing keys, depending
upon the number of PCA domains in lies within. its now possible
for a CA subscriber to select one which may be used in transacting
private business with that CA.
General comment on the v3 spec, open to debate, rather than need
for obvious change.
I note another issue with the model, related to Russ' domain,
but also related to 1422:-
the KeyAttributes such as those above are advisory only, assisting key
selection; mandatory requirements for key usage must be expressed
through the primaryKeyUsageRestriction extension, or the
keyUsageRestriction field of the OtherPublicKeyInfo syntax.
For the DMS policy requirement for KEA and DSS keypairs, Russ
mentioned, unlike for the primaryKeyRestrictions, the whole
otherPublicKey extension is always non-critical. Thus the policy notion
of a CA requiring use of the certified otherPublicKey for a given
purpose, is not _practically_ mandatory. this is a failure to address
requirement 12.2.1 (f).
I forsee therefore a need to have a otherKeyRestriction extension which is
critical, and this mechanism is distinct from the otherPublicKey
extension. Alternative kludges are available, but, there will be dependence on
local policy rule processing which is contrary to requirement of 12.5.1
(e).
This general issue is compounded by the fact that the text requires
mandatory policy notions expressed through primaryKeyRestrictions (and
ambiguously for otherPublicKeyRestrictions also)
to hold for all certificates within the jurisdiction. I assume, therefore,
that subordinate certificates need not explicitely represent the
policy indication, though must conform to it, given this rule.
This is ok in a 1422 world, where unique trust paths are guaranteed by
careful design of who may sign who, and the uniqueness of CA keys and
CA/end-entity identifiers and certificates. But X.509 does not require such an
organization, yet seems to require in some cases the properties of
unique paths faciliated by such a careful organiation by the combination of
rules of 12.2.2.4 and 12.5.1 (c)
Peter.