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

Hi David,

>Aram,
>
>Aram Perez wrote:
>> 
>> Hi David,
>> 
>> See my questions below:
>> 
>> >Aram Perez wrote:
>> ><snip>
>> >>     3) It is not clear to me who determines the value of the keyUsage 
>> >> field.
>> >> Does the CA arbitrarily assigned it, or do I specify the field in the
>> >> certificate request? And if non-repudiation is a CA service, how do I 
>> >> know the
>> >> CA will set the NR bit?
>> >
>> >The CA will insert whatever the subject, or the organization granting
>> >the subject the certificate, has contracted with the CA to insert,
>> >assuming the subject meets applicable requirements for the cert.
>> 
>> When I go to the VeriSign site and apply for either a Class 1 or Class 2
>> certificate, I see no place where I can tell VeriSign that I want the NR bit
>> set. And how people are going to read 116 pages of VeriSign's CSP?
>
>I won't vouch for any particular vendor, but I would suspect that any CA
>that you contract with will create certificates that meet your needs. 
>If they won't, then find another CA.

What do you mean by "any CA that you contract with"? Today I can go to VeriSign
and for either $10 (class 1) or $20 (class 2) per year, I can get a certificate.
 When I get the certificate, did I "contract with VeriSign"? And if I did, how
do I can tell Verisign to set the NR bit? It's not on any other the sign up
forms that I have seen.

>
>> 
>> >>
>> >>     4) How is the private key involved? What happens if the corresponding
>> >> certificate has the NR bit set but I use the private key to sign an 
>> >> ephemeral
>> >> object? Ditto for having the NR bit NOT set but I use the private key to 
>> >> do a
>> >> "conscious" signature?
>> >
>> >If the extension is "critical" and the key is not used in a manner
>> >appropriate to its indication, the processing application (recipient)
>> >should reject the transaction.
>> 
>> It appears that you are assuming that signing function accepts the 
>> certificate
>> as a parameter. I know of no cryptographic API that takes a certificate as a
>> parameter to a sign (or even verify) operation. All of the APIs I know (which
>> may be a limited set), always take a private key for signing and a public key
>> for verifying. None of them take a certificate.
>
>If you are verifying a digital signature, I am certainly assuming the
>use of a public key.  Whether the public key is transferred in the
>protocol, retrieved from an X.500 Directory, or queried from a
>relational database, a certificate is the accepted method for conveying
>the public key.  If we are not discussing public key certificates here,
>then our discussion is useless.

I agree that we are discussing public key certificates here. But my original
question was "How is the use of the public key in the certificate related to the
use (or misuse) of the corresponding private key?" Assuming that
"non-repudiation" is a service, how can a CA offer that service when it has no
control over the use (or misuse) of the private key?

Regards,
Aram Perez
Apple Computer, Inc.