Subject: Re: * was Re: Server Identity Verification in Application Protocols

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 01 Dec 2009 11:37:41 -0700

My apologies once again for the delayed reply.

On 10/6/09 4:05 AM, tom.petch wrote:
> This specification disallows the use of * to wildcard the reference identity.
> 
> syslog over TLS not only uses this, but also allows the use of a wildcard
> where it would not be allowed in the subjectAltName.
> 
> I would see this as quite common in networking scenarios, where the access
> is many to many, and so would like a less severe prescription against it.

One approach would be to allow "profiling" of the rules in this spec.
For example, we could add text such as the following:

###

This specification defines several dimensions that are legitimately a
matter of application profiling:

   1. In the case of domain names, whether the reference identity can
contain the wildcard character '*' (ASCII 42) as the least significant
domain label (e.g., "*.example.com").

   2. In the case of domain names, whether the reference identity can
contain the wildcard character '*' (ASCII 42) as one of the characters
in the least significant domain label fragment (e.g., "foo*.example.com").

Application protocols that re-use this specification rather than define
their own certificate rules need to specify whether they allow wildcards
in the ways just described.

###

We might also want to say that such use of wildcards defaults is "not
allowed" unless otherwise specified by the using protocol.

Peter

--
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 01 Dec 2009 11:47:06 -0700

On 10/14/09 9:11 AM, Kurt Zeilenga wrote:

> I would find it less objectionable for this I-D to simply say something
> like:
>    "This document details a process for client verification of the
> server's identity.  It is possibly that this process be used in server
> verification of a client's identity, however this document does not
> consider or detail how this might be done."

After thinking about Kurt's argument further and discussing the topic at
IETF 76, I agree that verification of client identities is out of scope
for this I-D. Interesting problem, but to be discussed elsewhere.

In my working copy, I have the following text:

      Note: This document applies only to server identities, only to
      TLS, and only to the PKI.  Similar considerations might apply to
      client identities (e.g., for mutual authentication), to security
      protocols such as [IPSEC] and [DTLS], and to keys or certificates
      created outside the context of the PKI (e.g., where a dependency
      on Certificate Revocation Lists or the Online Certificate Status
      Protocol might introduce unacceptable latency or denial of service
      attacks).  Indeed, some aspects of the encapsulation and
      verification rules provided in this document might apply to those
      scenarios, as well; however, those scenarios are outside the scope
      of this document and need to be addressed by separate
      specifications.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 02 Dec 2009 10:20:21 +0000

>in the least significant domain label fragment (e.g., "foo*.example.com").
(with a regular participant hat on):
I am not sure that the 2nd choice should be recommended at all.
But your suggested text looks fine to me otherwise.

>allowed" unless otherwise specified by the using protocol.
This is fine as well.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 02 Dec 2009 10:21:18 +0000

>      of this document and need to be addressed by separate
I like that.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 02 Dec 2009 06:08:24 -0800

>>      of this document and need to be addressed by separate

The beginning of the paragraph says what is in scope.  The second half of the 
last sentence says that everything else is outside of scope.  So it might not be 
essential to clarify what:

    "some aspects of the encapsulation and verification rules provided in this 
document might apply to those scenarios"

means, but I do not understand it at all.  "aspect applies"  seems to be what is 
causing my confusion.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 02 Dec 2009 19:35:13 -0700

> But your suggested text looks fine to me otherwise.

I tend to agree, but I wasn't sure that we wanted to prohibit the foo*
matching because I thought some folks on this list argued for allowing
it in some circumstances. I'll check the list archives on this point.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/