Re: [pkix] Next edition of X.509

[[e-mail] (Martin Rex)]

Peter Bowen wrote:
> On Sat, Jan 23, 2016 at 4:24 PM, Stephen Farrell
> <[e-mail]> wrote:
>> On 23/01/16 23:58, Peter Bowen wrote:
>>> Until it is clear that using
>>> EKU in the way I described in covered by X.509, it is not possible to
>>> have a strict profile (e.g. PKIX) include it in the profile.
>>
>> I don't know what you mean by that, can you elaborate?
>>
>> My guess is that almost nobody does new implementations of X.509
>> code nowadays, and those that might would go to 5280 and not the
>> latest version of X.509, but I'd be very interested if either of
>> those assumptions is wrong.

You guess is a pretty accurate description of the installed base, Stephen.  :)


> 
> 5280 clearly states that "This memo profiles the X.509 v3 certificate
> and X.509 v2 certificate revocation list (CRL) for use in the
> Internet."  I'm assuming (possibly incorrectly) that a profile is a
> subset.  It add restrictions but anything that is compliant to the
> profile is also compliant to the more general spec.

Peter, you're misreading rfc5280.  PKIX (rfc5280) is *NOT* a profile
of X.509v3 in general, but of X.509v3 08/2005 in particular.

When I asked PKIX CRL processing to adopt a fix for a defect that 
exists in X.509v3 08/2005, but has already been fixed in X.509v3 11/2008,
I faced pretty violent opposition from folks on the IETF PKIX mailing list
(likely because it would make behaviour of some of the installed base
 non-compliant if a certain approach to CRL validation would be changed
 (fixed) retroactively (no matter how obvious the defect is in 08/2005).

So adding a recursive EKU processing into certificate path validation
of X.509v3 xx/201x will have exactly *NO* relevance for the behaviour
of "PKIX-compliant" implementations.


Whether or not some PKIX implementations of the installed base
reject certificates that are not "properly EKU chained" is an entirely
different question.  PKIX implementation are allowed to reject
certificates for all kinds of local policy issues.

The reason why I believe this is an extremely dumb idea, is because
it completely breaks the original concept behind EKU.  Instead, it
hugely impairs new apps to define new EKUs (because this now requires
rolling CA certificates).  It doesn't provide any security benefits,
but it does create additional pricing models for public CAs for
issuing subCA certificates to organizations.


-Martin