ASN1, X509 CertV3, CRLV2, PKCS, ...

• Messages sorted by: [ date ][ thread ][ subject ][ author ]
• Previous message: Ned Freed: "Re: RFC-1847 parameter addition for content-type"

Dear colleagues

I send this mail to make public some implementations to all
interested in ASN.1, X.509 Certificate V3, X.509 CRL V2 and
PKCS#7. The main purpose is to provided all implementers with
different implementations to test their own, and to provided me
with valuable feedback. 

I have published some executables developed using a general
purpose ASN.1 tool. This tools is not a "compiler" but a library
and a set of C++ include files that allow you to easily write,
implement and use ASN.1 C++ classes and objects within an
application. It has support for all ASN.1 types (ASN.1 94)
despite REAL one. It can encode and decode BER and DER streams.
It has support for X.509 Certificate V3 and CRL V2 with many
integrated standard extensions. It has also support for PKCS#7.
It also includes a high-level crypto API that allows you to
easily plug crypto-code to sign, verify, encipher and hash ASN.1
objects, e.g. certificates, crls, certification paths,
user-defined, etc. 
Despite all the integrated features, it is very small in size
and fast. You can check it by downloading the following directory:

	ftp://sirius.ac.upc.es/pub/asn1/

Following, I include the README file for information about what
you can find in the directory: 

Regards,

Francisco Jordan
Group of Distributed Systems
DAC - Universitat Politecnica de Catalunya
Barcelona, Spain



/*/
 *   Copyright (C) 1996. @fjordan 96/07/05
/*/


Herein are 3 exe programs for PC (generated with MSCV C++
32-bits) and 3 B/DER-encoded examples of certificate V3, CRL V2
and PKCS#7.

# certv3.exe (67 Kbytes): parses (decodes) and prints ASN.1
structure for X.509 certificate version 3. It automatically
parses the following information:

	* Most used X.520, X.509 and PKCs attributes and algorithms
	* The following certificate extensions:
		- keyUsage
		- privateKeyUsagePeriod
		- subjectAltName
		- issuerAltName
		- basicConstraints
		- certificatePolicies
		- authorityKeyIdentifier
	* RSA public key in certificate SubjectPublicKeyInfo field


# crlv2.exe (67 Kbytes): parses (decodes) and prints ASN.1
structure for X.509 certificate revocation list version 2. It
automatically parses the following information:

	* Most used X.520, X.509 and PKCs attributes and algorithms
	* The following CRL extensions:
		- subjectAltName
		- issuerAltName
		- cRLNumber
		- reasonCode


# pkcs7.exe (85 Kbytes): parses (decodes) and prints ASN.1
structure for PKCS#7 standard. It automatically parses the following
information: 

	* Most used X.520, X.509 and PKCs attributes and algorithms
	* The following PKCS7 data:
		- data
		- signedData
		- envelopedData
		- signedAndEnvelopedData
	* X.509 Certificate V3
	* X.509 CRL V2


# certv3.ber: a X.509 certificate V3 encoding example that
contains the following extensions:

		- keyUsage (digitalSignature)
		- basicConstraints (cA FALSE)
		- subjectAltName (rfc822Name & uniformResourceIdentifier)
		- certificatePolicies (myPolicy: low, level 10, -- see below)

The certificatePolicies extension has been generated with the
following policy identifier and policy qualifier information
(also mere examples): 

		myPolicy CertPolicyId ::= 1.2.65536

		lowQualifierInfo PolicyQualifierInfo ::= {
			policyQualifierId	1.2.65536.1
		}

		levelQualifierInfo PolicyQualifierInfo ::= {
			policyQualifierId	1.2.65536.2
			qualifier	INTEGER (1..10)		-- policy level
		}


# crlv2.ber: a X.509 CRL V2 encoding example that contains the
following extensions: 

		- reasonCode
		- cRLNumber

There are two revoked certificates, the first because keyCompromise,
and the later because unspecified reason.
CRL number is 3.


# pkcs7.ber: a PKCS#7 encoding example that contains the example
found in Appendix A: Example signed-data encoding from RSA's "Some
Examples of the PKCS Standards".


HOW THE PARSERS LOOK LIKE?
=========================

All three programs have been generated using the following
source code and linking it with a library.


#include "x509.h"	// or "pkcs.h" for pkcs7.exe

void usage( char *s )
{
	cout << "Use: " << s << " <file.[bd]er>\n" ;
	exit( -1 ) ;
}

void fatal( Aint32 n )
{
	cout << "Error: " << aerror.getError() << " in byte " << n << endl ;
	exit( -1 ) ;
}


void main( int argc, char **argv )
{
	if ( argc != 2 ) usage( argv[0] ) ;

	ifile is( argv[1] ) ;	// open file-type input stream
	CertificateRevocationList c ;
	if ( ! c.decode( is ) ) fatal( is.bytes() ) ;

	// shows CRL
	cout << "* CRL: " ; c.print() ;

	exit( 0 ) ;
}

** For Certificate V3 and PKCS7 substitute
CertificateRevocationList with Certificate for certv3.exe and
ContentInfo for pkcs7.exe.


NOTE that the input-encoding is first decoded (if error the
process is stopped and signaled) and put in machine-memory in
a suitable object. Then, it is available for processing by
the application. In this particular case, it is printed.
Applications can directly address any of the automatically
parsed information cited above, i.e. extensions, public keys,
names, times, etc.

I hope you can use theses programs to make tests against your
own implementations or, eventually, to parse encoded-data.
If you find any error or inconsistency, please report it to my
e-mail.

Francisco Jordan <jordan@ac.upc.es>

• Previous message: Ned Freed: "Re: RFC-1847 parameter addition for content-type"