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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 2 Jan 2008 09:53:41 -0800

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

I would argue the reverse.
 
First it is far more important to be consistent with established practice than what the descriptive text in the X.520 spec might say. The Common Name is just a sequence of bits making up a tag-value pair. It is what it is, meaning is the result of usage.
 
More importantly I would argue that the word 'limited' should be considered in the context 'in at least a limited context'. In general we like names to be as unique as is possible. Common names are not unique in general (although my common name is in fact unique at this point in time). We should not hold the fact that EUI-48 addresses do in general have this desirable property against them. The spec says POSSIBLY ambiguous. EUI-48 names appear to comply in my view.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 2 Jan 2008 13:32:27 -0500

>I would argue the reverse.

Why am I not surprised?

>  First it is far more important to be consistent with established 
>practice than what the descriptive text in the X.520 spec might say. 
>The Common Name is just a sequence of bits making up a tag-value 
>pair. It is what it is, meaning is the result of usage.

If the DOCSIS and PacketCable specs preceded the X.520 publication, 
this would have been a good argument. But these specs came along much 
later. The folks at Cable Labs who decided to put the MAC address in 
the CN  made a poor choice.

If your comments apply to the capwap I-D, I have already stated that, 
given the need to be compatible with the extant, deployed base, there 
isn't much of a choice here. However, the capwap I-D needs to cite 
these specs as the justification for this odd decision, so that 
readers don't draw the wrong conclusion.

>  More importantly I would argue that the word 'limited' should be 
>considered in the context 'in at least a limited context'. In 
>general we like names to be as unique as is possible. Common names 
>are not unique in general (although my common name is in fact unique 
>at this point in time). We should not hold the fact that EUI-48 
>addresses do in general have this desirable property against them. 
>The spec says POSSIBLY ambiguous. EUI-48 names appear to comply in 
>my view.

If one looks at ALL of the text associated with the definition of CN, 
it is clear what sorts of names are envisioned, and a MAC address is 
not a reasonable candidate. One might work hard to try to find a way 
to justify the use, but hopefully a smart guy like you is doing so 
tongue-in-cheek.

Steve

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 2 Jan 2008 13:32:36 -0800

You write the spec, you hope that people will take notice.
 
If people do not take notice that is at least in part the fault of the spec writer for failing to make their intentions more clearly understood.

What the CableLabs sec should have said seems like a pointless argument to me at this point but for the record we have a professional disagreement as to the most reasonable interpretation of this passage. EUI-48 identifiers do not exactly map onto any meaningful concept within X.520 space, this is due to the same lack of imagination on its designers part that makes X.500 the real world success it is today. The choice is between using the CN field and creating a new one. The CN field approach meets the expectations of existing applications much better than a new creation would.

________________________________

From: [email-masked] on behalf of Stephen Kent
Sent: Wed 02/01/2008 1:32 PM
To: Hallam-Baker, Phillip
Cc: Scott G. Kelly; Sam Hartman; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates

Why am I not surprised?

If the DOCSIS and PacketCable specs preceded the X.520 publication, this would have been a good argument. But these specs came along much later. The folks at Cable Labs who decided to put the MAC address in the CN  made a poor choice.

If your comments apply to the capwap I-D, I have already stated that, given the need to be compatible with the extant, deployed base, there isn't much of a choice here. However, the capwap I-D needs to cite these specs as the justification for this odd decision, so that readers don't draw the wrong conclusion. 

If one looks at ALL of the text associated with the definition of CN, it is clear what sorts of names are envisioned, and a MAC address is not a reasonable candidate. One might work hard to try to find a way to justify the use, but hopefully a smart guy like you is doing so tongue-in-cheek.

Steve

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 05 Jan 2008 22:05:43 +1300

Stephen Kent <[email-masked]> writes:

>If the DOCSIS and PacketCable specs preceded the X.520 publication, this
>would have been a good argument. But these specs came along much later. The
>folks at Cable Labs who decided to put the MAC address in the CN  made a poor
>choice.

Only in the eyes of X.500 theologists.  As a pragmatic decision it's perfectly
appropriate.  If you're identifying a CC holder, the CN is your credit card
number.  If you're identifying a taxpayer, the CN is the taxpayer ID.  If
you're identifying a web server, the CN is the server's URL/FQDN.  If you're
identifying a piece of hardware addressed by MAC address, the CN is the MAC
address.

>If one looks at ALL of the text associated with the definition of CN, it is
>clear what sorts of names are envisioned

Yup, something that works with the global X.500 directory.  Just as soon as
that appears we can start requiring people to choose names compliant with it.

Peter.

---

From: Steven Legg <[email-masked]>
Date: Mon, 07 Jan 2008 11:18:36 +1100

Peter,

Peter Gutmann wrote:
> number.

One of the modes for accessing a directory is browsing up and down the
directory tree. As a human user browsing the directory tree, seeing a
list of entries with common names that are just numbers isn't very
helpful to me. A common name like "Peter Gutmann's Visa Card" is much
more informative than the common name "1234 5678 9012 3456". If I'm
interested in the entry for a particular card number then I would
just search directly on the attribute holding the card number, rather
that browsing the tree. The same considerations apply to the other
examples you've given.

The commonName attribute is not a particularly appropriate choice for
searching and sorting purposes either because it uses caseIgnoreMatch
as the equality matching rule. The values "1234 5678 9012 3456" and
"1234567890123456" are different common name values, but would be
the same value for an attribute with the NumericString syntax and
numericStringMatch equality matching rule. Unfortunately, LDAP and
X.500 don't define a general-purpose number attribute with this syntax
(serialNumber uses PrintableString and caseIgnoreMatch). Perhaps they
(or PKIX) should, to avoid further abuses of the commonName attribute ?

 > If you're identifying a taxpayer, the CN is the taxpayer ID.  If

The presence or absence of a global X.500 directory is not relevant.
Good naming practice applies just as much to stand-alone enterprise
directory deployments.

Regards,
Steven

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 07 Jan 2008 18:56:19 +1300

Steven Legg <[email-masked]> writes:

>directory tree.

And when do people ever do this?  Google, one of the worlds biggest IT
companies (?), made most of its fortune from the very fact that people don't
do this.  When did Joe Sixpack last use an Internet directory, and when did
they last use a non-directory Internet search engine?

(I'm guessing the answer is pretty close to "never" for the former, and "the
last time they went online" for the latter).

>A common name like "Peter Gutmann's Visa Card" is much more informative than
>the common name "1234 5678 9012 3456".

To whom is it informative?  In what possible context does anyone processing a
credit card payment care in the remotest manner whether card "1234 5678 9012
3456" belongs to "Peter Gutmann" or "The Jolly Green Giant"?  All they care
about is the card number and "authorised/declined".

(The very existence of anonymous prepaid credit cards prove that card
processors don't care in the slightest about "Peter Gutmann's Visa Card":
there's no name associated with the card at all since it has zero value to
them).

How about the following compromise between X.500 theologists and pragmatists:
The pragmatists agree to make all their DNs fully X.500 (well, X.520)
compliant the moment the global X.500 directory emerges, and in exchange the
X.500 theologists agree not to bother the pragmatists any more until the
global X.500 directory emerges.

Peter.

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 7 Jan 2008 11:09:07 -0500

You believe Google employees do a Google search when they want to find
the telephone number or organizational designator of another employee,
or find the employees of a particular organization?

I may or may not be representative of Joe Sixpack, but I use a directory
when I want to look up structured data and a full text search when I
want to find content on a topic.  And to answer the question, I used my
employer's directory more recently than I used our internal Google
service.
Semantic consistency makes structured data work better.

How about if the pragmatists refrain from objecting to standards for
tagged data field semantics, and instead just silently ignore the
standards that they find too restrictive.  Feel free to ignore Dublin
Core too, and go ahead and put Identifier information into the
Description element.

And stop chanting "global directory" - directories can federate based on
X.500 standards without needing a Borg to be assimilated into.

Bob Juenemann's jpeg-of-a-cat example is a perfectly pragmatic use for
the Common Name field.  Base-64 will make it fit Printable String, and
pragmatic applications could parse it and treat it like favicon.ico.  If
anything goes, then why not?

Dave

-----Original Message-----
From: Peter Gutmann

And when do people ever do this?  Google, one of the worlds biggest IT
companies (?), made most of its fortune from the very fact that people
don't
do this.  When did Joe Sixpack last use an Internet directory, and when
did
they last use a non-directory Internet search engine?

(I'm guessing the answer is pretty close to "never" for the former, and
"the
last time they went online" for the latter).

[...]

How about the following compromise between X.500 theologists and
pragmatists:
The pragmatists agree to make all their DNs fully X.500 (well, X.520)
compliant the moment the global X.500 directory emerges, and in exchange
the
X.500 theologists agree not to bother the pragmatists any more until the
global X.500 directory emerges.

Peter.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 7 Jan 2008 10:59:33 -0500

>identifying a piece of hardware addressed by MAC address, the CN is the MAC

Pragmatism is all too often cited as a justification for ill-advised 
behavior. All of your examples of what cab be stuffed into the CN 
attribute are good examples of what NOT to put there. The penultimate 
example specifically is disparaged by PKIX standards.

In the early days of TCP/IP, the folks responsible for the BSD 
implementation decided to NOT calculate the TCP checksum for each 
packet.  Pragmatically, they found the Ethernet MAC layer CRC to 
suffice and having to calculate the TCP checksum slowed down their 
implementation. The fact that a standard defined what to put in the 
the TCP checksum field was irrelevant to them, based on a purely 
local, pragmatic view of the situation.

I see echos of that mentality here.

Steve

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 7 Jan 2008 09:32:19 -0800

It seems that stating that the identifier used in a certificate MUST be
a MAC address may be overly restrictive.  It seems you would want to
allow for MAC address, but not require it.  Is there a reason why the
identifier needs to be a MAC address (if I understand correctly the AC
and WTP may not be directly L2 connected and may not have direct
knowledge of each others MAC address)?  
Why wouldn't another identifier string be acceptable?  
Is the MAC address interpreted by the peer or is it just an identifier
string?
If there are multiple MAC addresses which one is used?

Joe

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Scott G. Kelly
> Sent: Friday, December 21, 2007 1:55 PM
> To: Stephen Kent; Sam Hartman
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [secdir] Please review 
> draft-ietf-capwap-protocol-specification's use of certificates
> 
> 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
> 
> 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". 
> 
> 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.
> 
> Scott
> 
> >From: Stephen Kent <[email-masked]>
> >Sent: Dec 21, 2007 3:00 PM
> >To: Sam Hartman <[email-masked]>
> >Cc: [email-masked], [email-masked], [email-masked]
> >Subject: Re: [secdir] Please review 
> >draft-ietf-capwap-protocol-specification's use of certificates
> >
> >At 9:23 PM -0500 12/20/07, Sam Hartman wrote:
> >>Hi, folks.  The capwap working group is preparing to last 
> call their 
> >>protocol specification draft.
> >>
> >>I'd appreciate review from the pkix community of section 2.4.4.3 and
> >>12.6 of this draft.  These sections specify certificate 
> validation and 
> >>certificate usage for the protocol.  Scott Kelly and Charles Clancy 
> >>are security advisors for the working group and have been heavily 
> >>involved.
> >>
> >>The capwap certificate profile assumes that the CN in the 
> certificate 
> >>has structure and contains an ethernet MAC address.  The capwap 
> >>certificate profile also assumes that parts of the subject 
> name such 
> >>as the organization and organizational unit will be important to 
> >>certificate matching.
> >>
> >>I'd appreciate review and comments.
> >>
> >>--Sam
> >
> >It would be preferable to get an allocated name space for MAC 
> >addresses, under the OtherName or, better yet, under registeredID.
> >
> >I'd argue that it is inappropriate to put a MAC address into a CN. 
> >The text from X.520 makes this clear:
> >
> >The Common Name attribute type specifies an identifier of an object. 
> >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.
> >
> >An attribute value for common name is a string chosen either by the 
> >person or organization it describes or the organization 
> responsible for 
> >the object it describes for devices and application entities. For 
> >example, a typical name of a person in an English-speaking country 
> >comprises a personal title (e.g., Mr., Ms., Rd, Professor, 
> Sir, Lord), 
> >a first name, middle name(s), last name, generation 
> qualifier (if any, 
> >e.g., Jr.) and decorations and awards (if any e.g., QC).
> >
> >Examples
> >CN = "Mr. Robin Lachlan McLeod BSc(Hons) CEng MIEE"
> >CN = "Divisional Coordination Committee"
> >CN = "High Speed Modem".
> >
> >If there is a very strong desire to make use of an existing 
> attribute 
> >in the X.502 space, the SerialNumber attribute makes more sense. So 
> >long as we are talking about long, term, stable MAC 
> addresses assigned 
> >to devices by manufacturers, this is consistent with the 
> semantics of 
> >that attribute.  Moreover, we have advised folks to use 
> SerialNumber to 
> >represent data such as employee/student IDs in the past, so 
> one might 
> >expect to see support for this attribute in many CAs and clients.
> >
> >Steve
> 
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://mailman.mit.edu/mailman/listinfo/secdir
>

---

From: "Mani, Mahalingam (Mani)" <[email-masked]>
Date: Mon, 7 Jan 2008 11:31:53 -0700

If you look at the section (PSK usage) it becomes more evident that MAC
address is intended as a means of using a namespace for unique
identifier for WTP.

So - the extent to which the peer AC interprets is for that
identification of belonging to a database with a certain assurance of
uniqueness without having to create another device namespace. It was
perhaps partly motivated by other prior practices such as from cablelabs
& DOCSIS.

It is not intended as a runtime-verification at L2 (since WTPs and AC
deployment can span across routers).

So - does MAC address used thus qualify as acceptable identifier string
in your interpretation?

If so - does that still make this form of usage in CN acceptable?

My understanding is the LAN-side MAC address that is used (not the radio
addresses). I will let the CAPWAP authors clarify that.

-mani
-----Original Message-----
From: Joseph Salowey (jsalowey) [mailto:[email-masked]] 
Sent: Monday, January 07, 2008 9:32 AM
To: Scott G. Kelly; Stephen Kent; Sam Hartman
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [secdir] Please review

Joe

---

From: Stephen Kent <[email-masked]>
Date: Mon, 7 Jan 2008 14:21:01 -0500

>addresses). I will let the CAPWAP authors clarify that.

Mani,

I think the bottom line has been lost in the recent set of messages. 
My position, (stated in messages at least a week ago) as the SECDIR 
review for the document is:

	- CAPWAP needs to adopt the X.509 Subject DN convention 
adopted by the DOCSIS and later CableLabs specs, that calls for 
putting the MAC address in the CM field.

	- The document needs to justify this misuse of CN to 
represent the MAC address on that basis, and hence needs to cite the 
relevant specs.

	- the document should indicate that this use of NOT 
consistent with X.520 and PKIX standards, but has been used here for 
backwards compatibility.

	- it would be nice if future specs of this sort would employ 
the SerialNumber attribute for the MAC address IF there is a strong 
need to use the Subject field; the preferred solution would be to use 
a Subject Alternative Name and define a name space specifically for 
MAC addresses.

Steve

---

From: Russ Housley <[email-masked]>
Date: Mon, 07 Jan 2008 15:20:03 -0500

I think we disagree on the details of the CN=MAC Address situation.

CableLabs has been using this convention for a long time.  Other 
communities have followed this example because it has worked well for 
CableLabs.  While I think that defining a naming attribute for the 
MAC address might have been cleaner many respects, I understand why 
this was not done.  People want to make use of software that is 
readily available, such as OpenSSL's certificate libraries.  Teaching 
these libraries about new naming attributes is not simple, so people 
stick with the attributes that are readily available.

Russ

At 10:59 AM 1/7/2008, Stephen Kent wrote:

>attribute are good examples of what NOT to put there. The 
>penultimate example specifically is disparaged by PKIX standards.
>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 7 Jan 2008 15:49:35 -0500

At 3:20 PM -0500 1/7/08, Russ Housley wrote:
>communities have followed this example because it has worked well 
>for CableLabs.  While I think that defining a naming attribute for 
>the MAC address might have been cleaner many respects, I understand 
>why this was not done.  People want to make use of software that is 
>readily available, such as OpenSSL's certificate libraries. 
>Teaching these libraries about new naming attributes is not simple, 
>so people stick with the attributes that are readily available.
>
>Russ

I concur with your assessment of why people made the choice, which is 
why I agree that we have to live with it in this case.

I do not agree with the suggestion that we should back off on what 
constitutes good practice just because a specific piece of (open 
source) software has limitations in what it supports relative to the 
standards it purportedly implements. We have seen numerous 
limitations and several errors in the OpenSSL code over time.

I'm sure your agree that openSSL is NOT a reference implementation 
for X.509 nor PKIX standards, right?

Steve

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 7 Jan 2008 15:02:47 -0800

Hi Mani,

A MAC address is an acceptable identifier string, however if it is just
an identifier string I am not sure it is appropriate to limit it to MAC
address as the only possible identifier string.  MAC address is
currently deployed in the CN field.  I would have to defer to Steve and
others as to how appropriate this usage is with respect to PKIX and
X.509.  

Joe

> From: Mani, Mahalingam (Mani) [mailto:[email-masked]] 
> Sent: Monday, January 07, 2008 10:32 AM
> To: Joseph Salowey (jsalowey); Scott G. Kelly; Stephen Kent; 
> Sam Hartman
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; Pat Calhoun (pacalhou); Dorothy Stanley
> If you look at the section (PSK usage) it becomes more 
> evident that MAC address is intended as a means of using a 
> namespace for unique identifier for WTP.
> 
> identification of belonging to a database with a certain 
> assurance of uniqueness without having to create another 
> device namespace. It was perhaps partly motivated by other 
> prior practices such as from cablelabs & DOCSIS.
> 
> It is not intended as a runtime-verification at L2 (since 
> WTPs and AC deployment can span across routers).
> 
> So - does MAC address used thus qualify as acceptable 
> identifier string in your interpretation?
> 
> My understanding is the LAN-side MAC address that is used 
> (not the radio addresses). I will let the CAPWAP authors clarify that.
> 
> -mani
> It seems that stating that the identifier used in a 
> certificate MUST be a MAC address may be overly restrictive.  
> It seems you would want to allow for MAC address, but not 
> require it.  Is there a reason why the identifier needs to be 
> a MAC address (if I understand correctly the AC and WTP may 
> not be directly L2 connected and may not have direct 
> Is the MAC address interpreted by the peer or is it just an 
> identifier string?
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of Scott G. Kelly
> > 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
> > 
> > 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".
> > 
> 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.
> > 
> > Scott
> >

---

From: Steven Legg <[email-masked]>
Date: Tue, 08 Jan 2008 16:08:08 +1100

Peter,

Peter Gutmann wrote:
> And when do people ever do this?

User's of eB2Bcom's LDAP/X.500 directory product do it all the time,
and if you take a step back you'll realize that Google users do much the
same thing. When I use the web interface to the directory I typically start
with a search, which returns a list of matching entries. Clicking on one
of the search results presents a web page with the full details of
the entry along with links to other entries (the superior entry, any
subordinate entries and related entries), which I can click on to
browse through the directory tree. When I use Google it presents a
list of results for my search criteria. Clicking on one of the
search results leads me to a web page (hopefully with relevant content)
that typically has links to other web pages, which I can click on
to browse through the web. The scope and scale are different in each
case, but the user experience is much the same.

> Google, one of the worlds biggest IT
> To whom is it informative?

To an LDAP or X.500 directory administrator setting up access controls, to
an auditor reviewing directory audit logs, and to ordinary user's following
hyperlinks in the web interface to the directory, among others.

> In what possible context does anyone processing a
> 3456" belongs to "Peter Gutmann" or "The Jolly Green Giant"?

They don't, but there is the entire life-cycle of the credit card records
to consider. The people involved in issuing cards, cancelling cards and
resolving disputed payments probably do care that "1234 5678 9012 3456"
belongs to "Peter Gutmann".

 > All they care

The validity of X.500 naming is not contingent on the emergence of a global
X.500 directory. LDAP demonstrates that since it uses essentially the same
model, but makes no allusion to a global directory. Since PKIX standards
don't depend on there being a global X.500 directory any more than LDAP
does, making it a precondition for conformance of DNs strikes me as being
a silly proposition.

If PKIX was a world unto its own I wouldn't care what you did with DNs, but
there are LDAP and X.500 clients that expect to find a directory entry
corresponding to a certificate's subject name, so crummy subject DNs have
the potential to adversely affect me. You seem to be acknowledging that
stuffing a credit card number into the commonName attribute is not conformant
with X.520, so I guess you just don't care that such practices are bothersome,
for both practical and theoretical reasons, to people who use DNs to actually
name entries in a directory instead of just as identifiers in certificates.
I have a more practical compromise to offer: if you don't misuse any standard
I care about, then I won't misuse any standard you care about.

Regards,
Steven

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 08 Jan 2008 21:31:26 +1300

Steven Legg <[email-masked]> writes:

>User's of eB2Bcom's LDAP/X.500 directory product

Oh I see, you're from an X.500 directory vendor![0].  It's funny that whenever
I see someone waxing lyrical about the wonders of X.500 it always seems to be
because they're peddling X.500 themselves.  Anyway, I'll let others speak for
me:

  So far, LDAP has not done a great job of supporting PKI
    . Steve Kent, PKIX WG chair

  The X.500 linkage [...] has led to more failed PKI deployments in my
  experience than any other. For PKI deployment to succeed you have to take
  X.500 and LDAP deployment out of the critical path.
    . Phillip Hallam-Baker, Verisign principal scientist

Continuing in the spirit of quoting others:

>behavior. All of your examples of what cab be stuffed into the CN attribute
>are good examples of what NOT to put there. The penultimate example
>specifically is disparaged by PKIX standards.

  I think a lot of purists would rather have PKI be useless to anyone in any
  practical terms than to have it made simple enough to use, but potentially
  "flawed".
    - (IT person at a (very) large multinational after they gave up on PKI in
       frustration for reasons such as this one).

>In the early days of TCP/IP, the folks responsible for the BSD implementation
>decided to NOT calculate the TCP checksum for each packet.  [...]

The difference here was that TCP/IP took over the world while PKI... oh dear.
Reciting dogma at potential users rather than helping them solve their real-
world problems isn't making things any better.  You may be able to sit back
satisfied that you've preserved the integrity of your precious bodily fluids,
but it's a hollow victory if the world ends up ignoring your technology
because of this.

(If people are getting bored with this I can take it offline, but at the
moment I'm having way too much fun :-).

Peter.

[0] Imagine James Earl Jones spraying at Steven with a insecticide sprayer:
    "Out! Back to the sixties! Back! There's no place for you here in the
    future! Get back while you still can!".

---

From: Steven Legg <[email-masked]>
Date: Wed, 09 Jan 2008 17:11:12 +1100

Peter,

Peter Gutmann wrote:
> because they're peddling X.500 themselves.

That's strange. I thought I was just offering the observation that
numeric identifiers stuffed into DNs are a bad idea in the environment
for which DNs are primarily intended, i.e., LDAP and X.500 directories,
quite apart from the fact that X.520 doesn't allow the commonName
attribute to be used this way.

 > Anyway, I'll let others speak for
> me:
> 

I've implemented the X.509 matching rules in LDAP, and defined and
implemented component matching rules, which provide matching capabilities
beyond what X.509 provides. I'm doing my bit to make LDAP support
PKI better. If there are more things I can do then let me know.
Badly constructed DNs certainly don't help the situation. Making it
easy for folks to produce conformant DNs is something deserving of
further discussion.

> moment I'm having way too much fun :-).

I have no interest in rehashing the same old anti-X.500 rhetoric. Can't you
accept that there is a community of people outside PKI that find value in
standards that you have written off, and that can be adversely affected
by a cavalier attitude to the construction of DNs ?

Regards,
Steven