You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Zheng, Kai" <ka...@intel.com> on 2015/12/30 12:57:34 UTC
RE: Reconsider how to layout kerby-pkix
Kindly let me resend this to directory list for broader feedbacks if any. Thanks.
-----Original Message-----
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Wednesday, December 30, 2015 7:53 PM
To: kerby@directory.apache.org
Subject: Reconsider how to layout kerby-pkix
Hi folks,
I'm reconsidering how to layout kerby-pkix because sooner or later we will put more codes into it while implementing PKINIT fully particularly in the RSA case. Eventually we'll get rid of the codes from commons-ssl project and implement our own for the lacked facilities. We'll also try to avoid relying on JRE in the field because we have our own CMS/X509 codes already (CMS not available in JRE) thus we don't want to spend much time to convert back and forth among types from different side. So considering that, we may not want the module become too large in future, and if it has to split then I guess it's better to split it right now, before the release. Below is the layout I propose to use:
Kerby-pkix
-------------pkix-cms
-------------pkix-x509
-------------pkix-pkcs (pkcs8, pkcs12 and etc., now commons-ssl fits here but to be removed out later when not needed any longer)
In the each child module, the defined types are to be there along with relevant logics, algorithms, and supports related to the types.
One thing to worry about is their relationship or dependencies among these children. It looks rather messy in related specs to me, so any insight here?
The kerby-pkix library will stand alone only relying on kerby-asn1 library, not relying on any Kerberos things. Surely kerby-kerb will use it for the PKINIT support.
In future, the resultant kerby-pkix module will serve a complete and standalone library like kerby-kerb and can be used for the PKIX things. People may think this is out of the Kerberos scope, but I would think it's not. Kerby bases it on the Kerberos foundation, but would also support and integrate other authentication mechanisms like token and PKINIT. Purely Kerberos support may not let Kerby go far, IMO.
Thoughts and suggestions are very welcome! Thanks.
Regards,
Kai
Re: Reconsider how to layout kerby-pkix
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 03/01/16 13:44, Zheng, Kai a écrit :
> After some investigation about how to layout the relationships among the children modules, I thought it would be better to do the split after RC2 when we get PKINIT fully implemented and thus have clearer ideas for the kerby-pkix module.
+1 to that.
>
> So for now I only removed the commons-ssl library from the module as cleanup to prepare for the RC2 release.
Okie.
RE: Reconsider how to layout kerby-pkix
Posted by "Zheng, Kai" <ka...@intel.com>.
After some investigation about how to layout the relationships among the children modules, I thought it would be better to do the split after RC2 when we get PKINIT fully implemented and thus have clearer ideas for the kerby-pkix module.
So for now I only removed the commons-ssl library from the module as cleanup to prepare for the RC2 release.
Thanks.
Regards,
Kai
-----Original Message-----
From: Emmanuel Lécharny [mailto:elecharny@gmail.com]
Sent: Wednesday, December 30, 2015 11:46 PM
To: kerby@directory.apache.org
Subject: Re: Reconsider how to layout kerby-pkix
Le 30/12/15 13:52, Zheng, Kai a écrit :
> Thanks for the comment Emmanuel.
>
>>> I would drop the 'pkix-' prefix, assuming the modules will be under the pkix module anyway
> I understand this sounds good in a style (used by Directory main), though Kerby goes in the other, you might check it in the kerby-kerb module and see its children. The style is often seen in other projects, and hard to say which one is better, but one rational for the Kerby style is, the child module may be separately referenced and mentioned by other projects as standalone library so out of the parent context. So I would suggest we use the style consistently.
no problem at all. Go for kerby-xxx.
Re: Reconsider how to layout kerby-pkix
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 30/12/15 13:52, Zheng, Kai a écrit :
> Thanks for the comment Emmanuel.
>
>>> I would drop the 'pkix-' prefix, assuming the modules will be under the pkix module anyway
> I understand this sounds good in a style (used by Directory main), though Kerby goes in the other, you might check it in the kerby-kerb module and see its children. The style is often seen in other projects, and hard to say which one is better, but one rational for the Kerby style is, the child module may be separately referenced and mentioned by other projects as standalone library so out of the parent context. So I would suggest we use the style consistently.
no problem at all. Go for kerby-xxx.
RE: Reconsider how to layout kerby-pkix
Posted by "Zheng, Kai" <ka...@intel.com>.
Thanks for the comment Emmanuel.
>> I would drop the 'pkix-' prefix, assuming the modules will be under the pkix module anyway
I understand this sounds good in a style (used by Directory main), though Kerby goes in the other, you might check it in the kerby-kerb module and see its children. The style is often seen in other projects, and hard to say which one is better, but one rational for the Kerby style is, the child module may be separately referenced and mentioned by other projects as standalone library so out of the parent context. So I would suggest we use the style consistently.
Regards,
Kai
-----Original Message-----
From: Emmanuel Lécharny [mailto:elecharny@gmail.com]
Sent: Wednesday, December 30, 2015 8:09 PM
To: kerby@directory.apache.org
Subject: Re: Reconsider how to layout kerby-pkix
Le 30/12/15 12:57, Zheng, Kai a écrit :
> Kindly let me resend this to directory list for broader feedbacks if any. Thanks.
>
> -----Original Message-----
> From: Zheng, Kai [mailto:kai.zheng@intel.com]
> Sent: Wednesday, December 30, 2015 7:53 PM
> To: kerby@directory.apache.org
> Subject: Reconsider how to layout kerby-pkix
>
> Hi folks,
>
> I'm reconsidering how to layout kerby-pkix because sooner or later we will put more codes into it while implementing PKINIT fully particularly in the RSA case. Eventually we'll get rid of the codes from commons-ssl project and implement our own for the lacked facilities. We'll also try to avoid relying on JRE in the field because we have our own CMS/X509 codes already (CMS not available in JRE) thus we don't want to spend much time to convert back and forth among types from different side. So considering that, we may not want the module become too large in future, and if it has to split then I guess it's better to split it right now, before the release. Below is the layout I propose to use:
> Kerby-pkix
> -------------pkix-cms
> -------------pkix-x509
> -------------pkix-pkcs (pkcs8, pkcs12 and etc., now commons-ssl fits
> here but to be removed out later when not needed any longer)
>
> In the each child module, the defined types are to be there along with relevant logics, algorithms, and supports related to the types.
> One thing to worry about is their relationship or dependencies among these children. It looks rather messy in related specs to me, so any insight here?
> The kerby-pkix library will stand alone only relying on kerby-asn1 library, not relying on any Kerberos things. Surely kerby-kerb will use it for the PKINIT support.
>
> In future, the resultant kerby-pkix module will serve a complete and standalone library like kerby-kerb and can be used for the PKIX things. People may think this is out of the Kerberos scope, but I would think it's not. Kerby bases it on the Kerberos foundation, but would also support and integrate other authentication mechanisms like token and PKINIT. Purely Kerberos support may not let Kerby go far, IMO.
>
> Thoughts and suggestions are very welcome! Thanks.
The suggested structure sounds fine. I would drop the 'pkix-' prefix, assuming the modules will be under the pkix module anyway.
kerby-pkix
|
+-- cms
|
+-- x509
|
+-- pkcs
Re: Reconsider how to layout kerby-pkix
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 30/12/15 12:57, Zheng, Kai a écrit :
> Kindly let me resend this to directory list for broader feedbacks if any. Thanks.
>
> -----Original Message-----
> From: Zheng, Kai [mailto:kai.zheng@intel.com]
> Sent: Wednesday, December 30, 2015 7:53 PM
> To: kerby@directory.apache.org
> Subject: Reconsider how to layout kerby-pkix
>
> Hi folks,
>
> I'm reconsidering how to layout kerby-pkix because sooner or later we will put more codes into it while implementing PKINIT fully particularly in the RSA case. Eventually we'll get rid of the codes from commons-ssl project and implement our own for the lacked facilities. We'll also try to avoid relying on JRE in the field because we have our own CMS/X509 codes already (CMS not available in JRE) thus we don't want to spend much time to convert back and forth among types from different side. So considering that, we may not want the module become too large in future, and if it has to split then I guess it's better to split it right now, before the release. Below is the layout I propose to use:
> Kerby-pkix
> -------------pkix-cms
> -------------pkix-x509
> -------------pkix-pkcs (pkcs8, pkcs12 and etc., now commons-ssl fits here but to be removed out later when not needed any longer)
>
> In the each child module, the defined types are to be there along with relevant logics, algorithms, and supports related to the types.
> One thing to worry about is their relationship or dependencies among these children. It looks rather messy in related specs to me, so any insight here?
> The kerby-pkix library will stand alone only relying on kerby-asn1 library, not relying on any Kerberos things. Surely kerby-kerb will use it for the PKINIT support.
>
> In future, the resultant kerby-pkix module will serve a complete and standalone library like kerby-kerb and can be used for the PKIX things. People may think this is out of the Kerberos scope, but I would think it's not. Kerby bases it on the Kerberos foundation, but would also support and integrate other authentication mechanisms like token and PKINIT. Purely Kerberos support may not let Kerby go far, IMO.
>
> Thoughts and suggestions are very welcome! Thanks.
The suggested structure sounds fine. I would drop the 'pkix-' prefix,
assuming the modules will be under the pkix module anyway.
kerby-pkix
|
+-- cms
|
+-- x509
|
+-- pkcs