You are viewing a plain text version of this content. The canonical link for it is here.

Posted to kerby@directory.apache.org by "Zheng, Kai" <ka...@intel.com> on 2015/12/13 00:19:44 UTC

About the status of not-so-commons-ssl

Hi,

Is there anyone that knows the incubating status of the not so commons ssl project? I searched quite a while but don't find it.
https://wiki.apache.org/incubator/CommonsSSLProposal

I'm considering how to deal with the forked source codes maintained in pkinit-support branch. This is a thing when merge the branch to trunk.

The options are, either evolving based on our forked base towards the way desired by Kerby or, contribute to the project and push what Kerby desired things into it.

Thanks.

Regards,
Kai

RE: About the status of not-so-commons-ssl

Posted by "Zheng, Kai" <ka...@intel.com>.

Thanks Emmanuel for the asking. Let me extract some texts from here http://www.infoq.com/news/2007/06/not-yet-commons-ssl. 
The following two features are to be leveraged by implementing PKINIT:

    Support more file formats, and support these formats more robustly.

        commons-ssl supports over 50 formats of PKCS8 and OpenSSL Encrypted Private Keys in PEM or DER
        X.509 Certificates can be PEM or DER encoded. Can also come in PKCS7 chains. (To be fair, Java always supported this.)
        PKCS12 files can be in PEM (as created by openssl pkcs12).
        Parsing of Base64-PEM is more tolerant of extra whitespace or comments, especially outside the Base64 sections.

    Automatically detect type of KeyMaterial or TrustMaterial. Consumer does not need to know whether keystore is PKCS12 or JKS. They just need to know the password to decrypt the private key.

Please note: 
1. The not-so-commons-ssl library is AL 2.0 licensed;
2. Kerby avoids the BC dependency in production codes, though users can inject the BC crypto provider themselves;
3. Our version of the SSL library has removed the SSL support part and got away with external dependencies like BC, thus of much less codes now.

Regards,
Kai

-----Original Message-----
From: Emmanuel Lécharny [mailto:elecharny@gmail.com] 
Sent: Sunday, December 13, 2015 12:54 PM
To: Apache Directory Developers List <de...@directory.apache.org>
Subject: Re: About the status of not-so-commons-ssl

Le 13/12/15 00:19, Zheng, Kai a écrit :
> Hi,
>
> Is there anyone that knows the incubating status of the not so commons ssl project? I searched quite a while but don't find it.
> https://wiki.apache.org/incubator/CommonsSSLProposal

6 years old proposal. Dead in the water, IMHO.
>
> I'm considering how to deal with the forked source codes maintained in pkinit-support branch. This is a thing when merge the branch to trunk.
>
> The options are, either evolving based on our forked base towards the way desired by Kerby or, contribute to the project and push what Kerby desired things into it.

What exactly are you using commons-ssl for ? Is there anything you can't do with Bouncy-Castle, which is maintained and AL.2.0 compatible ?

RE: About the status of not-so-commons-ssl

Posted by "Zheng, Kai" <ka...@intel.com>.

Thanks Emmanuel for the asking. Let me extract some texts from here http://www.infoq.com/news/2007/06/not-yet-commons-ssl. 
The following two features are to be leveraged by implementing PKINIT:

    Support more file formats, and support these formats more robustly.

        commons-ssl supports over 50 formats of PKCS8 and OpenSSL Encrypted Private Keys in PEM or DER
        X.509 Certificates can be PEM or DER encoded. Can also come in PKCS7 chains. (To be fair, Java always supported this.)
        PKCS12 files can be in PEM (as created by openssl pkcs12).
        Parsing of Base64-PEM is more tolerant of extra whitespace or comments, especially outside the Base64 sections.

    Automatically detect type of KeyMaterial or TrustMaterial. Consumer does not need to know whether keystore is PKCS12 or JKS. They just need to know the password to decrypt the private key.

Please note: 
1. The not-so-commons-ssl library is AL 2.0 licensed;
2. Kerby avoids the BC dependency in production codes, though users can inject the BC crypto provider themselves;
3. Our version of the SSL library has removed the SSL support part and got away with external dependencies like BC, thus of much less codes now.

Regards,
Kai

-----Original Message-----
From: Emmanuel Lécharny [mailto:elecharny@gmail.com] 
Sent: Sunday, December 13, 2015 12:54 PM
To: Apache Directory Developers List <de...@directory.apache.org>
Subject: Re: About the status of not-so-commons-ssl

Le 13/12/15 00:19, Zheng, Kai a écrit :
> Hi,
>
> Is there anyone that knows the incubating status of the not so commons ssl project? I searched quite a while but don't find it.
> https://wiki.apache.org/incubator/CommonsSSLProposal

6 years old proposal. Dead in the water, IMHO.
>
> I'm considering how to deal with the forked source codes maintained in pkinit-support branch. This is a thing when merge the branch to trunk.
>
> The options are, either evolving based on our forked base towards the way desired by Kerby or, contribute to the project and push what Kerby desired things into it.

What exactly are you using commons-ssl for ? Is there anything you can't do with Bouncy-Castle, which is maintained and AL.2.0 compatible ?

Re: About the status of not-so-commons-ssl

Posted by Emmanuel Lécharny <el...@gmail.com>.

Le 13/12/15 00:19, Zheng, Kai a écrit :
> Hi,
>
> Is there anyone that knows the incubating status of the not so commons ssl project? I searched quite a while but don't find it.
> https://wiki.apache.org/incubator/CommonsSSLProposal

6 years old proposal. Dead in the water, IMHO.
>
> I'm considering how to deal with the forked source codes maintained in pkinit-support branch. This is a thing when merge the branch to trunk.
>
> The options are, either evolving based on our forked base towards the way desired by Kerby or, contribute to the project and push what Kerby desired things into it.

What exactly are you using commons-ssl for ? Is there anything you can't
do with Bouncy-Castle, which is maintained and AL.2.0 compatible ?