Re: [Secret] Call for consensus on updated charter

[Brad Lassey <[e-mail]>]

I support the charter and I'm willing to review WG drafts. We (Google) are
planning on implementing these drafts.

-Brad


On Thu, Jun 16, 2022 at 9:39 AM Prachi Jain <[e-mail]>
wrote:

> I support the charter and am willing to help with it.
>
> 1) Do you support the charter text? Or do you have objections or blocking
> concerns (please describe what they might be)?
> Yes and no concerns
> If you do support the charter text:
> (2) Are you willing to author or participate in the developed of the WG
> drafts? yes
> (3) Are you willing to review the WG drafts? yes
> (4) Are you interested in implementing the WG drafts? yes
>
>
> -Prachi
>
> On Tue, Jun 14, 2022 at 5:24 PM Roman Danyliw <[e-mail]> wrote:
>
>> Hi!
>>
>> In February 2022, the virtual SECRET BOF was convened [1].  We had a
>> robust discussion on the scope of work and an initial charter presented --
>> see the minutes [2].  Polling of the BoF participants showed a healthy
>> consensus on understanding of the problem and interest to solve it in the
>> IETF.  There also appeared to be a critical mass of energy to do this work.
>>
>> The BoF feedback and subsequent AD review pointed to a few places for
>> refinement to the charter, to include changing the proposed name of the
>> WG.  That version is included below for your review.
>>
>> The participants in the BoF showed consensus to proceed with chartering a
>> WG.  Now with a revised charter, I'd like to continue this BoF conversion
>> with an email thread to gauge interest to forming a WG to ensure we also
>> capture views from those who were unable to attend the BoF or those who
>> want to reiterate their positions.  Please respond to the list:
>>
>> (1) Do you support the charter text? Or do you have objections or
>> blocking concerns (please describe what they might be)?
>>
>> If you do support the charter text:
>> (2) Are you willing to author or participate in the developed of the WG
>> drafts?
>> (3) Are you willing to review the WG drafts?
>> (4) Are you interested in implementing the WG drafts?
>>
>> If you previously spoke of at the BoF, you are welcome to repeat yourself
>> here.
>>
>> If you have been following along on the mailing list, the charter text
>> below is the one that was being polished in GitHub (
>> https://github.com/dimmyvi/secure-credential-transfer/blob/main/charter.md)
>> with the milestones moved to the end.
>>
>> This call for feedback will end on Monday, June 27.
>>
>> Thanks,
>> Roman
>>
>> [1]
>> https://datatracker.ietf.org/meeting/interim-2022-secret-01/session/secret
>> [2]
>> https://datatracker.ietf.org/meeting/interim-2022-secret-01/materials/minutes-interim-2022-secret-01-202202100900-00.html
>>
>> ==[ snip ]==
>> WG Name = TIGRESS ("Transfer dIGital cREdentialS Securely")
>>
>> There are many situations in which it is desirable to transfer a copy of
>> a digital credential to another person. For example, you may want to
>> provide access to your vehicle to a friend or a family member. You may also
>> want to provide access to your home to your cat sitter. Or, you may want to
>> transfer a copy of a hotel key to your spouse. Today, no such standardized
>> method exists in a cross-platform, credential type-agnostic capacity.
>>
>> The WG charter includes the definition and standardization of a protocol
>> that will facilitate such credential transfers from one person's device to
>> another person's device. The protocol will leverage a "relay server" to
>> transfer data from sender to recipient. The scope of the transfer is
>> limited to a single origin device and a single destination device. Note
>> that neither private keys nor secret symmetric keys present on the sender's
>> device are exchanged during the transfer operation. In the transfer
>> protocol, the "credential" being transferred from sender to recipient
>> comprises data both necessary and sufficient for the recipient to exchange
>> with the credential authority for new digital key material granting the
>> recipient a subset of the sender's capabilities or entitlements.
>>
>> Privacy goals include:
>> * The relay server should not see sensitive details of the share
>> * The relay server should not be able to provision the credential itself,
>> acting as an intermediary for the recipient (person-in-the-middle,
>> impersonation attack)
>> * Aside from potentially the IP address, the relay server should not
>> learn the identity of the sender or receiver
>>
>> Sufficient security measures should be embedded in the protocol in an
>> effort to:
>> * Ensure only the intended recipient is able to provision the credential
>> * Ensure the credential can only be provisioned once (anti-replay)
>> * Ensure the sender has intent to share (proof of the fact that the share
>> initiation is attributed to a valid device and a user)
>>
>> The solution the WG comes up with must:
>> * Allow a sender to initiate a share and define a relay server
>> * Allow a recipient to view the share request, and provision the
>> credential associated with the share upon receipt
>> * Allow opaque message content based on the credential type (the protocol
>> should be able to carry various types of credentials)
>> * Allow sender device and receiver device to perform multiple round trip
>> communications within a limited time frame.
>> * Support a variety of types of credentials, to include those adhering to
>> public standards (e.g., Car Connectivity Consortium) and proprietary (i.e.,
>> non-public or closed community) formats
>> * Allow opaque message content based on the credential type
>>
>> Out of scope topics for the WG are:
>> * Defining the mechanism the receiver will use in order to provision the
>> credential with the credential authority
>> * The User Interface (UI) that is displayed to the sender or receiver
>> during sending or receiving - this will depend on the device OEM's UI and
>> HI guidelines.
>> * Defining the format or content of each field within the encrypted data
>> (i.e., the provisioned credentials and associated information) stored on
>> the relay server.
>>
>> The WG will deliver a protocol to facilitate secure credential transfer.
>> The WG must consider all Privacy and Security considerations in an effort
>> to perform the credential transfer in a secure manner. The protocol will
>> use appropriate cryptographic mechanisms to protect the transferred
>> credentials in accordance with the security and privacy goals described
>> above.
>>
>> Planned Deliverables:
>>
>> 2022-12: WG adoption of the secure credential transfer protocol
>> 2023-12: Submit secure credential transfer protocol to the IESG for
>> publication
>> ==[ snip ]=
>>
>> --
>> Secret mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/secret
>>
> --
> Secret mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secret
>