Subject: [pkix] PKIX WG's (lack of) agility to adopt missing features

From: [email-masked] (Martin Rex)
Date: Thu, 18 Apr 2013 23:57:03 +0200 (CEST)

(The original discussion was about Mozilla's creation of EKU path constraints)

On 2013-02-19 Stephen Kent wrote:
>
> On 2/19/13 7:41 PM, Peter Gutmann wrote:
>>
>> The other way of looking at it is that it's unfortunate that PKIX
>> refuses to standardise a widely-used and -adopted practice.
>> As Stefan pointed out, this is just another case of reality vs. PKIX,
>> reality will keep being what it is and PKIX will keep going down
>> its own path, unconstrained by reality.
>
> If all widely-used -adopted practices were good, we would adopt more of 
> them.
> 
> That is clearly not the case. And, often, those who choose to adopt a 
> practice that contradicts the standards do so before approaching PKIX.
> In such cases, adopting what has been done encourages the practice
> of avoiding the IETF process in favor of a "big vendor has decided
> to do X, so let's reward them with an RFC."

Considering how much and how quickly PKIX WG adopts and standardizes
"new features" that are needed by the real world
(e.g. 1999->2013 for the baby-step rfc2560bis-20),
one can hardly blame the real world to not waiting on PKIX WG.
To me, it looks more like PKIX is a dysfunctional IETF working group.

And while the "diversity" in PKIX WG seems like a significant challenge,
I personally believe that the leadership part could be using
(or could have used) the IETF process much more effectively and
creatively to figure out the stuff that is important (to the world)
and that can be accomplished without ratholing every other week.

-Martin