[stir] Re: Update for STIR CT and new draft Vesper for discussion

[Chris Wendt <[e-mail]>]

Hi Henk,

I think there may be a path for including CWT, but to be honest the SIP/telecom community in general is used to text based payloads in general and is now just getting conceptually comfortable with JWT in PASSporTs, so adding binary encoding and CWT may or may not be a big conceptual ask to swollow.  But I think it’s a fair question, and would love to hear others opinions on this.  Size of payload had had a bit of a debate early on in STIR, but at the end has become mostly tolerable in most implementations and not a big concern.

-Chris

> On Jul 16, 2024, at 10:08 PM, Henk Birkholz <[e-mail]> wrote:
> 
> Dear authors,
> 
> I followed a trail of shiny crumbs to this I-D action. I skimmed the I-D and I am wondering, is it in the scope of the STIR charter to register CWT and JWT Claims in one swoop? That would eliminate the need to do a parallel I-D, just for the CWT equivalent.
> 
> 
> Viele Grüße,
> 
> Henk
> 
> On 15.07.24 20:04, Chris Wendt wrote:
>> Hello STIR WG,
>> Just wanted to let everyone know about two document updates that we plan to discuss at the meeting next week.
>> First, we have created an 03 latest update of draft-wendt-stir-certiifcate-transparency.   We took some of the feedback received at the meeting at 119 and rather than try to align with the webpki certificate transparency RFC too closely, we moved to be more opinionated about what certificate transparency scheme would match current practices of STIR eco-systems.  Please let us know if you have any comments and join the discussion at the 120 meeting.
>> Name:     draft-wendt-stir-certificate-transparency
>> Revision: 03
>> Title:    STI Certificate Transparency
>> Date:     2024-07-08
>> Group:    Individual Submission
>> Pages:    13
>> URL: https://www.ietf.org/archive/id/draft-wendt-stir-certificate-transparency-03.txt <https://www.ietf.org/archive/id/draft-wendt-stir-certificate-transparency-03.txt>
>> Status: https://datatracker.ietf.org/doc/draft-wendt-stir-certificate-transparency/ <https://datatracker.ietf.org/doc/draft-wendt-stir-certificate-transparency/>
>> HTML: https://www.ietf.org/archive/id/draft-wendt-stir-certificate-transparency-03.html <https://www.ietf.org/archive/id/draft-wendt-stir-certificate-transparency-03.html>
>> HTMLized: https://datatracker.ietf.org/doc/html/draft-wendt-stir-certificate-transparency <https://datatracker.ietf.org/doc/html/draft-wendt-stir-certificate-transparency>
>> Diff: https://author-tools.ietf.org/iddiff?url2=draft-wendt-stir-certificate-transparency-03 <https://author-tools.ietf.org/iddiff?url2=draft-wendt-stir-certificate-transparency-03>
>> Abstract:
>>   This document describes a framework for the use of the Certificate
>>   Transparency (CT) protocol for publicly logging the existence of
>>   Secure Telephone Identity (STI) certificates as they are issued or
>>   observed.  This allows any interested party that is part of the STI
>>   eco-system to audit STI certification authority (CA) activity and
>>   audit both the issuance of suspect certificates and the certificate
>>   logs themselves.  The intent is for the establishment of a level of
>>   trust in the STI eco-system that depends on the verification of
>>   telephone numbers requiring and refusing to honor STI certificates
>>   that do not appear in a established log.  This effectively
>>   establishes the precedent that STI CAs must add all issued
>>   certificates to the logs and thus establishes unique association of
>>   STI certificates to an authorized provider or assignee of a telephone
>>   number resource.  The primary role of CT in the STI ecosystem is for
>>   verifiable trust in the avoidance of issuance of unauthorized
>>   duplicate telephone number level delegate certificates or provider
>>   level certificates.  This provides a robust auditable mechanism for
>>   the detection of unauthorized creation of certificate credentials for
>>   illegitimate spoofing of telephone numbers or service provider codes
>>   (SPC).
>> I’d also like to let everyone know about a new draft we also want to discuss related to certificate transparency, but more aligned with ways of representing entity vetting and right-to-use (RTU) of telephone numbers in the form of a “vesper” token.  It incorporates some of the ideas and technologies being discussed in SCITT and SPICE and we think is also relevant in particular for RCD and VCON as well.  The draft is linked below, and will plan to spend some time to introduce this at 120 meeting.
>> Name:     draft-wendt-stir-vesper
>> Revision: 00
>> Title:    VESPER - VErifiable STI Personas
>> Date:     2024-06-25
>> Group:    Individual Submission
>> Pages:    17
>> URL: https://www.ietf.org/archive/id/draft-wendt-stir-vesper-00.txt <https://www.ietf.org/archive/id/draft-wendt-stir-vesper-00.txt>
>> Status: https://datatracker.ietf.org/doc/draft-wendt-stir-vesper/ <https://datatracker.ietf.org/doc/draft-wendt-stir-vesper/>
>> HTML: https://www.ietf.org/archive/id/draft-wendt-stir-vesper-00.html <https://www.ietf.org/archive/id/draft-wendt-stir-vesper-00.html>
>> HTMLized: https://datatracker.ietf.org/doc/html/draft-wendt-stir-vesper <https://datatracker.ietf.org/doc/html/draft-wendt-stir-vesper>
>> Abstract:
>>   This document extends the STIR architecture by specifying the use of
>>   JSON Web Tokens (JWT) and Selective Disclosure JWT (SD-JWT) for
>>   representing persona related information intended to be the output of
>>   a Know Your Customer (KYC) or Know Your Business (KYB) type of
>>   vetting process.  It defines entities called Vetting Agents (VA) that
>>   perform a vetting of persona related information and can issue a
>>   verifiable token bearing the VA signature, containing information
>>   that can be disclosed or selectively disclosed to an interested
>>   party.  The Vetted Entity (VE) can hold this token in selectively
>>   disclosable forms to disclose specific information to the third
>>   parties.  The vesper token enables the delivery and verification of
>>   information with privacy protecting mechanism in a complete,
>>   selective or zero knowledge manner specifically supported by the SD-
>>   JWT.  This document also describes an API standard to be supported/
>>   hosted by a Vetting Agent (VA), which allow vetted parties to present
>>   tokens proving their KYC/KYB conformance, and incorporates proof of
>>   possession to ensure the legitimacy of the entity presenting the
>>   token.
>> Thanks!!
>> -Chris
> 
> _______________________________________________
> stir mailing list -- [e-mail] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>