[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Basic Cert-2-Directory mapping question
Bob,
I think the thing you are trying to get here is:
1. I have a signature made by a private key.
2. How do I find the corresponding public key to verify it.
3. How do I trust the public key.
You want a minimal stripped down signature, and a pointer the place in
which one *might* find the public key. At this point, I don't even need a
certificate, correct? I can just simply trust the public key.
However, for non-repudiation, and "where do I send the sherrif" motif,
certification of that public key is necessary to tie it to some attributes
in which you can make a trust decision. This is necessary, because that
certificate must be a matter of *public* record. However, public records
are strewn all over the place. You cannot go into the Motor Vehichle
department of Utah and ask for a copy of someones New York State Drivers
License, or their birth certificate.
It seems fundamental to me, that you need a protocol, a pointer to a
service of that protcol, and an identifier with which to get that
certificate.
In CORBA, there is a service called the Person IDentification Service
(PIDS). This service was built my many learned people in the business of
identification, i.e. hosptial patient registration. In this service, they
encounter all such problems as spliting and merging identities based on
*traits*, i.e. the two John Smiths problem. Traits can be considered very
dynamic things and change all the time. However, the basic cruxt is that
it all comes down to an object reference called an Identity.
Now, I know in the IETF you may not have the luxury of flinging CORBA
object references around, however, the basic premise is that you have the
following items in order to identify something:
1: a specification of a protocol,
2: a location of a service supporting that protocol,
3: and an identifier within that protocol.
Item 1, isn't much good if you don't have item 2 as well. And Item 3
is pretty much useless without 1 and 2.
Whether that service is LDAP, DAP, DNS, CORBA Naming, or PIDS, it doesn't
much matter, but there has to be something. Having the Identifer (#3) is
just not good enough.
Finding the end entity certificate (i.e. the signing key) shouldn't be
that hard. A signature can contain all items 1,2,3. Since the signing
entity can provide that information, correct?
However, I think the basic problem lies path discovery and validation
because certificates themselves do not contain items 1 and 2 of their
issuers.
Would you say that this is a correct interpretation of the problem?
Unfortuately, a certificate is a signature and it's missing important
information about its signer, such where to find its public key, and quite
possibly a certificate for that public key.
I seem to remember something about an AuthorityInfo extension. Does that
solve the problem well enough?
Cheers,
-Polar
On Tue, 16 Jan 2001, Bob Jueneman wrote:
> Skip,
>
> Just so it's clear, I probably should have defined at least one use
> model for what we have been talking about -- at least the use
> that I have in mind.
>
> what I'm trying to get away from this the necessity of wasting all
> of the bandwidth that is currently being used to repetitively
> download entire certificate chains containing the same information,
> over and over again to the same client. This is particularly the
> case in SSL/TLS and S/MIME, and I predict that when we start
> sending signed EDI transactions it will be the case there as well.
>
> What I want to do to minimize all of this is to send only two things
> with a given transaction -- the digital signature itself, stripped down
> as far as possible; and the name of the signer, in a minimal form
> as possible without imposing a rigid repository schema.
>
> ideally, the name of the signer should be a DN, whether in the form
> of a classical civil name structure, and DNS name, or some other form
> that is searchable, such as a DUNS number.
>
> Ideally, the structure of the DN should be compatible with existing
> RDN syntax, but perhaps with the addition of a new attribute type.
> I think that we are agreed that SOMETHING new is going to be
> required, and if that is the case a new attribute that is consistent with the
> current RDN syntactic structure would to my mind be preferable to
> introducing something else, such as a URL or URI.
>
> Although I don't want to get completely hung up on the use of a
> dir= RDN qualifier vs. a more explicit URL-type qualifier, I'm don't
> think I agree with your concern about the paradigm shift in the
> DN semantics a dir= type of qualifier would cause. Maybe I just
> don't understand.
>
> I am inclined to say that "DN semantics" is close to being an oxymoron.
> The fact is that the semantic definitions of most of the usual DN
> attributes are conspicuously vague. Consider "serial", "locality", commonName,
> or even "country". Yes, we all understand what a country is -- it's
> whatever the UN says it is, or isn't, and questions about disputed territories
> are brushed aside. But that isn't a semantic definition, that is simply a name to
> territory definition or mapping. The real question is what is the relationship
> between the country and the end-entity identified by the rest of the DN --
> is it merely a directory qualifier, or is it the country of residence?, citizenship?
> place of doing business? location of the home office? country of
> incorporation of an enterprise? If I am referring to a ship, for example, that
> is owned an operated by a UK company, registered in Liberia ,and
> is currently docked in Miami, what country should I use for the RDN
> of that ship?
>
> Since X.500 doesn't attempt to answer that question, I would claim that
> the only effective semantics for country is as a directory qualifier, under the
> old universal X.500 directory-in-the-sky assumption of a monopoly directory
> service, or at least a monopoly naming infrastructure per country.
>
> Since we know by now that the original assumption is no longer valid,
> if indeed it ever was, we can certainly use country to mean whatever
> we choose it to mean in terms of semantics, just as people have
> distorted the semantics of organization, and particularly
> organizationalUnit, to contain just about anything they want.
>
> (I'm not really suggesting an RDN containing a MPEG of my cat, but
> things that are nearly as strange have been done in the past.
> That doesn't make them "right", of course, just ubiquitous.)
>
> But what that leaves us with is the need to qualify what used to be a root,
> i.e., country, and to supply a new root, meaning basically who owns,
> operates, and defines the semantics and schema for all of the rest of t
> he RDNs which follow.
>
> I would submit that despite the semantic "recommendations" provided by
> the standards organizations, it is really the directory service provider who
> defines such things, or in some cases the Certificate Authority who creates a
> certificate, whether or not they actual deposit that certificate in an X.500
> directory
>
> >From this point of view, I believe that using a dir= type of directory service
> provider is not some kind of an ugly hack, but a reflection of reality, and a
> completely legitimate RDN qualifier. It specifies in a consistent DN syntax
> what the root of the DIT really is -- the name of the directory that contains
> and defines it.
>
> Now I'll grant that it isn't very likely that existing X.500 directories would
> suddenly change their DIT structure to explicitly include a dir= component
> at the Top. But I don't think that would be at all necessary, either -- it can be
> done implicitly.
>
> I wouldn't think it would be all that hard to define the attribute matching
> rules so that if the dir attribute (or one of the multi-=valued RDN components)
> is the DNS address of the directory that is being accessed, the result is
> TRUE, and otherwise FALSE.
>
> Another approach which might or might not work would be to use an alias,
> although I don't know whether it is possible to define an alias for a node,
> rather than for a leaf.
>
> For example, in Novell's own DIT, we don't even define c=US as the top
> component, although perhaps we "should".
>
> But I would assume/hope that if we were concerned about that, we could
> define an alias of c=us, o=Novell Inc. to point to the o=Novell node that is
> actually at the top of our DIT.
>
> Since you said that you actually considered this type of an approach
> at one time, perhaps you can say more about what led you away from
> that approach. I think you were right the first time.
>
> Regards,
>
> Bob
>
> >>> "Slone, Skip" <skip.slone@xxxxxxxx> 01/16/01 01:45PM >>>
> John,
>
> You wrote, "I don't think the proposed "dir" attribute is semantically very
> different
> from any other naming attributes" and that "the mechanism for searching has
> to treat the "dir" RDN somewhat differently from the other RDNs."
>
> My concern with different semantics is not a matter of degree; it's the fact
> that the semantics of DN must change -- at all -- to incorporate this
> concept. If there are other ways to deal with the problem, I see no
> compelling reason to change the semantics of something so fundamentally and
> deeply entrenched in dozens of standards as DN.
>
> I must add here that I have not always opposed this concept. I actually
> pursued this line of thinking two or three years ago in a different forum
> (X.500) while working a different problem (Related Entries). At that time, I
> was proposing that a "dnQualifer" be added to a DN to specify an access
> point through which the entry named by the DN could be found. While pursuing
> that line of thinking (which explored several syntactic/semantic variants),
> the semantic-shift problem kept getting in the way. In the end, we settled
> on a separate mechanism rather than change the semantics of DN. Flawed as it
> may be, DN is still a widely accepted concept; changing it will be an uphill
> struggle.
>
> -- Skip
>
> -----Original Message-----
> From: John_Wray@xxxxxxxx [mailto:John_Wray@xxxxxxxx]
> Sent: Tuesday, January 16, 2001 10:52 AM
> To: Slone, Skip
> Cc: 'Bob Jueneman'; ietf-pkix@xxxxxxx
> Subject: RE: Basic Cert-2-Directory mapping question
>
>
>
> >As I read your suggestion, you want to add an element to the DN
> >that directs the user to the appropriate directory. The new
> >element is syntactically an RDN, but semantically is something
> >different. The resulting new-style DN appears to me to
> >semantically comparable to an LDAP URL.
>
>
> I don't think the proposed "dir" attribute is semantically very different
> from any other naming attributes. What we're trying to do with names in
> certificates is to maintain the X.500 illusion that a DN uniquely
> identifies an entry in some global directory. But we don't have a single
> global directory; instead we have a collection of directories which don't
> talk to one another - i.e. instead of the single DN root assumed by X.500,
> we actually have multiple roots, one for each directory.
>
> The obvious way to resolve this sort of problem is to introduce a new
> "meta-root" that sits above all the directory roots. This corresponds to
> adding an RDN to the most significant end of each DN that names the
> particular directory within which the named entry lies. Precisely how a
> directory is named is TBD, but it must give an end-system enough
> information to for a query for that directory, without requiring prior
> knowledge of the directory, so an obvious possibility (for an LDAP
> directory) is scheme and hostport portions of an LDAP URL.
>
> Individual directories could either store this attribute explicitly within
> the entry (which would mean that these directories could be directly
> searched using the full DN) or, more likely, the "dir" attribute would have
> to be removed before searching an individual directory. So yes, the
> mechanism for searching has to treat the "dir" RDN somewhat differently
> from the other RDNs, but in terms of a naming model, it behaves just like
> any other RDN.
>
> As Bob points out, the "dir" attribute could be multi-valued, allowing
> information about an entry to reside in multiple directories (provided that
> the directories can all agree to use the same name for the entry).
>
> John
>
>
>
>
>
>
>
>
> "Slone, Skip" <skip.slone@xxxxxxxx> on 01/16/2001 09:16:13 AM
>
> To: "'Bob Jueneman'" <bjueneman@xxxxxxxxxx>
> cc: ietf-pkix@xxxxxxx
> Subject: RE: Basic Cert-2-Directory mapping question
>
>
> Bob,
>
> I'm glad to hear we agree on the nature of the problem. From that point of
> agreement, we can move the discussion to one of "what do we do about it?"
>
> In abstract terms, it appears to me that "what we can do about it" falls
> into two broad categories:
> 1) we can create a mechanism for explicitly identifying the appropriate
> directory, or
> 2) we can remove the barriers that currently prevent the directory from
> being discovered implicitly based upon existing information
>
> I would say that your approach fits in category 1, while my approach fits
> in
> category 2. Either approach has validity IMHO and is worthy of
> consideration.
>
> As I read your suggestion, you want to add an element to the DN that
> directs
> the user to the appropriate directory. The new element is syntactically an
> RDN, but semantically is something different. The resulting new-style DN
> appears to me to semantically comparable to an LDAP URL.
>
> Assuming we're on the same page up to this point, I'll say that my concern
> with this approach is that it changes the semantics of DN, potentially
> causing interoperability problems in that both clients and servers that
> understand the semantics as currently defined would have problems when
> encountering the new-style name. If we were to go with a "category 1" fix
> to the problem, I would rather see a new mechanism employed, such as a new
> PKIX-defined certificate extension that explicitly gives repository
> location
> information. As a new construct, we would be free to define whatever
> semantics we want, and could readily use existing concepts such as URLs.
>
> Now, in defense of my approach, I think we can all probably agree that *IF*
> the original concept of X.500-style distributed, global name resolution
> were
> a practical reality, we would be able to plug into the nearest DSA and find
> the named entry regardless of where it resides physically. Of course I
> emphasized the word "if" to imply that we can also probably agree that that
> original X.500 concept is not going to occur anytime soon, if ever. What I
> was proposing instead, was a "category 2" fix -- a way of removing that
> barrier by providing an alternative way of doing distributed name
> resolution. The alternative mechanism I proposed was one which builds upon
> an existing, working, global infrastructure that already has the requisite
> registration infrastructure in place. Without digging into the specifics,
> I
> would like to know if you or others believe that this *concept* has merit.
>
> -- Skip
>
>
> -----Original Message-----
> From: Bob Jueneman [mailto:bjueneman@xxxxxxxxxx]
> Sent: Monday, January 15, 2001 2:11 PM
> To: skip.slone@xxxxxxxx
> Cc: ietf-pkix@xxxxxxx
> Subject: RE: Basic Cert-2-Directory mapping question
>
>
> Skip,
>
> I don't particularly like the mechanism you've proposed, at least as
> I understand it. But I absolutely and completely agree with you
> as to the nature of the problem that has to be solved.
>
> Civil attribute type names will always be with us, and hence must be
> dealt with, for at least two fundamental reasons:
>
> 1. An address is not a name, although it may be a pseudonym. I
> don't want to be forced to change my identity, or to an extent
> my basis "self-hood," every time I change my ISP. And I especially
> don't want some system administrator telling me that my name
> must be limited to 8 characters, or that I have to change my name
> because someone else has already used that same name within
> that same system administrator's ill-conceived naming scheme.
>
> 2. E-mail address and other cyberspace identifiers fail to provide the
> essence of PKI from a nonrepudiation standpoint, i.e., what I call the
> "where do you send the sheriff" question.
>
> Granted, not all uses of PKI will or should involve legal nonrepudiation.
> But to the extent that at least some uses WILL have legal consequences,
> then the establishment of a globally unique and credible identity that is
> grounded in "meat-space" rather then cyberspace is absolutely essential.
>
> For those legally binding transaction to be worth anything at all, they
> have to be enforceable. And that means that a judgement may have
> to be enforced upon someone, either by seizing the assets or putting
> them in jail. And only in science fiction does the sheriff ride off into
> cyberspace to arrest someone.
>
> If I as a relying party wish to trade with someone, then I either want to
> charge her credit card (in which case PKI is demonstrably not necessary)
> or I want to know that she is the Mary Smith who resides at 123 Anywhere
> St,
> Metropolis, NY.
>
> The inclusion of that civil address not only servers to distinguish her
> from the other Mary Smiths, but more importantly it establishes a nexus
> or link between her identity and her probable whereabouts, and
> probably valuable real property as well.
>
> So civil addresses, both corporate or "organizationalPerson", or the
> harder-to-deal-with residentialPerson type will presumably always
> be with us, and will have to be dealt with.
>
> And unfortunately, perhaps, here int he US the simple and inescapable
> fact of the matter is that neither the federal nor the state governments
> operate the type of presumptively authoritative name registration
> authorities that are relatively common in other countries. I am perfectly
> free to move from one city to another, or from address to another in
> the same city, and to never notify anyone in authority at all, including
> the tax authorities. No one will ever say, "Papers, please."
>
> (Granted, if I choose to do that I may not be able to register to vote,
> but over half the population doesn't vote anyway. And the last time
> I registered, no one checked to see that I actually lived there -- that
> one of the problems we have with our voting system, even outside
> of the State of Florida.. And I may not be able to get a driver's license
> in order to legally drive a car, but a lot of illegal immigrants don't have
> driver's licenses either, although that doesn't keep them from driving.)
>
> So merely trying to ignore the problem of civil addressing schemes
> won't solve that problem. And neither will various approaches that
> make certain assumptions about monopoly name registration
> authorities, or try to divine or impute where a directory containing
> a particular name might be found based on some kind of a Karnak
> mentalist act.
>
> The primary issue is not the question of whether the name space
> is flat or hierarchical, or how hierarchical, much less what the
> "approved" schema is. What will be, will be, for reasons that
> are beyond our scope and power to influence, even if we wanted
> to.
>
> So.
>
> We cannot force a person to deposit his certificate or other useful
> information into a specific directory, even if we wanted to. Nor can
> we reliably impute a likely directory where such information might
> be found, at least in the absence of a monopoly or governmental
> mandate.
>
> The best we can do is to ASK the user where he has deposited
> such information, if anywhere, and to include that information
> EXPLICITLY in any directory or pseudo-directory reference, such
> as a DN.
>
> Although at one time I liked the notion of prefixing the DN with a
> URL, I have come to believe that John Wray's suggestion is the
> better way forward.
>
> He said:
> >
> >Bob,
> >
> >Accepting the fact that the X.500 dream of a single global directory is
> not
> >going to happen any time soon, DNs can still be turned into globally
> >significant pointers into a federation of directories in the way you
> >suggest, but it doesn't require altering the DN syntax (and therefore
> >doesn't have to break existing implementations). All that's needed is a
> DN
> >attribute that names the particular directory within which the name
> >resides. e.g. instead of "c=us;..;cn=My Name" you'd have "dir=My
> >Directory;c=us;...;cn=My Name", where "My Directory" is the URL of a
> >directory access point.
>
> By including an explicit directory qualifier of the form dir="directory
> URL"
> at the root (top) of the RDN chain, we have implicitly qualified all of the
> rest
> of the RDN, which is a Good Thing.
>
> By defining the syntax of the "dir" attribute appropriately, we could
> include
> both the access type (LDAP, http, etc.) and port number appropriately,
> either a default or explicitly indicated.
>
> And by making the dir component multivalued, we could accommodate
> a choice of multiple directories and multiple directory types.
>
> Once again -- the essence of the problem is not the format of the directory
> name but where a directory containing that name can be found.
> Including that information as a top-level qualifying component solves that
> problem (and potentially several others, such as name scope qualification)
> very neatly.
>
> Bob
>
> Robert R. Jueneman
> 'Security Architect
> Novell, Inc. -- the leading provider of Net services software
> >
> >
> >
> >
> >
> >
> >
> >>>> "Slone, Skip" <skip.slone@xxxxxxxx> 01/15/01 09:08AM >>>
> >Oscar,
> >
> >No offense taken, thus no apology needed.
> >
> >My comments from the soapbox last week were actually intended for the
> >community at large, and were meant to convey frustration at the apparent
> >unwillingness of solution providers in general to hear about -- and solve
> --
> >real world problems that are faced by users like myself in large, complex
> >environments.
> >
> >When I say "my environment is not so simple," the response I hear is
> "let's
> >not talk about the complexity; let's make some simplifying assumptions
> >instead."
> >
> >When I say "I have a nail AND a screw and need to put them both in the
> >wall," the response I hear is "we have provided you with a perfectly
> >adequate hammer, therefore you don't have a screw."
> >
> >As I was using the nail/hammer analogy, dc-based names are the nails;
> >civil-attribute-based names are the screws. No matter how good a job my
> >company does of using nails and nails alone, we still have tens of
> thousands
> >of trading partners, many of whom prefer screws to nails and will continue
> >to use them indefinitely. Without a screwdriver, it's hard to do business
> >with them.
> >
> >I don't really care what the screwdriver looks like. I've suggested a
> >fairly simple design that I think will work. So far, no one has commented
> on
> >the design. What I've heard instead is a chorus of "we still don't like
> >screws." Well, I don't like them either, but I still have to deal with
> >them. If I'm simply overlooking a screwdriver that we have lying around
> >somewhere, I would appreciate someone pointing it out to me.
> >
> > -- Skip
> >
> >
> >-----Original Message-----
> >From: Oscar Jacobsson [mailto:oscar.jacobsson@xxxxxxxxxxx]
> >Sent: Thursday, January 11, 2001 5:16 PM
> >To: Slone, Skip
> >Cc: 'Sharon Boeyen'; ietf-pkix@xxxxxxx
> >Subject: RE: Basic Cert-2-Directory mapping question
> >
> >
> >> From: Slone, Skip [mailto:skip.slone@xxxxxxxx]
> >> In response to this, I'm inclined to join Sharon on Marshall's soapbox
> and
> >> echo her words:
> >>
> >> "... I believe a more constructive approach is to accept the fact that
> >> different parts of the world and different environments will use a
> variety
> >> of nameforms ... We are not the global naming police either and should
> not
> >> try to impose the rules that anyone uses to name entities to which they
> >> issue certificates."
> >
> >I'm sorry if I came across as clamouring for rules be imposed. I know that
> >this working group has a tendency to be wary of suggestions that don't
> cater
> >for distinguished names containing cat MPEGs, so I should probably have
> been
> >more careful. The requirements I suggested were for a possible naming
> >standards document, conformance to which need not be enforced.
> >
> >The case at hand is not, IMHO, one of dictating that "all distinguished
> >names must be according to our will, or you shall feel our wrath". A
> >document however, outlining a naming strategy that would require of the
> >users of certificates named accordingly no a-priori knowledge of their
> >issuer (save for eventually having to reach something explicitly trusted
> in
> >the chain) in order to perform path validation, is something I would
> >personally consider very valuable indeed. I'm reasonably confident that
> >organizations intending to act as certification authorities or trusted
> third
> >parties would agree.
> >
> >> And to quote someone Sharon and I both know, "If all you have is a
> hammer,
> >> every problem looks like a nail."
> >
> >It seems I was less than clear here as well. :-(
> >
> >My intention was to point out that there are actually two separate
> problems
> >here (one nail, if you will, and one screw) each looking for its own
> >solution:
> >
> >1. Defining a repository, and subsequently entry, discovery process for
> >arbitrarily named entries.
> >
> >2. Defining a naming scheme that _if applied_ would automate this
> repository
> >and entry discovery process.
> >
> >I am only trying to address the second of these problems. The first is
> only
> >an issue because nobody seems to have properly addressed the second before
> >deploying certificates on the Internet en masse. The further we wait
> before
> >addressing number two, the more of a problem number one will become.
> >
> >I should probably make a habit of pointing out that the opinions stated
> here
> >are my very own, and not necessarily those of my employer.
> >
> >Cheers,
> >
> >//oscar
>
>
>
-------------------------------------------------------------------
Polar Humenn Adiron, LLC
mailto:polar@xxxxxxxxxx 2-212 CST
Phone: 315-443-3171 Syracuse, NY 13244-4100
Fax: 315-443-4745 http://www.adiron.com