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

[Pat Calhoun (pacalhou) (pcalhoun]

Works for me.

PatC 

-----Original Message-----
From: Sam Hartman [mailto:hartmans-ietf [at] mit.edu] 
Sent: Monday, March 10, 2008 1:59 PM
To: Pat Calhoun (pacalhou)
Cc: capwap
Subject: Re: [Capwap] Issue 34: keyPurposeID needs clarification

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