[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Consensus Text for key usage?
Ed,
I would like to leave the bandwith of the PKIX mailing list for
other topics and thus I am not going to argument for ever on that
topic. So, (I do hope that) this is my last reply to you on that
topic and I let Tim, the editor, take the final decision.
> > > > 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.
> > ....
> > > Suggestion: delete the sentence.
> >
> > 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 $.
>
> Or not. It depends on the CA's CPS, on what is disclaimed by the user
> in the signed data, etc. My objection to that text segment is that PKIX
> is not the party that should "warn" the user of anything, or mandate that
> the user "should be warned" -- such "warning" is outside the scope of
> PKIX in the same way that the CPS is outside the scope of PKIX.
Your two arguments can be refuted:
1) CA's CPS will say that key that has the NR bit set has NR
properties for everything signed with that key.
So if someting is maliciously signed, it becomes rather hard for the
user to say that it was maliciously obtained. He has to make sure
that nothing can be maliciously signed using that key. The
environment where the key is being used should have a "What You See
Is What You Sign" (WYSIWYS) property.
2) In the example no disclaimer can be placed by the user because he
does not know what he signs while opening the door.
So we currently end up with a simple conclusion: we simply disagree.
> > 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.
>
> But not for warnings that lie outside the scope of PKIX. For example, the
> user is not warned to set the date correctly in his computer -- and yet,
> setting a wrong date may make an expired certificate, valid. The
> justification/negation of user actions, or lack of actions, lie outside the
> scope of PKIX in the same way that justification of CA's actions are not
> the concern of PKIX.
I would have no problem to extend warnings to the case you describe.
So I do not take this as an argument.
> > > > 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.
> > >....
> > > 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.
>
> Your point is well taken. Perhaps an even more toned-down note would
> be useful, for example:
>
> If a certificate has both the digitalSignature and the
> nonRepudiation bit set, the private key owner should take
> measures to prevent a misuse of that private key.
Your proposal is missing the fact that the measures are related to
the environments where the key is being used. It may be sufficiently
explicit for you, but it would become hard to understand for the
novice.
> where not even justification is predicated -- leaving the user
> responsible for deciding "how", while PKIX clearly warns
> about "what" should be protected when the NR and DS bits
> are set.
>
> > > > 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
> > ....
> > > If one thinks though that saying something is necessary, I suggest, in
> > > agreement with the change proposed above:
> > >...
> >
> > Your proposed text is much more complicated to follow (and longer)
> > than the original one.
>
> Your point is well taken. I go back to my first suggestion to simply delete
> the addition. Seems less confusing at this time.
You cannot say above " this addition [...] seems obvious " and a few
lines later "delete the addition. Seems less confusing at this
time". It cannot be both obvious and confusing.
Ed, I have done my best to answer your E-mails. We cannot argument
for ever.
Tim, the final decision is yours.
Regards,
Denis
> Cheers,
>
> Ed Gerck