Subject: Re: Missing Protocol ?

From: Peter Sylvester <[email-masked]>
Date: Wed, 19 Apr 2000 14:11:35 +0200 (MET DST)

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

The purpose of a directory is to provide information,
and it is explicitely tolerated that the information can be slightly
wrong and inaccurate. 

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

That's not the real point: You seem to want a possibility to access
to a remote service that is akind of RA archive. The answers from this
service will be used by some RP (a juge). The answers are statements
that itsself need to be verifiable (using a signature), and re-verfiable
in case the process is reviewed. 

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

- NOTHING is added to the protocol. 
  The request is 'validate public key certificate': 
 'Tell me why you think this cert is good'. 
  Please explain why you think you ask for something else?

  The distinction of what is expected to be returned and 
  what is returned is made in an application context of both
  the requester and the responder. 

- What purpose do you think is 'too much'? You can also say:
  TCP is too complicated because you can do too many things
  with it, or HTTP is too generic, you can too many things with it,
  and to many protocols are encapsulated in http, or email is
  embracing too many applications, or S/MIME is embracing too
  many features, or cmp/cmc are too big, etc.  
  The purpose of horizontal protocol layer is to become usable
  by many applications. 

> 
> Note that the request is mainly intended to be used by adjudicators
> or plaintiffs, but nothing prevents anyone to send a request.
Sometimes there are means to address denial of service attacks.

> 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.
Is this different from any other cleint/server protocol that uses
some sort of authentication/authorisation mecanism? 

> 
> Let us now add a refinment about the construct of the request.
You are not going to add too many purposes I hope :-)

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

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

I can't resist: 'vsd' in dvcs is one vehicle to ask this question.

Anyway, you are not making a refinement but asking for two
different context:

- In the first case, a judge wants to obtain from the
  RA the whole set of justifications to be used to issue a certificate.
  The RA does not make any judgement about WHY this information is
  requested, independant of the certificate usage in an actual signature.

- In the second case, the requester presents an actual usage of 
  one or more certs, i.e., a signed document. I 

Thus, you are already through 3/4 of the dvcs features to request and
obtain secrity statement about documents and certificates/assertions.
(I assume that you accept the usefulness of timestamping).

Your example is not well-chosen, I can sign all kinds of documents,
and this doesn't per-se give me the right to get information about
other entities. You might have a case on countersignatures upon
a document that you have signed first, and you want to know who
has actually 'accepted' counter-signed your data. Anyway, this
is application dependant, and not a part of the infrastructure
protocol.
 
Have fun
Peter Sylvester

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 19 Apr 2000 15:15:17 +0200

Peter,

<snip>

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

>  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