httpslocal -- 19 Sep 2019

<YoshiroYoneya> scribe: urata

<YoshiroYoneya> Chair: YoshiroYoneya

<YoshiroYoneya> Agenda: https://github.com/httpslocal/group/wiki/Meeting2019Sep19TPAC

<YoshiroYoneya> Scribe: urata

<ajitomi> CG report 1: use cases and requirements: https://httpslocal.github.io/usecases/

<ajitomi> CG report 2: approaches for achieving HTTPS in Local Network: https://httpslocal.github.io/proposals/

yoneya: opening talk
... made some progress from last year's meeting
... 1st part : CG report update

kajiwara: update on CG report

kaji: CG report is finally ready
... last year talked about requirements
... publishing 2 reports

https://github.com/httpslocal/group/blob/master/20190919_F2F_TPAC2019/httpslocal-cg-report-progress.pdf

kaji: added non-cross-origin cases
... clarified HTTPS term in document
... refined requirement
... reorganaized use cases
... existing solutions: Mozilla's Thins Gateway
... new approaches:
... name constraints
... another candidate: private domain names:
... PAKE-based, ACE/OAuth based
... browser vendor feedback is welcomed
... releasing CG report
... duscussion items
... comments on feasibility, relistic or not, welcomed

joe_andrew: use case without internet access in scope?

ajitomi: covered in usecase 6

ja: usecase is making camera accessible

Okubo: how to manage trust store?

kaji: users should not to add certificate manually

ajitomi: raw public key is one method

xxx: how about trust anker?
... how would I know which cert to trust?

aji: use rpk based on use consent

xxx: certificate itself is trustworthy or not is the point

aji: device vendor checks attestation key

xxx: vendor may not be able to do that

okubo: specific reserved domain may be usable

benfrancis: consider hardware key pairgin?

aji: approach 4 is FIDO based

yone: next agenda: new work

ito: for local devices ca can't issue cert
... because not able to validate domain. local device is not reachable from ca.

<ajitomi> new approach based on technically constrainted certificate: https://httpslocal.github.io/proposals/#web-pki-approaches

ito: exceptional way may be usable
... technical constraints cert
... with tenical constraints and issue cert
... able to issue e.g. Device1.camera.example.com with local ip address
... ca is able to issue this kind of cert
... example usecase:
... ca can issue less than 2 year cert
... itf flat something may work
... need some method to put cert in device, there should be many ways, e.g. QR code
... public DNS server redirect the DNS requeuset to dynamic DNS
... ito: techincal constraints certificate works like this

igarashi: how QR code is initiated?
... when a user need to read QR code?

ito: should be first time using the device and also, the timing of cert update.

okubo: ACME could be used and it may be natural way

mizushima: how about domain validation?

ito: server cert influence many uses, client cert influence to single user

igarashi: this group focus on client/server model, isn't it?

ito: mechanism to install end use cert to device
... attestation mechanism
... need revocation mechanism for devices for unauth cert
... case of local network is offline, good for security
... this case is publick ca for local network

sudeep: comment: local network may include LTE. such carrier network may be one use case

yone: next agenda: discussion

last page of https://github.com/httpslocal/group/blob/master/20190919_F2F_TPAC2019/httpslocal-cg-report-progress.pdf

discussion items:

<YoshiroYoneya> DID WG, WoT WG will be useful to follow.

<JoeAndrieu> Please consider joining or at least following the work at the Decentralized Identifier Working Group (DIDWG) https://www.w3.org/2019/did-wg/ This group is developing cryptographic identifiers with decentralized roots of trust (typically using blockchain technology, but there are other approaches). We were just chartered and have an early draft at https://w3c.github.io/did-spec/ There is work being done towards making these usable for TLS conn[CUT]

<JoeAndrieu> some support and interest from browser companies--but it is early yet. The Web of Things Working Group is also considering how to use DIDs for local device communications. https://www.w3.org/WoT/WG/ They may have approaches that can support the work going on here.

<YoshiroYoneya> Web Network CG is also thinking about edge network.

sundeep: offload from edge would be applicable use case

kaji: this cg will talk with wot wg tomorrow

JoeAndrieu: https with private domains.. would be viable. below the https layaer but browser may be able to.

horiuchi_: realisticity depend on whether create client

uuu: depend on origins but skeptical. not subset of origins but think about new origin

igarashi: how to guarantee uniqueness of origin?
... uniquness means not overlapping of origins

ajitomi: think to need to add force origin such as random numbe or something which can be fingerprint
... ito-san's case is globally unique name
... many printer.local may exists all over the world but browser have to distiguish each

benfrancis: don't overloaded as concept of origin. locally distiguishable

<YoshiroYoneya> Don't overload the concept of "ORIGIN".

JoeAndrieu: ssh in local network works as tofu

<JoeAndrieu> tofu = Trust on First Use

YoshiroYoneya: group direction: WG, IG or work with DID, Web and Network IG

JoeAndrieu: writing use case in DID and like to use some of these usecases in DID

ryo-k_: suggestion about direction

YoshiroYoneya: any other comments, suggestions

JoeAndrieu: usecase writing is important. like to cowork as DID if needed

ajitomi: from toshiba. wrap up
... release CG report at Dec2019 but many issues are remaining
... suggestion from Marin from Mozilla for merging
... device discovery made as optional
... group is discussing on github and feel free to join

YoshiroYoneya: then group work to publish CG report at end of this year
... ending remark

- DRAFT -

httpslocal

19 Sep 2019

Attendees

Contents

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output