Subject: Non-constructive PKIX Input

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 10 Mar 2003 20:30:31 +0100

Steve wrote:

"If not, then your comment is just sniping, offered by someone
who has never contributed constructively to any PKIX effort."

Some of these non-constructive contributions include:

######## RFC3039 ########

After long and hard debates, I persuaded the authors to honor the idea
that QC CAs should not be allowed reuse DNs, as reuses would lead
to a considerably reduced credibility for the QC-concept as a whole. 

######## Permanent Identifier Extension ########

Now close to becoming a 3-year (!) task.
I have given the authors constructive input on how to align this
effort with existing practices in a way that also opens the door to a
higher-level PKI structure.

Here something went very wrong, and I still don't understand why. 
I always wanted and still do want to reconcile my efforts with their
stuff in order to create a "killer" RFC.  However, *they* don't.

Actually the only thing missing is a clear statement if RFC3039 is
correct regarding its description of "SerialNumber" [1], and thus
*can* be used as foundation for other standards, or if it incorrectly
passed the RFC-process due to an omission.

   1] It MAY contain a number or code assigned by the CA or an
       identifier assigned by a government or civil authority

######## Warranty Extension ########

My *thorough* analysis of the warranty-extension, which revealed
that the software support needed is of a magnitude and complexity that
likely will thwart any usage of it, still remains unchallenged.  

That the analysis is unchallenged is either due to the fact that no one
cares about the warranty-extension, or that the analysis is correct.

Whichever is true, it in a *constructive* way leads to the conclusion
that the warranty-extension draft should either be retargetted or be
abandoned.  I have proposed an effort to retarget the draft both
technically and scope-wise.  I'm not sure if this is possible though. 

####### Attribute Certificates and related drafts #######

OK, I admit that I have been a bit "hard" in my critique of these items.
It seems that the "market" has in its more "subtle" ways done the same.
The rationale behind this is though very simple:  An attribute-
certificate is nothing but a set of attributes optionally containing
a link to an entity associated with these attributes.  To an virtually
endless list of variants one should also add purchase orders, air-line
tickets, as well as more obscure things like authorization objects. 
A problem that the AC-developers did not take in consideration is that
real-world "AC"-designers are mainly concerned about content and
associated processes.  I.e. the "format" is definitely secondary.
To standardize "content" howver, is a task for the communities that
are supposed to deal with it, and not the IETF.  As these "communities"
all have different requirements, "legacy" designs, and technical
competences,  "AC"-formats are simply not possible to standardize at this
stage, maybe never.  A signed PDF-file may actually be want some need!

If one were to  write a sophisticated "AC"-based user-administration
system, RFC3281 would very unlikely be the choice, given XML's
extremely strong position for *new* designs.  SAML et. al. have
also enabled entirely new ways to build access systems, futher
limiting the viabiliy of X.509 ACs.

An X.509.v3 PKC OTOH, is (at its best), just a link between a key
and a name,  making it "universal", and was therefore an excellent
target for *successful* standardization in all possible aspects.

####### Subject Identification Method #######

An exhaustive analysis were performed, resulting in an advice to use
the already available OASIS SAML system (which I BTW also have
contributed to) as it offers a higher level of user-convenience and
does not rely on rather "special" client-based stuff.  This scheme also
lends itself to other novel uses of PKI and browser-technology.  I
therefore suggested dropping SIM as a PKIX task.

####### Naive statements and questions #######

The "Trivial PKI Question" was characterized as being naive at best.
I think that some people have some problems with "my approach" which
is to get as much feedback as possible.  By not applying a too pompous
tone, you get a lot!   In this case I put this question in various foras and
got results that were all over the map.   I noted that the answers
gotten from the PKIX-list were the least useful which confirms my view
that there must be pretty few active SW engineers following this list.

#### ### Plug-and-play PKI  #######

On your request (as you don't like my "colorful" PPTs), I indeed
created a PnP draft embryo:   
http://www.x-obi.com/OBI400/draft-rundgren-pkix-pnppki4ws-00.pdf
You and Tim have had that in your "custody" for 9 weeks but I still
have not gotten a formal decision or any real feedback.   Indirectly 
you said in your last message that efforts "competing" with existing
drafts will not be supported.  This reveals that you have not read the
paper thoroughly as it also addresses some entirely different issues
than the permanent identifier draft does.   I maintain that the only 
way one can ever understand the motives behind a sophisticated 
scheme like PnP, is to perform something like a "virtual design"
with and without the support of the scheme in question.  This is
what I did with the warranty extension and unfortunately it turned
out rather bad.

####### Server-based Legal-entity-only Signatures #######

I believe I'm partly responsible for this becoming a hot EU topic.
Many countries including Sweden now support this more or less
officially, in spite of being an "unthinkable" solution just a few
years ago.    Although not exactly an IETF-item, this will have a
profound effect on PKI deployment and probably even affect some
PKI-related standards as well.   That VISA dropped SET and
now push 3D Secure, is another sign of that "old truths" at least
in the realm of PKI, seem not to be that "true" anymore.

A one-page related document:
http://www.x-obi.com/OBI400/b2bsign.pdf

A long related document:
http://www.x-obi.com/OBI400/pki4org.pdf

####### Dissing Policy Extensions #######

As it is infeasible to standardize information of the "fluffy"
kind that Policy Extensions constitute, I maintain that usage of
these extensions have no purpose from an application software
point of view.  No existing COTS products make any use of PEs
and probably never will. Constructive input? Yes, for those who
accidently believed that PEs actually fill an important mission.  
For a CA to have a CP is surely important but that is not the
same as stuffing it in a certificate as an OID or so.

####### Dissing Directories #######

Is now an almost "accepted" activity within the PKI community.

Anders R