[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: German Key Usage
I think Hans have a very good point here.
It's very unfortunate if PKIX way of defining DS and NR bits differ from
other international activities.
The German signature law and apparently ongoing ISO work (ISO Draft 15782)
is to me example of such unfortunate situations which may cause a lot of
unnecessary confusion.
The problem arises for certificates with DS+NR bits set. May this key pair
be used for automated authentication services? I wouldn't know without
knowing the issuers interpretation of the key usage bits. Bad indeed.
If the original intent in X.509 was to have the nonRepudiation bit as a
service bit to define the interpretation of the DS bit, it might call for
reconsideration of the PKIX definition of the bits.
Would this definition of the DS and NR bits be more appropriate?
The digitalSignature bit is asserted when the subject public key
is used with a digital signature mechanism to support security
services other than certificate signing (bit 5), or revocation
information signing (bit 6). The full meaning of the digital-
signature bit is defined in combination with the nonRepudiation
bit (bit 1).
The nonRepudiation bit is asserted in combination with the digital-
Signature bit (bit 0) when the subject public key is used only
to verify digital signatures used to provide a non-repudiation
service which requires the signing entity's concios acceptance of
the signed message, protecing against the signing entity falsely
denying the message context, excluding certificate or CRL signing.
Pros:
-More consistent with the naming of the bits. (Removes a lot of hard
efforts in explaining why a key can be defined for use with non-repudiation
and at the same time exclude digital signatures. I have had some hard times
here. Haven't you?)
-Definition of non-repudiation based on consious acceptance of the signed
message is more distinguishing from other digital signature services then
purely the falsley denial aspect. The pure falsley denial aspect may very
well be valid for i.e. authentication.
-More consistent with the German signature law and apparently ongoing ISO
work.
-Still possible to combine any set of key usage purposes in certificates.
(DS bit without NR bit embrace all digital signature services)
Cons:
(I really can't come up with any. So please help me here)
I line up behind Hans Nilsson and ask for clarification of the original
intent behind the key usage bits. This must be settled before the draft
turns into an RFC. Maybe a topic for Chicago?
We will have a large meeting on friday where we will try to decide on a key
usage policy for Swedish standardization, so a quick reply before then will
be highly appreciated.
cheers
/Stefan
At 08:30 AM 8/11/98 +0100, Hans Nilsson wrote:
>I am struggling with the question of the usage of the non-Repudiation Key
>Usage bit. In a previous discussion, I claimed that the correct way would be
>to have different keys for Authentication (performed automatically, for
>example SSL client authentication) and Non-Repudiation (for legally binding
>digital signatures, where the user should be made aware of what he is
>signing). For the first key, the digitalSignature bit should be set, and for
>the second key the nonRepudiation bit should be set.
>
>As you all know, the Germans are now writing all the regulations and
>specifications for putting their new Digital Signature Law into effect. They
>have recently published version 2.0 of their Certificate Specifiation, which
>is very thorough and detailed, and can be found at
>http://www.bsi.bund.de/aufgaben/projekte/pbdigsig/download/a1-v2.zip
>
>Regarding Key Usage, they write (my translation):
>
>"The usage of the two bits digitalSignature and nonRepudiation differ in
>such a way that the Authentication process usually is automatic and quite
>frequent, whereas Digital Signatures for binding agreements are performed
>conciously and less frequent by the certificate holder".
>
>They then refer to the ISO Draft 15782 (Banking - Certificate Management
>Part 1: Public Key Certificates) and state that only Combination 2 from that
>specificaction should be used, where BOTH digitalSignature and
>NonRepudiation are set. At the same time, they say that these "User
>certificates shall not be used for Authentication purposes". This is of
>course because their specificaction only concerns certificates for legally
>binding digital signatures, i.e. nonRepudiation.
>
>It is quite evident that they interpret the nonRepudiation bit as an
>ADDITIONAL function for the digitalSignature mechanism, which is quite in
>line with what Denis Pinkas wrote to me earlier:
>---------------------------
>"A long time ago, when participating to the ISO work I advocated for
>the addition the NR bit.
>
>To paraphrase what I already said: the digital signature bit is a
>MECHANISM bit, while the non repudiation bit is a SERVICE bit.
>
>When the digital signature bit is set, it means that the algorithm
>specifies both the hash function and an asymmetric algorithm. In this
>way, you know it is not an encryption key.
>
>If the NR bit is not set, then the signed info is not valid for any
>evidence. The key can however be used for an authentication or an
>integrity service if the bit is set. My own view is that ONE SERVICE bit
>should be set when the digital signature (MECHANISM) bit is set.
>
>Denis"
>----------------------------
>
>Is Denis' and the German interpretation of the nonRepudiation bit right or
>wrong?
>
>I would be very happy if someone who participated in the original writing of
>the X.509 specification could clarify the meaning of the this bit and how it
>should be used. We need to have a common understanding and usage of this!
>
>Regards
>Hans Nilsson
>
>
>
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------