help-libtasn1
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] cleanup _asn1_copy_structure3


From: Tim Ruehsen
Subject: Re: [PATCH] cleanup _asn1_copy_structure3
Date: Tue, 4 Sep 2012 16:38:38 +0200
User-agent: KMail/1.13.7 (Linux/3.2.0-3-amd64; KDE/4.8.4; x86_64; ; )

Am Tuesday 04 September 2012 schrieb Nikos Mavrogiannopoulos:
> On Tue, Sep 4, 2012 at 3:48 PM, Tim Ruehsen <address@hidden> wrote:
> > Right now, after having taken a deeper look into the sources, I
> > personally dislike the source code.
> 
> You're not alone. Unfortunately it is the easiest to use ASN.1 parser.
> 
> > It is unnecessary complex, i would say hard to
> > maintain. I really can't find any of the stated "high quality" code.
> 
> Who states that?

see http://www.gnu.org/software/libtasn1
The part i am referring to is titled "High Quality".
Well the clang analyser is mentioned... since the last check, some time may 
have been passed ... using it, you will at least find one serious memory 
error.

> > Tree structure handling and content handling should be seperated.
> > Aren't there any well-tested tree library routines (e.g. GNU t*
> > functions) that could be used for adding, deleting, searching and
> > walking ?.
> 
> Could be. However, the author of this code is no longer interested in
> improving it. Unless there is someone willing to rewrite (simply
> patching may not work), it would be hard to improve.

That's my opinion as well.

> > I think, GnuTLS should have a tool to be able to convert .PEM files into
> > simple text files which could be read into a simple C structure by a
> > trivial routine. That would massively reduce complexity and resource
> > usage (CPU, Memory) and speed up GnuTLS startup.
> 
> This isn't trivial. ASN.1 structures can be overly complex and they
> rarely map to C structure (see PKCS #12 for an example). If you try to
> parse complex structures like that with other approaches (e.g. the
> libtomcrypt asn.1 parser functions) you'll become insane. Libtasn.1's
> advantage is _a very good_ interface for accessing elements within the
> structure. Unfortunately it is supported by very complex code.

Hey Nikos.
This mentioned tool could use libtasn1. Impact doesn't matter since the 
certificates seldom change.
The X509 certificate format is well defined in RFC 5280 and it should be easy 
to output these values into a text format like:
--------
tbsCertificate.version 2
tbsCertificate.serialNumber 85:bd:4b:f3:d8:da:e3:69:f6:94:d7:5f:c3:a5:44:23
tbsCertificate.signature sha1WithRSAEncryption
tbsCertificate.issuer C=US, O=America Online Inc., CN=America Online Root 
Certification Authority 1
...
signatureAlgorithm sha1WithRSAEncryption
signatureValue 7c:8a:d1:1f:18:37:82:e0:b8:b0:a3:ed:56:95:c8:62:61:9c: ...
--------

OpenSSL already has a tool to convert .PEM into a (human readable) text:
openssl x509 -text -noout -in <filename>

Maybe there already is a similar GnuTLS tool which we can extend a bit to 
produce machine readable text.

Regards, Tim



reply via email to

[Prev in Thread] Current Thread [Next in Thread]