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

Hi all,

I’ve put up a Pull Request adding clarifying text to the Charter in response to this discussion:
https://github.com/dimmyvi/secure-credential-transfer/pull/27 <https://github.com/dimmyvi/secure-credential-transfer/pull/27>

This was the last piece of feedback that came out of our BoF meeting a couple of weeks ago, so as soon as we can get some eyes on that PR to get it reviewed and merged, I think we should be good to go with regard to the Charter definition.

Thanks!
Matt

> On Feb 18, 2022, at 8:41 AM, Matthew Byington <mbyington=40apple.com@dmarc.ietf.org> wrote:
> 
> Hi Michael,
> 
> Apologies for the delay in getting back to you! 
> 
> I wanted to thank you for your comments and feedback.
> 
> I’m going to do two things today:
> 
> 1) Type up a bit of a longer email here in an effort to do a better job explaining how this might work, because it sounds like it really isn’t that clear yet.
> 2) Modify the charter text per your feedback to make it clear that we are *not* *ever* sharing any private key material.
> 
> Apologies in advance for the length of this email but I wanted to make sure that I explained it fully.
> 
> Context & Background
> 
> So, there are typically two types of credentials that you run into in the mobile digital credential space: symmetric credentials and asymmetric credentials.
> 
> An example of a symmetric credential is a MiFare DESFire credential (commonly used in transit application, hotels, and corporate settings).
> 
> 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.
> 
> The WG that we will establish aims to solve the sharing of both of these types of credentials. 
> 
> In _no_ circumstance shall a private key, nor a symmetric secret key, ever, ever be transferred to anyone else.
> 
> Symmetric
> 
> In the symmetric case, typically these are issued by remote credential authorities to your point in the email - for example if it’s a Hyatt credential that opens a hotel, Hyatt would be the one that issues the credential.
> 
> In the case of a digital key that lets a corporate employee enter a physical space such as a work building, the employer has an ACS (Access Control System) that is integrated into typically a third party provider (such as HID for example) and HID is the one issuing the credentials.
> 
> In these cases, to your point, the third party would absolutely have to issue the credential for the intended recipient.
> 
> The transfer protocol that we endeavor to standardize would simply facilitate that.
> 
> 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”
> 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.
> 
> 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.
> 
> Asymmetric
> 
> In this case, typically the credential authority (the entity that is issuing the credential) is actually *local*.
> 
> For example for Cars - the owner of the vehicle has an asymmetric key pair that is paired with the vehicle.
> 
> When that person shares, the exchange is basically:
> 
> 1) The sender initiates sharing to a recipient
> 2) The recipient generates an asymmetric key pair on their device with some form of attestation covering the public key, that proves it was generated on specific hardware (all of this is specific to CCC protocols)
> 3) The recipient sends the public key + attestation to the sender
> 4) the sender signs the receiver’s public key with their existing (paired with the vehicle) private key
> 5) Sender sends their signature back to the recipient
> 6) The recipient can then get into the vehicle because the vehicle trusts the owner’s signature which is covering the receiver’s public key.
> 
> obviously this is a gross simplification but hopefully helps illustrate that _no_ private keys are ever shared.
> 
> Next Steps
> 
> I will work on modifying the charter text today to make it more clear but I did want to provide some context over email.
> 
> Again, thanks so much for all of your comments!
> 
> Cheers,
> Matt
> -- 
> Secret mailing list
> Secret@ietf.org
> https://www.ietf.org/mailman/listinfo/secret