Hi, > I think it is a good idea. I would like to see it be in the 0.9.2 > branch.
Me too... > I have a local modification to this function where it will enforce the > attribute type but not the value. For example I want my users to have a > dn with this kind of structure DN: CN=someName, OU=someOU, L=" Any > locality", ST=VA, C=US > What my mod does, it checks for these attributes and if I have > DN_TYPE_PKCS10_3 ="ANY" it will check that this attribute is there but > it will ignore its value, so now I can have any locality I want while > still enforcing the rest. If you guys think that this is a good Idea > then I could submit it to the CVS. I do think this is a good idea. I am in favour of adding this to the 0.9.2 code if it is well tested. Another thought I'd like to share: In addition I have the following situation for which I plan a local modification to the request functions: Incoming (PKCS#10) request DN structures do not conform to the structure we want to enforce by the CA. Example: We want to enforce CN=<fqdn>:<application>, O=<our organization, DC=..., DC=.... in all issued certificates. The client software is unable to create requests with DC=... components and always adds C=... to the request. In addition the requesting parties often do strange stuff we cannot control. So basically I want to do the following: - Extract CN from request - Build SubjectAltName from CN - perform some custom sanity checks, such as checking if the CN is a FQDN and has an A record in our DNS - Use O=, DC=, DC= from public server configuration - Insert resulting pre-edited request to DB Same goes for SCEP and to some extent to Basic requests. I am quite sure this cannot be done in a general way that is useful for inclusion in OpenCA. But I think this cries for a canonical way to call a "Pre-Hook" for inserting a certificate request in the database. Other hooks, such as "Pre-Issuance" and maybe "Post-Issuance" for certificates and CRLs would be useful, I think. I am thinking of something like that: Configurable Perl method that is called with a hash ref containing the request details, e. g. pub.conf: REQ_PKCS10_HOOK MyStuff::Hook::Request So the Perl method MyStuff::Hook::Request (must be in Perl search path) would be called with a hash ref as argument containing the request file location and the parsed request information. The function may then choose to modify the structure and pass back a modified hash ref which would influence the Request header inserted into the DB by the request command. I'll do this locally for our project and won't commit it to CVS unless you all decide it's useful for inclusion. BTW: Oliver Welter would welcome this stuff, too, IIRC. cheers Martin ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ OpenCA-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openca-devel
