[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Consensus Text for key usage?
Ed,
> Tim Polk wrote:
>
> > There are two pieces of proposed text; text for the key usage extension
> > and text for the security considerations section.
> >
> > 4.2.1.3 Key Usage
> >
>
> No comments. The key usage text looks fine.
Good ! (pending a small change requested by Aram which seems quite
reasonable).
> > --- proposed new paragraphs for Security Considerations section
>
> Here, I have some comments.
>
> > A CA may include the key usage extension and assert the
> > nonRepudiation bit when issuing a certificate.
>
> This part is fine.
>
> > When such a
> > certificate 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.
> I am not in favor of this entire sentence. It fixes a context for the
> NR bit which *contradicts* the key usage section (for example: "A
> signature policy identifier embedded in the signed data MAY be used to
> explicitly provide context.") and it unduly imposes upon the owner
> of the private key a duty which the signer herself (the CA, that elusive lady)
> refrains from, for example: in the case of virus, fraud, etc,. These are valid
> cases and if they would be reflected in the text, we would have a repeat of a
> CA's CPS, I am afraid.
> So, "when such a certificate is delivered, it implies that" is not a matter to
> be solved here. Rather it MAY be solved in a signature policy identifier
> embedded in the signed data, it MAY be solved in the CA's CPS, etc., all
> as already predicated in PKIX.
> Suggestion: delete the sentence.
This is the implication of that bit, as far as the user is
concerned. Your argumentation saying that "it MAY be solved in a
signature policy identifier embedded in the signed data, it MAY be
solved in the CA's CPS, etc" is not valid. If I re-use the example I
used during my presenation at the last PKIX session in Washington,
the user should really be warned, e.g. not to insert his key in an
unknown door lock so that instead of getting the door opened he
unknowingly signs a check of 5.000 $. There may be alternatives to
the proposed wording, but the warning should be kept. Do not forget
that this belongs to the security considerations section, where
warnings are fully appropriate.
> > 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.
>
> I am not in favor of this entire sequence. It is not realistic that the
> owner of the private key "should make sure that all the
> environments and applications where the corresponding private key is
> being used" is anything. The most we can ask is a reasonable effort,
> which may not be much in the case of virus, fraud, theft, etc. To say
> otherwise is to put on the certificate subject's a burden which not even
> highly-qualified CAs want to shoulder.
>
> Suggestion: A toned-down statement might be useful, such as:
>
> If a certificate has both the digitalSignature and the
> nonRepudiation bit set, the private key owner should take
> justified measures to prevent a misuse of that private key.
I think your sentence creates more problems than the original one.
Some people might argument: what means a "justified measure" ? The
original sentence should be kept.
> Of course, "justified measures" are commensurate to cost and risk,
> which means that the above statement is even more effective than
> the original to define what the keyholder's responsibilities are (for
> example, a private key used to sign money transfer justifies a
> need for more precautions than a private key used to sign email messages
> in a mailing list) -- and avoids the trap of requiring the whole world
> to be secure. An untainable goal, which could easily make the original
> clause moot by excessive requirements (not even CAs can do this).
>
> Note: I have, on purpose, avoided the terms "reasonable measures"
> because reasonableness may be difficult to define in the technical
> sense, while a justification can be a letter from the ISP on which
> one relies upon without (usually) further checking.
>
> > 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.
>
> I am not in favor of this addition, which seems obvious (do not set the
> NR bit unless you want to set the NR bit), costly (two certificates) and
> unnecessary -- since I can use only one certificate with the NR bit set
> and deny NR directly in the signed data, case by case (NR opt out mode).
> Or, I can use only one certificate with the NR bit off and grant NR directly
> in the signed data, case by case (NR opt in mode).
>
> If one thinks though that saying something is necessary, I suggest, in
> agreement with the change proposed above:
>
> If the private key owner can only prevent misuse in some environments,
> then it is possible to use a certificate with the nonRepudiation bit
> set and deny non-repudiation in the signed data, case by case (NR opt
> out mode); or use a certificate with the nonRepudiation bit off and
> grant non-repudiation in the signed data, case by case (NR opt in
> mode); or use 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; or use another method that could
> be justified, so that the private key corresponding to the certificate
> with the nonRepudiation bit set is not used in environments that may
> either not conform to a non-repudiation signature policy, or be unknown.
Your proposed text is much more complicated to follow (and longer)
than the original one. It introduces notions which are not explained
in that document e.g. "NR opt out mode" ?!?" and "NR opt in mode"
?!? is also incorrect on several aspects; e.g. you said: " If the
private key owner can only prevent misuse in some environments, then
it is possible to use a certificate with the nonRepudiation bit set
[...] case by case". I do not think that the user, in *any* case,
should use (the corresponding private key of) a certificate with the
nonRepudiation bit set, if he cannot prevent the misuse of his
private key.
Tim, the editor, could apparently live with the original proposal.
Let us keep the original text, if you can also "live with it". :-)
Regards,
Denis
> Cheers,
>
> Ed Gerck