Subject: [Anima] creating iDevID certs with openssl

From: Robert Moskowitz <[email-masked]>
Date: Mon, 14 Aug 2017 13:44:42 -0400

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

But I am not sure what exactly to do with hwType and hwSerialNum

Are there any extant examples?

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

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 14 Aug 2017 15:03:09 -0400

Making some progress.

On 08/14/2017 01:44 PM, Robert Moskowitz wrote:
> 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 ]

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).

> Are there any extant examples?

So googling around for examples and not finding any.  But then my search 
foo has always been weak.

> 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

---

From: Kent Watsen <[email-masked]>
Date: Wed, 16 Aug 2017 16:43:15 +0000

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#L55

Kent

--

Making some progress.

> The 802.1AR cert section is understandably incomplete...

_______________________________________________
Anima mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/anima

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 16 Aug 2017 13:43:08 -0400

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:

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 16 Aug 2017 13:46:46 -0400

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:
> And see my 802.1AR setup.  I am much further along.  I got to this 
> point yesterday.
>
> 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.
>
> system on one of my Cubieboard2s running Fedora26 so I could bring it 
> to Singapore.
>
>> 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

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 18 Aug 2017 15:29:26 -0400

I want to share my work on building a generic ECDSA pki with an 802.1AR 
leaf.  You can see my work at:

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

I believe I have iDevID properly constructed, but I am not sure about 
hwSerailNumber plus its relationship to the DN's serialNumber.

I am interested in feedback on this.  I am willing to turn it into an 
ID.  First I have to do CRL and OCSP support.

openssl is NOT so easy to use for all this.  :(   Rich Salz and others 
on the openssl-user list were a great help.

Bob

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 23 Aug 2017 08:28:17 -0400

I have updated my guide for building a little ECDSA pki, including 
iDevID certs.  You can see it at:

www.htt-consult.com/pki

PEM works.  DER does not work.  I have been finding problems with 
openssl command line support for DER.  Which brings up a question for 
this list:

What format do you expect to see for: 
draft-ietf-anima-bootstrapping-keyinfra

PEM or DER?

PEM supports cert chains, DER does not.
DER is nice and small for small devices.  A PEM non-password P-256 
private key object is 241 bytes.  DER is 121 bytes (DER does not support 
encrypting the private key object).  This is a real cost of secure 
storage for some devices.

What format are the various bootstrap objects (eg vouchers)?  Has anyone 
built any of these for PoC?

---

From: Michael Richardson <[email-masked]>
Date: Wed, 23 Aug 2017 23:23:04 -0400

> Has anyone created iDevID certs with openssl including subjectAltName with
    > hardwareModuleName?

Not exactly, I was also adding my own PEN OID with the Serial Number.
    # the OID: 1.3.6.1.4.1.46930.1 is a Private Enterprise Number OID:
    #    iso.org.dod.internet.private.enterprise . SANDELMAN=46930 . 1
    # subjectAltName=otherName:1.2.3.4;UTF8:some other identifier

    > subjectAltName = otherName:1.3.6.1.5.5.7.8.4;SEQ:hmodname

My ruby code looks like:

    # include the official HardwareModule OID:  1.3.6.1.5.5.7.8.4
    @idevid.add_extension(ef.create_extension(
                                   "subjectAltName",
                                   sprintf("otherName:1.3.6.1.5.5.7.8.4;UTF8:%s",
                                   self.sanitized_eui64),
                                    false))

see: https://github.com/mcr/highway/blob/master/app/models/device.rb#L43

I include what I think is an IDevID for a device with EUI-48 12-00-00-66-4D-02.
I'm not 100% sure that's a valid hwSerialNumber, which is why I had used my own
OID :-)

https://github.com/mcr/fountain/tree/master/spec/certs has the public key
that signed the cert attached (and the cert as well)

The thing I found impossible to do programmatically was to create the
Registrar CA cert with the cmcRA bit set.  I had to resort to configuration
files like yours, see: https://github.com/mcr/fountain/blob/master/trialra.sh

-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Wed, 23 Aug 2017 23:24:34 -0400

Robert Moskowitz <[email-masked]> wrote:
    > 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.

So, you mean something like "anima-implementers", or "idevid-hackers" or some
list like that?

Or a more formal group?

---

From: Michael Richardson <[email-masked]>
Date: Wed, 23 Aug 2017 23:45:35 -0400

> PEM supports cert chains, DER does not.

I'm confused by this.
PEM, to me, is base64 encoded DER, probably with the BEGIN CERTIFICATE stuff.
If you are saying that PEM files can contain multiple certs, there are DER
ways to that.  TLS just concatenates I believe.

Here is where you'd find objects in BRSKI:

1) TLS ClientCertificate.
   This should be just the IDevID blob, and in TLS, it's in DER format,
   if the Registrar needs anything else in the chain, it must chase them down
   itself.

2) TLS ServerCertificate.
   https://tools.ietf.org/html/rfc5246#section-7.4.2
     Note: PKCS #7 [PKCS7] is not used as the format for the certificate
     vector because PKCS #6 [PKCS6] extended certificates are not used.
     Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task
     of parsing the list more difficult.

3) The plege's Voucher Request may be signed using JOSE (using the IDevID)
   The IDevID is not sent, it's the one from ClientCertificate.

4) The registar's Voucher Request may be signed using JOSE, using the
   Domain Owner's key.  That might not be the same key the Registrar uses
   to form the EST connection to the MASA (if the Registrar uses client
   authentication at all).
   The Domain Owner is within the pinned-domain-cert field.
   We define it as being DER binary.  In JSON format, that turns into base64
   encoded.  The reason we go there is that we do not want the
   ----BEGIN... stuff in there for JSON, in another encoding (CBOR), binary
   is just fine.

5) The resulting voucher also uses pinned-domain-cert as well, now signed
   by the MASA.

    > What format are the various bootstrap objects (eg vouchers)?  Has
    > anyone built any of these for PoC?

PoC?

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 24 Aug 2017 06:02:21 -0400

> ways to that.  TLS just concatenates I believe.

On the openssl-user list, the claim was made that concatinating DER 
certs for a cert chain like you do with PEM does not work with 
applications.  You have to use PKCS#12, but that includes the private 
key and is passworded.  I should be able to get the pointer to Viktor's 
post about this.

---

From: Kent Watsen <[email-masked]>
Date: Fri, 25 Aug 2017 13:36:45 +0000

> key and is passworded.  I should be able to get the pointer to Viktor's 

Concatenating PEM encodings into a single file is a hack, albeit a super
convenient one.  Instead of PKCS#12, have you looked into PKCS#7? - this
is what is used in the netconf-zerotouch draft for binary certificate
chains.

>     if the Registrar needs anything else in the chain, it must chase them down

FWIW, the netconf-zerotouch draft specifies that the device possesses the
IDevID cert *and* all the intermediate certs leading to the manufacturer's
well-known trust-anchor, all of which it provides during crypto handshake.

>       of parsing the list more difficult.

I don't understand how this relates to PKCS#6.  True about the SET, but this
is minor relative to the tradeoffs.  Can you say some more about this?

>     ----BEGIN... stuff in there for JSON, in another encoding (CBOR), binary

Correct, putting PEM-text into protocols is inappropriate.

>      > anyone built any of these for PoC?

Aren't the formats defined in the drafts?  E.g., the voucher draft
says it’s a PKCS#7.

Regarding PoC, here's some code to create/validate vouchers: 
https://github.com/netconf-wg/zero-touch/tree/master/openssl-test.

K.

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 25 Aug 2017 13:46:24 -0400

> is what is used in the netconf-zerotouch draft for binary certificate

Please read:

https://mta.openssl.org/pipermail/openssl-users/2017-August/006374.html

VIktor gives his views of what works in the field.  I have found Viktor 
to be a great help, and tends to really know what works. Besides on the 
openssl-user list, he is on the postfix-user list.
> well-known trust-anchor, all of which it provides during crypto handshake.

Most systems running netconf have the storage capacity for this.  I 
would think.

In my auto meetings, many of the devices they are discussing do not have 
this option.

> Aren't the formats defined in the drafts?  E.g., the voucher draft

I think PKCS is mentioned twice in the bootstrap draft.  Nothing about 
iDevID format, for example.  802.1AR does not say anything about iDevID 
(or lDevID) format.

> https://github.com/netconf-wg/zero-touch/tree/master/openssl-test.

For next week.

Bob

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Aug 2017 13:17:39 -0400

Kent Watsen <[email-masked]> wrote:
    >> https://tools.ietf.org/html/rfc5246#section-7.4.2 Note: PKCS #7
    >> [PKCS7] is not used as the format for the certificate vector because
    >> PKCS #6 [PKCS6] extended certificates are not used.  Also, PKCS #7
    >> defines a SET rather than a SEQUENCE, making the task of parsing the
    >> list more difficult.

    > I don't understand how this relates to PKCS#6.  True about the SET, but
    > this is minor relative to the tradeoffs.  Can you say some more about
    > this?

I was simply quoting rfc5246.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Aug 2017 13:19:15 -0400

> iDevID format, for example.  802.1AR does not say anything about iDevID

BTW: Doesn't rfc2315 officially replaced PKCS7 from a reference point of view?

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 28 Aug 2017 14:28:47 -0400

> BTW: Doesn't rfc2315 officially replaced PKCS7 from a reference point of view?

It does for IETFers, but not the rest of the world.  Everyone will say 
PKCS#7.

In fact IETFers don't refer to this as RFC2315 format...

All 2315 means is we have a public long-lived source for how to build 
and parse PKCS#7.

IMHO.

And is it still working with current PKCS#7 content?

Bob