Like Bob Moskowitz who has been posting about IDevID, I have also been
creating certificates with custom/private extensions in aid of creating
IDevIDs.
I'm one of the authors of both:
https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/
and https://datatracker.ietf.org/doc/draft-ietf-anima-voucher/
I want to create certificates with custom/private extensions programatically,
and I found it very difficult to do using the current ruby-openssl modules.
I was sure that it must be possible from the C-API, and found that this
following change to ruby's interface worked well for me:
https://github.com/ruby/openssl/pull/141
} I haven't found a seperate openssl-ruby list as yet, so please {
} excuse the BCC, and as this is not a security issue, I haven't {
} used that address. Please redirect me. {
The critical change being:
- ext = X509V3_EXT_nconf_nid(conf, ctx, nid, RSTRING_PTR(valstr));
+ ext = X509V3_EXT_nconf(conf, ctx, RSTRING_PTR(oid), RSTRING_PTR(value));
Because EXT_nconf does all the nid lookups, and processes the generics
itself, no point in the ruby-ssl code limiting itself to OIDs predefined
in objects.h by it's use of nid lookups directly.
** I'm asking the Openssl team if I'm using the API reasonably **
** Clearly, I have some possible garbage that has leaked in **
My code looks like:
@idevid.add_extension(ef.create_extension(
"subjectAltName",
sprintf("otherName:1.3.6.1.4.1.46930.1;UTF8:%s",
self.sanitized_eui64),
false))
which let me put a private extension having my private hardware number into
the SAN. That works just great, I think. I have in fact extracted the
result in metdtls code in my constrained device a few months ago.
After my changes above, I could now also do: (46930 being my PEN)
@idevid.add_extension(ef.create_extension(
"1.3.6.1.4.1.46930.2",
"ASN1:UTF8String:http://www.sandelman.ca";,
false))
which would insert a MASAURL (using a PEN until we get an id-pe OID
allocated) as described in: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-07#section-2.2
Of concern is that when I look at the resulting certificate:
dooku-[fountain/spec/certs](2.3.0) mcr 10006 %openssl x509 -noout -text -in
12-00-00-66-4D-02.crt
Certificate:
...
X509v3 Subject Alternative Name:
othername:<unsupported>
1.3.6.1.4.1.46930.2:
..http://www.sandelman.ca
Looking at a hexdump I see "0x0c" and "0x17" prior to the http, but maybe
it's a length or something.... I wondered if there was garbage or a UTF-8 BOM
or something inserted.. so, I pointed asn1parse at the result, and I see:
400:d=5 hl=2 l= 9 prim: OBJECT :1.3.6.1.4.1.46930.2
411:d=5 hl=2 l= 25 prim: OCTET STRING [HEX DUMP]:0C17687474703A2F2F7777772E73616E64656C6D616E2E6361
So the 0xc and 0x17 are really there.
Clearly, it's not being take as an UTF8String (because I would expect to see
UTF8STRING as the type if it were), yet the ASN1:UTF8String is in fact being
processed somehow.
If you want to see the whole certificate result, as sample/test data to my
Registrar:
https://github.com/mcr/fountain/blob/master/spec/certs/12-00-00-66-4D-02.crt
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] mcr@xxxxxxxxxxxx http://www.sandelman.ca/ | ruby on rails [
Attachment:
signature.asc
Description: PGP signature
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
