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

[Toerless Eckert]

On Wed, Jul 31, 2019 at 02:18:08PM +1200, Brian E Carpenter wrote:
> Let's be clear in the BRSKI text that our standard makes this a MUST
> *even if* it is not mandatory in the IEEE standard. Of course we can do
> that (and not including the serial number seems very sloppy), but we
> should be explicit that our requirement is stronger than the IEEE.

Right.

> Maybe it means that some light bulbs cannot be BRSKI pledges. I don't
> think we care, because our model is that nodes containing management
> smarts such as an ASA need to join the ACP, but managed nodes themselves
> do not.

GRASP, BRSKI, ACP are meant to also be independently reuseable,
not every device using  eithrer of them needs the full ANI.

My argument is rather that BRSKI as defined (mandating serialNumber) is
well representing whats used/required in well known type of devices and
that followon work can (IMHO) easily expand it for additional
constrained device solutions.

Cheers
Toerless

> Regards
>Brian
> 
> On 31-Jul-19 11:11, Toerless Eckert wrote:
> > On Tue, Jul 30, 2019 at 06:23:37PM -0400, Michael Richardson wrote:
> >>
> >> Toerless Eckert  wrote:
> >> > 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
> >>
> >> I didn't get that all from the original poster.
> >> I think you are jumping to a conclusion that is not supported by text here.
> > 
> > Yes, i was elaborating about why one would want an IDevID without the
> > serialNumber and what would need to happen to support that. But i also
> > said this should be out of scope for the current BRSKI document.
> > 
> >> They simply say that serialNumber is not a MUST in 802.1AR-2018, but 
> >> rather a SHOULD.
> >> And, that's not the point at all, really.
> >> IF you want to do BRSKI, then you MUST include a serialNumber in the DN.
> > 
> > Agreed.
> > 
> >> 802.1AR-2009, has section 7.2.8:
> >>
> >> 7.2.8 subject
> >>   The DevID subject field shall uniquely identify the device associated
> >>   with the particular DevID credential within the issuer???s domain of
> >>   significance. The formatting of this field shall contain a unique 
> >> X.500
> >>   Distinguished Name (DN). This may include the unique device serial
> >>   number assigned by the manufacturer or any other suitable unique DN
> >>   value that the issuer prefers. In the case of a third-party CA or a
> >>   standards certification agency, this can contain the manufacturer???s
> >>   identity information.
> >>
> >>   The subject field???s DN encoding should include
> >>   the ???serialNumber??? attribute with the device???s unique serial 
> >> number.
> >>
> >> Note lack of RFC2119 language (or a reference to it).
> >>
> >> So if the 2018 has "SHOULD" here, then that's a strengthing of the 
> >> language,
> >> not a weaking.
> >> The first paragraph does have weasel words "any other
> >> suitable unique DN", but 
> > 
> > Ok, i currently can't access the IEEE standards, so i can not compare
> > myself. My reading of the OP was that it was a weakening.
> > 
> > 
> >> I really think that a serialNumber DN attribute
> >> (as opposed to the serialNumber certificate attribute) is needed for BRSKI
> >> to interoperate well.
> > 
> > Agreed.
> > 
> >> If someone has a 10 million devices in the field which can be field 
> >> upgraded
> >> to run BRSKI (while still in a not-yet enrolled state in a box), then let's
> >> talk about this.  Maybe it's actually 10,000,000 TPM devices with IDevIDs
> >> already generated, but no serialNumber in it.  Getting the JRC code right
> >> to do other things can be a pain, but it can be done.
> > 
> > Right, this was my question to the OP as well. I was guessing its more
> > about minimizing cost for future built 10 million devices. Today you
> > would need to burn-in during manufacturing identity elements such as
> > specifically the serialNumber, so you need to devise a protected burn-in
> > process. If you just et the device generate a public key pair and you
> > simply capture the public key during manufacturing, maybe that is a
> > significant simplification when you talk 10 million devices. Just
> > guessing. In any case, serialNumber is a lot more useful when humans are
> > involved, but they may become less relevant when everything is
> > automated.
> > 
> > Cheers
> > Toerless
> > 
> >> -- 
> >> ]   Never tell me the odds! | ipv6 mesh 
> >> networks [
> >> ]   Michael Richardson, Sandelman Software Works|IoT architect 
> >>   [
> >> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails 
> >>[
> >>
> > 
> > 
> > 
> >> ___
> >> Anima mailing list
> >> Anima@ietf.org
> >> https://www.ietf.org/mailman/listinfo/anima
> > 
> > 

-- 
---

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

[Toerless Eckert]

On Wed, Jul 31, 2019 at 11:11:54AM +, Mendelson, Tsippy wrote:
> Hi,
> 
> My remark was about the inaccurate reference to IEEE 802.1AR requiring Serial 
> Number as a MUST in the IDevID - this can be easily fixed by saying that IEEE 
> 802.1AR recommends this but BRSKI enforces this - makes this a MUST.

Ack.

> But behind the scenes this question was coming from considerations related to 
> complexity that this adds to the manufacturing flow when required to 
> provision every device with a certificate that includes its Serial Number :-).
> This creates usability and security issues on the manufacturing line.

Thanks. Thats what i was guessing im my reply.

> We are devising a solution for this manufacturing problem by using an 
> embedded CA in a RoT / Hardware TEE in the platform for this purpose - but 
> there are concerns with this implementation as well. Therefore I wanted to 
> clarify this requirement. (Although I agree that it makes perfect sense).
> 
> Regarding: 
> " If you just let the device generate a public key pair and you simply 
> capture the public key during manufacturing, maybe that is a significant 
> simplification when you talk 10 million devices"
> 
> This is a very interesting remark as we are actually thinking of a solution 
> where the Platform Identifier in the Ownership Voucher (that the OEM uploads 
> to their inventory from the manufacturing line) would include 2 components:
> 1. The Serial Number assigned by the OEM to the platform - this could be a 
> Service Tag or perhaps a hash of all serial numbers of devices included in 
> the platform - or something else the OEM chooses - but as it can be a hash we 
> allocate 32 bytes for it.

I can not quite imagine what you are calling a "platform". Could give
give one or two examples ?

> 2. A hash of the Public Key of a key pair that is generated by the Platform 
> RoT for identity / TEE - this would be the public key in the IDevID 
> certificate. When using an embedded CA (in the RoT hardware) to issue IDevID 
> certificates, this would be the Public Key in the certificate of the embedded 
> CA that the IDevID Certificate is rooted to.

RoT ? TEE ?

> Altogether 64 bytes.
> 
> Using an embedded CA enables revoking and replacing the key and certificate 
> used for identity attestation easily, after a FW update that increases the 
> security version number. 

See above, i can't quite imagine the solution and its intended
workflows, but it sounds as if oyu wanted to figure out a variation of 
BRSKI/MASA
to actually enroll IDevID instead of LDevID...

It seems the main problem you want to solve is how client devices should
identify themselves to the MASA (or however else you want to call the
manufacturer or OEM backend) without a classical certificate IDevID and
without upfront tracking of any other form of serial IDs by the
manufacturer ? 

I am not sure about all useful crypto mechanisms to solve this, but
obviously you could have something like a platform-id in a TPM chip
thats the same for all devices for the platform, and the only operation
permitted is some proof of knowledge of that shared secret by the MASA
(e.g.: hash(nonce+secret) or the like).

Of course if you can born something unique into the devices during
manufacturing, you could do something like very_long_serial=random(seed), seed
becomes the platform identifier, and device identifies by sending
masa-private-key encrypted serial to MASA. Or something like that.

Crypto folks would likely have better suggestions ;-)

Cheers
Toerless

> Regards,
> Tsippy
> 
> -Original Message-
> From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] 
> Sent: Wednesday, July 31, 2019 05:18
> To: Toerless Eckert ; Michael Richardson 
> 
> Cc: Jayanna, Prabhu ; Mendelson, Tsippy 
> ; anima@ietf.org; Ruan, Xiaoyu 
> 
> Subject: Re: [Anima] Clarification reg old reference in the BRSKI draft to 
> IEEE 802_1AR-2009
> 
> Let's be clear in the BRSKI text that our standard makes this a MUST *even 
> if* it is not mandatory in the IEEE standard. Of course we can do that (and 
> not including the serial number seems very sloppy), but we should be explicit 
> that our requirement is stronger than the IEEE.
> 
> Maybe it means that some light bulbs cannot be BRSKI pledges. I don't think 
> we care, because our model is that nodes containing management smarts such as 
> an ASA need to join the ACP, but managed nodes themselves do not.
> 
> Regards
>Brian
> 
> On 31-Jul-19 11:11, Toerless Eckert wrote:
> > On Tue, Jul 30, 2019 at 06:23:37PM -0400, Michael Richardson wrote:
> >>
> >> Toerless Eckert  wrote:
> >> > From what i understand (and please correct me if you are coming from 
> >> a
> >> > di

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

[Mendelson, Tsippy]

Hi,

My remark was about the inaccurate reference to IEEE 802.1AR requiring Serial 
Number as a MUST in the IDevID - this can be easily fixed by saying that IEEE 
802.1AR recommends this but BRSKI enforces this - makes this a MUST.

But behind the scenes this question was coming from considerations related to 
complexity that this adds to the manufacturing flow when required to provision 
every device with a certificate that includes its Serial Number :-).
This creates usability and security issues on the manufacturing line.

We are devising a solution for this manufacturing problem by using an embedded 
CA in a RoT / Hardware TEE in the platform for this purpose - but there are 
concerns with this implementation as well. Therefore I wanted to clarify this 
requirement. (Although I agree that it makes perfect sense).

Regarding: 
" If you just let the device generate a public key pair and you simply capture 
the public key during manufacturing, maybe that is a significant simplification 
when you talk 10 million devices"

This is a very interesting remark as we are actually thinking of a solution 
where the Platform Identifier in the Ownership Voucher (that the OEM uploads to 
their inventory from the manufacturing line) would include 2 components:
1. The Serial Number assigned by the OEM to the platform - this could be a 
Service Tag or perhaps a hash of all serial numbers of devices included in the 
platform - or something else the OEM chooses - but as it can be a hash we 
allocate 32 bytes for it.

2. A hash of the Public Key of a key pair that is generated by the Platform RoT 
for identity / TEE - this would be the public key in the IDevID certificate. 
When using an embedded CA (in the RoT hardware) to issue IDevID certificates, 
this would be the Public Key in the certificate of the embedded CA that the 
IDevID Certificate is rooted to.

Altogether 64 bytes.

Using an embedded CA enables revoking and replacing the key and certificate 
used for identity attestation easily, after a FW update that increases the 
security version number. 

Regards,
Tsippy

-Original Message-
From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] 
Sent: Wednesday, July 31, 2019 05:18
To: Toerless Eckert ; Michael Richardson 
Cc: Jayanna, Prabhu ; Mendelson, Tsippy 
; anima@ietf.org; Ruan, Xiaoyu 

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

Let's be clear in the BRSKI text that our standard makes this a MUST *even if* 
it is not mandatory in the IEEE standard. Of course we can do that (and not 
including the serial number seems very sloppy), but we should be explicit that 
our requirement is stronger than the IEEE.

Maybe it means that some light bulbs cannot be BRSKI pledges. I don't think we 
care, because our model is that nodes containing management smarts such as an 
ASA need to join the ACP, but managed nodes themselves do not.

Regards
   Brian

On 31-Jul-19 11:11, Toerless Eckert wrote:
> On Tue, Jul 30, 2019 at 06:23:37PM -0400, Michael Richardson wrote:
>>
>> Toerless Eckert  wrote:
>> > 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
>>
>> I didn't get that all from the original poster.
>> I think you are jumping to a conclusion that is not supported by text here.
> 
> Yes, i was elaborating about why one would want an IDevID without the 
> serialNumber and what would need to happen to support that. But i also 
> said this should be out of scope for the current BRSKI document.
> 
>> They simply say that serialNumber is not a MUST in 802.1AR-2018, but rather 
>> a SHOULD.
>> And, that's not the point at all, really.
>> IF you want to do BRSKI, then you MUST include a serialNumber in the DN.
> 
> Agreed.
> 
>> 802.1AR-2009, has section 7.2.8:
>>
>> 7.2.8 subject
>>   The DevID subject field shall uniquely identify the device associated
>>   with the particular DevID credential within the issuer???s domain of
>>   significance. The formatting of this field shall contain a unique X.500
>>   Distinguished Name (DN). This may include the unique device serial
>>   number assigned by the manufacturer or any other suitable unique DN
>>   value that the issuer prefers. In the case of a third-party CA or a
>>   standards certification agency, this can contain the manufacturer???s
>>   identity information.
>>
>>   The subject field???s DN encoding should include
>>   the ???serialNumber??? attribute with the device???s unique serial 
>> number.
>>
>> Note lack of RFC2119 language (or a reference to it).
>>
>> So if 

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

[Brian E Carpenter]

Let's be clear in the BRSKI text that our standard makes this a MUST
*even if* it is not mandatory in the IEEE standard. Of course we can do
that (and not including the serial number seems very sloppy), but we
should be explicit that our requirement is stronger than the IEEE.

Maybe it means that some light bulbs cannot be BRSKI pledges. I don't
think we care, because our model is that nodes containing management
smarts such as an ASA need to join the ACP, but managed nodes themselves
do not.

Regards
   Brian

On 31-Jul-19 11:11, Toerless Eckert wrote:
> On Tue, Jul 30, 2019 at 06:23:37PM -0400, Michael Richardson wrote:
>>
>> Toerless Eckert  wrote:
>> > 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
>>
>> I didn't get that all from the original poster.
>> I think you are jumping to a conclusion that is not supported by text here.
> 
> Yes, i was elaborating about why one would want an IDevID without the
> serialNumber and what would need to happen to support that. But i also
> said this should be out of scope for the current BRSKI document.
> 
>> They simply say that serialNumber is not a MUST in 802.1AR-2018, but rather 
>> a SHOULD.
>> And, that's not the point at all, really.
>> IF you want to do BRSKI, then you MUST include a serialNumber in the DN.
> 
> Agreed.
> 
>> 802.1AR-2009, has section 7.2.8:
>>
>> 7.2.8 subject
>>   The DevID subject field shall uniquely identify the device associated
>>   with the particular DevID credential within the issuer???s domain of
>>   significance. The formatting of this field shall contain a unique X.500
>>   Distinguished Name (DN). This may include the unique device serial
>>   number assigned by the manufacturer or any other suitable unique DN
>>   value that the issuer prefers. In the case of a third-party CA or a
>>   standards certification agency, this can contain the manufacturer???s
>>   identity information.
>>
>>   The subject field???s DN encoding should include
>>   the ???serialNumber??? attribute with the device???s unique serial 
>> number.
>>
>> Note lack of RFC2119 language (or a reference to it).
>>
>> So if the 2018 has "SHOULD" here, then that's a strengthing of the language,
>> not a weaking.
>> The first paragraph does have weasel words "any other
>> suitable unique DN", but 
> 
> Ok, i currently can't access the IEEE standards, so i can not compare
> myself. My reading of the OP was that it was a weakening.
> 
> 
>> I really think that a serialNumber DN attribute
>> (as opposed to the serialNumber certificate attribute) is needed for BRSKI
>> to interoperate well.
> 
> Agreed.
> 
>> If someone has a 10 million devices in the field which can be field upgraded
>> to run BRSKI (while still in a not-yet enrolled state in a box), then let's
>> talk about this.  Maybe it's actually 10,000,000 TPM devices with IDevIDs
>> already generated, but no serialNumber in it.  Getting the JRC code right
>> to do other things can be a pain, but it can be done.
> 
> Right, this was my question to the OP as well. I was guessing its more
> about minimizing cost for future built 10 million devices. Today you
> would need to burn-in during manufacturing identity elements such as
> specifically the serialNumber, so you need to devise a protected burn-in
> process. If you just et the device generate a public key pair and you
> simply capture the public key during manufacturing, maybe that is a
> significant simplification when you talk 10 million devices. Just
> guessing. In any case, serialNumber is a lot more useful when humans are
> involved, but they may become less relevant when everything is
> automated.
> 
> Cheers
> Toerless
> 
>> -- 
>> ]   Never tell me the odds! | ipv6 mesh networks 
>> [
>> ]   Michael Richardson, Sandelman Software Works|IoT architect   
>> [
>> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails   
>>  [
>>
> 
> 
> 
>> ___
>> Anima mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
> 
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Toerless Eckert]

On Tue, Jul 30, 2019 at 06:23:37PM -0400, Michael Richardson wrote:
> 
> Toerless Eckert  wrote:
> > 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
> 
> I didn't get that all from the original poster.
> I think you are jumping to a conclusion that is not supported by text here.

Yes, i was elaborating about why one would want an IDevID without the
serialNumber and what would need to happen to support that. But i also
said this should be out of scope for the current BRSKI document.

> They simply say that serialNumber is not a MUST in 802.1AR-2018, but rather a 
> SHOULD.
> And, that's not the point at all, really.
> IF you want to do BRSKI, then you MUST include a serialNumber in the DN.

Agreed.

> 802.1AR-2009, has section 7.2.8:
> 
> 7.2.8 subject
>   The DevID subject field shall uniquely identify the device associated
>   with the particular DevID credential within the issuer???s domain of
>   significance. The formatting of this field shall contain a unique X.500
>   Distinguished Name (DN). This may include the unique device serial
>   number assigned by the manufacturer or any other suitable unique DN
>   value that the issuer prefers. In the case of a third-party CA or a
>   standards certification agency, this can contain the manufacturer???s
>   identity information.
> 
>   The subject field???s DN encoding should include
>   the ???serialNumber??? attribute with the device???s unique serial 
> number.
> 
> Note lack of RFC2119 language (or a reference to it).
> 
> So if the 2018 has "SHOULD" here, then that's a strengthing of the language,
> not a weaking.
> The first paragraph does have weasel words "any other
> suitable unique DN", but 

Ok, i currently can't access the IEEE standards, so i can not compare
myself. My reading of the OP was that it was a weakening.


> I really think that a serialNumber DN attribute
> (as opposed to the serialNumber certificate attribute) is needed for BRSKI
> to interoperate well.

Agreed.

> If someone has a 10 million devices in the field which can be field upgraded
> to run BRSKI (while still in a not-yet enrolled state in a box), then let's
> talk about this.  Maybe it's actually 10,000,000 TPM devices with IDevIDs
> already generated, but no serialNumber in it.  Getting the JRC code right
> to do other things can be a pain, but it can be done.

Right, this was my question to the OP as well. I was guessing its more
about minimizing cost for future built 10 million devices. Today you
would need to burn-in during manufacturing identity elements such as
specifically the serialNumber, so you need to devise a protected burn-in
process. If you just et the device generate a public key pair and you
simply capture the public key during manufacturing, maybe that is a
significant simplification when you talk 10 million devices. Just
guessing. In any case, serialNumber is a lot more useful when humans are
involved, but they may become less relevant when everything is
automated.

Cheers
Toerless

> -- 
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works|IoT architect   [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
> 



> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima


-- 
---
t...@cs.fau.de

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Michael Richardson]

Toerless Eckert  wrote:
> 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

I didn't get that all from the original poster.
I think you are jumping to a conclusion that is not supported by text here.

They simply say that serialNumber is not a MUST in 802.1AR-2018, but rather a 
SHOULD.
And, that's not the point at all, really.
IF you want to do BRSKI, then you MUST include a serialNumber in the DN.

802.1AR-2009, has section 7.2.8:

7.2.8 subject
  The DevID subject field shall uniquely identify the device associated
  with the particular DevID credential within the issuer’s domain of
  significance. The formatting of this field shall contain a unique X.500
  Distinguished Name (DN). This may include the unique device serial
  number assigned by the manufacturer or any other suitable unique DN
  value that the issuer prefers. In the case of a third-party CA or a
  standards certification agency, this can contain the manufacturer’s
  identity information.

  The subject field’s DN encoding should include
  the “serialNumber” attribute with the device’s unique serial number.

Note lack of RFC2119 language (or a reference to it).

So if the 2018 has "SHOULD" here, then that's a strengthing of the language,
not a weaking.   The first paragraph does have weasel words "any other
suitable unique DN", but I really think that a serialNumber DN attribute
(as opposed to the serialNumber certificate attribute) is needed for BRSKI
to interoperate well.

If someone has a 10 million devices in the field which can be field upgraded
to run BRSKI (while still in a not-yet enrolled state in a box), then let's
talk about this.  Maybe it's actually 10,000,000 TPM devices with IDevIDs
already generated, but no serialNumber in it.  Getting the JRC code right
to do other things can be a pain, but it can be done.

-- 
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Toerless Eckert]

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 +, 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: tte+i...@cs.fau.de
> Cc: Ruan, Xiaoyu ; Jayanna, Prabhu 
> ; Mendelson, Tsippy 
> 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,
>      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: +972-2-589-2468
> Cellular: +972-54-7885061
> 
> 
> 
> 
> -
> 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
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima


-- 
---
t...@cs.fau.de

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Mendelson, Tsippy]

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: tte+i...@cs.fau.de
Cc: Ruan, Xiaoyu ; Jayanna, Prabhu 
; Mendelson, Tsippy 
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,
  .
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: +972-2-589-2468
Cellular: +972-54-7885061




-
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
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima