Subject: Re: [pkix] Next edition of X.509

From: Peter Bowen <[email-masked]>
Date: Fri, 22 Jan 2016 17:49:58 -0800

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 <[email-masked]> 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:[email-masked]]
> Sendt: 07 December 2015 11:45
> Til: Erik Andersen <[email-masked]>; Directory list <[email-masked]>; PKIX <[email-masked]>
> Cc: [email-masked]
> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/pkix
>>
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: "Erik Andersen" <[email-masked]>
Date: Sat, 23 Jan 2016 11:19:51 +0100

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:[email-masked]] 
Sendt: 23 January 2016 02:50
Til: Erik Andersen <[email-masked]>
Cc: Stephen Farrell <[email-masked]>; Directory list <[email-masked]>; PKIX <[email-masked]>; [email-masked]
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 <[email-masked]> wrote:
> Til: Erik Andersen <[email-masked]>; Directory list 
> <[email-masked]>; PKIX <[email-masked]>
> Cc: [email-masked]
> 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.
>
>> based on a set of defects reports, which include the justification 
>> for the changes. The Defect reports may be found on 
>> An early corrigendum has been approved within ISO and ITU-T and may 
>> be found
>> called whitelist but now the term is authorization and validation 
>> list is used. A proposal for such a feature is included in the amendment.
>>
>> 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>

---

From: Peter Bowen <[email-masked]>
Date: Sat, 23 Jan 2016 04:44:08 -0800

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

---

From: Michael StJohns <[email-masked]>
Date: Sat, 23 Jan 2016 12:32:03 -0500

> needed in section 10 to include key purposes in the input, output, and

As a general concept, backwards compatibility is a good idea.  As is 
having end systems all get the same results when presented with the same 
data.   I don't think the above approach accomplishes this.

Instead of overloading the current meaning of ExtendedKeyUsage, I would 
strongly recommend creating another extension, new OID with similar 
syntax, but the new semantics.  This also gives you the opportunity to 
turn on the "critical" bit (maybe "bits" if you have some extended 
usages that you care about always and others that you don't).

Alternately (and possibly the best choice), place the OIDs in the 
CertificatePolicy extension as constraints on the key usage bits. You 
can use the same EKU oids, but their presence in the certificate policy 
then becomes a constraint on subordinate certificates and you can 
describe exactly how that works. (See my post script for a couple of 
ways of doing this).

In your above comment I would avoid the language "in addition to, or in 
place of" and use one or the other.   If you leave the language in, then 
you need additional language which describes how to determine which 
rules in the situation where the ExtendedKeyUsage meanings are disjoint 
with the KeyUsage meanings.  (E.g. "If there is an ExtendedKeyUsage 
purpose that would normally imply a required KeyUsage bit (for example a 
"SignSpecialValidationCACertificate" implies that the "keyCertSign" bit 
should be on), but that bit is not set, then the relying party shall 
consider the certificate signing of all but certificates with a profile 
consistent with the extended key usage OID invalid).

If it takes a human (as opposed to a computer) to understand - 
consistently - what's meant by what's included in the certificate, then 
we're not doing it right.  Figuring out whether the relying party needs 
to do an "OR" ("or in place of") or an "AND" ("in addition to") between 
KeyUsage bits and ExtendedKeyUsage OIDs meanings (or some combination 
thereof) is already painful.

Mike

ps -
Possibility 1 (not exactly how Policies are supposed to work, but): 
Grab  a new oid and call it id-ce-extended-keyusage-policy.   Stick the 
ExtendedKeyUsage values as "PolicyQualifierInfo.policyQualifierId"s.  
Have the PolicyQualifierInfo.qualifier be an ENUM of { allowed, 
required, prohibited }.  Define a specific algorithm for determining 
acceptance.

Possibility 2: Each EKU OID becomes a new policy.  Add a 
policyQualifierId of id-qt-acceptance-enum with a qualifier as above 
{allowed, required, prohibited}.  Each EKU OID has one policy qualifier 
info of this type.  This is probably cleaner as it requires each 
subordinate certificate to have a specific EKU expression for each EKU 
policy in the parent.

---

From: Peter Bowen <[email-masked]>
Date: Sat, 23 Jan 2016 09:40:13 -0800

On Sat, Jan 23, 2016 at 9:32 AM, Michael StJohns <[email-masked]> wrote:
> As a general concept, backwards compatibility is a good idea.  As is having
> end systems all get the same results when presented with the same data.   I
> don't think the above approach accomplishes this.

I probably should have pointed out that I'm not trying to dream up
something new here.  Microsoft, OpenSSL, and Mozilla all have
implemented this and are compatible with each other's certificate path
processing libraries, at least in this respect.  As I understand it,
this use of the EKU extension has been widely deployed for more than a
decade.  However it is not clear that anyone has ever proposed it to
be included as part of the X.509 standard.

The lack of standardization or recognition in X.509 and PKIX has led
to many disagreements over whether it is valid.  My hope is that this
revision of X.509 might be able to at least clarify that it is not
invalid to use EKU in the manner that it is currently used by these
systems.

> strongly recommend creating another extension, new OID with similar syntax,
> but the new semantics.  This also gives you the opportunity to turn on the
> "critical" bit (maybe "bits" if you have some extended usages that you care
> about always and others that you don't).
>
> CertificatePolicy extension as constraints on the key usage bits. You can
> use the same EKU oids, but their presence in the certificate policy then
> becomes a constraint on subordinate certificates and you can describe
> exactly how that works. (See my post script for a couple of ways of doing
> this).
>
> place of" and use one or the other.   If you leave the language in, then you
> need additional language which describes how to determine which rules in the
> situation where the ExtendedKeyUsage meanings are disjoint with the KeyUsage
> meanings.  (E.g. "If there is an ExtendedKeyUsage purpose that would
> normally imply a required KeyUsage bit (for example a
> If it takes a human (as opposed to a computer) to understand - consistently
> - what's meant by what's included in the certificate, then we're not doing
> it right.  Figuring out whether the relying party needs to do an "OR" ("or
> in place of") or an "AND" ("in addition to") between KeyUsage bits and
> ExtendedKeyUsage OIDs meanings (or some combination thereof) is already
> painful.
>
>
> Mike
>
>
> ps -
> Possibility 1 (not exactly how Policies are supposed to work, but): Grab  a
> new oid and call it id-ce-extended-keyusage-policy.   Stick the
> ExtendedKeyUsage values as "PolicyQualifierInfo.policyQualifierId"s.  Have
> the PolicyQualifierInfo.qualifier be an ENUM of { allowed, required,
> prohibited }.  Define a specific algorithm for determining acceptance.
>
> Possibility 2: Each EKU OID becomes a new policy.  Add a policyQualifierId
> of id-qt-acceptance-enum with a qualifier as above {allowed, required,
> prohibited}.  Each EKU OID has one policy qualifier info of this type.  This
> is probably cleaner as it requires each subordinate certificate to have a
> specific EKU expression for each EKU policy in the parent.
>
>
>
>
>
>
>>
>>> I would like to explore whether there is support for such an addition to
>>> X.509. Could I have your comments please?
>>>
>>> Regards,
>>>
>>> Erik
>>>
>>> Cc: Stephen Farrell <[email-masked]>; Directory list
>>> <[email-masked]>; PKIX <[email-masked]>; [email-masked]
>>> 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
>>>
>>>> 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?
>>>>
>>>>> 1.
>>>>> http://www.x500standard.com/uploads/extensions/x509-pdam-amd2.pdf,

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sat, 23 Jan 2016 18:34:59 -0500

>From security viewpoint I am sympathetic to what Peter says.  If we roll
back the clock constraining the path for EKU is a superior approach and COTS
use it.

But, rather putting this onus on X.509, should this not be done in RFC 5280
prior to or in conjunction with X.509 revisions?

-----Original Message-----
From: pkix [mailto:[email-masked]] On Behalf Of Peter Bowen
Sent: Saturday, January 23, 2016 12:40 PM
To: Michael StJohns <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [pkix] Next edition of X.509

On Sat, Jan 23, 2016 at 9:32 AM, Michael StJohns <[email-masked]>
wrote:
>> 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.
>>
>> needed in section 10 to include key purposes in the input, output, 
>> and processing.
>>
>> Thanks,
>> Peter
>
>
having
> don't think the above approach accomplishes this.

I probably should have pointed out that I'm not trying to dream up something
new here.  Microsoft, OpenSSL, and Mozilla all have implemented this and are
compatible with each other's certificate path processing libraries, at least
in this respect.  As I understand it, this use of the EKU extension has been
widely deployed for more than a decade.  However it is not clear that anyone
has ever proposed it to be included as part of the X.509 standard.

The lack of standardization or recognition in X.509 and PKIX has led to many
disagreements over whether it is valid.  My hope is that this revision of
X.509 might be able to at least clarify that it is not invalid to use EKU in
the manner that it is currently used by these systems.

> Instead of overloading the current meaning of ExtendedKeyUsage, I 
> would strongly recommend creating another extension, new OID with 
> similar syntax, but the new semantics.  This also gives you the 
> opportunity to turn on the "critical" bit (maybe "bits" if you have 
> some extended usages that you care about always and others that you
don't).
> can use the same EKU oids, but their presence in the certificate 
> policy then becomes a constraint on subordinate certificates and you 
> can describe exactly how that works. (See my post script for a couple 
> of ways of doing this).
>
you
> need additional language which describes how to determine which rules 
> in the situation where the ExtendedKeyUsage meanings are disjoint with 
> the KeyUsage meanings.  (E.g. "If there is an ExtendedKeyUsage purpose 
> that would normally imply a required KeyUsage bit (for example a 
> "SignSpecialValidationCACertificate" implies that the "keyCertSign" 
> bit should be on), but that bit is not set, then the relying party 
> shall consider the certificate signing of all but certificates with a 
> profile consistent with the extended key usage OID invalid).
>
> consistently
> - what's meant by what's included in the certificate, then we're not 
> doing it right.  Figuring out whether the relying party needs to do an 
> "OR" ("or in place of") or an "AND" ("in addition to") between 
acceptance.
> {allowed, required, prohibited}.  Each EKU OID has one policy 
> qualifier info of this type.  This is probably cleaner as it requires 
> each subordinate certificate to have a specific EKU expression for each
EKU policy in the parent.
>>> I would like to explore whether there is support for such an 
>>> addition to X.509. Could I have your comments please?
>>>
>>> Regards,
>>>
>>> Erik
>>>
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
>>>
>>>> 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.
>>>>
>>>>> have forwarded to the ISO/IEC JTC1/SC6 two documents for three 
>>>>> months
>>>>> ballots:
>>>>>
>>>>>
>>>>>
>>>>> An early corrigendum has been approved within ISO and ITU-T and 
>>>>> may be found
>>>>> These three documents together with the seventh edition will 
>>>>> provide the input to the next edition of X.509. The different 
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>> 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

---

From: Erwann Abalea <[email-masked]>
Date: Sun, 24 Jan 2016 00:43:01 +0100

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 <[email-masked]>:

> > Cc: Stephen Farrell <[email-masked]>; Directory list <
> [email-masked]>; PKIX <[email-masked]>; [email-masked]
> implement this even though it is unclear at best whether such is compliant
> with X.509 (10/2012).
> >
> > Thanks,
> > Peter
> >

-- 
Erwann.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sat, 23 Jan 2016 18:54:59 -0500

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:[email-masked]] On Behalf Of Erwann Abalea
Sent: Saturday, January 23, 2016 6:43 PM
To: Peter Bowen <[email-masked]>
Cc: Directory list <[email-masked]>; PKIX <[email-masked]>
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 <[email-masked] <mailto:[email-masked]> >:

Thanks,
Peter

On Sat, Jan 23, 2016 at 2:19 AM, Erik Andersen <[email-masked] <mailto:[email-masked]> > wrote:
> Fra: Peter Bowen [mailto:[email-masked] <mailto:[email-masked]> ]
> Til: Erik Andersen <[email-masked] <mailto:[email-masked]> >
> Cc: Stephen Farrell <[email-masked] <mailto:[email-masked]> >; Directory list <[email-masked] <mailto:[email-masked]> >; PKIX <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
> On Mon, Dec 7, 2015 at 3:38 AM, Erik Andersen <[email-masked] <mailto:[email-masked]> > wrote:
>> Hi Stephen,
>>
>> Fra: Stephen Farrell [mailto:[email-masked] <mailto:[email-masked]> ]
>> Til: Erik Andersen <[email-masked] <mailto:[email-masked]> >; Directory list
>> <[email-masked] <mailto:[email-masked]> >; PKIX <[email-masked] <mailto:[email-masked]> >
>> Cc: [email-masked] <mailto:[email-masked]> 
>>> [email-masked] <mailto:[email-masked]> 
>> [email-masked] <mailto:[email-masked]> 

_______________________________________________
pkix mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/pkix

-- 

Erwann.

---

From: Peter Bowen <[email-masked]>
Date: Sat, 23 Jan 2016 15:58:38 -0800

> prior to or in conjunction with X.509 revisions?

RFC 5280 states that it profiles X.509.  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.

The topic of using EKU for constraints has been raised previously on
PKIX, and during that discussion it was said:

"If there is such a strong belief that the extension should be
interpreted in a manner similar to the way that certificatePolicies
are processed, why hasn't a proposal been made to change X.509 to
specify these semantics?"

Since Erik was so kind as to make the offer to take comments on X.509
in preparation for a new revision, I figured I would take the
opportunity to make the proposal as suggested.

---

From: Erwann Abalea <[email-masked]>
Date: Sun, 24 Jan 2016 01:11:29 +0100

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 <[email-masked]>
a écrit :

> *From:* pkix [mailto:[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>] *On Behalf Of *Erwann
> Abalea
> *Sent:* Saturday, January 23, 2016 6:43 PM
> *To:* Peter Bowen <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> *Cc:* Directory list <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>; PKIX <
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> *Subject:* Re: [pkix] Next edition of X.509
>
>
>
> 2016-01-23 13:44 GMT+01:00 Peter Bowen <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>:
>
> On Sat, Jan 23, 2016 at 2:19 AM, Erik Andersen <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
> > Hi Peter,
> >
> > Fra: Peter Bowen [mailto:[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>]
> > Til: Erik Andersen <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> > Cc: Stephen Farrell <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>; Directory
> list <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>; PKIX <
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>;
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> > On Mon, Dec 7, 2015 at 3:38 AM, Erik Andersen <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
> >> Hi Stephen,
> >>
> >> Fra: Stephen Farrell [mailto:[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>]
> >> Til: Erik Andersen <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>; Directory list
> >> <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>; PKIX <
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> >> Cc: [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> >>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> >> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

-- 
Erwann.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 24 Jan 2016 00:24:01 +0000

Hiya,

On 23/01/16 23:58, Peter Bowen wrote:
> Until it is clear that using

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.

Thanks,
S.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sat, 23 Jan 2016 19:35:25 -0500

It should not be like certificate policies; it should be like name constraints.  That is, absence of extension means the certificate is unrestricted.  I believe that is how COTS (at least MSFT to my knowledge) process it.

-----Original Message-----
From: Peter Bowen [mailto:[email-masked]] 
Sent: Saturday, January 23, 2016 6:59 PM
To: Santosh Chokhani <[email-masked]>
Cc: Michael StJohns <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [pkix] Next edition of X.509

On Sat, Jan 23, 2016 at 3:34 PM, Santosh Chokhani <[email-masked]> wrote:
> From security viewpoint I am sympathetic to what Peter says.  If we 
> roll back the clock constraining the path for EKU is a superior 
> approach and COTS use it.
>
> But, rather putting this onus on X.509, should this not be done in RFC 
> 5280 prior to or in conjunction with X.509 revisions?

RFC 5280 states that it profiles X.509.  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.

The topic of using EKU for constraints has been raised previously on PKIX, and during that discussion it was said:

"If there is such a strong belief that the extension should be interpreted in a manner similar to the way that certificatePolicies are processed, why hasn't a proposal been made to change X.509 to specify these semantics?"

Since Erik was so kind as to make the offer to take comments on X.509 in preparation for a new revision, I figured I would take the opportunity to make the proposal as suggested.

>>> 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.
>>>
> decade.  However it is not clear that anyone has ever proposed it to be included as part of the X.509 standard.
>
> revision of
> X.509 might be able to at least clarify that it is not invalid to use 
> EKU in the manner that it is currently used by these systems.
>
>> in the situation where the ExtendedKeyUsage meanings are disjoint 
>> purpose that would normally imply a required KeyUsage bit (for 
>> example a "SignSpecialValidationCACertificate" implies that the "keyCertSign"
>> doing it right.  Figuring out whether the relying party needs to do 
>> an "OR" ("or in place of") or an "AND" ("in addition to") between 
>> Grab
> a
>>>>>> 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:
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://www.x500standard.com/uploads/extensions/x509-pdam-amd2.pdf
>>>>>> , which is the 3rd PDAM text for an amendment to X.509.
>>>>>>
>>>>>> based on a set of defects reports, which include the 
>>>>>> justification for the changes. The Defect reports may be found on

---

From: Peter Bowen <[email-masked]>
Date: Sat, 23 Jan 2016 16:43:19 -0800

> 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."  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.

Thanks,
Peter

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 24 Jan 2016 00:51:32 +0000

Hiya,

On 24/01/16 00:43, Peter Bowen wrote:
> 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

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.

---

From: "Erik Andersen" <[email-masked]>
Date: Sun, 24 Jan 2016 10:53:31 +0100

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:[email-masked]] På vegne af Stephen Farrell
Sendt: 24 January 2016 01:52
Til: Peter Bowen <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Emne: Re: [pkix] Next edition of X.509

Hiya,

On 24/01/16 00:43, Peter Bowen wrote:
>>> 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.
>>
>> 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.
> 

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.
> 

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.

---

From: "Erik Andersen" <[email-masked]>
Date: Wed, 27 Jan 2016 11:33:53 +0100

Hi Peter,

Back to the subject.

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.

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?

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.

Regards,

Erik

-----Oprindelig meddelelse-----
Fra: Peter Bowen [mailto:[email-masked]] 
Sendt: 23 January 2016 13:44
Til: Erik Andersen <[email-masked]>
Cc: Directory list <[email-masked]>; PKIX <[email-masked]>
Emne: Re: [pkix] Next edition of X.509

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 <[email-masked]> wrote:
>> 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.
>>

---

From: Peter Bowen <[email-masked]>
Date: Wed, 27 Jan 2016 04:05:21 -0800

> 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…

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