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
