Uhmm, so you want to create something that could be in contradiction with what's written in the policy section (did you look there?)? And in case of contradiction, what takes priority, the _required setting or the policy setting?
Yes, it's possible to get things out of sync. But more usefully, it's also possible to "head off" bad requests by making the user enter fields that the CA requires. OF course, if things are out of sync, the CA and its policy take precedence. What happens now if a cert request contains an RDN that isn't in the CA's policy? I don't see how _required is any different from that.
I understand the semantics of _min, it just surprised me, that's all. A zero-length field doesn't meet the minimum length. :) I was expecting "strlen(p) == 2" not "*p == '\0' || strlen(p) == 2", as it were.
The problem is the inconsistencies. Why doesn't the CA get automated enforcement checking of lengths, just whether or not a field is there? Etc. Why can't the "req" command be able to format a request (and prompt for fields) that is most like what the CA wants? (Sometimes it might fail, if the CA changes policies or a difference CA signs things, but you get the point.)
If you don't like my _required change -- and wouldn't that be the first time OpenSSL rejected a not-incompatible feature? -- would you accept something that added a "-policy" argument to the req command? I could at least use match or supplied to mean "a required field".
/r$
-- Rich Salz, Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
