On Wed, Jun 23, 2004, Christian Weber wrote:

> I tried to ask this question to the list before, but seemingly the
> attachment blocked itīs way. So the attachment is included as base64-block.
> 
> Requesting information on signtrust (german, Deutsche Post AG) generated 
> smartcard
> certificates leads to a download of a "signed response".
> 
> Examining the respose shows that it is much like an ocsp response (binary 
> example
> appended in base64) though feeding it into openssl with command
> 
> >openssl ocsp -respin QNcLp5XvEIcAAGyqehE.rsp -noverify -text
> 
> leads to the following output:
> 
> >OCSP Response Data:
> >    OCSP Response Status: successful (0x0)
> >Error parsing response
> >10240:error:0D084078:asn1 encoding routines:ASN1_TEMPLATE_EX_D2I:explicit 
> >tag not constructed:tasn_dec.c:444:
> >10240:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 
> >error:tasn_dec.c:272:Field=value.byName, Type=OCSP_RESPID
> >10240:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_D2I:nested asn1 
> >error:tasn_dec.c:566:Field=responderId, Type=OCSP_RESPDATA
> >10240:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_D2I:nested asn1 
> >error:tasn_dec.c:566:Field=tbsResponseData, Type=OCSP_BASICRESP
> >10240:error:0D08806E:asn1 encoding routines:ASN1_unpack_string:decode 
> >error:asn_pack.c:189:
> 
> This output was generated by openssl--0.9.7-stable-SNAP-20040611 on linux 
> 386.
> 
> Looking at the asn structure itself one notices that the ResponderId is 
> coded as
> Tag 81: "Signtrust" (dunno how to interpret this) instead of the usual x509 
> representation.
> 
> RFC2560 tells:
> >    ResponderID ::= CHOICE {
> >      byName               [1] Name,
> >      byKey                [2] KeyHash }
> 
> but doesnīt specify Name itself.
> 
> So my question is: does the signtrust coding match the rfc rules?
> If it does can anybody give me a hint how to fix the asn1 paring
> so that it recognizes the coding?
> 

No it violates the RFC rules and doesn't include a valid Name structure in
there. Name BTW is defined in RFC3280 et al.

>From the request data it looks like they've treated this as a string type
and put "SignTrust" in there: this is just plain wrong.

Since the response is broken OpenSSL is quite right to reject it and any
decent ASN1 parser would reject it too. 

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to