[kmf-discuss] OIDs and Extensions

[Wyllys Ingersoll]

Massimiliano Pala wrote:
>
> 
> I think this model would fit many, if not all, known extensions so far. Can
> you make an example of multiple tags/values which would not fit this API ?


A complex extension like PolicyInformation might not fit into this model:

          PolicyInformation ::= SEQUENCE {
               policyIdentifier   CertPolicyId,
               policyQualifiers   SEQUENCE SIZE (1..MAX) OF
                               PolicyQualifierInfo OPTIONAL

A single tag would not be sufficient to specify this sort of structure.


> I was thinking that by decoupling the extension "creation" and the value
> adding, by simple calling multiple times the addValue function the
> extenstion
> can support multiple values. For example:
> 
>     /* generate new extension */
>     rv = KMF_NewExtension( &ext, "subjectAltName" );
> 
>     /* add a new vale and update the Data/Length by adding to the current
>        DER encoded value the new value */
>     rv = KMF_ExtensionAddValue( &ext, "ASN1:UTF8String", "me at me", 5 );
>     rv = KMF_ExtensionAddValue( &ext, "IP", "192.168.1.1", 11);
>     rv = KMF_ExtensionAddValue( &ext, "DNS", "me.me.me", 8);
> 
> Basically the KMF_ExtensionAddValue would:
> 
>    1. generate a new value by using the OID and the provided value
>    2. concatenate the DER encoded value to the ext's DER Data field
>    3. update the Length value in the Ext's structure
> 
> Would this work ? To simplify the KMF_ExtensionAddValue() we could use
> KMF_OID
> instead of char * for the type:
> 
>     KMF_ExtensionAddValue( &ext, KMF_ENC_UTF8_STRING, "me at me", 5);
>     KMF_ExtensionAddValue( &ext, KMF_ENC_GEN_NAMES_IP, "192.168.1.1", 11);
>     KMF_ExtensionAddValue( &ext, KMF_ENC_GEN_NAMES_DNS, "me.me.me", 8);

I like this better.  Handling strings always adds complexity.  Using
predefined constants makes the underlying logic much easier.  There
are already a bunch of tags defined in the kmfberder headers that I could
move over to the kmftypes.h header in order to expose them for this routine.

If the 3rd parameter is always an ASCII string, then the 4th is not needed
since we could always just do "strlen()", but if you envision binary
buffers being used in the 3rd then we need to keep the length.

Also, one more thing - we are in the process of overhauling almost all
of our APIs.   Some of the old ones we will keep for backwards
compatibility.  The biggest changes coming up are:
  * name changes - The naming convention we use internally for public
    libraries is to use lower-case with "_" separating major words.
    so, functions like "KMF_ExtensionAddValue" will become "kmf_extension_add_value"
    KMF_NewExtension becomes "kmf_new_extension".  If you are creating new
    functions, you ought to just use the new convention now.

  * All of the complex functions that use the KMF_***_PARAM structures
    as inputs are changing to a new attribute/value pair array similar to
    how PKCS#11 functions work.  This is necessary so that we can extend/modify
    the interfaces in the future without breaking binary compatibility
    with earlier releases.

I will be posting an updated document that reflects these changes in the next
few weeks, but I wanted to give you a heads up.    I realize this is
hugely inconvenient for you, but its necessary for us to do this prior
to exposing the interfaces to the world.  Currently, they are considered
"consolidation private", which means that technically, only internal Sun
apps should be using them.   If you send me a list of the APIs that
you are using I can give you an advance warning of how they will be changed
in the next release.

-Wyllys