Hi, Alex. Sorry, I cannot get into this explanation:
>> To public the certificate somewhere else >> (not in the place defined by its DN) >> the special attribute DirName was used in OpenCA. >> It seems to me that the right way is to fill that attribute (DirName) >> with the proper DN while creating the certificate. > I disagree. The DirName in our case (and I guess this is a pretty > "normal" situation) would depend on the certificate DN and a search in > the directory itself (so say the CN is a unique identifier within a > directory, one could find the LDAP DN by searching for the CN in the > directory) ... The directory search part should IMHO be part of the LDAP > workflow, as the certificate request / issuance does not need to deal > with LDAP then. One could think about constructing the search filter > within the certificate request workflow though and then passing it on > (via the workflow context) to the LDAP publication workflow - what do > you think about that? What is 'a search in directory itself'? Is it LDAP directory that you mention here? My vision is that LDAP and X.509 use the same kind of addressing via DN which is really 'distinguished' and needs no 'unique idetifiers' to find the object. >> workflow that attribute must be checked and used as the DN for publishing >> in the case it is not empty. Otherwise the certificate DN must be used >> as LDAP DN. This way we store the information on the place where the >> certificate is expected to be published in the certificate attribute. > People might not want to put that kind of information into their > certificates, though, because the directory is private for example and > the certificate is to be used publicly or so ... It seems to me that the directory may be private but this privacy is provided by access rules and not by hiding the LDAP address of the object. In such a case process of 'publishing' looks strange. I would say that the purpose of LDAP-publishing workflow is to provide public access to certificates according to the purpose of the system to support PUBLIC keys infrastructure. Hiding certificates in some special place for some special purposes can be done for example in the same way as in smart-card personalization workflow: the certificates are added as attributes to ready-made LDAP nodes. LDAP-publishing works differently - some nodes are created 'on the fly'. One more idea is to support DN suffix substitution for publishing certificates in the certain branch of LDAP tree. Also we can store some extra information in OpenXPKI database (as already done for the 'role' attribute) without including it in certificates. Best regards, Petr Grigoriev. P.S. I am offline until the 25th of August. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ OpenXPKI-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-devel
