Customers aren't required to solely the TCSC. They could use the TCSC for the ones they want redacted and a standard intermediate for the others. Most of the customers I've spoken with don't plan on redacting a lot of domains. There are just certain domain paths they want to make secret. For them, the TCSC is perfect because they can redact all sub domains while still leaving all their externally facing stuff on a regular intermediate.
-----Original Message----- From: Trans [mailto:[email protected]] On Behalf Of Steve Medin Sent: Tuesday, December 13, 2016 11:50 AM To: Ryan Sleevi <[email protected]> Cc: Matt Palmer <[email protected]>; [email protected]; Peter Bowen <[email protected]> Subject: Re: [Trans] Redaction What the 23kb TCSC I created taught me was that there are orgs that need: <sitepurpose>.<brand>.<geography> And <sitepurpose>.<brand>.<catchy new TLD> And all the permutations thereof, as well as the directory names of 80 data centers owing to a legacy of inserting the place of operation in the DN rather than corporate global or regional HQ. Brand is also deep, not only through acquisition but some orgs have a web presence of hundreds of microsites that are FQDN rather than query path. When a TCSC is created, it has to envelope a legacy of naming that received certificates in another manner. That means a lot of decisions that were made without DNS name and directory name constraints need to be accounted for in the extension. Once the TCSC is created, unless IT has an overbearing role in domain/brand approval, the deep branded organization is going to put a new name in the second/third level domain for every launch. That's another key ceremony, a new intermediate on the AIA CA Issuers URI, and ALL CAPS in the certificate issuance email reminding the server admin to rip out the old intermediate and add the new one. Ten brand launches later, 11 different TCSCs, wait, which one do I install? I don't intend to offend server admins, this isn't a matter of competence, it's a matter of the number and variety of tasks carried by the typical admin in the type of organization I describe. > -----Original Message----- > From: Ryan Sleevi [mailto:[email protected]] > Sent: Monday, December 12, 2016 10:48 PM > To: Steve Medin <[email protected]> > Cc: Peter Bowen <[email protected]>; Matt Palmer > <[email protected]>; [email protected] > Subject: Re: [Trans] Redaction > > On Mon, Dec 12, 2016 at 7:10 PM, Steve Medin > <[email protected]> wrote: > > Yea, but when I talk about the Plex Pass certs, I'm not on the > > internal network privacy concern that split-horizon suits, I'm > > talking about how TCSC fits customers with static and limited domain > > ownership. > > Can you expand on what use case for redaction doesn't fit into that > model? I don't believe we've heard such a use case articulated. > > That is, while it's possible to imagine foo.corp.example.com as part > of a domain hierarchy, or even impendingmerger.example.com (to use > Peter Bowen's example), are you suggesting that you believe it to be > routine and normal that such certificate holders need > > impendingmerger.example.com > impendingmerger.example.net > impendingmerger.example.org > impendingmerger.example > impendingmerger.pretend-the-next-word-is-a-cctld.example > impendingmerger.some-other-brand-name.example > (etc)? > > Otherwise, the discussion of the limitations of TCSC to branding don't > really seem to fit to the topic of the redaction use cases discussed > so far, but it's possible you're imagining a yet undiscovered case?
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
