Re: [Secret] Follow up on Michael's Comments

Hi Michael,

Thank you for your feedback, questions and comments.

Here is a link to the CCC:
https://carconnectivity.org/digital-key/ <https://carconnectivity.org/digital-key/>

Referring to the name, I do believe Francesca and other ADs are working on changing the name away from “SECRET”.

I wasn’t sure exactly how much information should go into the Charter - but I can look at revising it a bit if you think it’s still unclear.

I do think some of the answers to your questions, and discussion points around them, might be better suited for the Working Group rather than informally over email.

In the case of a symmetric transfer such as an HID credential, we’d be transferring a set of data generated by HID that acts as a “voucher” of sorts.

This would be transferred from sender to recipient and then the recipient would “redeem” that with HID for a real, newly minted credential.

I think we can certainly go into additional detail on the WG, once it’s established. It’s challenging to discuss over email.

Thanks
Matt

> On Mar 5, 2022, at 9:06 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> 
> Please know that I'm not hostile to this work occuring.
> I just don't want to confuse people about the goals.
> (Although I really don't like the choice of BOF name)
> 
> I'm please to learn that there are protocols like SCP03, and that they handle
> delegation.  This is sorely missing in what people see today iin IoT.
> 
> I'd love to have an overview talk at IOTOPS about SCP03 and the CCC
> automotive credential protocol.
> 
> Matthew Byington <mbyington@apple.com> wrote:
>> An example of an asymmetric credential would be digital car key
>> credentials adhering to the CCC standard, or asymmetric credentials
>> used in Home or MFH (multi-family home) that adhere to the ISO18013
>> open standard.
> 
> Could you please cite the specific CCC document involved?
> ISO18013 is not publically available.
> 
>> In _no_ circumstance shall a private key, nor a symmetric secret key,
>> ever, ever be transferred to anyone else.
> 
> ...
>> In these cases, to your point, the third party would absolutely have to
>> issue the credential for the intended recipient.
> 
> So, how are we involved at all?
> 
>> The transfer protocol that we endeavor to standardize would simply facilitate that.
> 
> What would we be transfering, in a symmetric key case, where HID has to issue
> the credential?
> 
>> I don’t want to get into the solutioning here too much (let’s save that
>> for the WG) but you can almost think about it like:
> 
>> 1) Sender (with existing provisioned credential from remote credential
>> authority) asks the RCA for a “bearer token”
> 
> While one can implement Bearer Tokens as indexes into database (instead of a
> key that decrypts something like a Kerberos Ticket), by their nature, they
> have all the privacy implications of symmetric keys.
> 
>> 2) RCA issues bearer token (could be a signed piece of data, could be a
>> UUID, etc) and on their backend, ties that to the access rights/levels
>> specific to a subset of what the sender has, based on the sender’s
>> existing rights and the sender’s desired rights for the recipient
> 
>> 3) The RCA returns this BT to the sender.
>> 4) The sender sends this BT to the receiver thru the transfer protocol we’d define in the WG
>> 5) The recipient calls the credential authority and “redeems” this for
>> a valid provisioned credential with key material completely separate
>> from the sender’s.
> 
> This sure sounds a lot like OAUTH2 to me :-)
> Perhaps it would all work better if we explicitely used the terminology from
> OAUTH2.
> 
>> The security of (5) is well-established today with protocols like JCOP
>> platform running on a  device, SCP03 (secure channel protocol
>> encryption) etc etc that exist on most mobile devices today. That is
>> completely out of the scope of the transfer work flow.
> 
> Okay, then I think that we need some high-level explanation of these
> protocols.  I'd like to see the charter reference them with "such as..."
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> -- 
> Secret mailing list
> Secret@ietf.org
> https://www.ietf.org/mailman/listinfo/secret