Re: [Cmpforopenssl-devel] cmpforopenssl - Problem in the management of the revocation reason

[Martin P. <ma...@pe...>]

Hi Riccardo,

thank you for reporting.

Could you
- create a ticket on https://sourceforge.net/p/cmpforopenssl/bugs/
- note the exact GIT commit you use (e.g. the output of 'git log | head')
- note the exact command line you use
- attach the full Wireshark trace

I don't fully understand the OCSP issue you describe; it'd likely be good
if that is also included in the code. Maybe you also have an CRL to look at?

BR,
Martin


On Wed, Sep 20, 2017 at 10:21 PM, Riccardo Bruzzone <
ric...@er...> wrote:

>
>
> Hi all,
> Using the git clone https://git.code.sf.net/p/cmpforopenssl/git
> cmpforopenssl-git
>
> I downloaded and installed your last version of cmpforopenssl in a Ubuntu
> 14.04.5 LTS VM (I made this on September 14th).
>
>
>
> Trying evaluating the cmpforopenssl, I saw that your application isn’t
> managing correctly the revocation reason.
>
> The cmp revocation request was tested using both cmpforopenssl and
> cmpclient (both have been run in clear test … no TLS used).
>
> In both case the Certificates were revoked
>
> but an unexpected wrong revocation code (different from all value tryied)
> was observed invoking the OCSP protocol with the Serial Number of the
> certificate previously revoked via cmpforopenssl.
>
> Independently from the value of revocation reason used in the
> cmpforopenssl syntax, the certificates is always revoked with the reason of
> cessationOfOperation.
>
>
> Response verify OK
>
> trazas5.pem: revoked
>
>         This Update: Sep 15 13:24:15 2017 GMT
>
>         Reason: cessationOfOperation
>
>         Revocation Time: Sep 15 13:23:02 2017 GMT
>
> root@security:/opt/cmp/bin
>
>
> Analysing the RR answer in both cases, the first one sent from cmpclient
> and the second one from cmpforopenssl, I’m seeing that:
>
>
>    - In Wireshark trace generated during the cmpclient test, the
>    CRLReason value (keyCompromise 1) associated to the id-ce-reasonCode is
>    correctly decoded.
>
>
>
>
>
>    - In the Wireshark trace generated during the cmpforopenssl test, the
>    RR packet has been declared as malformed  …. this after id-ce-reasonCode
>    row.
>
>
>
>
> Can I help you to analyse this behaviour ?
> Do you have a patch available on this part to be tested ?
>
>
>
> Br
>
> *Riccardo*
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Cmpforopenssl-devel mailing list
> Cmp...@li...
> https://lists.sourceforge.net/lists/listinfo/cmpforopenssl-devel
>
>