Subject: Re: Strawpoll for DPD/DPV protocols

From: Peter Sylvester <[email-masked]>
Date: Wed, 22 Jan 2003 12:27:50 +0100 (MET)

Some thoughts in a brainstorming way: 

- There is a lot of overlap in concrete techniques used by
  there various protocols.

- The proposals specify a protocol using concrete data units
  and not necessarily as an abstarct protocol mapped to
  concrete syntaxes.

- There are different choices for some major protocol elements,
  i.e., transport, pretection of transport of data units,
  different elements in the payload.

- There is an inflation of different ways to identify certificates
  which is more or less obscured by concrete syntxes and not
  explained by requirements. 

-  There is a variety of possible relationships depending
  on the intent of the usage of the protocol. This can
  range from a very thin client that is close to a server
  and can use some simple authentication method to
  some asynchronous email based client / server comm.

- The different possible trust relationships between
  clients and server are not clear.

- The different needs for transport of payload protection for these
  cases are not always clear. 

The technical differences, in particular the different ways to
secure payloads and to address identification and authentication
which somehow almost looks like layer violation make me feel
that we might want to establish some general principles of
best known techniques for certain aspects. 

It seems that 80% or more of each proposal cover issues that do not
have anything to do with the underlying problem but with 
'lower layers', or, one might consider to a maximum already
existing techniques.  

I'd like to start with a small description of some points without
trying to be complete in any way. these points are rather
independant of this particular protocol, they apply to
others as well. 

Or, does this remind me to CMC vs CMP? 

- payload identification.

  It is always a difficult thing to find a syntax when you see
  just a pure piece of DER encoded data. One always needs an
  external indication, e.g; mime type, or an implicit
  convention. 

  On the other hand, there is at least one known technique that
  simplifies the detection of syntaxes, i.e. the usage of
  a CMS ContentInfo. By exchanging data uniots which are
  encapsulated in a CMS ContentInfo, this removes some requirements
  to the lower transport, and IMO allows more robust implementation
  since the sending partner can indicate in a clear way
  and independantly of the transport the intended syntax.

- payload security

  Due to the various different situations for clients and servers
  and the trasport protocols, different ways to protect the payload
  are possible. 

  Again, it seems that the variety of mechanisms with total
  encapsulaton provided by CMS be a good way to protect
  the payload by various ways. In particular, in certain
  circumstances, a signature protection may not be necessary,
  other faster authentication mechanism may be appropriate.

  Other protocols in PKIX and elsewhere have already shown that
  some ad hoc special methods may create some problems; in
  particular to get the implementions right. benfitting
  from existing implmentations of SMIME and the experiences
  seem not a bad thing to me.

  There is a sub issues of identification and binding of
  authentication in the response. Again, SMIME provides
  a standadised mechnism in ESS.

- Identification of transaction participants

  It seems useful to me to have a clear separation of 
  the authentication identifications and the identifications
  that can be used in the payloads to indicate the
  participating identities, in particular if the
  communication is secured by means that use different
  identifiers. 

- transport issues:

  A well known defacto way for protocols is to use HTTP or
  HTTPS as a lower layer. On the other hand, the complexity
  of this should not be underestimated. for example, to what
  degree should a client accept redirections or textual
  responses.

- ASN1 issues: 

  Protocol proposers should provide a proof that they
  have read ASN1 specification, and have specified
  and implemented using it. :-) This is rather a flame.

- using of Extension.

  technical:

  The usage of the ASN1 definition of Extension borrowed
  from X509 is, mildly saying, a very stupid thing.
  First, the definition itself in X509 shows an absolute
  lack of possibilities of ASN1 i.e. the encapsulation of
  an ASN1 structure in an string instead of of using
  .. in old terms .. ANY DEFINED BY  (oops, another flame).
  Well, ten years ago, some decoder/coder writers were
  no lonnger available to maintain broken tools ...

  But, more important, the definition is made in order
  to support a ONE WAY communication between the issuer
  of the certificate. Even with that, the meaning of
  critical has already been changed in a significant
  way.

  At, one might not add any particular meaning to
  critical, thus the field becomes superfluous.

  Furthermore, we have already seen that even the
  usage of extensions in a standard protocol 
  has created some incomplete spec (Nonce in OCSP). 

  one might consider to simply use a CMS
  contentInfo. 

  logical: 

  An overly use of optional extension does not really
  simplify the interoperability. 

  In an extreme, one could argue that the whole
  PDUs should simply be a particalur profile 
  of 'Extensions'. 

-- 
regards
Peter Sylvester

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 22 Jan 2003 17:11:07 +0100 (MET)

I think that I have send a mail with another proposal. It seems
that the number of blacklists is growing :-)

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 22 Jan 2003 21:10:34 +0100 (MET)

> Folks,
> 
> It is time for this co-chair to eat some crow.
> 
> I totally blew it in my strawpoll message.  I missed Peter Sylvester's 
> compliance matrix for DVCS (submitted on December 24). I was on vacation at 
> the time, and didn't do a thorough job of catching up on the list.  Since I 
> hadn't seen the compliance matrix, I did not include DVCS as a 
> candidate.  I should have followed up with Peter to confirm that *before* 
> sending the strawpoll message, but I did not.
> 
> DVCS is a fourth strong candidate for consideration in the the DPD/DPV 
> strawpoll.  Please review RFC 3029 "Data Validation and Certification 
> Server Protocols" and the compliance matrix as you prepare to vote.
> 
> If DVCS is your preferred protocol, please use the subject line 
> STRAWPOLL:DVCS to vote for DVCS.
> 
> Now *I* have a choice to make - barbecue or teriyaki?
> 

Thansk for the fast correction...  oysters or sashimi ?