Subject: [TLS] Proposed cached info update

From: Stefan Santesson <[email-masked]>
Date: Wed, 01 Aug 2012 10:56:01 -0700

I went through the cached info draft and found something in the protocol
syntax that I don't believe is totally correctly expressed.

I made a diff that shows my proposed update:
http://tinyurl.com/cachedinfodiff

The issue at hand is that we use an existing structure to send the cached
info.

The data being replaced is in both cases sent as a vector (single
dimension array) of opaque blobs.
The data being sent instead is a vector of structured cached info elements.

This makes the sending of cached info syntax compatible with the original
syntax as the structured cached info element is compatible with an opaque
blob element.

The current draft and the proposed change is bits on the wire compatible,
it just assigns the vector containing cached info a more sensible name
"cached_objects<1..2^24-1> instead of using the name of the old opaque
vector being replaced (i.e. ASN.1Cert<1..2^24-1> and
DistinguishedName<1..2^16-1>).

I would like those being more experts in the TSL presentation language to
double check me so I don't make a stupid error here.

Thanks

/Stefan

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 01 Aug 2012 15:26:31 -0600

On 7/31/12 7:44 PM, Scott Rea wrote:
> We'd like to address a few concerns with RFC 6125.  Because the
> relevant discussion list is not active, we contacted the authors
> and TLS Chair who instructed us to post our concerns to this list.
> 
> Our primary concern with RFC 6125 is that Wildcard certificate use
> is wide-spread and has proved to be a cost-effective alternative
> to multi-domain certificates.  Asking for the deprecation of
> wildcard certificates undermines a lot of existing infrastructure
> and current establishments.

RFC 6125 does not deprecate use of the wildcard character '*' in PKIX
certificates. Although Jeff and I would have liked to deprecate such
use, we did not go that far, based on the feedback we received while
working on the document that became RFC 6125.

See Section 4.1:

7.  Unless a specification that reuses this one allows continued
       support for the wildcard character '*', the DNS domain name
       portion of a presented identifier SHOULD NOT contain the wildcard
       character, whether as the complete left-most label within the
       identifier (following the description of labels and domain names
       in [DNS-CONCEPTS], e.g., "*.example.com") or as a fragment
       thereof (e.g., *oo.example.com, f*o.example.com, or
       fo*.example.com).  A more detailed discussion of so-called
       "wildcard certificates" is provided under Section 7.2.

See also Section 6.4.3.

> We feel that RFC's current recommendations fail to adequately
> balance the risks and convenience of an existing practice, is based
> only on theoretical problems, and does not accurately reflect
> current industry practices or beliefs.

Those are worthy topics of discussion. Unfortunately, I don't have the
cycles for such a discussion this week. I might have the cycles next week.

> We suggest the following changes to RFC 6125:

Just so you know, Jeff and I do not have active plans to work on a
document superseding RFC 6125, for several reasons: it was a *lot* of
work the first time, we both have other tasks we need to complete, we
think it needs to be used for a while and cited by other specs [1]
before we can determine what changes need to be made, it probably
needs to be adjusted in the light of output from the DANE WG, etc.

Peter

[1] http://www.arkko.com/tools/allstats/citations-rfc6125.html

---

From: [email-masked] (Martin Rex)
Date: Thu, 2 Aug 2012 00:26:30 +0200 (CEST)

Scott Rea wrote:
> We'd like to address a few concerns with RFC 6125.  Because the relevant
> discussion list is not active, we contacted the authors and TLS Chair who
> instructed us to post our concerns to this list.
> 
> Our primary concern with RFC 6125 is that Wildcard certificate use is
> wide-spread and has proved to be a cost-effective alternative to
> multi-domain certificates.  Asking for the deprecation of wildcard
> certificates undermines a lot of existing infrastructure and current
> establishments.   We feel that RFC's current recommendations fail to
> adequately balance the risks and convenience of an existing practice, is
> based only on theoretical problems, and does not accurately reflect current
> industry practices or beliefs.

I assure you that the issue of wildcard certs, their usage
has been discussed in quite detail on the cert id mailing
_before_ the document now known as rfc6125 was last called
and published.

(Finding the mailing list archives seems non-trivial, since the
 discussion list itself seems to be no longer listed under
 "non-WG discussion lists" on www.ietf.org)

http://www.ietf.org/mail-archive/web/certid/current/maillist.html

(I realize I should have modified/changed the message subject
 more often...)

A few selected (non-representative!) postings from the discussion
on the certid non-WG IETF mailing list that mention wildcard matching:

http://www.ietf.org/mail-archive/web/certid/current/msg00345.html
http://www.ietf.org/mail-archive/web/certid/current/msg00485.html
http://www.ietf.org/mail-archive/web/certid/current/msg00461.html
http://www.ietf.org/mail-archive/web/certid/current/msg00471.html
http://www.ietf.org/mail-archive/web/certid/current/msg00472.html
http://www.ietf.org/mail-archive/web/certid/current/msg00482.html

> We suggest the following changes to RFC 6125:

IETF RFCs, once published, are immutable.  As Peter mentioned, the
process to change a standard or BCP would be to update or obsolete
it with a successor document.  But that is a significant amount of
work.  Considering that the issue of wildcards has been discussed
in significant length during the developemnt of rfc6125, I personally
see little motivation for a successor effort at the moment...

-Martin

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 2 Aug 2012 14:54:12 -0700

I agree that this change is useful.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 20 Aug 2012 05:07:36 +0000

I also agree with this change.  Can you submit a new draft with this change and then we can go to working group last call? 

Thanks,

Joe
On Aug 2, 2012, at 2:54 PM, Hannes Tschofenig wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls