Re: [pkix] Next edition of X.509

[Stephen Farrell <[e-mail]>]

Hiya,

On 24/01/16 00:43, 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.
>>
>> If I'm not wrong, then updates to the base X.509 spec are no
>> longer really important, other than for the sake of tidiness.
>> Another corollary would be that the opinions of people who
>> have no influence over running code but who think one document
>> or the other is more important, can safely be ignored. Again,
>> good to know it that's incorrect.
> 
> 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."  

Right, the history though is that PKIX and CCITT (now ITU-T)
collaborated very well twenty years ago on that and it was
then a good idea to ensure a lack of divergence. I think the
world has changed sufficiently since then, but again that's
back to the assumptions from my previous posting.

Keep in mind that RFC2459 begat RFC3280 which begat RFC5280
so there's a good bit of history, and we mostly wanted to
minimise the code/text changes throughout that evolution.

> 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.
> 
> During discussions about PKI interoperability (especially getting
> existing PKIs cross-signed by other PKIs or added to trust anchor
> lists) it has come up repeatedly that some PKI implementers see the
> use of EKU in a CA-certificates as a constraint as not allowed under
> X.509 and therefore not allowed in RFC 5280.
> 
> If I have this wrong, and you think that it is a viable path to define
> the use of EKU in CA-certificates as a constraint in the PKIX profile
> with no changes to X.509, I would be very happy.

There are many cases where things initially proposed in an I-D
ended up being back-ported to the ITU-T X.509 document. If you
have a thing you think needs doing and find that publishing an
I-D seems like a reasonable approach, then I'd say just go for
it and we'll see if it gets support from implementers. If OTOH
you care more about whether text gets into an ITU-T spec, then
that might not be the route for you.

Cheers,
S.

> 
> Thanks,
> Peter
>