Re: [Anima] Clarification reg old reference in the BRSKI draft to IEEE 802_1AR-2009

[Toerless Eckert <[e-mail]>]

Ideally i would like to negotiate you into liking and accepting the text
as it stands, and if then - if you are interested - to help write a small
followup document amending the solution space to other pledge IDevID
formats (e.g.: without these easy identifiers). The reason for me saying this
is that the authors and i think the industry well understands the
workflows in which these device identifiers are also communicated via
sales integration, appear on printed labels and all the like. So we feel
safe that we have a rock solid solution when we do have this identifier
in the IDevID.

>From what i understand (and please correct me if you are coming from a
different angle), you may be able to reduce cost in manufacturing of
low-cost and/or constrained device by not having to have IDevID securely
installed with such serialNum, but instead just having a
self-signed certificate or maybe even only a self-generated key-pair -
and then for example just using a simple registration process at the
manufacturer to remembrer the public key pair there - manufacturer
doesn't need to create any other device tracking space other than the
public key. Not good for humans, but good enough for automated
mechanisms. This is i think what we discussed during a BRSKI/ACME side-meeting
last week (see also notes sent by Owen and I).

I think it is perfectly feasible to adopt BRSKI to support these type
of environments, probably with only few changes, but it would be a lot
easier to conclude on HOW to do it through the aforementioned separate
followup document. 

For example, i am not sure if TLS can authenticate just with public key
pair, or not (if not we would always ask to create self-signed
certificate), then we might need to amend the voucher format (not sure),
and ultimately, there may need to be some form of standardized sales
integration signaling so that the owner learns about the public keys of
the devices he bought. E.g.: something like this.

Cheers
    Toerless

On Tue, Jul 23, 2019 at 09:26:54AM +0000, Mendelson, Tsippy wrote:
> Hi,
> 
> Sending again to wider ANIMA audience - as I received no response.
> 
> Thanks,
> Tsippy
> 
> 
> 
> 
> From: Mendelson, Tsippy
> Sent: Sunday, June 30, 2019 11:18
> To: [e-mail]
> Cc: Ruan, Xiaoyu <[e-mail]>; Jayanna, Prabhu <[e-mail]>; Mendelson, Tsippy <[e-mail]>
> Subject: Clarification reg old reference in the BRSKI draft to IEEE 802_1AR-2009
> 
> Hello,
> 
> We have identified a reference to an old spec in BRSKI draft draft-ietf-anima-bootstrapping-keyinfra-22.
> 
> The draft refers to:
> 
> [IDevID]   "IEEE 802.1AR Secure Device Identifier", December 2009,
>               <http://standards.ieee.org/findstds/
>               standard/802.1AR-2009.html>.
> However there is a later spec: https://standards.ieee.org/standard/802_1AR-2018.html
> 
> The specific quote from 802.1AR-2009 that we would like to ask about is in section 2.3.1 "Identification of the Pledge":
> 
> 
> The following fields are defined in [IDevID] and [RFC5280]:
> 
> 
> 
>    o  The subject field's DN encoding MUST include the "serialNumber"
> 
>       attribute with the device's unique serial number.  (from [IDevID]
> 
>       section 7.2.8, and [RFC5280] section 4.1.2.4's list of standard
> 
>       attributes)
> 
> In 802_1AR-2018 we could not find that the "serialNumber" attribute MUST be included rather we found SHOULD:
> [cid:image002.jpg@01D54150.D86DC7C0]
> Here it says: An IDevID certificate subject field shall be non-null and should include a unique device serial number.
> 
> We would be happy for a clarification.
> 
> Thanks,
> Tsippy
> 
> 
> 
> 
> 
> 
> Tsippy Mendelson,
> Manageability Chief Architect,
> IP Technologies Group, SecIP - CSE FW Architect
> Intel Israel Design Center
> Phone: [phone]
> Cellular: [phone]
> 
> 
> 
> 
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.



> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima


-- 
---
[e-mail]