Capwap Mailing List: Re: Issue 34: keyPurposeID needs clarification

[Sam Hartman (hartmans-ietf]

>>>>> "Pat" == Pat Calhoun (pacalhou) <pcalhoun [at] cisco.com> writes:

    Pat> All,
    Pat> The editors, security advisors, chairs and ADs met today at lunch and
    Pat> discussed this topic. We agreed on an approach, which I believe is
    Pat> represented in the following text:

    Pat> <text>
    Pat> If a device presents its certificate which includes either the id-kp-
    Pat> capwapAC or id-kp-capwapWTP EKU, its role MUST be enforced.  For
    Pat> instance, if a certificate received during a DTLS session
    Pat> establishment includes the id-kp-capwapAC EKU, the receiving CAPWAP
    Pat> device MUST NOT allow its peer to act as a WTP.  In the absence of
    Pat> either one of these EKUs, the id-kp-anyExtendedKeyUsage EKU allows a
    Pat> device to act as either a WTP or AC.
    Pat> </text>

The EKU extension is defined in such a way that if a device presents
both keyPurposeIDs then the device is permitted to take on either
role.

I'd say something like
[I'm not looking at RFC 3280, so please double check my capitalization]

All capwap devices MUST support the ExtendedKeyUsage certificate
extension if it is present in a certificate.  If the extension is
present, then the certificate MUST have either the id-kp-
   capwapAC or the id-kp-anyExtendedKeyUsage  keyPurposeID to act as an AC.  
Similarly, if the extension is present, a device must have the id-kp-capwapWTP 
or id-kp-anyExtendedKeyUsage  keyPurposeID to act as a WTP.

--------------------

As a note, the extension is called EKU, but the extension contains multiple 
keyPurposeIDs