Re: [scim] I-D Action: draft-ietf-scim-device-model-03.txt

[Eliot Lear <[e-mail]>]

Hi Monty,

Actaully I agree with what you write.  As you'll hear today, this is 
work to be done, but I don't think it's a lot of work.  The only *real* 
issue is whether versioning should be internalized to the module name or 
separated.

Eliot

On 18.03.2024 02:59, Monty Wiseman wrote:
> I can include an approach for using TCG-defined device identity (as 
> provided in the links below) but I have a broader concern. This draft 
> includes a specific set of device Extensions for specific 
> implementations but doesn't appear to to be extensible. What if a new 
> method comes along (or a modification of an existing one. I recommend 
> we take the approach we just did for the csr-attestion in LAMPS where 
> there is a need to provide attestations from many types of components 
> (TPM being just one example). There is a place specified in the spec 
> where an OID is provided to identify the type of attestation_statement 
> is being provided and we (LAMPS) will be requesting an IANA registry 
> for those. This way the RFC is extensible. See: 
> https://datatracker.ietf.org/doc/draft-ietf-lamps-csr-attestation/
>
> Monty Wiseman
> Security Architect, Beyond Identity
> www.beyondidentity.com
>
> On 24/03/05 18:58, Eliot Lear wrote:
>> Hi Monty
>>
>> To get things in, I think the general approach should to indicate, at 
>> least briefly, what the semantics of the server would be.  So for 
>> instance, for DPP the semantics involve getting the QR code 
>> components to the DPP controller so that when a device "chirps", it 
>> can perform the authentication exchange.
>>
>> What would those semantics be here?  Would it simply be to insert a 
>> certificate root and, say, Subject bound by that root, into an 
>> EAP-TLS/TEAP process?  At which point, the two SCIM data objects 
>> would be something like a trust anchor (or a URL to it) and then a 
>> Subject or SAN or some such.
>>
>> Eliot
>>
>> On 05.03.2024 00:33, Monty Wiseman wrote:
>>> There should be a Device Extension for TCG-defined TPM-based 
>>> devices. There is a "Platform Certificate" and "TPM2 Key for device 
>>> Identity" (802.1ar keys in TPM) x.509-based certificate defined by 
>>> Trusted Computing Group (TCG) that defines a particular device and 
>>> includes supply chain assurance back to the manufacturer. I'd be 
>>> willing to contribute.
>>>
>>> https://trustedcomputinggroup.org/wp-content/uploads/IWG_Platform_Certificate_Profile_v1p1_r19_pub_fixed.pdf 
>>>
>>>
>>> https://trustedcomputinggroup.org/wp-content/uploads/TPM-2p0-Keys-for-Device-Identity-and-Attestation_v1_r12_pub10082021.pdf 
>>>
>>>
>