[ebxml-msg-comment] Re: [ebxml-cppa-comment] A "Trivial" Securee-business Question

[Anders Rundgren <anders.rundgren@telia.com>]

Title: Message

Thanx Dale,

To put DUNS numbers in DNs is indeed possible but a problem is how to inform the software (and users) that the object actually is a DUNS number without creating an arbitrary amount of special DN attributes.  In case you are interested, I have initiated an (not yet sanctioned) IETF draft effort to address this as well as many other issues related to the mapping of PKI to business systems.  It exploits the fact that practically all commercial CAs as well as most professionally run private CAs, implicitly form a two-level architecture where the CA cert/key vouches for a certain issuance and associated name space (like VeriSign's web-server CA that vouches for DNS host names together with associated owner and nothing else).  By making this de-facto scheme explicit, a foundation for a more robust PKI-to-business-system-mapping is created.  To get back to DUNS, such numbers would to preferably be expressed like http://xmlns.dnb.com/D-U-N-S : 678456123 where the first part would be stored at the CA-level, and the actual DUNS number using an existing DN attribute, at the end-entity-level.  Well, it is up to D&B to define the actual name-space but something according to these lines is a more "XML-ish" and future-proof way than using special codes to identify DUNS.  There are maybe thousands of possible name-spaces possible as even a company could (I really hope not) define name-spaces for employees, clients, whatever.  It seems that the URI is nowadays the only truly universal way to identify objects with, so it is (about) time for business to adopt this as well.  As we can keep our legacy EAN, DUNS, VAT, and SIREN numbers as they are today, this step in not that big.  Although some standards institutions may object.

 

BTW, I would be very happy to get a co-editor or just a reviewer on this draft...

 

 

Best

Anders Rundgren

----- Original Message -----

From: Dale Moberg

To: Anders Rundgren ; ebxml-msg-comment@lists.oasis-open.org ; ebxml-cppa-comment@lists.oasis-open.org

Cc: ebxml-cppa@lists.oasis-open.org ; ebxml-msg@lists.oasis-open.org ; ebxml-jc@lists.oasis-open.org

Sent: Thursday, March 06, 2003 17:46

Subject: RE: [ebxml-cppa-comment] A "Trivial" Secure e-business Question

 

Hi Anders,

 

Thanks for your question. I will be adding it to the CPPA agenda at our upcoming face to face in San Diego Mar 10 to 14.

 

Actually this issue was raised during the ebXML TA Risk and Security analysis group. 

 

The possibility exists for multiple partyIds being used in both Messaging and CPPA. The systems for identification of a subject are varied and CPPA has a draft discussing some of the alternatives. Then system configurations can add the Distinguished Name (DN) system of X.509 as one "type" of PartyId, and use the IETF's string serialization of DN  to carry values. In that way we can convey multiple IDs for the party (=subject) , without imposing constraints on the DN in the certificate itself.

I t might, however, be worthwhile exploring conventions for how users of one PartyID naming scheme make use of, say, DUNS numbers in a DN

 

Like you,  I am not certain either how to obtain a consensus for such a convention or how to gain sanction for that convention-- that is, what standards body approval would be appropriate. Also would the same DN be used in the possibly distinct certificates involved in SSL/TLS, digital signature on a message, application security and so on?

T he DNS name is one that is now used within SSL/TLS, to identify a server. That keypair is usually under tight control of the server and it can be a job to make it available to other applications unless they both support pkcs12 export/import (and even then it can be a job!!).

S o it is definitely worth considering at the face to face, and I will also try to raise the issue during the joint meetings next Wednesday with Messaging.

 

Dale Moberg 

---

Question:  How should the identity as expressed in a business 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.

One can note that the only PKIs working on a global scale, are building on a one-to-one identity mapping between the entity's perceived identity and the identity as expressed in the certificate.  Yes, I of course refer to e-mail and web-server certificates.   Other aspiring users of PKI, like e-commerce, have not even begun to look into this issue as apparently nobody feels that it is "their business".  Who are we wainting for?  The IETF, OASIS, W3C, EU, or the UN?  Or are we maybe waiting for Microsoft and VeriSign?.

A LONG-TERM REMEDY

To create a foundation for a more robust and "frictionless" PKI-secured e-business, I strongly believe 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".

Regards
Anders Rundgren
Senior Internet e-commerce Architect

+46 70 - 627 74 37

draft-rundgren-pkix-pnppki4ws-00.pdf