Re: [Spasm] Let's focus

["Santosh Chokhani" <[e-mail]>]

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:[e-mail]] On Behalf Of Richard Barnes
Sent: Friday, May 27, 2016 9:48 AM
To: Stephen Farrell <[e-mail]>
Cc: [e-mail]
Subject: Re: [Spasm] Let's focus

 

 

 

On Fri, May 27, 2016 at 9:43 AM, Stephen Farrell <[e-mail] <mailto:[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] <mailto:[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] <mailto:[e-mail]> 
>>> https://www.ietf.org/mailman/listinfo/spasm
>>>
>>
>>
>
>
>
> _______________________________________________
> Spasm mailing list
> [e-mail] <mailto:[e-mail]> 
> https://www.ietf.org/mailman/listinfo/spasm
>