Subject: [Spasm] Let's focus

From: Richard Barnes <[email-masked]>
Date: Thu, 26 May 2016 16:04:45 -0400

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.

I'm personally most concerned about the "fix the EKUs" milestone, at least
as it's realized in [2].  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.  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).

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.

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.

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

---

From: Wei Chuang <[email-masked]>
Date: Thu, 26 May 2016 13:11:12 -0700

On Thu, May 26, 2016 at 1:04 PM, Richard Barnes <[email-masked]> 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 certificate i18n email address draft is actively being worked on.
Probably a next rev posted next week or sooner.

-Wei

> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 26 May 2016 21:23:15 +0100

Hiya,

> set of stakeholders to develop, implement, and deploy a solution.

Well we can bikeshed names for sure but moving on...

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

It'd be good to see that kind of interest in the EKU work yes. Absent
that, I would guess deployment won't happen.

> cert discovery mechanism for S/MIME" milestone, rather than being bound to

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

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

---

From: Richard Barnes <[email-masked]>
Date: Fri, 27 May 2016 09:04:48 -0400

On Thu, May 26, 2016 at 4:23 PM, Stephen Farrell <[email-masked]>
wrote:

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

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 27 May 2016 14:43:59 +0100

Hiya,

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

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

Cheers,
S.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 27 May 2016 09:48:01 -0400

> 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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 27 May 2016 09:56:53 -0400

I agree.  This is unlikely to be deployed.

It would be better for us to see how MSFT and NSS handles EKU in intermediate certificates and bite the bullet and document it and may be work around the edges if there are security holes and implementers wish to close them.

From: Spasm [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Friday, May 27, 2016 9:48 AM
To: Stephen Farrell <[email-masked]>
Cc: [email-masked]
Subject: Re: [Spasm] Let's focus

On Fri, May 27, 2016 at 9:43 AM, Stephen Farrell <[email-masked] <mailto:[email-masked]> > wrote:

Hiya,

On 27/05/16 14:04, Richard Barnes wrote:
> On Thu, May 26, 2016 at 4:23 PM, Stephen Farrell <[email-masked] <mailto:[email-masked]> >
> wrote:
>
>>
>> Hiya,
>>

Fully agree.

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.

>>> [email-masked] <mailto:[email-masked]> 
> [email-masked] <mailto:[email-masked]>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 27 May 2016 10:43:12 -0400

On Fri, May 27, 2016 at 9:56 AM, Santosh Chokhani <
[email-masked]> wrote:

> It would be better for us to see how MSFT and NSS handles EKU in
> intermediate certificates and bite the bullet and document it and may be
> work around the edges if there are security holes and implementers wish to
> close them.
>

To be clear, if you want to cover the browser/OS space, you basically have
the following major RP stacks:
- Microsoft
- Apple
- mozilla::pkix
- NSS
- OpenSSL / BoringSSL

Speaking for the mozilla::pkix and NSS side of things, we would be unlikely
to implement anything without a pretty significant security benefit.

--Richard

> *From:* Spasm [mailto:[email-masked]] *On Behalf Of *Richard
> Barnes
> *Sent:* Friday, May 27, 2016 9:48 AM
> *To:* Stephen Farrell <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Spasm] Let's focus
>
>
>
>
>
>
>
> On Fri, May 27, 2016 at 9:43 AM, Stephen Farrell <
> [email-masked]> wrote:
>
>
> Hiya,
>
>