pem-dev
[Top] [All Lists]

Re: StrongAuthenticationUser object class

1994-03-08 12:53:00


   >From: jueneman <jueneman%wotan(_at_)com(_dot_)gte>
   >Subject: Re: StrongAuthenticationUser object class
   >Date: Tue, 08 Mar 94 12:36:13 EST

   >Mark,
   >
   >Thanks for your detailed and informed reply. I should warn readers who have 
only a 
   >passing interest in X.500 that this message is rather lengthy, and may 
require going
   >back to my original message in order to keep the context clear, but I think 
that
   >these issues are very important if we are to adequately support PEM and 
other
   >users of PKC with a workable X.500 directory.
   >

I dont think we are progressing the PEM RFCs on the standards path.

1) IETF activities are being used to support "submissions" to the NADF -
private members-only commercially-driven group. This is just wrong. The IETF
should only work from NADF published documents and statements. Liason is 
fine, interworking is not.

2) Carl repeats his biannual statement that uniqyeness of Y values to get 
identifier
uniqueness is all that the world requires to obtain proof of origin. Carl
should perhaps write an Internet-draft proposing the protocol elements formats 
which
should be added to the existing <origid> and <recipid> fields, and specify how
how the protocol engines may distinguish between Dn-identified public keys
and thos which are self-identifying. The defns should ensure that support
for self-identitying keyed users is optional processing, yet
still unambiguous.

3) Christian vents his frustration atthe difficulty of mapping geopolitical
structures into IT management and protocol procedures, and obtaining
certificates from an X.500 directory . He should writeup the proposed
alternative, and also specify the protocol he suggested last year for accesesing
certificates remotely

4) RIPEM and PGP state adhernets that all the Internet user community wants is
data origin authentication service, at thd end of the day, with 
consequentially-limited
privacy.

5) Continual discussion of X.500 contradicts the instruction of the area
director to ensure PEM and X.500 services are exclusively handled within
the IETF. 

A) we finally have a specific proposal in the required form from  Rhys to
amend the protocol and procedures for handling domain-name strings used
as identifiers. this will go forward to Seattle for decision on what
to do next. Perhaps Rhys you could advise the WG on what you
see the next steps to be? 

B) we have a committement from RSA DSI to write up the procedures for handling
the protocol elements to assure RIPEM messaging security semantics for PEM 
implementations. Hopefully, this will take the form of a published I-D.

C) im going to suggest to Mike Roe that he reformats parts of that PASSWORD
R2.2 deliverable into an informaitonal-RFC, as it addressed the only problem
the (non-INRIA) PASSWORD people had with PEM -namely that we didnt
understand the model behind the certification system. This will also
make it possible to reference the material properly. (Its a shame 
one can't (professionaly) reference Steve Kent's lucid explanations from this 
list, also.)

D) Perhaps Bob will reconsider publishing his ongoing "redesign
of authentication syntax and semantics" as an I-D, rather than putting 
it through the NADF?

<Prev in Thread] Current Thread [Next in Thread>