Capwap Mailing List: Issue 34: keyPurposeID needs clarification

[Pat Calhoun (pacalhou) (pcalhoun]

All,

The issue that was raised was that the use of the keyPurposeID was
unclear. I actually disagree since the last last sentence of section
2.4.4.3 includes:

<existing text>
2.4.4.3.  Certificate Usage
[...]

   The particulars of authorization
   filter construction are implementation details which are, for the
   most part, not within the scope of this specification.  However, at
   minimum, all devices MUST verify that the appropriate EKU bit is set
   according to the role of the peer device (AC vs. WTP), and that the
   issuer of the certificate is appropriate for the domain in question.
</existing text>

However, if Sam felt this was not sufficient, I have added a sentence to
an
existing paragraph (the last sentence below):

<proposed text>
2.4.4.3.  Certificate Usage
[...]

   Part of the CAPWAP certificate validation process includes ensuring
   that the proper EKU is included and allowing the CAPWAP session to be
   established only if the extension properly represents the device. For
   instance, an AC SHOULD NOT accept a connection request from another
AC, and
   therefore MUST verify that the id-kp-capwapWTP EKU is present in the
   certificate.
</proposed text>

I believe this provides about as much guidance as needed.

PatC