Subject: [rtcweb] JSEP: multiple fingerprints for a certificate

From: Bernard Aboba <[email-masked]>
Date: Wed, 24 Aug 2016 14:19:46 -0700

Currently JSEP references RFC 4572, not draft-ietf-mmusic-rfc4572-update.

As a result, JSEP reiterates requirements from RFC 4572, such as the
following:

      the digest algorithm used
      for the fingerprint MUST match that used in the certificate
      signature.

During the August 23 WEBRTC WG interim, a question arose as to whether
the IETF RTCWEB WG intends to revise JSEP to reference
draft-ietf-mmusic-rfc4572-update and its allowance of multiple
fingerprints per certificate.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Aug 2016 06:06:46 +0000

Hi Bernard,

>As a result, JSEP reiterates requirements from RFC 4572, such as the following:
>

> During the August 23 WEBRTC WG interim, a question arose as to whether the IETF RTCWEB WG intends to revise JSEP to reference draft-ietf-mmusic-rfc4572-update and its allowance of multiple fingerprints per certificate.

A generic question: as draft-ietf-mmusic-rfc4572-update updates RFC 4572, do we need to explicitly reference the draft? By referencing RFC 4572, don’t we also implicitly reference any specification that updates the RFC?

This is an important question, because we also reference other RFCs that have been updated by recent drafts, and we need to make sure the updates apply.

Regards,

Christer

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 25 Aug 2016 00:10:18 -0700

Christer --

If the intent is to continue to impose the RFC 4572 restrictions, then the
JSEP text enforcing those restrictions is fine, as is the current JSEP
reference to RFC 4572.

However, if the desire of the WG is to remove those restrictions and allow
multiple fingerprints per certificate, then JSEP text quoting from RFC 4572
needs to be removed - and a reference to RFC 4572 update is required which
validates that loosening.

On Wed, Aug 24, 2016 at 11:06 PM, Christer Holmberg <
[email-masked]> wrote:

> A generic question: as draft-ietf-mmusic-rfc4572-update updates RFC 4572,
> do we need to explicitly reference the draft? By referencing RFC 4572,
> don’t we also implicitly reference any specification that updates the RFC?
>
> This is an important question, because we also reference other RFCs that
> have been updated by recent drafts, and we need to make sure the updates
> apply.
>
> Regards,
>
> Christer
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Aug 2016 07:17:45 +0000

Hi,

>If the intent is to continue to impose the RFC 4572 restrictions, then the JSEP text enforcing those restrictions is fine, as is the current JSEP reference to RFC 4572.
>
>However, if the desire of the WG is to remove those restrictions and allow multiple fingerprints per certificate, then JSEP text quoting from RFC 4572 needs to be removed - and a reference to RFC 4572 update is required which validates that loosening.

I do agree that the text in JSEP shall not restrict usage of multiple fingerprints, and any quoted text should be from 4572-update.

My question is whether we need to explicitly add a reference to 4572-update for that, or whether 4572-update is implicitly referenced by referencing RFC 4572. I don’t really care which way we do – I just want to know :)

Regards,

Christer

On Wed, Aug 24, 2016 at 11:06 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi Bernard,

Regards,

Christer

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 25 Aug 2016 09:04:12 -0600

The JSEP authors have typically tried to have JSEP ref everything that implementers need to know just to make it easier for them to find it. I will add a ref to draft-ietf-mmusic-4572-update to JSEP.  Given it is an "update" it technical is a dependency either way. 

Clearly we want the WebRTC spec to work for where the IETF is going with 4572-update

I do think we need some discussion in mmusic about what the right thing with this update is. 

> On Aug 25, 2016, at 1:17 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
> On Wed, Aug 24, 2016 at 11:06 PM, Christer Holmberg <[email-masked]> wrote:
>> Hi Bernard,
>> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Aug 2016 15:11:34 +0000

Hi,

>The JSEP authors have typically tried to have JSEP ref everything that implementers >need to know just to make it easier for them to find it. I will add a ref to draft-ietf->mmusic-4572-update to JSEP.  Given it is an "update" it technical is a dependency >either way. 

Ok. That means we also need to reference a number of other "update" drafts that affect JSEP, but I think I sent you a list of those already?

Regards,

Christer

>Clearly we want the WebRTC spec to work for where the IETF is going with 4572->update
>
>I do think we need some discussion in mmusic about what the right thing with this >update is. 

> My question is whether we need to explicitly add a reference to 4572-update for that, or whether 4572-update is implicitly referenced by referencing RFC 4572. I don't really care which way we do - I just want to know :)
> 
> Regards,
> 
> Christer
> 
> 
> 
>> A generic question: as draft-ietf-mmusic-rfc4572-update updates RFC 4572, do we need to explicitly reference the draft? By referencing RFC 4572, don't we also implicitly reference any specification that updates the RFC?
>>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 25 Aug 2016 09:34:04 -0600

> On Aug 25, 2016, at 9:11 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

I thought I got everything on your list in latest version but pleas have a look and see what else is missing. Greatly appreciate you checking this and helping track down any more updates. 

Here's the list of things I think that WebRTC normatively depends on so if we have "updates" to any of these, I should add them 

draft-ietf-avtcore-multi-media-rtp-session
draft-ietf-avtcore-rtp-circuit-breakers
draft-ietf-avtcore-rtp-multi-stream
draft-ietf-avtcore-rtp-multi-stream-optimisation
draft-ietf-avtext-rid
draft-ietf-avtext-sdes-hdr-ext
draft-ietf-ice-dualstack-fairness
draft-ietf-ice-rfc5245bis
draft-ietf-ice-trickle
draft-ietf-mmusic-ice-sip-sdp
draft-ietf-mmusic-msid
draft-ietf-mmusic-mux-exclusive
draft-ietf-mmusic-rid
draft-ietf-mmusic-sctp-sdp
draft-ietf-mmusic-sdp-bundle-negotiation
draft-ietf-mmusic-sdp-mux-attributes
draft-ietf-mmusic-sdp-simulcast
draft-ietf-payload-flexible-fec-scheme
draft-ietf-rtcweb-alpn
draft-ietf-rtcweb-data-channel
draft-ietf-rtcweb-data-protocol
draft-ietf-rtcweb-fec
draft-ietf-rtcweb-jsep
draft-ietf-rtcweb-overview
draft-ietf-rtcweb-rtp-usage
draft-ietf-rtcweb-security
draft-ietf-rtcweb-security-arch
draft-ietf-rtcweb-transports
draft-ietf-tsvwg-rtcweb-qos
draft-ietf-tsvwg-sctp-dtls-encaps
draft-ietf-tsvwg-sctp-ndata
draft-ietf-ice-trickle
draft-ietf-tram-stunbis
draft-ietf-avtcore-5761-update
draft-ietf-mmusic-4572-update
draft-ietf-mmusic-dtls-sdp
draft-ietf-avtcore-rfc5764-mux-fixes

RFC1889
RFC2198
RFC2327
RFC3264
RFC3388
RFC3389
RFC3489
RFC3550
RFC3551
RFC3555
RFC3556
RFC3605
RFC3611
RFC3711
RFC3758
RFC3890
RFC4145
RFC4566
RFC4570
RFC4571
RFC4572
RFC4585
RFC4588
RFC4733
RFC4756
RFC4820
RFC4895
RFC4961
RFC5052
RFC5053
RFC5061
RFC5104
RFC5109
RFC5124
RFC5245
RFC5285
RFC5389
RFC5506
RFC5576
RFC5583
RFC5705
RFC5761
RFC5763
RFC5764
RFC5766
RFC5768
RFC5888
RFC5928
RFC5956
RFC6051
RFC6062
RFC6096
RFC6156
RFC6184
RFC6188
RFC6236
RFC6263
RFC6330
RFC6363
RFC6364
RFC6464
RFC6465
RFC6520
RFC6525
RFC6544
RFC6555
RFC6562
RFC6681
RFC6682
RFC6716
RFC6749
RFC6904
RFC6951
RFC7022
RFC7053
RFC7064
RFC7065
RFC7104
RFC7160
RFC7164
RFC7301
RFC7496
RFC7587
RFC7635
RFC7639
RFC7657
RFC7667
RFC7675
RFC7728
RFC7741
RFC7742
RFC7850
RFC7874
RFC6336
RFC7350
RFC6365
RFC7564
RFC5198
RFC7564
RFC7613
RFC7345