Subject: Re: [certid] open issue: wildcards in component fragments

From: =JeffH <[email-masked]>
Date: Wed, 13 Oct 2010 14:39:38 -0700

> Note that at least two technology communities have forbidden wildcard
 > certificates:
 >
 > 1. RFC 5992 forbids wildcard certificates in the SIP community.
 >
 > 2. The CA/Browser Forum doesn't allow issuance of wildcard certificates
 > under its "Extended Valuation Certificates" profile.
 >
 > So there is some precedent for forbidding wildcard certificates. Is that
 > a best current practice? Should this I-D state that wildcard
 > certificates (of whatever variety) are NOT RECOMMENDED?

I'm thinking that the latter is the way to go wrt wildcards. RFC2119 sez..

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
    there may exist valid reasons in particular circumstances when the
    particular behavior is acceptable or even useful, but the full
    implications should be understood and the case carefully weighed
    before implementing any behavior described with this label.

..which certainly sounds reasonable for this situation.

Our working copy of -tls-server-id-check (which are trying to pub by end of 
this week) has further clarifications wrt the spec's not outright forbidding 
current practice and various other current specifications, thus present 
wildcard use does not necessarily conflict with such a "NOT RECOMMENDED" 
stance. Plus such a stance aligns better with the EV Guidelines, RFC5992, and 
perhaps other specs going forward.

=JeffH

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 13 Oct 2010 15:52:19 -0600

On 10/13/10 3:39 PM, =JeffH wrote:
> Our working copy of -tls-server-id-check (which are trying to pub by end
> of this week) has further clarifications wrt the spec's not outright
> forbidding current practice and various other current specifications,
> thus present wildcard use does not necessarily conflict with such a "NOT
> RECOMMENDED" stance. Plus such a stance aligns better with the EV
> Guidelines, RFC5992, and perhaps other specs going forward.

Jeff and I have been thinking about this independently today, and it
seems we're going in the same direction. Following Martin Rex's argument
to its logical conclusion has led me to believe that wildcards deserve
to be NOT RECOMMENDED in a best current practice document.

Peter

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

---

From: Martin Rex <[email-masked]>
Date: Thu, 14 Oct 2010 00:20:29 +0200 (MEST)

> to be NOT RECOMMENDED in a best current practice document.

I'm certainly in favor of NOT RECOMMENDING the use of any wildcards
to server admins (and to a lesser extent app protocol designers)
in the security considerations section of the server-id-check
document.

I'm less inclined about recommending to implementations to
not implement it at all (which is about utility functions of the
TLS implementation for use by the application).

Aside from pathological cases
(like a DV-validated cert issued with DNS-ID="*", "*.*", "*.*.*" and
 extremely "liberal" TLS-client-implementations of rfc-2818),
the risk about wildcard certs is more about the administrative
procedures of the server & domain admins using such certs.
Keep in mind that the security of all the servers in the domain
vitally depend on responsible admins and reasonably safe procedures,
and the matching rules described in server-id-check are hardly going
to affect that.

The other extreme, of server certificates that list several hundred
DNS-IDs is not necessarily safer than a single wildcard.

Rather than leaving the issue of wildcards as underspecified as
rfc-2818, I would appreciate a few words of what is commonly
available in current web browsers and could be implemented with
minor effort and low complexity.

-Martin

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 14 Oct 2010 15:59:14 -0600

> TLS implementation for use by the application).

After further reflection, I agree with you. I think Jeff is on board
with that, as well.

We should be able to publish -10 real soon now.

> minor effort and low complexity.

Proposed text is always welcome.

Peter

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