Re: [Secdispatch] [lamps] IDevID considerations document to secdispatch

["Brockhaus, Hendrik" <[e-mail]>]

> Von: Spasm <[e-mail]> Im Auftrag von Michael Richardson
> 
> Tomas Gustavsson <[e-mail]> wrote:
>     > On 2020-06-28 22:51, Michael Richardson wrote:
>     >>
>     >> Thank you again for reviewing the document!
>     >>
>     >> I know that primekey is involved in creating Birth Certificates for
>     >> many product lines. (Your website's term, not mine, but a good
>     >> one)
> 
>     > It wasn't my (ours) terminology unfortunately :-). We found it
>     > elsewhere. I don't remember where "birth" came from. 3GPP 33.310 have
>     > the same concept, but calling Vendor certificate. I think birth
>     > certificate is a little better, as it's more generic than specifying a
>     > vendor relationship.
> 
> I do like the birth concept, and I am thinking if changing the document name to
> include it would make sense.
> Perhaps someone with expertise in attachment parenting can provide some
> interesting words about how trust anchors are installed.
> 

I use the image of the "birth certificate" to better explain the attributes of an IDevID certificate.
- Issued at manufacturing time (in Germany the birth certificate is a simple sheet stamped and signed by the local register office)
- The enrollment process requires some organizational/physical security, as there is nothing to derive trust from at that point in time (in Germany the father or mother have to request the birth certificate personally. They need to define the name of the child in front of the register officer and need present a conformation letter from the hospital or midwife about the date of birth)
- It lasts as long as the device is used (in Germany a birth certificate has no validity and it is difficult to get a new one, if you lost yours)
- It is required for initial authentication to request an operational certificate (in Germany the birth certificate is required if you request a national ID card or a passport)
- It should not be used for day-to-day operational tasks (you would not use the birth certificate to identify yourself other than to the register office. Only rarely it is requested, e.g., when becoming a governmental or public official)

>     >> I wonder if you can comment on which of the three methods you
>     >> support? Do you have any suggestions on names for the three
>     >> methods? To me, just getting three good names is 90% of the value
>     >> of this document.
> 
>     > We support:
>     > 2.1.1.  On-device private key generation
>     > Standard CSR-submitted-to-CA  process
> 
> I have named this:
>   a) _device-generated_ / _mechanically-transfered_
>   b) _device-generated_ / _network-transfered_
> 
> I know that you are blown away by my imagination here.
> Perhaps someone can feed this through a mechanical translator, run it
> English->German->Mandarin->Swahili->English, and see what comes back.
> 
> I think that it's useful for the entity that needs to examine the risk for the
> process to distinguish the two transfer methods.
> 
> 
>     > 2.1.2.  Off-device private key generation
>     > Typically CA-generates-keystore process. Some protocols, i.e.
>     > CMP/RFC4210 have standard support for encrypting the private key sent
>     > back to the client
> 
> I have named this:
>    a) _factory-generated_ / _mechanically-transfered_
>       Like a serial console connection, or a JTAG flash writer.
> 
> for b) _factory-generated_/ _network-transfered_
> 
> yes, but what key would you use? :-)
> The device has nothing....
> So I think that it really has to always be used in the factory with a physically
> secure network connection.

I personally would prefer to say '_infrastructure-generated_' than '_factory-generated_', because the generation on the device will most likely also take place in the factory.

> 
>     > 2.1.3.  Key setup based on 256-bit secret seed
>     > We haven't seen this. Albeit, it's not so much related to the PKI
>     > part, so it can still be supported/used if the certificate issuance is
>     > done using a CSR process to the CA.
> 
> I have named this: device/factory-co-generated

Same here: 'device/infrastructure-co-generated'.

- Hendrik