[kmf-discuss] OIDs and Extensions

[Massimiliano Pala]

Wyllys Ingersoll wrote:
> Darn it, the example is still not right.
> The fact that the ASN.1 library (libkmfberder.so.1)
> is not exposed makes it harder than I had thought.

Yes it does, at least for me. I have to deal with custom extensions (and
besides this, extensions are always increasing as well as OIDs, so I
need for the CA project a way to encode extensions).

> newextn.BERvalue.Data/Length need to refer to the
> entire ASN.1 encoded octet stream for the entire extension.

So , the second example (the first one I guess it is ok, right ?) is
not right because I should DER encode the value and use that in the
Data/Length fields, right ?

I was thinking about the possibility to have a single function in KMF
that would encode an extension provided the OID, type and value and
value length.

For example:

	KMF_NewExtension( KMF_EXTENSION *ext, char *OID);
	KMF_ExtensionAddValue( KMF_EXTENSION *ext, char *type,
		char *value, int len );

where:

	OID can be a dotted notation, like "0.2.3.1.333.221", or a
	one of the recognized values, like "subjectAltName".

	type can be a dotted notation or one of the "DER" or "ASN1:ASN1_type",
	where ASN1_type could be OCTET_STRING, UTF8_String, INTEGER, etc...

         value is the value to be encoded in the extension

	len is the length of the value (before encoding)


This would prevent the need to expose the ASN1 library, I guess.

[...]
> For a multi-part extension,  I think as long as you
> encode it correctly, KMF will add it just fine.

I will try to come up with something and let you know... :)

Thanks,
Dr. Max

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3088 bytes
Desc: S/MIME Cryptographic Signature
Url : http://oss-beta1.opensolaris.org/pipermail/kmf-discuss/attachments/20070522/a9a881a9/attachment.bin