[kmf-discuss] kmf pktool

Wyllys Ingersoll wyllys.ingersoll at sun.com
Fri Jan 4 13:23:26 PST 2008


David Major wrote:
> Wyllys Ingersoll wrote:
>   
>> David -
>>
>> I'm adding kmf-discuss to the CC list.  Response below...
>>
>>
>>
>> David Major wrote:
>>
>>     
>>> Hi Wyllys,
>>>
>>> We are really new to PKI.
>>>
>>> We are working on a data archiving project which requires SSLv3.
>>>
>>> 	http://www.opensolaris.org/os/project/mms/whatis/
>>>
>>> We are currently using OpenSSL with DSA certs.
>>>       
>> Why DSA?  
>>     
>
> MMS is based on several IEEE 1244 specs.
>
> The IEEE standard 1244.2-2000 for Media Management Systems (MMS) Session
> Security, Authentication, Initialization Protocol (SSAIP) calls out
> using SHA1 to sign messages. According to the O'Reilly "Network Security
> with OpenSSL" book RSA does not support SHA1/DSS1. To keep it simple, I
> assumed DSA keys were needed so why not use DSA certificates. I also
> assume RSA had a patent on it until the year 2000 and the IEEE spec was
> published in 2000.
>   

You can have SHA1 signatures with an RSA key/cert, it is pretty common.  
DSS, though,
not so much.  RSA certs can have SHA1 or MD5 signatures, when you use 
DSA, you are
limited to SHA1 - at least insofar as the KMF support goes.  There are 
probably other combinations,
but we just used the most common ones.

> KMF has support for DSA, but it hasn't been tested nearly
>   
>> as well as RSA.
>>     
>
> We'll also need to store the server's DH and dsa parameters in KMF.
> Another assumption we made is all DSA certs are generated using the same
> dsa parameters.
>   

The DSA parameters are encoded in the cert along with the public key 
information.   DH
parameters are not (I don't think).


>>> It seems (I feel) most applications are adding certificates to the
>>> server and skipping getting the certificate request signed by the CA. Is
>>> it valid to use certificates not signed by at least a self-signed
>>> certificate authority or does pktool provide that function?
>>>       
>> No it is not secure or useful to have a certificate that is not signed. 
>> In fact, it is not a certificate at all until it has a signature, even
>> if it is only self-signed.   Most security experts frown on the use of
>> self-signed certs in favor of actually getting them signed by a CA
>> which will manage the revocation lists properly.
>>
>>     
>
> I did not see the value in it either, for example mercurial uses
> ssh-keygen certs which I heard is bad practice to use other applications
> certificate handling...
>   

The only problem with the above is that ssh-keygen is only creating 
self-signed certs,
there is no CA involved that can manage the certs and keys being used.

> You'd have to get a mercurial account from Jon first.  To do that, you
> need to generate an ssh key via
> $ ssh-keygen -t dsa*
> *Then send Jon the ~/.ssh/id_dsa.pub and he'll be able to set it up for you
> After you authorization, the rest is pretty simple.
>
>   

I have a DSA cert that I've used with mercurial before.


>>> Can we use KMF across the network to get at a self-signed CA CRL?
>>>       
>> KMF can retrieve CRLs  and certificates across the network.  See the
>> "kmf_download_crl" and "kmf_download_cert" functions documented here:
>> http://opensolaris.org/os/project/kmf/files/KMFAPI_Reference.pdf
>>
>> What you may really want is the "kmf_validate_cert" function (also
>> documented above). I don't know of any real-world apps that use these
>> functions yet, but they have been tested.
>>     
>
> Ok, the IEEE SSAIP spec allows for the hello command and welcome
> commands to pass a certificate and an authentication message to valid
> its peer on a non-SSL/SSL connection. We are thinking about using
> two-authentication and possibly client authentication of the server's
> certificate. We currently use the OpenSSL
> SSL_CTX_use_certificate_chain_file() and X509_verify_cert() group of
> functions for peer verification and revoked cert check.
>   
I believe that should work ok.

-Wyllys



More information about the kmf-discuss mailing list