Re: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates

[Stephen Kent <kent@xxxxxxx>]

At 4:54 PM -0500 12/21/07, Scott G. Kelly wrote:
> Hi Steve,
>
> Thanks for taking a look at this. Regarding placement of the MAC in 
> the CN, I would offer two observations:
>
> 1) this is what is specified in the DOCSIS and PacketCable cert 
> profiles, and it was on this basis that device certs for LWAPP were 
> originally designed in this way. You can see the DOCSIS profile at 
> www.drizzle.com/~aboba/CPW/DOCSIS.ppt

I was not aware that DOCSIS and PacketCable had created cert profiles 
using this convention. That provides a strong rationale for CAPWAP 
specs to be compatible where the two overlap, i.e., in terms to certs 
provisioned in WTPs and ACs. Since this is the rationale for this 
questionable use of the CN field, the document should include cites 
to the relevant DOCSIS and PacketCable specs, and say that this 
convention has been employed here because these specs have caused 
numerous devices to be provisioned with certs of this form.

> 2) I don't see anything in the X.520 language that explicitly 
> precludes this usage, so assuming that the docsis/packetcable 
> designers reviewed that spec, I can see how they could reasonably 
> conclude that this is acceptable. Arguably, the string 
> representation of the MAC address is "a string chosen [by the] 
> organization responsible for the object it describes for devices and 
> application entities".

One ought not expect the writers of X.520 to anticipate every 
questionable use of an attribute and say "no, don't do this" so I 
don't think your observation above is a valid argument in favor of 
using CN here. Also, the text for common name starts by saying "A 
Common Name is not a directory name; it is a (possibly ambiguous) 
name by which the object is commonly known in some limited scope 
(such as an organization) and conforms to the naming conventions of 
the country or culture with which it is associated." This text, which 
precedes the text you cite, makes it clear that a MAC address should 
not be represented as a common name. A vendor assigning a MAC 
generally does so in a globally unique fashion, which contradicts the 
"limited scope" concept cited in the standard. A MAC address is not 
at all congruent with the allusions to "naming conventions of the 
country or culture with which it is associated" part of the 
description of the common name attribute.

The usual argument for putting a value in an attribute where it is 
inappropriate is because preferable choices for where to put the 
value are not commonly supported.  So, for example, if you were 
dealing with version 1/2 certs, rather than version 3, the use of 
otherName or registeredID would not be available.  But, the 
serialNumber attribute has always been available.

I looked at the DOCSIS and PacketCable slides for which you provided 
the URL.  I see that the DOCSIS profile for cable modems calls for 
two CN attributes in the cert. If one argues that here is a need to 
use only widely supported attribute types (hence a rationale for 
using common name over serial number for the MAC address), then one 
ought not take an attribute that would NOT be repeated in a DN, and 
insert two instances of it, as was done here.

> Please don't misunderstand: I'm not trying to be difficult, and I 
> have a very healthy respect for the depth of your knowledge in this 
> area. However, there are a *lot* of devices deployed that already 
> use this convention. It might be more pragmatic to interpret X.520 a 
> little less restrictively.

I'm not trying to be difficult either.Sam asked PKIX to review 
PKI-specific parts of the spec and I did. I expect the IESG to ignore 
my objection,
given the deployed base you and others cite. But let's be honest and 
recognize that this was an error, probably based on bad advice given 
to by the DOCSIS folks.  Also note that PKIX RFCs have taken a strong 
stand against putting inappropriate values into the CN field in the 
past, e.g., stuffing an e-mail address there, despite the fact that 
lots of certs were issued tha way.

Steve