directory-kerby mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zheng, Kai" <kai.zh...@intel.com>
Subject Reconsider how to layout kerby-pkix
Date Wed, 30 Dec 2015 11:53:15 GMT
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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message