Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt

From: Michael Myers <[email-masked]>
Date: Sun, 11 Jul 1999 15:32:22 -0700

Steve,

Let us however lose sight of the fact that certificates provide a very
convenient vehicle for the transport of application-independant attributes.
One's purchasing authority or purchase authorization authority isn't and
shouldn't necessarily be restricted to a particular application context.  We
run the risk otherwise of re-inventing the equivalent of a PKI for each
application.

Mike

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: Friday, July 09, 1999 7:11 AM
> To: Ben Laurie
> Cc: PKIX-List
> Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> 
> 
> Folks,
> 
> I think we may be loosing trakc of some issues here.
> 
> 	- certificates are not the only option for passing around signed
> data.  many appications develop their own data structures 
> when then need to
> use signatures to ensure data origin authentication and connectionless
> integrity, or non-repudiation.  thus, the use of XML for various
> applications does not imply a need to use XML in 
> certificates.  don't try
> to stuff everything into a cert just because we have an 
> ability to do so
> via extensions.
> 
> 	- depending on the  context, Ben is right that one 
> might be able to
> avoid some of the issues that motivate the use of DER in 
> ASN.1. however,
> our experience with PEM development back in the late 80s 
> showed the need
> for canonical representations in other than just 
> certificates, with regard
> to signed data structures.  I disagree with Ben's comments re 
> DER.  while
> it is certainly true that people have made mistakes in 
> implementing DER, I
> think we are in pretty good shape these days and I'm not aware of any
> lingering issues now.
> 
> Steve
>

---

From: Daniel Finkelstein <[email-masked]>
Date: Sun, 11 Jul 1999 20:04:04 -0400

Michael Myers wrote:

Steve,

One's purchasing authority or purchase authorization authority isn't
and

shouldn't necessarily be restricted to a particular application context.
We

run the risk otherwise of re-inventing the equivalent of a PKI for
each

application.

It's a risk that's already happening. Interoperability threatens to create
such a monster, as "draft-compliant" PKI implementations function well
enough alone, but not with each other. So then we'll need glue to tie them
together. PKI middleware!

Having worked with many of the participants' company's PKI software
products, it's interesting to note how many don't work together at all,
especially considering the teamwork required in the drafts. It seems like
a case of one hand not knowing what the other hand is doing. But then again,
this is all very academic. Until the drafts are static and concrete enough
in the details to justify judgment, PKI products have very good excuses
as to why they don't work together. And become, as you noted, application
specific.

--
Daniel Alex Finkelstein
New Technologies
phone   212-383-2951
pager   917-427-1630
fax     212-383-3289
Securities Industry Automation Corporation

---

From: Stephen Kent <[email-masked]>
Date: Tue, 13 Jul 1999 03:11:41 -0400

Mike,

>run the risk otherwise of re-inventing the equivalent of a PKI for each

Agreed.  Just let's not go overboard.

Steve

---

From: Daniel Finkelstein <[email-masked]>
Date: Fri, 16 Jul 1999 16:54:39 -0400

Michael Myers wrote:

Steve,

application.

Yes, this is true. But there is also the distinction to make between the
data that certificates via encryption of some kind protect, and the data
in the certificates themselves. All the data in the certificates can be
stored and retrieved elsewhere, such as SQL databases, LDAP and X.500 directory
services, and so on. But the protected data isn't so portable...yet.
Just to reiterate your point by logical extension.