Re: [Anima] creating iDevID certs with openssl

Kent,

Thanks for the reply.  They don't have it right with:

[ alt_names ]
otherName = 1.3.6.1.5.5.7.8.4;UTF8:EX320

Go to:  http://www.htt-consult.com/pki.html

And see my 802.1AR setup.  I am much further along.  I got to this point 
yesterday.

There are a number of things you need to match the 1AR profile.  I 
believe I am making hardwareModuleName per RFC4108.  I believe I have 
hwType right as an OID.  The thing is what to use for hwSerialNum.

There are a lot of pieces in the cnf file so I am not posting it here.

But I am making a CSR with the HMN in it and the intermediate CA is 
signing that, making a cert.

All my certs are ECDSA P-256.  I also put the proper 'forever' enddate 
value in.

THe SAN can only be specified within the cnf file, so you need a hack to 
add it to the file prior to making the CSR.

There are a number of 'next steps'.  I can develop this for an offline 
system on one of my Cubieboard2s running Fedora26 so I could bring it to 
Singapore.

But I would like to put together a group that want to develop this. 
There is no interest, but there is help, on the openssl-user list.

On 08/16/2017 12:43 PM, Kent Watsen wrote:
> Hi Bob, I'm watching this thread with interest. My take on this [1] is 
> a little different than yours, but I was just prototyping a rough 
> solution, I never took it to completion... [1] 
> https://github.com/netconf-wg/zero-touch/blob/master/openssl-test/vendor/idevid-certificate-pki/intermediate-ca/openssl.cnf#L55Kent 
> -- Making some progress. On 08/14/2017 01:44 PM, Robert Moskowitz wrote:
>> I have just joined this list.  So if this is covered in the archives
>> anywhere, my weak search foo did not uncover it...
>>
>> Has anyone created iDevID certs with openssl including subjectAltName
>> with hardwareModuleName?
>>
>> I have been working on this for a few days and have worked out HOW to
>> even get certs to contain SAN, particularly going the csr route. I
>> have learned on the openssl list that HMN is not directly supported
>> and that you have to use othername.  Something like
>>
>> [ req_ext ]
>> subjectAltName = otherName:1.3.6.1.5.5.7.8.4;SEQ:hmodname
>>
>> [ hmodname ]
>> hwType = OID:1.2.3.4 # Whatever OID you want.
>> hwSerialNum = FORMAT:HEX,OCT:01020304 # Some hex
> This produces a subjectAltName content of:
>
>       0:d=0  hl=2 l=  27 cons: SEQUENCE
>       2:d=1  hl=2 l=  25 cons:  cont [ 0 ]
>       4:d=2  hl=2 l=   8 prim:   OBJECT            :1.3.6.1.5.5.7.8.4
>      14:d=2  hl=2 l=  13 cons:   cont [ 0 ]
>      16:d=3  hl=2 l=  11 cons:    SEQUENCE
>      18:d=4  hl=2 l=   3 prim:     OBJECT            :1.2.3.4
>      23:d=4  hl=2 l=   4 prim:     OCTET STRING      [HEX DUMP]:01020304
>
>
> I suspect that hwtype is a full vendor OID for registering this device.
> Say my company, HTT Consulting makes sensor widgets.  The OID for that
> could be:
>
> 1.3.6.1.4.1.6715.10.1 (where 10 is HTT's devices and 1 is the sensor
> widget).
>
>> But I am not sure what exactly to do with hwType and hwSerialNum
>>
>> Are there any extant examples?
> So googling around for examples and not finding any.  But then my search
> foo has always been weak.
>
>> Currently there is no way to feed any SAN value in at the command like
>> 'openssl req'.  It has to go into the config file, so once I work out
>> WHAT to but into these fields, I will have to do some kludgly stuff to
>> stuff values into the config then run the command. There are examples
>> of this around for SANs of IP, DNS, etc.
>>
>> BTW, so far I have a simple guide for making a pki of ECDSA certs
>> using openssl.  I would be willing to share what I have done todate.
>> The 802.1AR cert section is understandably incomplete...
>>
>> Bob
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>
>