Re: [pkix] Next edition of X.509

["Erik Andersen" <[e-mail]>]

OK - let me explain what the intention is for the current work on X.509.

1. X.509 has been developed over a long period. It has been edited, at times
simultaneously, by   different people. There has been a shift in terminology
during that time (e.g. the term certificate using system has been used as a
synonym for relying party). Streamlining terminology and style is  a pure
(major) editorial task not intended to change the technical content.

2. When attribute certificates were introduced, an attempt was made to
generalize a lot of the text to cover both types of certificates. This was
not done consistently and has made the text difficult to read. X.509 has a
section 2 with the header "Public-key certificate framework", but it has a
lot of stuff about attribute certificate before it has been introduced in
Section 3. The goal has been to separate the discussion on PKI and PMI. This
give a little redundancy, but not that much. People only interested in
public-key certificates can read section 2 without being bothered with a lot
on attribute certificate talk. Again, no technical change is intended.

3. The IT world is changing quite rapidly. I sometimes have the feeling that
many PKI experts assumes that the work has more or less been done, except
possibly for cryptographic algorithms. We have smart grid  and  IoT being
developed quite rapidly. These are new environments with new challenges for
PKI (and possibly for PMI). Revocation is this environment can be a major
challenge. Resource constrained (battery driven) devices have to be
supported, etc. All this requires X.509 adaptations. These adaptations has
to made without affecting the current use of PKI. It is certainly not the
intention to cause problems for running code. Personally, I am quite
involved in smart grid security within IEC TC 57 WG15 on behalf of the
Danish Energy Sector to progress that work and to understand the special
requirements..

So the tasks are: 1) Streamline X.509; 2) adapt it to new environments.

Collaboration with PKIX is very important, but we cannot let PKIX slow-down
our effort to adapt to new environments. The task here is quite urgent.
Major national infrastructure are at risk.

Regards,

Erik

-----Oprindelig meddelelse-----
Fra: pkix [mailto:[e-mail]] På vegne af Stephen Farrell
Sendt: 24 January 2016 01:52
Til: Peter Bowen <[e-mail]>
Cc: <[e-mail]> <[e-mail]>
Emne: Re: [pkix] Next edition of X.509


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
> 

_______________________________________________
pkix mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pkix