Re: [Spasm] Let's focus

On Thu, May 26, 2016 at 4:23 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
wrote:

>
> Hiya,
>
> On 26/05/16 21:04, Richard Barnes wrote:
> > Hey all,
> >
> > I'm concerned that the proposed scope [1] for this WG is (1) too broad,
> and
> > (2) inconsistent with the participation so far.
> >
> > The breadth concern is evident in the ambiguity of the name "Some?"  This
> > group should identify some concrete, practical problems in the Internet
> > they need to solve, describe them, and demonstrate that they have the
> right
> > set of stakeholders to develop, implement, and deploy a solution.
>
> Well we can bikeshed names for sure but moving on...
>
> >
> > I'm personally most concerned about the "fix the EKUs" milestone, at
> least
> > as it's realized in [2].
>
> Yeah, me too. The discussion around that has been eerily reminiscent of
> some of the less productive things from the "late" PKIX period.
>
> > From the perspective of someone who works a lot
> > in the Web PKI, this sounds like a request for a feature that has
> negative
> > value.  The incremental value of the proposed feature would be to allow
> > "everything but X" CAs.  Recent experience in the Web PKI has driven home
> > how harmful it can be to have divergent sets of RPs relying on the same
> > PKI, so allowing CAs to be more unconstrained is moving in the wrong
> > direction.
>
> Fair point. If the WG is chartered I think it'd have to decide if
> that's ok or not.

You've kinda got the cart before the horse here.  If this use case isn't
good, then there's no point to having the milestone.

> (Stefan's 1-bit counter-proposal didn't have the
> same property though or am I wrong?)
>
> > I'm not dogmatic on this, but in order to be persuaded, I would
> > need to see active interest from some real CAs, and from the logs of this
> > list, I'm not seeing anyone who's a current participant in the Web PKI
> > (apologies if I've failed to recognize someone).
>
> It'd be good to see that kind of interest in the EKU work yes. Absent
> that, I would guess deployment won't happen.
>

Again, I think demonstrating interest from the relevant community is needed
*before* chartering.  The underlying principal of BoFs, etc., is that spec
here get developed by the people that are going to use them / be affected
by them.  If those people aren't here, we shouldn't charter work.

--Richard

> >
> > I'm also concerned about the "SRV for cert stores" milestone, though I
> > admit I'm not as deep in this space.  Looking at the proposed doc, it
> seems
> > like the SRV adds any value over just looking stuff up at a well-known
> URI,
> > e.g., adding a "x5c" attribute to a WebFinger resource.  Anything that
> > requires special DNS magic (and SRV counts) is going to face significant
> > deployment barriers.  So I would be happier if this were a "define a
> simple
> > cert discovery mechanism for S/MIME" milestone, rather than being bound
> to
> > a specific mechanism.
>
> From my POV, that's yet another experiment in the public-key-retrieval-
> to-support-e2e-messaging-security set of experiments that included the
> openpgp-dane one recently approved. (And I'd be fine with more of those
> experiments too for reasons stated during the IETF LC of the dane work.)
>
> >
> > Overall, it seems like this group should focus on moving the ball forward
> > with regard to making S/MIME deployable in today's Internet -- fixing
> > papercuts around AEAD, i18n, and cert discovery.  The PKIX stuff is
> > unrelated and addresses an entirely different constituency.
>
> I'm personally if the work here isn't all one effort but a small set of
> sorta-diverse efforts. So long as they're likely to be deployed that is.
> If that's not likely, then I'd be for dropping them from the charter.
>
> Cheers,
> S.
>
> >
> > --Richard
> >
> >
> > [1] https://datatracker.ietf.org/doc/charter-ietf-spasm/
> > [2] https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-01
> > [3] https://tools.ietf.org/html/draft-bhjl-x509-srv-00
> >
> >
> >
> > _______________________________________________
> > Spasm mailing list
> > Spasm@ietf.org
> > https://www.ietf.org/mailman/listinfo/spasm
> >
>
>