Nick: Thanks for this summary. This resolves my previous concerns.
Russ > On Jul 18, 2017, at 7:06 AM, Nick Sullivan <nicholas.sulli...@gmail.com> > wrote: > > Sean, > > We've had some additional discussions in person here at IETF 99 with folks > who were in the proxy certificates and short-lived certs camp, and we think > there is now more agreement that the mechanism described in this draft is > superior to the alternatives. I've included a summary of some of the pros and > cons of the approaches: > > Proxy certificates vs. Delegated Credentials > Pro proxy certificates: > - Already deployed in some industries, though not on the Web. > - Fits the conceptual model that public key == certificate. > Con proxy certificates: > - Proxy certificates adds additional complexity to the delegation other than > limiting the time period (full X.509, additional constraints such as > hostname). > - Encourages implementers to reuse PKIX libraries rather than build code as > part of TLS: > -- There have been problems and inconsistencies around pathlen and > constraints enforcement in existing PKIX libraries. > -- Modifying these libraries is more complex and risk prone than delegated > creds (which can easily be implemented in TLS as demonstrated by the 3 > interoperable implementations at the IETF 98 hackathon). > - In proxy certificates, pathing is SKI dependent, not directly tied to EE > cert. This is a binding weaker than delegated credentials which includes a > signature over the EE certificate. > > Short-lived certs vs. Delegated Credentials > Pro short-lived certs: > - Short lived certs work with existing libraries, no new code changes. > Con short-lived certs: > - Not widely available from CAs, especially for EV. > - Potentially problematic to the CT ecosystem (all certificates must be > logged in CT, which may bloat them). > - Introduces a high-risk operational dependency on external party: > -- Requires frequent exchanges with an external Certificate Authority (must > provide proof of domain possession to CA vs. internally managed credential > minter for delegated credentials). > -- There is no fallback if the CA has outage. With delegated credentials you > can fall back to a LURK-style protocol with the long-lived certificate key. > > Given these comparisons, we think the proposed draft is the superior option > and would like to continue the discussion about adopting it. > > Nick > > On Fri, May 19, 2017 at 12:58 AM Sean Turner <s...@sn3rd.com > <mailto:s...@sn3rd.com>> wrote: > All, > > During the WG call for adoption, a couple of questions were raised about > comparison/analysis of sub-certs versus proxy and/or short-lived > certificates. There is some discussion currently in the draft, but the > chairs feel that these issues need further discussion (and elaboration in the > draft) prior to WG adoption. So let’s keep the conversation going. > > J&S > > > On Apr 12, 2017, at 15:31, Sean Turner <s...@sn3rd.com > > <mailto:s...@sn3rd.com>> wrote: > > > > All, > > > > At our IETF 98 session, there was support in the room to adopt > > draft-rescorla-tls-subcerts [0]. We need to confirm this support on the > > list so please let the list know whether you support adoption of the draft > > and are willing to review/comment on the draft before 20170429. If you > > object to its adoption, please let us know why. > > > > Clearly, the WG is going to need to work through the trade-offs between > > short-lived certificates and sub-certs because both seem, to some, to be > > addressing the same problem. > > > > Cheers, > > > > J&S > > > > [0] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts > > <https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts> > > _______________________________________________ > TLS mailing list > TLS@ietf.org <mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls > <https://www.ietf.org/mailman/listinfo/tls> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
