Subject: [sacm] Endpoint ID Design Team Notes: 2015-05-08

From: "Adam W. Montville" <[email-masked]>
Date: Fri, 8 May 2015 10:32:26 -0500

Agenda
ID Characteristics Spreadsheet
At least the following discussions:
Multiplicity
Is immutability necessary?
Decompose credentials?
Combining slides for virtual interim

Materials (including recordings) are available here
https://www.dropbox.com/sh/bs0hioy5qh6qzr1/AAA2lzSwCFE_pfYMlpP3bRu_a?dl=0

To all: Please take some time to review the Excel sheet available at the Dropbox URL above, as we’ll be introducing it during the virtual interim.  The name of the file is “SACM Endpoint Id Properties v3.xlsx”.  

NOTES
Dave’s going through his Excel sheet (AVAILABLE at above URL).  We looked at properties/characteristics of “identifying attributes” and discovered four of particular interest:
Multiplicity: How many endpoints does the attribute seek to identify or relate to?
Persistence: How often does something change?
Immutability: How permanent is the attribute value (how easily can it be changed)?
Verifiability: Can an external-to-sacm-component verify a given attribute?

Lisa brings up the 1:* relationship we have (initially) listed for cryptographic IDs.  Machine certificates are expected to be 1:1, user certificates could be 1:*.  The bottom line is that some of these relationships will require that the attributes are sufficiently decomposed so that we arrive at a true multiplicity statement.

Lisa is saying that there are two ways something can be “hardware rooted”.  One way is if it’s represented in hardware, another is if it’s rooted in some piece of hardware such as a certificate in a TPM.  Essentially, “baked into a hardware” or “protected by a TPM”, where “protected by a TPM” is not as rooted as “baked into hardware”.

Henk is challenging the semantics of this approach, because things can get tricky at the edge.  Things, even when they seem “rooted” can be changed.

We may want to break out certificates further (Lisa).  There are machine certificates rooted in a TPM, there are some not rooted in TPM.  There are others rooted or not in TPM.  The verifiability of these are also affected.  The immutability of a host certificate is arguably higher than the immutability of a user or other certificate.

Lisa on splitting immutability.  How difficult and how likely.  The difficulty would be the difference between HW rooted and non HW rooted.  This discussion resulted in some changes to the spreadsheet to further decompose the proposed identification attributes and their related properties.

Henk made the point that “verifiability” is, at present, only “external”.  It’s not clear whether we should have any sort of “internal verifiability”.  

Ron is mentioning that management tools might help for verifiability.  Dave suggests that we may not be going for “trust in tools” with this exploration.  Instead, we’re trying to see if there are attribute properties that offer verifiability to some degree.

We are discussing changing “verifiable” to “corraboratable”.  

THE QUESTION TO ANSWER: Are these attribute properties/characteristics appropriate as a way to describe the degree to which the attribute can serve as an identifying attribute?

Have we answered the above question?  It seems that we have, though further exploration is still required.

---

From: Jerome Athias <[email-masked]>
Date: Fri, 8 May 2015 20:14:08 +0300

Hi,

should geolocation attributes be considered?

Best regards

2015-05-08 18:32 GMT+03:00 Adam W. Montville <[email-masked]>:
> To all: Please take some time to review the Excel sheet available at the
> Dropbox URL above, as we’ll be introducing it during the virtual interim.
> The name of the file is “SACM Endpoint Id Properties v3.xlsx”.
>
> NOTES
> Dave’s going through his Excel sheet (AVAILABLE at above URL).  We looked at
> properties/characteristics of “identifying attributes” and discovered four
> of particular interest:
>
> Lisa brings up the 1:* relationship we have (initially) listed for
> cryptographic IDs.  Machine certificates are expected to be 1:1, user
> certificates could be 1:*.  The bottom line is that some of these
> relationships will require that the attributes are sufficiently decomposed
> so that we arrive at a true multiplicity statement.
>
> Lisa is saying that there are two ways something can be “hardware rooted”.
> One way is if it’s represented in hardware, another is if it’s rooted in
> some piece of hardware such as a certificate in a TPM.  Essentially, “baked
> into a hardware” or “protected by a TPM”, where “protected by a TPM” is not
> as rooted as “baked into hardware”.
>
> Henk is challenging the semantics of this approach, because things can get
> tricky at the edge.  Things, even when they seem “rooted” can be changed.
>
> We may want to break out certificates further (Lisa).  There are machine
> certificates rooted in a TPM, there are some not rooted in TPM.  There are
> others rooted or not in TPM.  The verifiability of these are also affected.
> The immutability of a host certificate is arguably higher than the
> immutability of a user or other certificate.
>
> Lisa on splitting immutability.  How difficult and how likely.  The
> difficulty would be the difference between HW rooted and non HW rooted.
> This discussion resulted in some changes to the spreadsheet to further
> decompose the proposed identification attributes and their related
> properties.
>
> Henk made the point that “verifiability” is, at present, only “external”.
> It’s not clear whether we should have any sort of “internal verifiability”.
>
> Ron is mentioning that management tools might help for verifiability.  Dave
> suggests that we may not be going for “trust in tools” with this
> exploration.  Instead, we’re trying to see if there are attribute properties
> that offer verifiability to some degree.
>
> THE QUESTION TO ANSWER: Are these attribute properties/characteristics
> appropriate as a way to describe the degree to which the attribute can serve
> as an identifying attribute?
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: Ira McDonald <[email-masked]>
Date: Fri, 8 May 2015 15:04:20 -0400

Hi,

>From the perspective of mobile devices (and even hardcopy printers, my
other world),
three kinds of "location" attributes are important:

(1) Geolocation - just use RFC 5870 'geo' URI specification
(2) Physical location - string such as "north end of 2nd floor, Abbot
building"
(3) Network location - subnet and/or overlay network topological location

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Fri, May 8, 2015 at 1:14 PM, Jerome Athias <[email-masked]>
wrote:

> > Have we answered the above question?  It seems that we have, though
> further
> > exploration is still required.
> >
> >
> >
> >
> >
> >