[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-cryptoapi
Subject:    Re: Types of signing certificates
From:       Charlie_Kaufman () IRIS ! COM
Date:       1999-02-16 19:59:10
[Download RAW message or body]


>Here is my problem:  I've been talking with various certificate
>authority companies about providing certificates for this system.  They
>would additionally provide cert repository services, etc.  One of them
>is adamant that signing keys/certificates can only be used in very
>particular ways.  He bases this on PKIX documentation.  His list of
>'valid' uses is limited to:
>
>  ...
>

>Why should this be a concern to the CA?  Why does this make for an
>inherently less secure system than the formal protocols listed above?  I
>thought the CA should only be concerned with the procedure for issuing
>the certificate and providing the CRL.  Why should he care how I package
>up the signature and send it to a verifying piece of code?


The answer is part technical and part political/legal/economic.



First, the technical part.



One reason for a certificate (or the hierarchy in which a certificate

lives) to specify allowed key usages is to prevent security breeches

based on using the same key in different incompatible protocols.



For example, if you use an RSA public/private key pair both for the

purpose of signing messages and as part of a challenge-response

protocol in which you prove your identity by signing a challenge, then

an attacker can forge your signature by sending you the message

digest of a message he chooses as a challenge and then tack your

response on as the signature. There are lots of other examples. Most

are theoretical and/or easily remedied if the designers of the two

protocols know about one another. So if a CA creates a certificate

for someone's public key, he is doing both the subject and the

verifier a favor by specifying (or implying somehow) the contexts

in which the key should be used and trusted.



In your case, it is important that the syntax for the messages you

create be easily distinguished from a signature on an S/MIME

message, a response to a challenge in any of the "already approved"

protocols, or any of the formats of anyone else who is

"extending" the use of the key. This could have been easily

remedied if PKCS #1 had included an OID of the key usage in

the signature and encrypted data formats of RSA data (assuming

everyone used PKCS #1), but they didn't.



But the real reason is political/legal/economic.



While people may hide behind the technical justification (or

not understand it and therefore be overzealous), the real

reason is that people see the PKI as a choke point for a lot

of important technology and feel if they can control it, it

will give them a lot of power. Different groups have different

motivations.



Governments think they can enforce GAK (Government

Access to Keys) by requiring that keys used for encryption

have a certificate saying that encryption is allowed and then

by requiring that issuers of those certificates assure that the

keys are escrowed.



Legal types think they can make digital signatures legally

binding by prescribing procedures for the issuance of "signing"

certificates, and that they can enforce their will by threatening

errant CAs with unbounded liability should they issue a

certificate to someone who breaks the rules.



Companies out to make a buck think they can make a lot of

money by issuing limited use (and limited expiration)

certificates because it keeps people coming back for more.

I have heard that some companies have licenses to BSAFE that

prohibit them from issuing certificates for uses outside of

their own applications. I don't know whether this is true, but

it makes sense if you're trying to license the RSA algorithm

separately to every company and every application.

[September 20, 2000 is only 552 days away... mark it on your

calendars].



---------



Bottom line:



Yes, stick to your guns. If you are inventing new syntax, make

it distinctive (either by including something unlikely (like an

OID)) either in the quantity being digested or the quantity

being RSA signed. There may be some CA vendors who are unwilling

(or unable) to deal with you, but you probably couldn't afford

them anyway.



Good Luck!



        --Charlie Kaufman

        (charlie_kaufman@iris.com)

----------------------------------------------------------------
Users Guide http://www.microsoft.com/workshop/essentials/mail.asp
contains important info including how to unsubscribe.  Save time, search
the archives at http://discuss.microsoft.com/archives/index.html

[prev in list] [next in list] [prev in thread] [next in thread]