Archived

This forum has been archived. Please start a new discussion on GitHub.

IceSSL encoding

nsns
nsns
in Bug Reports
First of all,
Happy New Year and the best wishes to the ZeroC team and their excellent product !

The Ice Manual states that the default value for the 'encoding' attribute of both 'public' and 'private' elements is PEM. This is not true. The default value is 0.

The problem is in:

IceSSL::CertificateFile::CertificateFile( ... )
: _filename(""),
_encoding(0) // <-- problem here

It should be:

IceSSL::CertificateFile:CertificateFile( ... )
: _filename(""),
_encoding(SSL_FILETYPE_PEM)

I would propose also to extend the error messages adding also the encoding type:
PEM, DER(ASN1), or unknown.

I have also a different philosophical question: Ice has the good mechanism for configuration, why did you decide to use for the IceSSL plugin an absolutely different format -- XML.

Cheers, Nikolai

Comments

  • mes
    mes California
    Re: IceSSL encoding
    Originally posted by nsns
    Happy New Year and the best wishes to the ZeroC team and their excellent product !
    Thank you Nikolai!
    The Ice Manual states that the default value for the 'encoding' attribute of both 'public' and 'private' elements is PEM. This is not true. The default value is 0.

    The problem is in:

    IceSSL::CertificateFile::CertificateFile( ... )
    : _filename(""),
    _encoding(0) // <-- problem here
    Thanks, we'll fix this.
    I have also a different philosophical question: Ice has the good mechanism for configuration, why did you decide to use for the IceSSL plugin an absolutely different format -- XML.
    The SSL plug-in is highly configurable, and we felt an XML file would be more appropriate for expressing its configuration options. We always try to keep things as simple as possible, and in the case of SSL we felt this was simpler than using the regular configuration properties.

    For example, it is very straightforward in XML to accept one or more occurrences of a value, such as a certificate. The semantics of properties, however, require each property name to be unique, in which case specifying multiple values requires either artificially unique property names, or overly complex property values.

    I've recently had an opportunity to review the SSL configuration mechanism because I'm implementing an SSL plug-in for the Java mapping. Although the Java version will not use an XML configuration file, I still feel it is appropriate in C++ given the variety of configuration options provided by OpenSSL. The SSL capabilities in Java offer much fewer options, therefore properties will be used to configure the Java plug-in.

    Take care,
    - Mark
  • nsns
    nsns
    I see your point. But consider also an Ice-based application point of view. I like to have a possibility for the flexible configuration but also I know that in the most cases my application will need only three parameters: capath, certificate, and private key. And for a sake of these three properties I need to provide a 14-line XML-file plus dtd.
    The possible workaround is to generate the XML-files on the fly but this will complicate my programs and will require the write access to the underlying filesystem.
    The other solution could be to set the SSL properties programatically but it is not clear how can I do it.

    The different question: how can I set up my own certificate verification procedure ?
    For example, if my certificates contain an application specific extension I'd like to check it.

    Cheers, Nikolai
  • mes
    mes California
    Originally posted by nsns
    I see your point. But consider also an Ice-based application point of view. I like to have a possibility for the flexible configuration but also I know that in the most cases my application will need only three parameters: capath, certificate, and private key. And for a sake of these three properties I need to provide a 14-line XML-file plus dtd.
    Yes, I agree that the XML configuration is overkill for simple cases.
    The possible workaround is to generate the XML-files on the fly but this will complicate my programs and will require the write access to the underlying filesystem.
    The other solution could be to set the SSL properties programatically but it is not clear how can I do it.
    The C++ plug-in currently requires that a configuration file be provided.
    The different question: how can I set up my own certificate verification procedure ?
    For example, if my certificates contain an application specific extension I'd like to check it.
    I'm afraid that's not possible at present.

    Take care,
    - Mark
  • nsns
    nsns
    I've recently had an opportunity to review the SSL configuration mechanism because I'm implementing an SSL plug-in for ...
    Yes, I agree that the XML configuration is overkill for simple cases.

    The attached tarball contains my workaround. I use IceSSL but without XML configuration.
    Of course, this is dirty and non-portable trick but maybe the code will be interesting to you
    in sight of the future modifications.

    Yet another comment on the IceSSL documentation. The default value for the certificate verification depth is -1 (probably, means infinite) but in the doc it is 10. It is not clear why the RSA key size is the mandatory argument. This value is a property of key/cert and can be extracted from there.

    --
    Cheers, Nikolai

Categories