Minutes: STIR Virtual Interim September 20, 2019

== Attendees ==

Adam Roach, Andrew Gallant, Arleen Elliot, Ben Campbell, Bopsi Chandramouli,
Chris Wendt, Eric Burger, Hala Mowafy, Jon Peterson, Kevin Cassidy, Martin
Dolly, Mary Barnes, Michael Richardson, Mike Hamilton, Rich Salz, Rifaat
Shekh-Yusef, Robert Sparks, Russ Housley, Sathvik Prasad, Vijay Gurbani

== Agenda ==

Close open issues on:

    draft-ietf-stir-passport-rcd-04
    draft-ietf-stir-cert-delegation-00

== draft-ietf-stir-passport-rcd-04 ==

Chris presented updates in version 04.

Question: Should call-info/RCD be used together for the two main cases?

  1: Post-validation: Extract out identity headers towards UE  (e.g. eCNAM)
  2: compact-form (canonicalization from display-name and call-info) - needs
     further definition

Conclusions:  Align the RCD with call-info. Use call-inf as a mechanism to
define compact-form. Future extensions to call-info may need to align with RCD.
Need to make sure this really works—may need a separate “stub” draft.


Discussion: issues related to URL nesting in RCD. Issues include the
possibility of intentional abuse, the need for any vetting authority to verify
nested URIs, and the need to put reasonable limits on nesting.

Conclusions: The draft should guidance for the use of referenced content in
RCD, including the use of nested references. There are a number of
considerations here; the group needs some proposed text to discuss.

Discussion: Should the use of the “rcdi” mechanism should be normatively
required?

Conclusions: “MUST” use rcdi if the RCD includes referenced content (i.e.
Links). “MAY” use otherwise.

Discussion: Do we need 3 digest algorithms? Current algorithms align with existing passport signature algorithms.

Conclusions: Keep as is (i.e. keep the 3 algorithms)

Discussion: “icn” key vs using “logo” in a jcard.

Conclusions: Favor the jCard usage. jCard is more expressive  than the “icn”
key about the originator’s intent. jCard gives a better chance of having both
the sender and recipient interpret the content in the same context. We should
align with jCard as main mechanism for both RCD and call-info, but need to have
discussion in both areas to come to consensus.

Discussion: Is third-party RCD evil?

Conclusions: Not necessarily. There are reasonable use cases for third part
RCD. These may provide migration paths since not all call originators will be
able to sign their own RCD passports on day 1.

Discussion: Privacy Considerations.

Conclusions: The privacy considerations for RCD are mostly similar to those for
SIP headers. The same privacy mechanism should apply to RCD as the rest of the
SIP message. The main difference is the use of referenced content. The draft
should include privacy considerations related to referenced content.


== draft-ietf-stir-cert-delegation ==

Discussion: Should this work continue, given the controversy in other industry
groups about the best way to handle enterprise caller use cases?

Conclusions: Continue to progress the work. Industry likely to use multiple
solutions in parallel. Treat this as a tool in the toolbox that other groups
can use (or not) as they wish.


Discussion: How do OCN and tn blocks interact?

Conclusions: Typically parent cert contains the OCN and the child cert has TN
blocks, in which case the parent OCN constrains the childTN blocks. If a single
cert has both OCN and TN blocks, they are additive, that is, the OCN does not
constrains the TNs. This may need further discussion/clarification, as people
not involved in the discussion may have different interpretations.