Re: [pkix] Next edition of X.509

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

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:[e-mail]] 
Sent: Saturday, January 23, 2016 6:59 PM
To: Santosh Chokhani <[e-mail]>
Cc: Michael StJohns <[e-mail]>; <[e-mail]> <[e-mail]>
Subject: Re: [pkix] Next edition of X.509

On Sat, Jan 23, 2016 at 3:34 PM, Santosh Chokhani <[e-mail]> 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.

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