Subject: [MMUSIC] 4572 update: forbid weak hashes?

From: Jonathan Lennox <[email-masked]>
Date: Thu, 7 Apr 2016 12:31:41 +0000

Hi, all —

For the RFC 4572 update, I think we should add that receivers MUST NOT match on fingerprints computed with weak hashes, and senders SHOULD NOT send them.

If we do this, it removes some of the questions about “do you need to verify a fingerprint for every hash algorithm, or only one.”

Weak hashes definitely include MD2 and MD5.  I guess we still want SHA-1 to be supported, though?

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Apr 2016 13:35:07 +0000

Hi Jonathan,

>For the RFC 4572 update, I think we should add that receivers MUST NOT match on fingerprints >computed with weak hashes, and senders SHOULD NOT send them.
>
>If we do this, it removes some of the questions about “do you need to verify a fingerprint for every >hash algorithm, or only one.”

What about saying that one MUST match on the strongest hash received? 

Then, if you only receive a weak hash, isn't it still better to match than doing nothing?

>Weak hashes definitely include MD2 and MD5.  I guess we still want SHA-1 to be supported, though?

I'll let others decide on whether we still want to allow SHA-1, but the suggestion is to make SHA-256 the preferred one.

Regards,

Christer
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 7 Apr 2016 13:45:09 +0000

> On Apr 7, 2016, at 10:35 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Jonathan,
> 

Not if the hash is so weak it’s not secure, and a plausible implementation wouldn’t be using it.  Such an offer might be a bid-down attack of some sort.  You’re better off rejecting the stream.

> I'll let others decide on whether we still want to allow SHA-1, but the suggestion is to make SHA-256 the preferred one.

Oh, absolutely, no question.  But since 4572 preferred SHA-1, it probably needs to stay supported for some time.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Apr 2016 14:04:14 +0000

Hi,

>>> For the RFC 4572 update, I think we should add that receivers MUST NOT match on fingerprints >>> computed with weak hashes, and senders SHOULD NOT send them.
>>> 
>>> If we do this, it removes some of the questions about “do you need to verify a fingerprint for every >>> hash algorithm, or only one.”
>> 

Clarification: of the received hashes, the strongest one that the receiver support

>Not if the hash is so weak it’s not secure, and a plausible implementation wouldn’t be using it.  Such >an offer might be a bid-down attack of some sort.  You’re better off rejecting the stream.

Do we let the application decide what is considers "too weak", or do we want to specify something?

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Thu, 7 Apr 2016 11:06:08 -0300

> What about saying that one MUST match on the strongest hash received?

Maybe three pieces of advice are right.

1. Implement the strongest hash you can
2. Check all the hashes you can
3. Don't accept a session if you can only check weak hashes

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Apr 2016 14:08:57 +0000

Hi Martin,

I'd have to double check the MMUSIC minutes, but if I remember correctly people did not want to check multiple hashes (point 2).

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 7 Apr 2016 10:20:25 -0400

On Thu, Apr 7, 2016 at 10:08 AM, Christer Holmberg <
[email-masked]> wrote:

> I'd have to double check the MMUSIC minutes, but if I remember correctly
> people did not want to check multiple hashes (point 2).
>

You should check all the hashes you consider secure and if any one of them
matches the DTLS association certificate, accept the media.

It cannot not be the strongest hash or all the hashes that must match.
Either of those things are too restrictive and can break some scenarios.
Just as an example, consider that RTP and RTCP can come from two different
sources (devices) which will use different DTLS associations for each
component, use different certificates, and potentially support different
sets of hash functions. Because of this, the fact that RTP device supports
SHA-256 does not mean that RTCP will use it or support it.

Regards,
_____________
Roman Shpount

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 07 Apr 2016 11:00:03 -0400

> 3. Don't accept a session if you can only check weak hashes

I'm just now looking at this, but it seems to me that it is sufficient
for the receiver of the hashes to check any one hash that it considers
to have a sufficiently secure algorithm.  If the hash was sent to it,
that shows that the sender considers it to be secure enough.  (Of
course, if it does not receive any hash that it considers secure, the
receiver should reject the negotiation.)

There doesn't seem to be any reason for the receiver to check more than
one sufficiently secure hash.  Because it received them, the receiver
knows that the sender thinks both hashes are secure, and by hypothesis
the receiver thinks they are both secure, so every party to the
transaction expects that if one hash is valid, the other one will be.

Of course, we could allow the receiver to check multiple hashes if it
wishes...

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 7 Apr 2016 11:21:34 -0400

> 2. Check all the hashes you can

If you check the strongest hash you can and it succeeds, then what is 
the point of checking any others? The one check should be sufficient if 
there is only one stream. It is a bit more complex if there are multiple 
streams (e.g., RTP and RTCP).

How about:

1) implement as many as you can of hashes you consider strong enough.

2) for all the streams you are originating:
    include fingerprints using all the hashes you support.
    (Or is it ok to include fewer?)

3) for streams you are receiving:

3.1) discard any fingerprints using hashes you don't support,
      and any that you consider too weak to be trusted.

3.2) sort the remaining fingerprints, strongest hashes first.

3.3) for each stream, check fingerprints from the list in order
      until you find one that matches.
      Reject the session if none match.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Thu, 7 Apr 2016 15:08:57 -0400

On Thu, Apr 7, 2016 at 11:21 AM, Paul Kyzivat <[email-masked]> wrote:

> If you check the strongest hash you can and it succeeds, then what is the
> point of checking any others?

If you check any hash that you consider secure and it succeeds, you do not
need to check any others. There is no difference if it is the strongest or
just the hash that is strong enough.

> The one check should be sufficient if there is only one stream. It is a
> bit more complex if there are multiple streams (e.g., RTP and RTCP).
>
> How about:
>

It might be ok to include fewer but I cannot think of a single reason why
you would do this.

> 3.2) sort the remaining fingerprints, strongest hashes first.

There is no reason to sort. This will not make hash check any more secure.
If a hash you consider secure is compromised you will just get false
positive slightly later. There is probably a reason to sort hashes based on
the amount of resources it will take for you to check them, with easiest to
check first  in order to optimize the hash checking process. This will
likely sort the hashes weakest first.

>      Reject the session if none match.

Once again, if any match accept the session. If none match, reject.
Checking order does not matter and will not affect overall security.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 7 Apr 2016 15:27:21 -0400

On 4/7/16 3:08 PM, Roman Shpount wrote:
> On Thu, Apr 7, 2016 at 11:21 AM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     If you check the strongest hash you can and it succeeds, then what
>     is the point of checking any others?
>
>
> If you check any hash that you consider secure and it succeeds, you do
> not need to check any others. There is no difference if it is the
> strongest or just the hash that is strong enough.

>     The one check should be sufficient if there is only one stream. It
>     is a bit more complex if there are multiple streams (e.g., RTP and
>     RTCP).
>
>     How about:
>
> It might be ok to include fewer but I cannot think of a single reason
> why you would do this.
>
> There is no reason to sort. This will not make hash check any more
> secure. If a hash you consider secure is compromised you will just get
> false positive slightly later. There is probably a reason to sort hashes
> based on the amount of resources it will take for you to check them,
> with easiest to check first  in order to optimize the hash checking
> process. This will likely sort the hashes weakest first.

If everybody did this, and the easiest to check one is compromised, and 
used by a MiTH to inject a bogus cert that matches that nobody might 
notice. Isn't that undesirable?

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Thu, 7 Apr 2016 15:31:45 -0400

> notice. Isn't that undesirable?

This is why you should discard hashes that you consider too weak. After you
done this, since any single hash match is sufficient, it does not matter in
what order the hashes are checked. If the weak hash is present, the session
will be accepted.
_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Thu, 7 Apr 2016 16:33:36 -0300

> what order the hashes are checked. If the weak hash is present, the session

I would argue that you should check all hashes that you support and
are present.  Then, you can be protected against weaknesses that you
aren't aware of.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 7 Apr 2016 15:54:59 -0400

> are present.  Then, you can be protected against weaknesses that you

Let me try to explain this again why this will not work. Consider that RTP
and RTCP can come from two different sources (devices) which will use
different DTLS associations for each component, use different certificates,
and potentially support different sets of hash functions. Because of this,
the fact that RTP device supports SHA-256 does not mean that RTCP will use
it or support it.

Regards,
______________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Thu, 7 Apr 2016 17:09:42 -0300

> the fact that RTP device supports SHA-256 does not mean that RTCP will use

How is that relevant?  If the RTCP endpoint doesn't support X, then it
uses what it can.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 7 Apr 2016 16:55:03 -0400

> How is that relevant?  If the RTCP endpoint doesn't support X, then it

Let me clarify, let's say RTP device supports SHA-256 and SHA-1 and RTCP
device supports SHA-1 only. The combined offer from these two devices will
have an m= line with 3 fingerprints: SHA-256 and SHA-1 fingerprint for RTP
device certificate and SHA-1 fingerprint for RTCP device certificate. When
the other end point gets DTLS association from RTP device, two fingerprints
will match (one SHA-1 and one SHA-256). When remote end point gets DTLS
association from RTCP device only one SHA-1 fingerprint will match. If I
understand your proposal correctly this will cause DTLS association for
RTCP to be rejected since it did not match a single SHA-256 fingerprint.
This is definitely undesirable.

Regards,
_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Thu, 7 Apr 2016 18:13:34 -0300

On 7 April 2016 at 17:55, Roman Shpount <[email-masked]> wrote:
> If I understand your proposal correctly this will cause DTLS association for

Well, the entity generating the SDP is not constrained by the hashes
that the two devices support, is it?

But, assuming that it is, then my original text did have the property
you describe.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 7 Apr 2016 17:25:51 -0400

> that the two devices support, is it?

This all depends on the architecture.  In the solution I had to deal with
RTP and RTCP would generate temporary certificates and send only
fingerprints to the device which produced final SDP.

I do agree this is esoteric.

_____________
Roman Shpount

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 7 Apr 2016 18:37:50 -0300

> On Apr 7, 2016, at 11:20 AM, Roman Shpount <[email-masked]> wrote:
> 
> You should check all the hashes you consider secure and if any one of them matches the DTLS association certificate, accept the media.

+1 

This allows us to do things like include hash for two servers even when you re not sure which server will actually be used.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 8 Apr 2016 11:08:53 -0400

I don't have a horse in this race. I think those of you who do need to 
finish deciding what the rules are for multiple fingerprints, and then 
write the result into the draft update. Clearly it is ambiguous at the 
moment.

	Thanks,
	Paul

On 4/7/16 5:37 PM, Cullen Jennings wrote:
>
>> On Apr 7, 2016, at 11:20 AM, Roman Shpount <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> You should check all the hashes you consider secure and if any one of
>> them matches the DTLS association certificate, accept the media.
>
> +1
>
> This allows us to do things like include hash for two servers even when
> you re not sure which server will actually be used.
>
>
>
>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 8 Apr 2016 15:14:27 -0400

I just wanted to re-iterate the question. We have two options:

1. If m= line has multiple fingerprints with hash functions X, Y, Z, at
least one fingerprint with each function must match DTLS association for
the media to be accepted. For example, if m= line has two fingerprints with
hash function SHA-1, and two with SHA-512, DTLS association certificate
must match at least one SHA-1 and one SHA-512 fingerprint.

2. If m= line has multiple fingerprints with hash functions X, Y, Z, at
least one fingerprint with any hash function which is considered secure
enough must match DTLS association for the media to be accepted. For
example, if m= line has two fingerprints with hash function SHA-1, and two
with SHA-512, DTLS association certificate must match one of either SHA-1
or SHA-512 fingerprints.

Option 1 has a benefit of being more secure since it provides the combined
secure of individual hash functions. It does put additional restrictions
how equipment can be combined into producing a single m= line. For instance
if fingerprints from two servers are combined into a single m= line and it
is not known in advance which one will be used, both servers will need to
always support the same hash functions and be updated at the same time.

Option 2 is less secure since it is only as secure as the least secure
hash. On the other hand option 2 allows to be more flexible in how
equipment is combined to form the single m= line. Two servers in above
example, for instance, can support different hash functions.

I would ask the group to state their preferences.

I prefer option 2 but can live with option 1.

Regards,

_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 8 Apr 2016 16:06:01 -0400

On 4/8/16 3:14 PM, Roman Shpount wrote:
> the media to be accepted. For example, if m= line has two fingerprints
> with hash function SHA-1, and two with SHA-512, DTLS association
> certificate must match at least one SHA-1 and one SHA-512 fingerprint.
>
> example, if m= line has two fingerprints with hash function SHA-1, and
> two with SHA-512, DTLS association certificate must match one of either
> SHA-1 or SHA-512 fingerprints.
>
> Option 1 has a benefit of being more secure since it provides the
> combined secure of individual hash functions. It does put additional
> restrictions how equipment can be combined into producing a single m=
> line. For instance if fingerprints from two servers are combined into a
> single m= line and it is not known in advance which one will be used,
> both servers will need to always support the same hash functions and be
> updated at the same time.
>

I don't have a preference. But I will observe that a problem here arises 
because fingerprints for multiple DTLS associations don't identify which 
association they are intended for. Obviously the source of the 
fingerprints has this information. Discarding that info is complicating 
the algorithm.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 Apr 2016 13:38:34 +0000

Hi,

I think option 1) does not support hash agility – which is one of the main reason from sending multiple fingerprints to begin with – as it assumes that the sender and receiver will support the same hash functions.

Option 2) seems to be what Cullen also suggested: as long as there is at least one fingerprint (calculated using a has function which the receiver considers secure enough) that matches the DTLS association. So, in general I support option 2).

However, we need to keep in mind that there may be fingerprints sent for multiple certificates. Do we need to mandate at least one match per cerfificate?

Regards,

Christer

From: mmusic <[email-masked]<mailto:[email-masked]>> on behalf of Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Friday 8 April 2016 at 22:14
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] 4572 update: forbid weak hashes?

1. If m= line has multiple fingerprints with hash functions X, Y, Z, at least one fingerprint with each function must match DTLS association for the media to be accepted. For example, if m= line has two fingerprints with hash function SHA-1, and two with SHA-512, DTLS association certificate must match at least one SHA-1 and one SHA-512 fingerprint.

2. If m= line has multiple fingerprints with hash functions X, Y, Z, at least one fingerprint with any hash function which is considered secure enough must match DTLS association for the media to be accepted. For example, if m= line has two fingerprints with hash function SHA-1, and two with SHA-512, DTLS association certificate must match one of either SHA-1 or SHA-512 fingerprints.

Option 1 has a benefit of being more secure since it provides the combined secure of individual hash functions. It does put additional restrictions how equipment can be combined into producing a single m= line. For instance if fingerprints from two servers are combined into a single m= line and it is not known in advance which one will be used, both servers will need to always support the same hash functions and be updated at the same time.

Option 2 is less secure since it is only as secure as the least secure hash. On the other hand option 2 allows to be more flexible in how equipment is combined to form the single m= line. Two servers in above example, for instance, can support different hash functions.

Regards,

_____________
Roman Shpount

On Fri, Apr 8, 2016 at 11:08 AM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
I don't have a horse in this race. I think those of you who do need to finish deciding what the rules are for multiple fingerprints, and then write the result into the draft update. Clearly it is ambiguous at the moment.

        Thanks,
        Paul

On Apr 7, 2016, at 11:20 AM, Roman Shpount <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>>> wrote:

+1

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Roman Shpount <[email-masked]>
Date: Mon, 25 Apr 2016 10:47:39 -0400

Christer,

There is no indication what fingerprint applies to what certificate in SDP
fingerprint attribute. The rule should be if connection is established a
certificate which matches at least one hash that you consider secure, the
connection should be accepted. If you would make it more complicated, this
will likely break backwards interop or would require changes to
fingerprint/DTLS/certificates.

Regards,

_____________
Roman Shpount

On Mon, Apr 25, 2016 at 9:38 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> I think option 1) does not support hash agility – which is one of the main
> reason from sending multiple fingerprints to begin with – as it assumes
> that the sender and receiver will support the same hash functions.
>
> Option 2) seems to be what Cullen also suggested: as long as there is at
> least one fingerprint (calculated using a has function which the receiver
> considers secure enough) that matches the DTLS association. So, in general
> I support option 2).
>
> However, we need to keep in mind that there may be fingerprints sent for
> multiple certificates. Do we need to mandate at least one match per
> cerfificate?
>
> Regards,
>
> Christer
>
>
>
> From: mmusic <[email-masked]> on behalf of Roman Shpount <
> [email-masked]>
> To: "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 Apr 2016 18:37:13 +0000

Hi,

>There is no indication what fingerprint applies to what certificate in SDP fingerprint attribute. >The rule should be if connection is established a certificate which matches at least one hash >that you consider secure, the connection should be accepted. If you would make it more >complicated, this will likely break backwards interop or would require changes to >fingerprint/DTLS/certificates.

I don’t want to make things complicated – I want to agree on something, update the draft based on that, and go WGLC :)

Regards,

Christer

On Mon, Apr 25, 2016 at 9:38 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

Regards,

_____________
Roman Shpount

        Thanks,
        Paul

+1

---

From: Roman Shpount <[email-masked]>
Date: Mon, 25 Apr 2016 15:18:30 -0400

On Mon, Apr 25, 2016 at 2:37 PM, Christer Holmberg <
[email-masked]> wrote:

> >There is no indication what fingerprint applies to what certificate in
> SDP fingerprint attribute. >The rule should be if connection is
> established a certificate which matches at least one hash >that you
> consider secure, the connection should be accepted. If you would make it
> more >complicated, this will likely break backwards interop or would
> require changes to >fingerprint/DTLS/certificates.
>
>
>
> I don’t want to make things complicated – I want to agree on something,
> update the draft based on that, and go WGLC :)
>
>
>
I agree with trying to keep things simple. This means agreeing to something
that is secure enough (one match for anything you consider secure is
enough) vs trying to create something that is more secure (one fingerprint
for each offered fingerprint hash algorithm must match).

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 Apr 2016 19:26:10 +0000

So, does anyone object to the proposal: no matter how many certificates (and associated fingerprints) the SDP contains, as long as there is *one* hash (that the receiver supports and consider secure enough) matches the certificate, things are good.

(I agree that is also the best (only?) solution from a backward compatibility perspective)

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 25 April 2016 22:19
To: Christer Holmberg <[email-masked]>
Cc: Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [MMUSIC] 4572 update: forbid weak hashes?

I agree with trying to keep things simple. This means agreeing to something that is secure enough (one match for anything you consider secure is enough) vs trying to create something that is more secure (one fingerprint for each offered fingerprint hash algorithm must match).

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Apr 2016 15:56:19 -0400

On 4/25/16 3:26 PM, Christer Holmberg wrote:
> So, does anyone object to the proposal: no matter how many certificates
> (and associated fingerprints) the SDP contains, as long as there is
> **one** hash (that the receiver supports and consider secure enough)
> matches the certificate, things are good.

The possibility that the fingerprints might cover multiple certs, for 
multiple connections, messes things up.

IIUC, *if* there is only one connection to be protected then all the 
fingerprints must be fingerprints of the cert for that one. And in that 
case if you check one and it fails to match then there is indeed an 
error, even if another one matches.

Should it be acceptable to consider this case a failure? Or is this too 
complicated?

One possibility would be to state that the minimum check, that MUST be 
applied, is that at least one fingerprint MUST match every cert covered 
by the SDP, and that an optional check (MAY be applied) is that *each* 
fingerprint match one of the certs covered by the SDP. (The optional 
check is something that a formal tester/verifier might perform.) It 
would be a requirement that the sender ensure that the harder test 
succeed if the recipient applies it.

I can live with just the minimum being stated.

	Thanks,
	Paul

> *From:*Roman Shpount [mailto:[email-masked]]
> *Sent:* 25 April 2016 22:19
> *To:* Christer Holmberg <[email-masked]>
> *Cc:* Paul Kyzivat <[email-masked]>; [email-masked]
> *Subject:* Re: [MMUSIC] 4572 update: forbid weak hashes?
>
>
>
> On Mon, Apr 25, 2016 at 2:37 PM, Christer Holmberg
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     >There is no indication what fingerprint applies to what certificate
>     in SDP fingerprint attribute. >The rule should be if connection is
>     consider secure, the connection should be accepted. If you would
>     make it more >complicated, this will likely break backwards interop
>     or would require changes to >fingerprint/DTLS/certificates.
>
>
>
>     I don’t want to make things complicated – I want to agree on
>     something, update the draft based on that, and go WGLC :)
>
>
>
>
>
> I agree with trying to keep things simple. This means agreeing to
> something that is secure enough (one match for anything you consider
> secure is enough) vs trying to create something that is more secure (one
> fingerprint for each offered fingerprint hash algorithm must match).
>
>
>
> Regards,
>
> _____________
> Roman Shpount
>
>
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 25 Apr 2016 16:11:30 -0400

On Mon, Apr 25, 2016 at 3:56 PM, Paul Kyzivat <[email-masked]> wrote:

> case if you check one and it fails to match then there is indeed an error,
> even if another one matches.
>

There is still a use case when an offer is sent but it is not yet known
which of the several media processors will be used when connection is
actually established. Such offer will contain fingerprints for certificates
on all the media processors, but only one of them will match. This is true
even for a single connection (bundle).

> applied, is that at least one fingerprint MUST match every cert covered by
> the SDP, and that an optional check (MAY be applied) is that *each*
> fingerprint match one of the certs covered by the SDP. (The optional check
> is something that a formal tester/verifier might perform.) It would be a
> requirement that the sender ensure that the harder test succeed if the
> recipient applies it.
>

We might add another SDP parameter for this or extend fingerprint in a
backwards compatible way to indicate some sort of certificate group, but
this is making things more complicated. Multiple people indicated that this
is out of scope for this document revision.

> I can live with just the minimum being stated.

We are mostly trying to document what people thought was already supported
in maximum backwards compatible manner. I think minimum match is the only
way.
_____________
Roman Shpount