Hi Petr,
On Mon, Jul 28, 2008 at 08:53:42AM +0400, [EMAIL PROTECTED] wrote:
> 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. Then in the LDAP-publishing
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?
> 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 ...
Cheers,
Alex
--
Dipl.-Math. Alexander Klink | IT-Security Engineer
[EMAIL PROTECTED] | working @ urn:oid:1.3.6.1.4.1.11417
-------------------------------------------------------------------------
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
