Re: [pkix] Next edition of X.509

[Erwann Abalea <[e-mail]>]

If you need an EKU used by an end-entity certificate to be present in the
CA certificates (=granted), then you'll need the OCSPsigning EKU to be
present in the issuing CA certificate. Which makes this issuing CA
certificate a designated OCSP responder for its issuer.

The problem will arise if you want to constrain a CA for specific key
usages, i.e. when you'll want to make use of this redefinition.

Le dimanche 24 janvier 2016, Santosh Chokhani <[e-mail]>
a écrit :

> What do you mean by not working?
>
>
>
> If one assumes that absence of EKU makes a certificate unconstrained, does
> this not work?
>
>
>
> May be you mean OCSP clients do not enforce EKU for the path.
>
>
>
> *From:* pkix [mailto:[e-mail]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>] *On Behalf Of *Erwann
> Abalea
> *Sent:* Saturday, January 23, 2016 6:43 PM
> *To:* Peter Bowen <[e-mail]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>>
> *Cc:* Directory list <[e-mail]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>>; PKIX <
> [e-mail] <javascript:_e(%7B%7D,'cvml','[e-mail]');>>
> *Subject:* Re: [pkix] Next edition of X.509
>
>
>
> It doesn't work with designated OCSP responder certificates, unless you
> introduce an exception for this particular extended key usage.
>
>
>
> 2016-01-23 13:44 GMT+01:00 Peter Bowen <[e-mail]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>>:
>
> 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 <[e-mail]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>> 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:[e-mail]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>]
> > Sendt: 23 January 2016 02:50
> > Til: Erik Andersen <[e-mail]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>>
> > Cc: Stephen Farrell <[e-mail]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>>; Directory
> list <[e-mail]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>>; PKIX <
> [e-mail] <javascript:_e(%7B%7D,'cvml','[e-mail]');>>;
> [e-mail] <javascript:_e(%7B%7D,'cvml','[e-mail]');>
> > 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 <[e-mail]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>> 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:[e-mail]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>]
> >> Sendt: 07 December 2015 11:45
> >> Til: Erik Andersen <[e-mail]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>>; Directory list
> >> <[e-mail]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>>; PKIX <
> [e-mail] <javascript:_e(%7B%7D,'cvml','[e-mail]');>>
> >> Cc: [e-mail] <javascript:_e(%7B%7D,'cvml','[e-mail]');>
> >> 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
> >>> [e-mail] <javascript:_e(%7B%7D,'cvml','[e-mail]');>
> >>> https://www.ietf.org/mailman/listinfo/pkix
> >>>
> >>
> >> _______________________________________________
> >> pkix mailing list
> >> [e-mail] <javascript:_e(%7B%7D,'cvml','[e-mail]');>
> >> https://www.ietf.org/mailman/listinfo/pkix
> >
>
> _______________________________________________
> pkix mailing list
> [e-mail] <javascript:_e(%7B%7D,'cvml','[e-mail]');>
> https://www.ietf.org/mailman/listinfo/pkix
>
>
>
>
>
> --
>
> Erwann.
>


-- 
Erwann.