headers
Hallam-Baker, Phillip | 2 Jan 2008 18:53
Picon
Favicon

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

>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.
Permalink | Reply | 19 comments |
headers
Hallam-Baker, Phillip | 2 Jan 2008 18:46
Picon
Favicon

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

This all fits into the category of 'it really does not matter how it is done provided that as many systems as possible do it in the same way'.
 
At some point it would be really nice to be able to use these certificates in combination with 802.1x type authentication protocols. That is going to be easiest and cheapest for all concerned (manufacturers, administrators, tool builders) if there is as much consistency as possible.
 
Since we are having a debate about how to do this, how about a short RFC that describes one way to do it? Preferably the way CableLabs or whoever has the most device certs out there today does it. That way the next committee that starts down this path can read up on how it is done in the field already and use the result to swat down whatever NIH proposal someone would otherwise put on the table.
 
I would suggest that the spec would cover both the EUI-48 and EUI-64 address forms. Perhaps we could even persuade the IEEE to take a chunk of .arpa or other DNS space and hand out zone delegations along with OUI prefixes. That way manufacturers could if the choose use the DNS as a means of delivering indexes to device description information on demand as has utility in certain applications (but not necessarily all).
 
I can spend time on this if there is interest.
 
From: owner-ietf-pkix <at> mail.imc.org on behalf of Russ Housley
Sent: Thu 27/12/2007 4:09 PM
To: Joseph Salowey (jsalowey); Bernard Aboba; Scott G. Kelly; Stephen Kent; Sam Hartman; Max Pritikin (pritikin)
Cc: capwap-chairs <at> tools.ietf.org; ietf-pkix <at> imc.org; secdir <at> mit.edu
Subject: RE: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates


CableLabs and WiMAX specifications include the MAC address in the CN.

Russ

At 06:19 PM 12/26/2007, Joseph Salowey (jsalowey) wrote:

>I don't believe that 802.1AR uses the MAC address in the CN field.  I
>believe it makes use of the SerialNumber field and does not mandate that
>the identity must be a MAC address (it doesn't prevent it either).  The
>current text from draft 1.2 on SubjectName is
>
>"The DevID subject field shall uniquely identify the particular DevID
>credential within the issuer's domain of significance. The formatting of
>this field shall contain a unique X.500 distinguished name (DN). This
>may include the manufacturer's serial number, manufacturer's factory
>programmed MAC address, issuer's or user's node name or any other
>suitable unique string that the issuer prefers.
>
>It is recommended that the subject field's DN encoding include the
>'serialNumber' attribute with the device's unique serial number. "
>
>The current editor of the document, Max Pritikin, is copied on this
>message.
>
>Joe
>
> > -----Original Message-----
> > From: secdir-bounces <at> mit.edu [mailto:secdir-bounces <at> mit.edu]
> > On Behalf Of Bernard Aboba
> > Sent: Friday, December 21, 2007 8:00 PM
> > To: Scott G. Kelly; Stephen Kent; Sam Hartman
> > Cc: capwap-chairs <at> tools.ietf.org; ietf-pkix <at> imc.org; secdir <at> mit.edu
> > Subject: Re: [secdir] Please review
> > draft-ietf-capwap-protocol-specification's use of certificates
> >
> >
> > Although I agree with Steve that a MAC address would best be
> > placed within the SerialNumber attribute, the cat is long out
> > of the bag.  WiMAX Forum, IEEE 802.1ar and DOCSIS have all
> > specified inclusion of a MAC address within a CN.  So the
> > issue is no longer whether this is done, but rather, whether
> > it is done in a uniform way.
> >
> >
> >
> > ----------------------------------------
> > > Date: Fri, 21 Dec 2007 16:54:45 -0500
> > > From: s.kelly <at> ix.netcom.com
> > > To: kent <at> bbn.com; hartmans-ietf <at> mit.edu
> > > CC: capwap-chairs <at> tools.ietf.org; ietf-pkix <at> imc.org; secdir <at> mit.edu
> > > 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
> > >
> > > -----Original Message-----
> > >>From: Stephen Kent
> > >>Sent: Dec 21, 2007 3:00 PM
> > >>To: Sam Hartman
> > >>Cc: capwap-chairs <at> tools.ietf.org, ietf-pkix <at> imc.org, secdir <at> mit.edu
> > >>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
> > > secdir <at> mit.edu
> > > https://mailman.mit.edu/mailman/listinfo/secdir
> >
> > _______________________________________________
> > secdir mailing list
> > secdir <at> mit.edu
> > https://mailman.mit.edu/mailman/listinfo/secdir
> >

Permalink | Reply | 0 comments |
headers
Stephen Kent | 2 Jan 2008 19:32
Picon

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

At 9:53 AM -0800 1/2/08, Hallam-Baker, Phillip wrote:
>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.

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
Permalink | Reply | 18 comments |
headers
Stephen Kent | 2 Jan 2008 19:40
Picon

Re: New other certs extension I-D


At 10:53 PM +0000 12/21/07, stephen.farrell <at> cs.tcd.ie wrote:
>Hi Steve,
>
>>  I did a quick read of the I-D
>
>Thanks for taking the time to read this.
>
>>  I do have a concern.  The text says:
>>
>>  When this extension is present the CA is asserting that the same end
>>  entity is the subject of the relevant certificates. Mechanisms for
>>  how this assertion is validated by the CA or used by consumers of the
>>  certificate are out of scope of this memo.
>>
>>  I agree that the CA's actions re validation may be outside the scope
>>  of a document like this. However, we might say that CA is expected to
>>  have acted in accordance with any CP cited in the new cert, and
>>  performed whatever validation called for in the CPS for the CA.
>>
>>  I am less sanguine about being silent re what the client (RP) is
>>  expected to to do based on these links.  That creates a dangerous
>>  ambiguity. Since there were some examples provided to motivate this
>>  extension, I think you should use those as a starting point to
>>  describe what you think a client will do, based on this extension.
>
>Yes, as written there'd be nothing to stop a CA
>putting in references to web server certs and VPN g/w certs
>and code signing certs all in one place, which does
>seem odd but I didn't see a security problem arising.
>
>I did think of adding an OID in there, e.g. to say that
>all the linked certs are current or former web server
>certs issued to the same organisation/web site. However,
>I didn't see a concrete problem with leaving that out,
>so I did. Might be worth thinking again though.
>
>Or, I suppose one could simply make the extension specific
>to web server certs, but that feels a bit wrong, as I reckon
>there must be other uses for this extension.

Stephen,

Maybe my comments were not precise enough.

My concern is that there is not sufficient description of what an RP 
MUST/SHOULD do with the info provided via this proposed extension. 
Giving example of what an RP MIGHT do is not enough. We need to be 
precise. In so doing, we should be able to figure out what 
constraints are imposed on CAs who make use of the extension, and 
what security implications arise.

If we just create syntax for transporting these pointers, and some 
suggestions about what an RP might do with the info, we create a 
situation where a CA doesn't know what utility they provide (because 
it cannot count on how an RP will use the info) and users cannot know 
what their local PKI engines are doing with the info, which may 
undermine local PKI management efforts.

Steve
Permalink | Reply | 7 comments |
headers
Hallam-Baker, Phillip | 2 Jan 2008 22:32
Picon
Favicon

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

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: owner-ietf-pkix <at> mail.imc.org on behalf of Stephen Kent
Sent: Wed 02/01/2008 1:32 PM
To: Hallam-Baker, Phillip
Cc: Scott G. Kelly; Sam Hartman; capwap-chairs <at> tools.ietf.org; ietf-pkix <at> imc.org; secdir <at> mit.edu
Subject: RE: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates

At 9:53 AM -0800 1/2/08, Hallam-Baker, Phillip wrote:
>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.

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
Permalink | Reply | 0 comments |
headers
Peter Gutmann | 5 Jan 2008 10:05
Picon
Picon
Picon
Favicon

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


Stephen Kent <kent <at> bbn.com> 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.
Permalink | Reply | 16 comments |
headers
Erik Andersen | 5 Jan 2008 13:19
Picon

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


Hi Folks,

I do not want to be directly involved in this discussion.

As the project editor of X.500, including X.520, I may probably be titled as
an X.500 theologist, although I am not very religious.

I always get a little scare when people talks about pragmatic solutions, and
I normally translate that into "cutting corners" or "quick and dirty
solutions". Sticking to standards is not just a theological question, but a
very practical to allow systems from different vendors developed at
different times to interwork.

As to the matter at hand. It is not just theology to stick to the defined
semantics of different attribute types. It has a practical aspect as I have
been taught by implementers (never, never change the semantic). If there are
different semantics attached to the same attribute type, in adversely
affects (or confuses) client software.

This probably doesn't help.

Erik Andersen
Andersen's L-Service
Mobile: +45 20 97 14 90
e-mail: era <at> tdcadsl.dk
http://www.x500standard.com/
http://home20.inet.tele.dk/era/me

> -----Original Message-----
> From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-pkix <at> mail.imc.org]
> On Behalf Of Peter Gutmann
> Sent: 5. januar 2008 10:06
> To: kent <at> bbn.com; pbaker <at> verisign.com
> Cc: capwap-chairs <at> tools.ietf.org; hartmans-ietf <at> mit.edu; ietf-
> pkix <at> imc.org; scott <at> hyperthought.com; secdir <at> mit.edu
> Subject: RE: [secdir] Please review draft-ietf-capwap-protocol-
> specification's use of certificates
> 
> 
> Stephen Kent <kent <at> bbn.com> 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.
Permalink | Reply | 0 comments |
headers
Steven Legg | 7 Jan 2008 01:18

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


Peter,

Peter Gutmann wrote:
> Stephen Kent <kent <at> bbn.com> 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.

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

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

> 
> Peter.
>
Permalink | Reply | 12 comments |
headers
Peter Gutmann | 7 Jan 2008 06:56
Picon
Picon
Picon
Favicon

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


Steven Legg <steven.legg <at> eb2bcom.com> writes:

>One of the modes for accessing a directory is browsing up and down the
>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.
Permalink | Reply | 11 comments |
headers
Erik Andersen | 7 Jan 2008 11:38
Picon

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


Hi,

I do not believe this is a question about a global directory or not.

I have the feeling that the term "X.500 theologists" is meant as a
disparaging term.

What about changing the terminology and replace the terms "X.500
theologists" and "pragmatists" with those wanting a clean design and those
that do not care.

During a long life working with IBM customers, I have too often seen hopeful
youngsters developing so-called pragmatic solutions that resulted in bad and
non-extensible designs. The result has been that more and more ice pilled up
in front of the project until it came to a grinding stop. So, I get a bad
feeling in my stomach whenever the word pragmatic is mentioned.

Erik Andersen
Andersen's L-Service
Mobile: +45 20 97 14 90
e-mail: era <at> tdcadsl.dk
http://www.x500standard.com/
http://home20.inet.tele.dk/era/me

> -----Original Message-----
> From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-pkix <at> mail.imc.org]
> On Behalf Of Peter Gutmann
> Sent: 7. januar 2008 06:56
> To: pgut001 <at> cs.auckland.ac.nz; steven.legg <at> eb2bcom.com
> Cc: capwap-chairs <at> tools.ietf.org; hartmans-ietf <at> mit.edu; ietf-
> pkix <at> imc.org; kent <at> bbn.com; pbaker <at> verisign.com; scott <at> hyperthought.com;
> secdir <at> mit.edu
> Subject: Re: [secdir] Please review draft-ietf-capwap-protocol-
> specification's use of certificates
> 
> 
> Steven Legg <steven.legg <at> eb2bcom.com> writes:
> 
> >One of the modes for accessing a directory is browsing up and down the
> >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.
Permalink | Reply | 1 comment |

Gmane