Re: [pkix] Next edition of X.509

[Peter Bowen <[e-mail]>]

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
>