Shifting around the risk burden, Re: Consensus Text for key usage?

[Ed Gerck <egerck@xxxxxxx>]

Denis:

My disagreement with you is not a matter of
opinion, but in basics. What you propose is
outside the scope of X.509.  Section 1 states
(my inserted *):

 Authentication (and other security services [including
 thus non-repudiation]) can only be provided within
 the context of a defined security policy. It is a matter for
 users of an application to define *their own* security
 policy which may be *constrained* by the services
 provided by a standard.

Further, the general scope of X.509 is *authentication*,
the verification of user credentials. What the user signs
with those credentials is outside the scope of X.509  --
the user is in no way constrained on the content, meaning
or legal implications of what is signed.

So, PKIX MAY constrain the security policies that users
can define but PKIX MUST NOT define that security
policy, NOR what it must include, NOR the legal or otherwise
any implication of what is signed.  PKIX  MAY only say
what a user's security policy MUST NOT allow -- and even
so, ONLY in regard to the scope of PKIX (authentication of
user credentials).

And, this makes pretty good sense. Why should it be
desirable, as you wish, for PKIX to impose upon
users the non-technical burden of risk for the *data*
signed with  a key when X.509 is moot on what is signed
and even on how users should verify what is signed prior
to signing?  And, what does this have to do with security
considerations on *private-keys* in PKIX -- are you really
still constraining user security policies for keys when you
set a mock criminal code  for data that is signed by keys?
After all, PKIX *refuses* to warn CAs on *any* security
risks in that very same NR security discussion you propose --
and thus CAs can become the back-door of user security
if one follows what you suggest and shift the burden of risk
100% to the user.

So, following your suggested additions and forceful defense
of them, I am forced to conclude that even though PKIX is not
willing to trust users to take the necessary precautions, it
does expect them to take the risk of failing to take the
precautions. Is this a fair conclusion?

Your suggestion is therefore: (i) not in accord with X.509
design framework (Section 1) and, (ii) does not allow
risk to be well balanced between user and CA.  In
effect, your suggestion *interferes* with the CA-user
relationship -- which is hands-off by design in X.509,
and intends to *impose* rules on the consequences
of content signed by users -- which is clearly outside
the scope of X.509.

Further, what you propose would amount to an
overreaching security policy set by PKIX over *all*
users, while any  CA is free to do whatever they
want and even to treat different users differently.

Note also that X.509 refrains from setting security
policies even for user identification (this is also
in accord with X.509 Section 1 cited above).  For
example, X.509 Section 11.2.a states that: "a
certification authority shall be satisfied of the
identity of a user before creating a certificate for
it",  which means that identity validation procedures
are to be satisfied in the CA's frame of reference by
following the CA's own rules (CPS), which are
declared outside the scope of X.509 and can be
entirely different for different CAs and even for
different users in the same CA.

So, what is this all about? It is about NOT including the
following text segments in PKIX security discussions,
for the reasons inlined:

1. NOT include:
 When such a  certificate [with NR bit set] is delivered, it
 implies that the owner of the corresponding private key
 should be warned that, in the event of a dispute, he may
 be held responsible of the data signed with this  key.

REASON:  Setting user's security policy on the data
*signed* by the user is outside the scope of PKIX.
The text seems to intend to allow CAs to hide behind
PKIX in order to impose upon users a burden which
not even CAs accept for the data they sign with their
own key.  Obviously, this would be unfair and is not
what this WG should recommend.

2. NOT include:
 If a certificate has both the digitalSignature and the
 nonRepudiation bit set, the owner of the private key
 should make sure that all the environments and
 applications where the corresponding private key is
 being used do not allow a misuse of that private key.

REASON: Obviously impossible -- the user has no way of
knowing that *all* the environments and applications where the
corresponding private key is being used do not allow a misuse of
that private key.  Further, setting user's security policy is outside
the scope of PKIX -- especially so in *applications*.

3. NOT include:
 If that confidence can only be obtained in some
 environments, two different certificates, one with one public
 key and the digitalSignature bit set and another one with a
 different public key and the nonRepudiation bit set, should be
 used, so that the private key corresponding to the certificate
 with the nonRepudiation bit set is only used in secure
 environments.

REASON: Obviously, the private key corresponding to any
certificate [not only NR] should only used in secure
environments, where "secure" is a concept relative to risk
and cost.  Besides, X.509 *already* says this in "One of the
basic principles of strong authentication is that the user’s
private key remain secure. A number of practical methods
are available for the user to hold his private key in a
manner that provides adequate security".

Cheers,

Ed Gerck

PS: My early attempt to "save" some of your suggestions by
editing them to be in accord with X.509's factual text has
been unfruitful. Therefore, it seems better to me to just
delete them. This is however a matter of opinion and I would
welcome (as a second option) that number (2) and (3) be
edited. However, I see nothing of substance that would be
left if (1) is edited to reflect X.509 as an authentication spec,
not a one-sided surreptitious criminal code on content
signed -- as currently implied by it.