Re: [Spasm] Let's focus

[Stephen Farrell <[e-mail]>]

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. (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.

> 
> 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
>