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

> As far as I can tell from all the comments on this list the DS bit
> should be used for unconscious signatures (session-oriented 
> authentication applications, e.g. SSL/TLS-like protocols) and the 
> NR bit should be used for conscious signatures (binding signatures, 
> long-term signatures).

The non-repudiation in SSL/TLS/IPSEC is very limited. It is not the 
content of the channel that is signed. There are however circumstances
in which the fact of a communication being made may not be subject
to repudiation. 

For example in a perfect forward secrecy protocol when one party has 
submitted a signed D-H key.

The issue with the non-repudiation bit is slightly different IMHO.
The issue is whether the party which is depending on the certificate
should be allowed to depend on the non-repudiation inherent in the
protocol or not.

For example if I am using a private key to access a Web site via
client auth I might well want to combine that with my encryption
key and have the convenience of a soft certificate, possibly
escrowed, probably with a back up copy of the private key on
a floppy.

I might very well take the view that when others are going to depend
upon the non-repudiation properties of a certificate that the key should
be held on some form of secure hardware, and quite likely generated
internally, never to leave it.


Since the cost of making sure that a protocol is inherently repudiable
is high I think it is quite reasonable to distinguish between the
two uses.

It also seems quite reasonable to allow the use of a very high security
key to be explicitly resricted to those cases where non-repudiation
is required.

I don't see any reason for inserting additional text into the
profile to mandate DS be always set with NR.


On the other hand the S/MIME and TLS specifications should be very
specific about the key usage bits which MUST be set or clear
for certain operations to be performed.

In summary this is a very important issue but this is not the place
to address it. The semantics of the key usage bits will be 
pragmatically defined by applications. 


                Phill

smime.p7s
Description: S/MIME cryptographic signature