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:[email protected]] Sent: Wednesday, December 30, 2015 8:09 PM To: [email protected] 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:[email protected]] > Sent: Wednesday, December 30, 2015 7:53 PM > To: [email protected] > 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
