I would love to tackle Ed25519 certs, but that is still in dev in openssl.
Also I don't like that they used SHA512, rather than SHAKE128. It is ok
for big systems, but not for the little stuff.
On 08/16/2017 01:43 PM, Robert Moskowitz wrote:
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
[email protected]
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
