Re: [pkix] Next edition of X.509

On Wed, Jan 27, 2016 at 2:33 AM, Erik Andersen <era@x500.eu> wrote:
> The second sentence in your proposal seems to imply that when a CA certificate has a certain extended key usage, then this extended key usage also applies for subsequent public-key certificates on certification path. Is that a right interpretation.

Yes, that is the right interpretation.  To further clarify, a
CA-certificate that includes an extKeyUsage extension containing the
anyExtendedKeyUsage key purpose is equivalent to a CA-certificate that
does not include an extKeyUsage extension.

> As to your first mail, it was my impression you were asking for the definition of new OIDs with associated semantics to cover restriction. Is that the case?

No.  There is no request to define new OIDs.  Rather the request is to
clarify (or redefine depending on your view) the meaning of the
extKeyUsage extension when present in a CA-certificate.

> The Chinese member body of SC6 is interested in a better algorithm for certificate validation to be added to X.509. I wonder whether your suggestion fits into that effort.

Without more details, I would assume it could.  Several code libraries
that implement portions of X.509 already interpret extKeyUsage as
described.

Thanks,
Peter

> -----Oprindelig meddelelse-----
> Fra: Peter Bowen [mailto:pzbowen@gmail.com]
> Sendt: 23 January 2016 13:44
> Til: Erik Andersen <era@x500.eu>
> Cc: Directory list <x500standard@freelists.org>; PKIX <pkix@ietf.org>
> Emne: Re: [pkix] Next edition of X.509
>
> In 8.2.2.4, replace the first sentence with:
>
> The presence of this extension in an end-entity certificate indicates one or more purposes for which the certified public key may be used, in addition to, or in place of the basic purposes indicated in the key usage extension field. The presence of this extension in a certificate issued by one CA to another CA constrains the key purposes in subsequent certificates in a certification path.
>
> If there is support for this addition, then additions will also be needed in section 10 to include key purposes in the input, output, and processing.
>
> Thanks,
> Peter
>
> On Sat, Jan 23, 2016 at 2:19 AM, Erik Andersen <era@x500.eu> wrote:
>> Hi Peter,
>>
>> I would like to explore whether there is support for such an addition to X.509. Could I have your comments please?
>>
>> Regards,
>>
>> Erik
>>
>> -----Oprindelig meddelelse-----
>> Fra: Peter Bowen [mailto:pzbowen@gmail.com]
>> Sendt: 23 January 2016 02:50
>> 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
>>
>> Erik,
>>
>> While I'm sure this is a contentious proposal, I would proposal that
>> X.509 add language allowing usage of Extended Key Usage for constraints, joining certificate policies, name constraints, basic constraints, etc.  Many widely deployed certificate path validation libraries already implement this even though it is unclear at best whether such is compliant with X.509 (10/2012).
>>
>> Thanks,
>> Peter
>>
>> On Mon, Dec 7, 2015 at 3:38 AM, Erik Andersen <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]
>>> Sendt: 07 December 2015 11:45
>>> Til: Erik Andersen <era@x500.eu>; Directory list
>>> <x500standard@freelists.org>; PKIX <pkix@ietf.org>
>>> Cc: 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
>>>> https://www.ietf.org/mailman/listinfo/pkix
>>>>
>>>
>>> _______________________________________________
>>> pkix mailing list
>>> pkix@ietf.org
>>> https://www.ietf.org/mailman/listinfo/pkix
>>
>