Subject: Trivial PKI Question

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 3 Mar 2003 22:44:47 +0100

A "TRIVIAL" PKI QUESTION
-----------------------------------

Assume that you have a business message like a purchase order

    <Order>
        <From name="Big Buyer Corp.">
            <OurRef name="John Doe"/>
        </From>
        <To name="MegaCar International"/>
        <Item>10 Medium-sized SUVs</Item>
        <Comment>Make it quick please!</Comment>
    </Order>

Now assume that "Big Buyer Corp." is an advanced organization
using digital signatures.

==============================================
Question:  How should the identity as expressed in the document
relate to the identity as expressed by the signer's certificate?
==============================================

Among the complications we find

1.  The PKI-identity is presumably "strong" as it is vouched for by a
     CA, while the identity in the business document is only "claimed"
     by the entity itself.  ==> The PKI identity is governing?

2.  The hierarchical naming system used by PKI (X.500) is completely
     different to the various naming schemes used in businesses.

3.  Some PKI-folks claim that signatures should be tied to individuals.
     Does this mean that the signer's certificate in the sample should
     identify John Doe of Big Buyer Corp.?

4.  The receivers (relying parties) are automated processes supposed
     to securely handle similar messages from numerous business parties.

5.  Current e-commerce standards like ebXML and Web Services does
     NOT address this basic question.

My own conclusion is that PKI was created to support e-mail where
these questions do not arise.  For other types of messaging, PKI in
its current shape does not scale well, or at least creates as many
new problems as it was meant to solve existing ones.

Regarding #1, I believe that most business systems ignore the PKI-
identity due to #2, #3 and #4.  Although a bit weird, the logic behind
that is that if an entity having a known key/cert is "lying", they will
sooner or later get in trouble anyway.  The drawback is that this will
be found out by a *human*, and usually only *after* a malpractice has
been performed.

A LONG-TERM REMEDY
-------------------------------

To create a foundation for more frictionless PKI-secured e-business,
I think that there *long-term* should be a one-to-one mapping between 
[basic] business message identities and certificate identities.
As the business community is never going to adopt X.500 naming, as 
well as having their own naming problems, this will likely require
changes on both sides.  A possible scheme using the currently only
globally functioning naming system (DNS/URIs), is that entities are
uniquely defined by two elements:

- A naming domain (name space) based on a URI like: "http://www.visa.com/cc"
- A local identifier in that domain like: 4555-5555-2244-8888

Although the example identified a credit-card, the scheme works for just
about any kind of object or entity.  An advantage of using HTTP URIs is
that you usually can get further information "by clicking on the link".

Anders Rundgren

---

From: "Olle Mulmo" <[email-masked]>
Date: Tue, 4 Mar 2003 03:08:05 +0100

Anders,

For S/MIME, the problem you state was circumvented by putting the
email address in SubjectAltName::rfc822Name. In the case of Kerberos
and PKInit, they added the Kerberos principal name in SubjectAltName
as well. Same thing with Microsoft and their smart card login.

So why not just create another such circumvention for XML-based
naming? Something like an OtherName of type

  XmlName ::= SEQUENCE {
     identifier        UTF8String,
     nameSpace  [0]    UTF8String OPTIONAL }

/Olle

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Anders Rundgren
Sent: den 3 mars 2003 22:45
To: [email-masked]
Subject: Trivial PKI Question

A "TRIVIAL" PKI QUESTION

    <Order>

A LONG-TERM REMEDY

Anders Rundgren

---

From: Stephen Kent <[email-masked]>
Date: Thu, 6 Mar 2003 15:07:45 -0500

>A "TRIVIAL" PKI QUESTION

Whether the identity in the Subject name is accurate depends on who 
the CA is and whether the CA has vouched for a name for which it is 
authoritative, or whether it has done some checking on the likely 
accuracy of some name for which the CA is not authoritative. So, I 
think we already disagree about one premise of your question.

It is clearly desirable that there be an exact match between a name 
in a cert and the name in the document, IF the authorization policy 
requires that level of authentication. As others have noted, another 
likely scenario is that the RP needs only to know that the cert was 
issued by an organization that will assume liability for the actions 
of the individual to whom the cert is issued, irrespective of the 
specific ID in the cert and in the document.

>      different to the various naming schemes used in businesses.

"completely different" is an odd construct in English, and arguably 
just plain wrong in this contect. If I am issued a cert that has a 
subject name of the form "C=US, O= Verizon, OU= BBN Technologies, CN 
= Stephen Kent" that is a hierarchic name that is readily mapped to 
my identity in my professional context, and thus is is not at all 
"completely different" as you assert.

>      identify John Doe of Big Buyer Corp.?

Some LAWS require that signatures be tied to individuals in some 
contexts. It's not just a matter of opinions expressed by "PKI 
experts." But, you have not provided a sufficient description of the 
context to determine if there is a problem here or not.

>      to securely handle similar messages from numerous business parties.

A reasonable goal.

>      NOT address this basic question.

You have failed to articulate a well-formed question, so the 
conclusion above is not supported by your arguments.

>new problems as it was meant to solve existing ones.

Definitely wrong. E-mail security encounters some of the problems you 
allude to above, e.g., the mismatch between the Subject DN and an 
e-mail adddress as a suitable, native ID form.  X.509 v3 addressed 
this problem with the Subject AltName extension and the RFC822address 
name form. But, the assertion above is naive, at best.

>be found out by a *human*, and usually only *after* a malpractice has

I have no idea what "most business systems" do, but since we often 
see people making poor design choices, I would not be surprised by 
any claims of what may be done. Still, remedial security measures are 
very common in many financial transactions and so we ought not say 
that such an approach is not "secure" absent a more thorough analysis 
of the threat model, etc.

>A LONG-TERM REMEDY

any time someone uses the term "frictionless" I know we've moved into 
marketing hype land.

>that you usually can get further information "by clicking on the link".

Oh. This is just another advertisement for your notions on how to 
"fix" everything that is "wrong" with X.509.

Nevermind,

Steve

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 7 Mar 2003 07:52:56 +0100

Steve Kent wrote:

<snip of a ton of mostly only patronizing lines>

   >any time someone uses the term "frictionless" I know we've moved into 

To this private list of Dr. Kent's no-words we should also add "existing practices",
"simplicity", "scalability", "plug-and-play", "business-system", "XML-based",
"VeriSign", "Microsoft", and most of all "the market".

   >"fix" everything that is "wrong" with X.509.

By adding a minute constraint extension on top of RFC3280, PKI can
technically be converted from being an n-level structure of arbitrary
complexity, into a 2-level self-describing structure.

But as "simplicity" is like a red blanket to Dr. Kent, he insists only
promoting technically broken stuff like the PI, which obviously was
engineered by looking at the world through a microscope.

  >Nevermind,

I don't.  I rather support Phill's statement that it is time for you and PKIX
to wrap-up and close the show.  "The thrill is gone".  It is BTW only two
weeks to the next IETF, and you have even have not even managed to create
an agenda for PKIX.  http://www.ietf.org/meetings/wg_agenda_56.html

Anders

---

From: Stephen Kent <[email-masked]>
Date: Fri, 7 Mar 2003 12:13:46 -0500

>"VeriSign", "Microsoft", and most of all "the market".

I realize that English is not your native language, and thus I do 
applaud your generally excellent use of English. Let me help clarify 
some of the subtleties that seem to be confusing, based on the text 
above:

	- "Exitsing practices" is a fine phrase, but it is sometimes 
used by folks to avoid changes to paradigms with which they feel 
comfortable. So, depending on how one uses it, the phrase might be a 
good reason for a design choice, or a defense against an appropriate 
paradigm shift.

	- "Simplicity" and "scaleability" are over-used, generally 
not quantifiable, and usually trite terms on the verge of being 
buzzwords. The phrase "plug-and-play" is certainly a buzz phrase, and 
more appropriately rendered as "plug and pray" in many instances.

	- Proper names of companies are just that, even when spelled 
using the poly-capitalized form that became so trendy in the 90's.

	- "XML-based" is potentially an accurate description of a 
technology, but it confers no intrinsic goodness.

	- "Market" is a term often used by people in an attempt to 
lend weight to their positions, when no technical justification for 
such positions exists. It too could be a neutral, useful term, but 
its misuse renders it questionable in many contexts.

Hopefully this brief tutorial will help your writing in the future.

>complexity, into a 2-level self-describing structure.

Is the preceding string of words intended to convey some meaning?

>engineered by looking at the world through a microscope.

Simplicity is hardly a panacea, though it is a desirable feature. On 
the other hand, some things that are promoted as simple as just 
simplistic.

>an agenda for PKIX.  http://www.ietf.org/meetings/wg_agenda_56.html

Were you planning to attend this IETF meeting? If so then you have a 
legitimate desire to see the agenda as soon as possible. If not, then 
your comment is just sniping, offered by someone who has never 
contributed constructively to any PKIX effort. Tim is responsible for 
the agenda, and I'm sure your concern will be noted by him.

More broadly, if you believe PKIX is not providing utility then feel 
free to not participate in the WG activities, rather than wasting the 
time of WG members. The message that prompted my response exhibited 
very sloppy analysis which was contrived to promote your pet project 
as a solution. I provided a detailed critique of the errors and 
omissions in the message, to which you did not respond. Instead, your 
response merely tries to argue that YOU know what the market wants 
and YOU have THE solution. That seems to be typical form of your 
messages to this list, hence my characterization of you not 
contributing constructively.

Maybe there is a problem that is important and for which you have a 
good solution. Unfortunately, you have repeatedly failed to do a good 
job of characterizing the problem. Instead, you have emphasized your 
proposed solution. We don't need solutions looking for problems, 
especially when your solutions conflict with existing PKIX standards 
track efforts.

Steve