Re: [pkix] Next edition of X.509

["Santosh Chokhani" <[e-mail]>]

>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:[e-mail]] On Behalf Of Peter Bowen
Sent: Saturday, January 23, 2016 12:40 PM
To: Michael StJohns <[e-mail]>
Cc: <[e-mail]> <[e-mail]>
Subject: Re: [pkix] Next edition of X.509

On Sat, Jan 23, 2016 at 9:32 AM, Michael StJohns <[e-mail]>
wrote:
> On 1/23/2016 7:44 AM, Peter Bowen wrote:
>>
>> 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
>
>
> 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.

> 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.
>
>
>
>
>
>
>>
>> On Sat, Jan 23, 2016 at 2:19 AM, Erik Andersen <[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]]
>>> Sendt: 23 January 2016 02:50
>>> Til: Erik Andersen <[e-mail]>
>>> Cc: Stephen Farrell <[e-mail]>; Directory list 
>>> <[e-mail]>; PKIX <[e-mail]>; [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]> 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]]
>>>> Sendt: 07 December 2015 11:45
>>>> Til: Erik Andersen <[e-mail]>; Directory list 
>>>> <[e-mail]>; PKIX <[e-mail]>
>>>> Cc: [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]
>>>>> https://www.ietf.org/mailman/listinfo/pkix
>>>>>
>>>> _______________________________________________
>>>> pkix mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/pkix
>>
>> _______________________________________________
>> pkix mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pkix
>
>
> _______________________________________________
> pkix mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix

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