Re: [Spasm] Let's focus

[Richard Barnes <[e-mail]>]

On Fri, May 27, 2016 at 9:43 AM, Stephen Farrell <[e-mail]>
wrote:

>
> Hiya,
>
> On 27/05/16 14:04, Richard Barnes wrote:
> > On Thu, May 26, 2016 at 4:23 PM, Stephen Farrell <
> [e-mail]>
> > 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.
>
> Sorry, I wasn't clear. What I meant was that if this use-case is
> included in a charter, then the WG will need to figure out if
> "everything but X" CAs is a good/bad idea to support when trying
> to solve for the use case.
>
> >
> >
> >
> >> (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.
>
> Fully agree.
>
> Earlier though we did say on this list that we only want to charter work
> where we do think it'll likely be implemented and likely deployed. If
> there's a proposed work item in the current charter text where we do not
> think that applies, then it ought be deleted. (Which is what I think
> Russ was saying in his mail too.)
>
> So for item#2 in the current draft charter, can people say if they think
> the results of that work is/is-not likely to be deployed?
>

On this particular point: I haven't talked to anyone else about this, but
my personal view is that this is very unlikely to get deployed.  In
addition to changes to CA and RP code, it would require substantial
rewriting of the BRs, the related audit standards, and root program
policies.  So it would need to have some significant benefit to offset that
significant cost, and I'm just not seeing that.

--Richard




>
> Cheers,
> S.
>
>
> >
> > --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
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/spasm
> >>>
> >>
> >>
> >
> >
> >
> > _______________________________________________
> > Spasm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/spasm
> >
>
>