Re: [pkix] Next edition of X.509

Hi Wei,

A technical corrigendum to the seventh edition of X.509 provides an update to X.509 that adds internationalized DNS (Item 5 of http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor1.pdf). This technical corrigendum has been finally approved within ISO and ITU-T and is in principle part of the seventh edition of X.509. It will be integrated into the next edition of X.509 to be completed by the end of this year.

We have also introduced a DNS attribute type in an approved technical corrigendum to X.520  (Item 2 of http://www.x500standard.com/uploads/dtc/X520-Ed7-Cor1.pdf). The intention here is to have short, globally unique distinguished names. This reduces size and processing requirements, important in some environment.

It is true that we not done something for rfc822 names and the RFC 6532 issue. I will put it on my to-do-list, which is rather long. Maybe we also need a new attribute type based on rfc822 names for unique and short distinguished names.

Kind regards,

Erik

Fra: Wei Chuang [mailto:weihaw@google.com] 
Sendt: 04 February 2016 20:23
Til: Erik Andersen <era@x500.eu>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>; Directory list <x500standard@freelists.org>; PKIX <pkix@ietf.org>; WG15@iectc57.org
Emne: Re: [pkix] Next edition of X.509

Hi Erik,

I would like to point out that internationalized email addresses are not well supported in the existing documentation by the ITU X.509 as well as IETF RFCs as email addresses are specified as GeneralNames rfc822Name which are encoded with IA5String.  While domain labels have been internationalized via punycoding in RFC5280, I'm not sure if this is reflected in the ITU X.509 documentation.  Moreover Unicode email local-part as discussed in RFC6532 is not handled by either the ITU X.509 or RFCs.  How to handle that is probably served better by a separate discussion thread, which I've sent out an initial post to pkix@ietf.org <mailto:pkix@ietf.org> .  A similar issue likely exists with uniformResourceIdentifier type as well.  Perhaps its worth looking if there are others?

-Wei

On Mon, Dec 7, 2015 at 3:38 AM, Erik Andersen <era@x500.eu <mailto:era@x500.eu> > wrote:

Hi Stephen,

I will collect any comment on any list. The goal is to get the best technical specification.

Regards,

Erik

-----Oprindelig meddelelse-----
Fra: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie <mailto:stephen.farrell@cs.tcd.ie> ]
Sendt: 07 December 2015 11:45
Til: Erik Andersen <era@x500.eu <mailto:era@x500.eu> >; Directory list <x500standard@freelists.org <mailto:x500standard@freelists.org> >; PKIX <pkix@ietf.org <mailto:pkix@ietf.org> >
Cc: WG15@iectc57.org <mailto:WG15@iectc57.org> 
Emne: Re: [pkix] Next edition of X.509

Thank you Erik! Do I understand correctly that comments from this list that you get before February are useful and that sending comments to the pkix list works well enough for you?

If so, great, and I'd ask folks who care about RFC5280 or other PKIX RFCs to please review this to check for any glitches that might affect interop should new code be written based on the ISO doc. I'm sure other comments are also welcome,

Cheers,
S.

On 07/12/15 10:33, Erik Andersen wrote:
> In preparation for the next edition of X.509 (the 2016 edition), I
> have forwarded to the ISO/IEC JTC1/SC6 two documents for three months ballots:
>
>
>
> These two documents may be found as:
>
>
>
> 1.       http://www.x500standard.com/uploads/extensions/x509-pdam-amd2.pdf,
> which is the 3rd PDAM text for an amendment to X.509.
>
> 2.       http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor2.pdf, which a
> second draft technical corrigendum. This technical corrigendum is
> based on a set of defects reports, which include the justification for
> the changes. The Defect reports may be found on
> http://www.x500standard.com/index.php?n=Ig.DefectReports.
>
>
>
> An early corrigendum has been approved within ISO and ITU-T and may be
> found
> as: http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor1.pdf.
>
>
>
> These three documents together with the seventh edition will provide
> the input to the next edition of X.509. The different
> X.recommendations, including X.509, may be found at
> http://www.itu.int/rec/T-REC-X/e. This edition of X.509 is freely available in the PDF version.
>
>
>
> Those involved in  ISO/IEC JTC1/SC6 can, of course, submit ballot
> comments on the two documents out for ballot. Others, which may have
> comments on the these document, may post them on the lists and after
> consolidation and consensus, they may be issued as ITU-T comments.
>
>
>
> It is important to check whether any of the suggested changes affects
> running codes. If that is a case, it is a mistake.
>
>
>
> The intension behind the changes has been:
>
> 1.       A better separation between public-key certificates and attribute
> certificates.
>
> 2.       Use of a consistent terminology.
>
> 3.       Use of a consistent editing style in accordance with the ITU-T
> editing guidelines..
>
> 4.       A new PKI component called trust broker assists a relying party
> validating a public-key certificate is included.
>
> 5.       IEC TC57 WG15 has identified a requirement for a feature first
> called whitelist but now the term is authorization and validation list
> is used. A proposal for such a feature is included in the amendment.
>
> The main goal has been to position X.509 for new challenges, such
> smart grid security and security for Internet of Things with battery
> driven devices, very short messages (can we put a 257 octets signature
> on a few octets message?) , short reaction time requirements, many
> millions of entities, etc. This is all very different from Web-based  systems.
>
> Kind regards,
>
> Erik
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> pkix mailing list
> pkix@ietf.org <mailto:pkix@ietf.org> 
> https://www.ietf.org/mailman/listinfo/pkix
>

_______________________________________________
pkix mailing list
pkix@ietf.org <mailto:pkix@ietf.org> 
https://www.ietf.org/mailman/listinfo/pkix