Subject: Re: Missing Protocol ?

From: [email-masked]
Date: Fri, 14 Apr 2000 16:06:03 -0400

I don't think that anyone is proposing "an effort to develop a schema
for the universe of information which could constitute a human identity".
At least I hope not :-(
     What I, at least, am proposing is a mechanism by which identifiers
which were assigned by a known identified organization can be represented
in a GeneralName, in such a way that an RP can tell who is the assignment
authority for the identifier.  The cases where the assignment authority is
a government agency or the issuing CA are of special importance.  Some may
consider this out of scope for PKIX, but it is certainly not more complex
or unworkable than the existing DN arrangement.
     The fields that would actually be used in this way are likely to
include things like employee identifications.  "John Smith who has been
General Motors employee 356789" is a much more definitive identifier than
"John Smith" or even "John Edward Smith from Michigan who works for GM".

          Tom Gindin

"David P. Kemp" <[email-masked]> on 04/14/2000 01:25:23 PM

Please respond to "David P. Kemp" <[email-masked]>

To:   [email-masked]
cc:
Subject:  Re: Missing Protocol ?

> From: Denis Pinkas <[email-masked]>
> > From: Ed Gerck
> > Here, in PKIX, the main purpose of a CA is also to bind a public key to
the name
> > contained in the certificate and thus assure third parties that some
measure of care
> > was taken to ensure that this binding is valid for both -- i.e., name
and key. However,
> > the issue whether a user's DN actually corresponds to identity
credentials that are
> > *globally* linked to a person, or to a local alias or, simply to an
e-mail address -- and
> > how such association was verified --   is  outside the scope of PKIX
and depends
> > on each CA's CPS.
>
> I am not sure that this is really outside the scope of PKIX. If some
> judge would like to make the difference between John Smith 22 and
> John Smith 23, what can he do ? Nothing that has been standardized
> today. :-(  In PKIX we currently do not offer any solution. Maybe we
> should ? What kind of solution ? Being able to get back (when
> appropriate) the registration information (sometimes called the
> credentials) that has been registered at the time of registration by
> the RA. I do not think that it may be practical to get that
> information by paper and in a different format for every CA in the
> world. A protocol (and a schema) might be useful.
>
> Denis

Denis,

As long as CPSs are different, the "big identity in the sky" (the
information about a subject which makes John Smith 22 different from
John Smith 23) will be different, and outside the scope of PKIX.  If
the judge has access to a certain body of information:  employment and
credit history, property ownership and tax records, utility bills, etc,
and the CA has used any of that information to establish identity, then
the certificate may be useful to the judge.  If the CA uses only email
address to establish "identity", the certificate will be useless to a
judge dealing in non-electronic matters.  I don't see how PKIX could
consider in-scope an effort to develop a schema for the universe
of information which could constitute a human identity.

Dave

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 14 Apr 2000 16:39:46 -0400 (EDT)

Oh, well in that case, why don't we just use GeneralName:registeredID
and be done with it.

Both OIDs and DistinguishedNames are supposed to have Naming
Authorities which maintain registries and delegate the responsibility
to maintain subordinate registries.  But only OIDs seem to actually
follow the model :-(.  The only way to get an OID arc under US(840) is
to get it from ANSI.  There is no corresponding discipline in
establishing DNs beginning with, e.g., C=US, and until every cert
issuer agrees that there should be, there will be no global DNs.

Dave

> From: [email-masked]
> To: "David P. Kemp" <[email-masked]>
> cc: [email-masked]
> Date: Fri, 14 Apr 2000 16:06:03 -0400
>

---

From: [email-masked]
Date: Mon, 17 Apr 2000 12:25:09 -0400

Some comments.  I think we can get a lot of this into certificates or
CMP responses, if we don't try for a "universal solution".  If liability is
at issue, even one of the ID's should do the trick.  The only problem I see
is a privacy problem.  If something shouldn't be in a certificate, which
RP's should be allowed to get it?  If ordinary unprivileged RP's are
allowed to get it, why (other than certificate lifetime considerations)
shouldn't it be in the certificate?

          Tom Gindin

Al Arsenault <[email-masked]> on 04/17/2000 11:19:08 AM

To:   Denis Pinkas <[email-masked]>
cc:   ietf-pkix <[email-masked]>
Subject:  Re: Missing Protocol ?

Now that I understand better what you're getting at with this stuff  :-)

Denis Pinkas wrote:
>
> Since I launched this thread, I am following the various exchanges.
> I pick this one to comment.
>
> > Thierry,
> >
> >         I'm not sure that there is a solution for this problem that
doesn't
> > involve knowledge external to the PKI.
>
> Since the knowledge is not external to PKI, the problem may be
> considered by the PKIX WG.
>
> >         Suppose that the fondest dreams of the early X.500 designers
had come
> > true, and every item (to include person) in the known universe had a
> > globally unique name.  Even in that case, if you are working with one
> > "Jim Jones of GM" and not with any other "Jim Jones of GM", and you
need
> > to distinguish them, then YOUR "Jim Jones of GM" has to tell you
> > out-of-band what his globally-unique name is, or at least enough
> > disambiguating information to let you accurately pick it out from the
> > entries in the global directory.  Otherwise, you'll never know which is
> > which.
> >
> >         The same type of information can be passed to you "out-of-band"
in the
> > current situation; when you first begin working with the right "Jim
> > Jones of GM", he can provide you his certificate directly, or give you
> > enough disambiguating information to make sure you find it somewhere
> > else.  If he doesn't, you're not going to work securely.
> >
> >         (All of this is a long way of saying that we're really
wandering here.
> > I'm not convinced that it is possible to define a technical - by which
I
> > mean "machine-processable" - protocol that is guaranteed to find you
the
> > right certificate if you don't have enough information from other
> > contexts.)
>
> When dealing with signatures, it is the other way around. You have a
> certificate, that may even contain a pseudonym. When it does not
> contain a pseudonym, the question is still: who indeed is that
> person (e.g. Jim Jones 22) ? This person may be liable for a
> contract worth 10.000 $ and the requester would like to get the home
> address of the signer.
>
> The information that was obtained at the time of registration (and
> that is NOT contained in the certificate) may help.
>
> The problem is that this registration information varies from one CA
> to another and we are not going to standardize it easily. Is it
> really a problem ?
>
> We could standardize the request and very loosely standardize the
> response. The request is easy to standardize: "I want more
> registration information on the certificate holder that has the
> following serial number". Depending both, on who the requester is
> and the certificate policy of the CA, more or less (even none)
> information will be released to the requester. We could thus
> standardize the response without mandating any component to be
> returned. In any case, it would be better than paper.
>
> Thoughts ?
>
> Denis
>
>
>

More "questions" than "thoughts":

1.  Is the set of information that might reasonably be requested
sufficiently bounded as to be specifiable in a protocol?  Off the top of
my head, depending on the circumstances, I might ask for:

     - passport number/nationality
     - employee ID number
     - mail stop/address
     - phone number
     - driver's license number
     - SSN/other identity number
     - physically descriptive information (no, I'm not kidding here.  I
used to have a roommate named Tom Smith.  He worked in an office with
another Tom Smith.  The middle names and even the generational qualifier
were the same.  So when you called, you asked for 'the Tom Smith with a
beard' or 'the clean-shaven Tom Smith', depending on which one you wanted.
The guy with the beard was threatened with mayhem if he ever shaved while
working in that office.:-)
     - a whole bunch of other stuff

[Tom Gindin] Most of your list, up to (not including) physically
descriptive information, has perfectly well-defined formats in our domain
already - and IMO we should start with those.  The ones I have been trying
to profile for an OTHER-NAME format to go into certificates are Employee ID
number, SSN or other nationwide government ID number, CA-assigned ID
number, and Passport, Driver's license, or other government agency ID
number.  Maybe we should include phone number (distinguished between work
and home) as long as there's a separate place for extension number at work.
How would we do mail stop/address - perhaps with an X.400 Physical Delivery
Address?  Of course, most people have different work and home mail
addresses too.

If this is going to be meaningful to software and hardware, we'll have to
quantify/limit the list of acceptable information somehow.

[Tom Gindin] Yes, we need to keep the list down.  However, I don't think
that means empty.  For the four ID types, I have only three syntaxes and
two of them are effectively subsets of the other.

2.  Do you envision the response being anything that a machine might
parse and act upon, or only a general form for returning information for
human consumption/decision?

3.  If we can get past 1., do you picture this being a new protocol, or an
extension to CMP/CMC?

Thanks,

Al Arsenault
Chief Security Architect
Diversinet Corp.
P.O. Box 6530
Ellicott City, MD 21042-0530
(410) 480-2052

---

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 17 Apr 2000 14:49:45 -0600

Tom,

You're right, the potential sticking point is the privacy issue.

But privacy comes in several flavors, and there is also some 
concern for cluttering up certificate with information that may 
not always be required.

I don't think we need to come to the complexity of a German wine 
label (auslese cabinette, green capsule, with silver stripes) to solve this.

Consider the telephone company's policy.  My number can be listed, 
unpublished, or unlisted.  If it is listed, I may or may not list an address,
and if I do it doesn't have to be my real address -- it could be a forwarding 
service, or just a ZIP code.  (In the LA area, it costs extra to have your 
phone be unlisted, but it costs nothing to have a phony  address. So 
hundreds of people just list their names as Joe Doakes, 90210.

If my listing it is merely unpublished, you can ask for it. 

If it is unlisted, only law enforcement, and maybe other emergency 
services can get it, but I don't know if it requires a warrant in that case.

Same with the Tom Smith-with-the-beard.  Tom may not choose to list his 
hirsuteness or glabrousness, but he probably would have no problem with 
telling anyone who asks.  

His social security number might be a different story, but even then 
he is unlikely to defend that to the death, as too many people already 
have access to it. But he might require that such usage be audited, and 
that he have the right to know who asked for it, just as credit checks 
must be reported upon request.

If he is under the Witness Protection program, he is going to strenuously 
resist giving anyone his real name, birth date, etc.

But afer all, isn't what DIRECTORIES are for?

Why do we need a new protocol???

The answer is LDAP.  What was the question??

Bob

>>> <[email-masked]> 04/17/00 10:25AM >>>

          Tom Gindin

doesn't
had come
need
in the
wandering here.
I
the

Thanks,

Al Arsenault
Chief Security Architect
Diversinet Corp.
P.O. Box 6530

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 18 Apr 2000 13:46:31 +0200 (MET DST)

> 
> Sure, Denis.  Particularly since I've currently got my mind warpped around CMP.
> 
> This fits well within perceived uses of the genm and genp of CMP.  If it is 
> a request from Jon Q, the CA can decide what to respond.  If genm contains 
> a warrant, well then...
> 

- An RA collects the justifications and at the moment when it demands the certificate,
  it creates a time stamped document containing the data in whatever way and stores it
  wherever this should be, indexed by one or all the certificates it is related to.
  The document may even contain the certificates. 

- An authorised RP may asks someone (else) to return this document. The
  server should return a statement saying that 'the RA had used the data xxx to
  issue the certificate, or in other words: The server decides that the cert is/was
  valid because of of the existence of that document content.  

There are obviously several ways to implement this with some of the protocols
that exist. Since my current favorite is dvcs, I start with this:

The request would be a for a 'verify public key certificate'. The response would
not contain the certificate chain, or maybe it would, it can contain all kinds
of certificates, etc, just ONE of the certEtcToken elements would be the
signedData object created by the RA. 

CMP or CMC are similar good candidates. 

Peter Sylvester

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 18 Apr 2000 15:30:47 +0200 (MET DST)

> shouldn't it be in the certificate?
'Ordinary' i.e., non-authorised RPs are NOT allowed to access to such data.

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 19 Apr 2000 11:48:08 +0200

Bob,

I appreciate you sense of humour, at the very end of this E-mail,
when you say: "But afer all, isn't what DIRECTORIES are for? Why do
we need a new protocol??? The answer is LDAP.  What was the
question??

Before discussing the technical solution(s), the thread is
discussing very validly the purpose and the goal of that (missing ?)
protocol. Since the information that might be released will not
match exactly with the arguments from the request (i.e. you cannot
ask specically for an attribute) I am not convinced that LDAP would
be the best choice. In addition, up to now, RAs do not need to
support a Directory or structure the information they have so that
it can be placed in a Directory.

The other arguments you raise in your E-mail, as well as the
examples provided by Robert Moskowitz, illustrate the topic very
well.

Peter Sylvester while advocating for the use of DVCS was saying: "
Since my current favorite is dvcs, I start with this: The request
would be a for a 'verify public key certificate'. The response would
not contain the certificate chain, or maybe it would, it can contain
all kinds of certificates, etc, just ONE of the certEtcToken
elements would be the signedData object created by the RA ".

The request we need has nothing to do with 'verify public key
certificate'. DVCS is already embrassing too many purposes. It would
not be a good idea to add one more purpose in the same shell.

Note that the request is mainly intended to be used by adjudicators
or plaintiffs, but nothing prevents anyone to send a request.
However, a server may well refuse to provide a response. So any RP
could make a request. It will always be up to the RA to decide
which, if any, information will be released.

Let us now add a refinment about the construct of the request.
Information may be released (or not) depending upon not only who the
requestor is, but also depending upon what kind of information is
provided. For example, if I can prove that a document was both
signed by myself and another party, I could perhaps legitimately ask
more information about that other party. Providing this "proof" as
part of the (authenticated) request might be valuable. Note that
this can be done without providing the actual content of what was
signed, thus respecting some privacy.
 
Regards,

Denis

---

From: Michael Zolotarev <[email-masked]>
Date: Thu, 20 Apr 2000 11:53:09 +1000

I am not sure that the problem the proposed protocol is addressing is the
real problem.

I do not think that the protocol will be something of a frequent use: If an
entity can not be uniquely and unambiguously identified without some extra
'with-the-beard' information, that information should be present in the
entity's certificate. You do not want to reach out and ask an RA for extra
details about the entity every time you deal with that entity. It is just
going to be a pain. Therefore, I do not think we have a real requirement
here. Passing it over to the "unique ID" thread :)

I am not convinced that the protocol is necessary for infrequent use either:
When a judge or police, or anybody else needs more information about the
entity, an RA can be contacted directly. You do not really need a protocol.
A judge, police etc can do it by phone, by fax, by email or by face to face.
As they do it now, conveniently and simple enough. 

As a bottom line: if a protocol is not going to be used frequently, and we
can get by without it for occasional need, do we need the protocol at all?

Regards
Michael

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Wednesday, April 19, 2000 11:15 PM
> To: Peter Sylvester
> Cc: [email-masked]
> Peter,
> <snip>
> > - NOTHING is added to the protocol.
> >   The request is 'validate public key certificate':
> >  'Tell me why you think this cert is good'.
> 
> This NOT the question. 
> 
> >   Please explain why you think you ask for something else?
> 
> You give a certificate reference and you would ONLY like to know
> some (or all) the registration information that was provided at the
> time of registration.
> 
> <snip>
> 
> > Are you asking for a service that send the document or the 
> signatures
> > to a server, and depending on the signature, the server returns
> > some information about it:
> > 
> > "Please tell me what you think about these signature and provide as
> >  much information as you may want to give me."
> 
> No. See the question above.
> 
> > I can't resist: 'vsd' in dvcs is one vehicle to ask this question.
> 
> I can't resist either: DVCS is NOT the right vehicule for this.
> 
> Regards,
> 
> Denis
>

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 21 Apr 2000 18:52:23 +0200 (MET DST)

> > > I see no reason for this. AAs (Attributes Authorities) are not the
> > > same like RAs (Registration Authorities).
> > > The response comes from the RA, not an AA. In any case the use of
> > > AAs is not mandated.
> > 
> > It's a question of assurance.  If you trust a directory, you don't need
> > signed attributes.  I lean towards end-to-end security whenever
> > possible, and therefore prefer the RA to sign attributes rather than
> > having the directory dish out unprotected information.  If the
> > authoritative RA database is available online, there is little reason
> > to prefer signed over unsigned.  But as soon as the information is
> > replicated, cached, passed along, or otherwise distributed, the RA's
> > signature becomes helpful.  When the RA signs attributes, it becomes,
> > by definition, an AA.
> 
> Certainly not. Using AC mandates a very precise data structure. So
> it is not because the answer is signed that the RA becomes an AA.
This has nothing to do with the content of the AC. It may be someone
else that the original RA, that creates the AC, but that's probably
not the slightly more difficult situation both of you had in mind.
 
It was discussed that an attrib cert could be appropriate vehicle to carry
a statement of the kind:

  We, the 'issuer' declare (sign) that  'holder' has been registered
  and we have stored the following 'attributes'.
  
Attributes are defined by oids, the CPS of the RA would define the semantics.
the requester can make a request without knowing the schema of the data.

It seems thus possible to me that the RA information can be represented
in an attrib cert.

If so, what does this tell us about the RA caracteristique of being an AA.
I don't care. 

> Note that the RA may respond without any signature and that the
> security may be provided using, e.g. TLS.

What you are saying here is very strange: A judge does not just want
to read a data base, but wants to create a verifiable decision.

There is not just 'one security'. The security of the transport of the
information is something else than the security of the objects. 

There is also the engagement / guarantee implied by the signature of the RA. 

It may be required that the requests/responses need to be archived
The certificate owner may have the right that the RA prooves exactly to whom the
information have been given, and why. There may be strict privacy laws, and
just standard security/audit rules, etc. 
This may mean that the transaction result may need to stored encrypted,
etc.  

It may be also useful to have a reponse: "We, the RA declare that YOU, the requester,
has asked at date X to obtain information about certuser XXXX, we delivered the
following information at date Y to You, you are already the 4711th one, we have
registered the transaction under id 123465." 

Now you can select your favorite more or less secure query protocol
or/and data format, e.g.:
LDAP, CMP++, CMC++ OCSP-Y-NOT, SCVP++, BERT++, DVCS, SNMP, DAP, YASSQPI, 
XML-DIGSIG/XER, POLICE/BLOCKS, JUDGE/SMIME, ... 

> Anyway the intent is not to place that information in multiple
> untrusted Directories, but to query one server (ain the same way
> this is done for OCSP). The idea is to allow to locally store that
> information in some data base that could be queried using LDAP.

This is an implementation detail of the RA. You could have:

'select * from RABASE where certhash=XXXXXXX and serialnumber=1234'

Why does all that need to be online with a direct response. Before handing out
these information, a human intervention may be required, or the information
may not be available online. someone might need to open a safe and get the
required archive cd. 

 cat cdrom/XXXXXXX/1234 | sign+-crypt+log ... 

Thus you should consider to make the transaction transport independant
(mail, http, blocks, pigeons + paper copy).   

P