cmpforopenssl-devel

[Cmpforopenssl-devel] How to retrieve extra certificates from extraCerts on a client side?

[ABULIUS, M. (MUGUR) <mug...@al...>]

Hello,
This topic concerns the "extraCerts" field of the CMPv2 PKIMessage for the "Initialization Response".
The 3GPP "TS 33.310 V9.5.0 (2010-12)" specifies at §9.5.4.3:
"The extraCerts field of the PKIMessage carrying the initialization response shall contain the operator root certificate and  ..."
However I didn't see any way to retrieve the extraCerts certificates from the ip (init response) with the  "cmpforopenssl" tool. In my understanding (looking sources) the option "--extracert FILE" is an input option only. Also the option "--capubs DIRECTORY" is used only to retrieve caPubs certificates.
Do you intend to provide any option to retrieve extraCerts certificates from initial response?
Best Regards
Mugur

[Cmpforopenssl-devel] Need new option to specify recipient instead "--cacert"

[ABULIUS, M. (MUGUR) <mug...@al...>]

Hello,
This topic concerns the option "-cacert FILE' of  "cmpforopenssl" tool in case of a initial CMPv2 request sequence.
Our understanding is that this option is mandatory and that it specifies the path to a client local CA certificate file corresponding to the signing CA.
Looking to the source files I have the feeling that the only usage of this option with the initial CMPv2 request sequence is to provide the issuer's name that will fill up the recipient field on the header of the request. I didn't see any other usage of the CA file.
On my specific scenario I know the "issuer" name for the CA but I don't have the CA certificate on the client side before sending the ir (initial request) to server.
My question is if it is possible to add a new option "-caname" or "--recipient" (or similar) to specify the missing field (i.e. issuer). This option could be VERY useful when the "-cacert" is unknown.

Best Regards
Mugur

[Cmpforopenssl-devel] Need 2048-bits RSA key files and +, regardless the presence of the "--extcert FILE" option.

[ABULIUS, M. (MUGUR) <mug...@al...>]

Hello,
This topic concerns the client's private key and the interdependency between the options:
"-key FILE"
"-extcert FILE"
Our understanding (after reading the source code) concerning the relationship between these 2 options is the following:
*       If the two options are specified then the tool uses for the initial request as client's private key the file specified by the "--key FILE" option.
*       If the option "--extcert FILE" doesn't exist for the initial request then the tool generates a 1024 bits RSA key at location specified by "--key FILE" option.
In our scenarios we need ***2048*** bits RSA keys (possibly more) without using the "--extcert FILE".  We think that the greatest flexibility is to allow (as an additional option) an input key file even in case the option "--extcert FILE" is not specified.
Is possible to add such option / behavior?
Which is, please, the rational of the current interdependency between these two options?
Best Regards
Mugur

[Cmpforopenssl-devel] Support of the CMPv2 error message - code '06'H

[ABULIUS, M. (MUGUR) <mug...@al...>]

Hello,
This topic concerns the support of the CMPv2 error message - code '06'H (ErrorMsgContent / ErrorMsgRep).
Do you intend to support this CMPv2 message with OpenSSL?
Best Regards
Mugur

Re: [Cmpforopenssl-devel] Need new option to specify recipient instead "--cacert"

[Martin P. <cmp...@iz...>]

Hi,

the cmpforopenssl tool is not much more than a very simple
proof-of-concept for utilizing the library's API.

It is certainly possible to add the new option.

Please consider to give your enhancements back to the project -
preferably as bug report on Sourceforge. We'll then test and integrate
it.

Kind regards,
Martin



On Mon, Jun 13, 2011 at 5:45 PM, ABULIUS, MUGUR (MUGUR)
<mug...@al...> wrote:
> Hello,
> This topic concerns the option “—cacert FILE’ of  “cmpforopenssl” tool in
> case of a initial CMPv2 request sequence.
> Our understanding is that this option is mandatory and that it specifies the
> path to a client local CA certificate file corresponding to the signing CA.
> Looking to the source files I have the feeling that the only usage of this
> option with the initial CMPv2 request sequence is to provide the issuer's
> name that will fill up the recipient field on the header of the request. I
> didn't see any other usage of the CA file.
> On my specific scenario I know the “issuer” name for the CA but I don’t have
> the CA certificate on the client side before sending the ir (initial
> request) to server.
> My question is if it is possible to add a new option “—caname” or
> "--recipient" (or similar) to specify the missing field (i.e. issuer). This
> option could be VERY useful when the “—cacert” is unknown.
>
> Best Regards
> Mugur
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Cmpforopenssl-devel mailing list
> Cmp...@li...
> https://lists.sourceforge.net/lists/listinfo/cmpforopenssl-devel
>
>

Re: [Cmpforopenssl-devel] How to retrieve extra certificates from extraCerts on a client side?

[Martin P. <cmp...@iz...>]

Hi,

same here - the "cmpforopenssl" *tool* is not the main focus of that
project so not all functionality present in the API is necessarily
available there.

Patches are welcome :-)

Martin



On Mon, Jun 13, 2011 at 5:25 PM, ABULIUS, MUGUR (MUGUR)
<mug...@al...> wrote:
> Hello,
> This topic concerns the “extraCerts” field of the CMPv2 PKIMessage for the
> “Initialization Response”.
> The 3GPP “TS 33.310 V9.5.0 (2010-12)” specifies at §9.5.4.3:
> “The extraCerts field of the PKIMessage carrying the initialization response
> shall contain the operator root certificate and  …”
> However I didn’t see any way to retrieve the extraCerts certificates from
> the ip (init response) with the  “cmpforopenssl” tool. In my understanding
> (looking sources) the option “--extracert FILE” is an input option only.
> Also the option “--capubs DIRECTORY” is used only to retrieve caPubs
> certificates.
> Do you intend to provide any option to retrieve extraCerts certificates from
> initial response?
> Best Regards
> Mugur
>
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Cmpforopenssl-devel mailing list
> Cmp...@li...
> https://lists.sourceforge.net/lists/listinfo/cmpforopenssl-devel
>
>

Re: [Cmpforopenssl-devel] Support of the CMPv2 error message - code '06'H

[Miikka V. <mvi...@us...>]

Hi,

Support for this message is implemented - see the function PKIError_data() in
cmp_ses.c for example. The cmpclient doesn't necessarily yet print out the error
messages in every situation though.

best regards,
Miikka


Excerpts from ABULIUS, MUGUR (MUGUR)'s message of 2011-06-13 18:25:46 +0300:
> Hello,
> This topic concerns the support of the CMPv2 error message - code '06'H (ErrorMsgContent / ErrorMsgRep).
> Do you intend to support this CMPv2 message with OpenSSL?
> Best Regards
> Mugur

Re: [Cmpforopenssl-devel] Need 2048-bits RSA key files and +, regardless the presence of the "--extcert FILE" option.

[Miikka V. <mvi...@us...>]

Hi,

It would indeed be a good idea to allow an input key file. As Martin mentioned,
the cmpclient tool is not much more than a proof-of-concept at this point, so
these options have mainly been used for testing the library. The behaviour of
'--key' flag is a bit confusing since in an IR message it specifies a file where
a newly generated key will be saved and in a KUR it specifies a key to be used
as input. The '--extcert' option is used for authentication with an external
certificate.

I will change the --key flag so that it checks if the key file already exists,
and if it does the file will be used as an input for initial request. Thanks for
pointing this out!

best regards,
Miikka

Excerpts from ABULIUS, MUGUR (MUGUR)'s message of 2011-06-13 18:16:36 +0300:
> Hello,
> This topic concerns the client's private key and the interdependency between the options:
> "-key FILE"
> "-extcert FILE"
> Our understanding (after reading the source code) concerning the relationship between these 2 options is the following:
> *       If the two options are specified then the tool uses for the initial request as client's private key the file specified by the "--key FILE" option.
> *       If the option "--extcert FILE" doesn't exist for the initial request then the tool generates a 1024 bits RSA key at location specified by "--key FILE" option.
> In our scenarios we need ***2048*** bits RSA keys (possibly more) without using the "--extcert FILE".  We think that the greatest flexibility is to allow (as an additional option) an input key file even in case the option "--extcert FILE" is not specified.
> Is possible to add such option / behavior?
> Which is, please, the rational of the current interdependency between these two options?
> Best Regards
> Mugur