Stephan Martin schrieb:
> 
> > The problem is that we use directly the names of the extensions which
> > are used by OpenSSL and get in trouble if these names are changed by
> > OpenSSL (it is a violation of our abstraction). Should we normalize the
> > names and use a hash with the normalized names?
> 
> Technically that would be no problem, but at the present i can't see the
> need for using this abstract layer. At the present, there would only be
> the possibility to *read* the extensions.

The reason is very simple. If you follow the discussions about OpenSSL's
DN-handling then you understand my intention. If OpenSSL changes the
names of an extension then we must only change the name in OpenSSL.pm. I
think the best way is to have a hash with the original names and a hash
with our names. So the question is only which names we should use for
the hashs. EXT, EXT_OPENCA, EXT_OPENSSL ..., any ideas?
 
> That's the same problem, like the different ways of parsing
> the Subject-DN in OpenSSL.pm  and REQ.pm (I think, it was there??)
> The one parses in a generic way everything and provides a hash with all
> existent data and you can look, what you want to use. And the other one
> looks only for specific parts and you will never be able to see the rest.

Robert wrotes a new module X500::DN. You can load the DN via
OpenCA::(X509|REQ), put it into X500::DN via parseRFC2253 and then you
can do all what you want via X500::DN->get*.

Michael
-- 
-------------------------------------------------------------------
Michael Bell                   Email (private): [EMAIL PROTECTED]
Rechenzentrum - Datacenter     Email:  [EMAIL PROTECTED]
Humboldt-University of Berlin  Tel.: +49 (0)30-2093 2482
Unter den Linden 6             Fax:  +49 (0)30-2093 2959
10099 Berlin
Germany                                       http://www.openca.org

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
_______________________________________________
OpenCA-Devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/openca-devel

Reply via email to