Re: Authentication vs. binding signature, and ephemeral vs.permanent key usage

Stefan,

Well said.

Dave S.

Stefan Santesson wrote:
> 
> Petra,
> 
> May I suggest some simple truths and some conclusions to that.
> 
> #1) How to interpret key usage bits.
> <snip>Petra:
> >Well, I wouldn't call this a restriction, it only excludes
> >non-repudiation, certificate signing and revocation information
> >signing. The DS bit is definetly not restricted to session-oriented
> >authentication only.
> 
> The major rules are:
> - No usage other than those identified by the key usage bits are allowed.
> - Every key usage bit indicates an _ALLOWED_ key usage for the key (not
> restricted).
> 
> So the implication of this according to the X.509 and the PKIX definitions
> are:
> - If the DS bit is set then "session oriented authentication" is allowed.
> - If NR bit is set then non-repudiation services are allowed.
> - If only DS bit is set then only DS compliant services are allowed.
> - If only NR bit is set then only non-repudiation services are allowed.
> - If NR+DS bit is set (German proposal) then both NR services and "session
> oriented" services are allowed.
> 
> #2) What bits should be set?
> This is only a matter of the CA:s certificate policy. Second it is a matter
> of whether the end entities involved in secure information exchange accepts
> the policy of the CA.
> 
> #3) Who provides non-repudiation services?
> <snip>Petra:
> >In my opinion non-Repudiation is a service offered by a CA - see my
> >answer to Tony's mail.
> 
> A non-repudiation service is established between to end entities. One
> having the role of signing entity and one having the role of relying party
> (for each signature involved).
> 
> When establishing this service these end entities may chose to rely on
> certificates from one or more CA:s but this does not make the CA provider
> of the non-repudiation service.
> 
> #Conclusion:
> <snip> Petra:
> >I think the separation is quite important, but unfortunately it's not
> >defined by now how to separate and distinguish certificates for
> >conscious and unconscious signatures.
> 
> -According to #2, there may be policies where separation is of great
> importance (as in German signature law).
> -According to #1, separation of these keys are fully supported by current
> definitions in X.509 and in PKIX.
> 
> The only problem arises when incompatible interpretations of
> "non-repudiation" leads to unintended usage of the certified key.
> 
> So what help do we have in this except from key usage definitions in X.509
> and PKIX.
> 
> In X.509 Annex B (informative) it is stated:
>   non-repudiation - This service provides proof of the integrity and
>   origin of data - both in an unforgeable relationship - which can be
>   verified by any third party at any time.
> 
> In PKIX it is stated:
>    A certificate user should review the certificate policy generated by
>    the certification authority (CA) before relying on the authentication
>    or non-repudiation services associated with the public key in a par-
>    ticular certificate.  To this end, this standard does not prescribe
>    legally binding rules or duties.
> 
> So according to this the exact properties of the non-repudiation service
> may be stated in the policy. This may also be enough.
> I would, though, not object to a common understanding that "unforgeable
> relationship"[X.509] _DOES_ require the signing entity's conscious
> acceptance of the signed message content.
> 
> /Stefan
> 
> At 05:15 PM 8/21/98 +0200, Petra Glöckner wrote:
> >comments see below...
> >
> >Denis Pinkas wrote:
> >>
> >> Petra,
> >>
> >> I tried to follow the exchanges but they are going rather fast. I picked
> >> your message from yesterday and will use it to reply.
> >>
> >...
> >>
> >> > But I think this definition is not correct. The DS bit is not restricted
> >> > to session-oriented authentication.
> >>
> >> No, it is restricted. The text says:
> >>
> >>       The digitalSignature bit is asserted when the subject public key
> >>       is used with a digital signature mechanism to support security
> >>       services other than non-repudiation (bit 1), certificate signing
> >>       (bit 5), or revocation information signing (bit 6). Digital signa-
> >>       ture mechanisms are often used for entity authentication and data
> >>       origin authentication with integrity.
> >>
> >>       The nonRepudiation bit is asserted when the subject public key is
> >>       used to verify digital signatures used to provide a non-
> >>       repudiation service which protects against the signing entity
> >>       falsely denying some action, excluding certificate or CRL signing.
> >
> >Well, I wouldn't call this a restriction, it only excludes
> >non-repudiation, certificate signing and revocation information
> >signing. The DS bit is definetly not restricted to session-oriented
> >authentication only.
> >
> >> > The DS bit has to be set in a
> >> > certificate used for integrity of an object and authenticity of
> >> > the originator, i.e. for digital signatures in general - no matter
> >> > whether the signing act happens conscious or unconscious and automatic.
> >> > For example to (consciously) sign my email I don't necessarily need to
> >> > have the NR bit set, but I need the DS bit set in my certificate.
> >> >
> >> > NonRepudiation is a service provided by my CA by issuing and archiving
> >> > my certificate.
> >>
> >> No. I would disagree. The CA may do so, but is not in any way obliged to
> >> do so, just because the NR bit is set.
> >
> >so what does it mean if the NR bit is set ? What's the difference to DS
> >?
> >The assumption:
> >       NR is for conscious signatures
> >       DS is for unconscious automatic signatures
> >cannot be based on the pkix draft because it's not defined like that.
> >I'd like to follow this solution but right now the pkix draft does not
> >require the DS bit for unconscious automatic signatures. If everybody
> >interprets the DS bit like that, we should add this requirement to the
> >definition of the DS bit.
> >
> >> > So if a CA issues a certificate containig the NR bit
> >> > it indicates that the certificate and any other information about the
> >> > certificate holder will be archived and will remain available in the
> >> > future beyond certificate expiration.
> >>
> >> This conclusion is based on a wrong assumption, and so is also wrong.
> >> :-(
> >>
> >> > So it's like a regular and a golden credit card: The DS certificate is
> >> > the regular and the NR certificate the golden credit card with extra
> >> > services and additional costs.
> >> > Signatures with a NR certificate will be regarded as more trustworthy
> >> > than signatures with only the DS bit set. Some applications might even
> >> > require a NR certificate.
> >>
> >> I do not follow you on this track.
> >
> >Like Tony proposed, we need to agree on a definition for
> >non-Repudiation.
> >In my opinion non-Repudiation is a service offered by a CA - see my
> >answer to Tony's mail.
> >
> >> > Now the question still remains whether the NR bit has to be set
> >> > exclusivly or combined with the DS bit.
> >>
> >> Yes. This is the question. More precisely: can a certificate have both
> >> bits set, and in such a case what are the implications?
> >>
> >> Note: when a single bit is set, there is no problem.
> >
> >Agreed !
> >
> >> > In my opinion nonRepudiation services require the integrity
> >> > of the message and authenticity of the originator, both provided by the
> >> > digital signature.
> >>
> >> No. Much more than that, e.g. to be sure about the time of the signature
> >> (hence the use of a TSA is a way to address this concern) and to
> >> validate the path against the policy under which the signature was
> >> affixed.
> >
> >So, do you require a timestamp for all signatures with a NR certificate
> >?
> >Will the verification of such a signature fail without a timestamp?
> >The implications on the verification in case of the nonRepudiation bit
> >set in a certificate are not clear to me.
> >
> >> > So the DS bit always needs to be set with the NR bit.
> >> > If the definition of the NR bit will be changed, and it will include
> >> > the integrity and authenticity as well, the NR bit would be sufficient.
> >> > Otherwise both bits need to be set !
> >>
> >> I do not see a need to change the definition.
> >
> >If you look at the big confusion on these keyUsage bits you have to
> >agree,
> >that we cannot leave like that either.
> >
> >> > I think the separation between keys used for conscious and unconscious
> >> > signing has to be placed somewhere else in the certificate, e.g. in the
> >> > extended key usages.
> >>
> >> This is not necessary.
> >
> >What isn't necessary: The separation of keys or to place the seperation
> >somewhere else in the certificate ?
> >I think the separation is quite important, but unfortunately it's not
> >defined by now how to separate and distinguish certificates for
> >conscious
> >and unconscious signatures.
> >
> >> > You shouldn't overload the semantics of the
> >> > keyUsage field ! I'd propose that a certificate to be used for access
> >> > control purposes where your private key is automatically used for
> >> > signing must contain an additional indicator, e.g. another extension.
> >> > Additionally, the DS bit in the keyUsage must be set.
> >> >
> >> > Comments ?
> >>
> >> No change to the current text is needed. However, some clarifications on
> >> that topic might be helpful. If needed, they could be placed in the
> >> "Security consideration section" (section 10 page 67).
> >>
> >> Let me now tackle the previous question:
> >>
> >> Can a certificate have both bits (DS and NR) set, and in such a case
> >> what are the implications?
> >>
> >> In such a case this means that the certificate can be used for both
> >> services. This is economical (one private key and a single certificate)
> >> but can be dangerous, unless such a certificate and the correspondant
> >> private key is only used in well known environments and with well known
> >> protocols that do not suffer from the kind of attack mentioned in the
> >> paper "Protocol Interactions and the Chosen Protocol Attack", recently
> >> advertised on the mailing list.
> >>
> >> A private key whose certificate has the NR bit set must only be used in
> >> well known environments with well known protocols. If the DS bit is also
> >> set, the constraint is extended to plenty of protocols and environments
> >> that may be more difficult to control. As a *very* simple example, an
> >> authentication scheme where I would be invited to sign a 160 bits
> >> challenge would not be acceptable for a certificate where both bits are
> >> set, but quite acceptable if only the DS bit is set.
> >>
> >
> >Some clarification like that should be added to the current text, if all
> >agree on this definition. This would help a lot !
> >
> >Petra
> >Attachment Converted: "c:\internet\eudora\attach\vcard16.vcf"
> >
> >Attachment Converted: "c:\internet\eudora\attach\smime17.p7s"
> >
> -------------------------------------------------------------------
> Stefan Santesson                <stefan@xxxxxxxxxxx>
> 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
> -------------------------------------------------------------------

-- 
David Simonetti, Booz·Allen & Hamilton Inc.