Given this example, and using traditional technologies and
protocols, this problem appears intractable. However, there
is a new solution - becoming an OASIS standard shortly - that
not only solves this problem, but goes beyond this stage of
the problem to address the next stage of the problem.
Everybody on this forum understands that when this Purchase
Order is sent encrypted, it has to be encrypted with a symmetric
key, and the symmetric key has to be encrypted with the public
key of the receiver(s) and packaged with the ciphertext PO (ala
S/MIME). However, there is no current standard to do this with
groups - just individuals.
But, if the symmetric key is abstracted out of the package and
an infrastructure exists to support its secure distribution on
the internet, the problem is solved.
The infrastructure I speak of is a Symmetric Key Management System
(SKMS). It is part of an Enterprise Key Management Infrastructure
(EKMI), which includes a PKI.
While the Purchasing problem is not very complex, lets run with
it to continue the thread:
a) When a Purchasing Manager (PM) wants to send an encrypted/signed
PO to a vendor's Order Receiving System, the vendor issues the
PM a signing and an encryption certificate from the vendor's EKMI.
b) After the PM prepares the PO, they sign it with their company
issued digital certificate, and then using the vendor-issued
signing certificate, request a symmetric key from the vendor's
EKMI;
c) The vendor's SKMS, validates the request based on the signature
and cert-chain, and issues a symmetric key based on policies
defined by the vendor in the SKMS; the key is transported after
being encrypted under the vendor-issued encryption certificate
to the PM;
d) The PM receives the key, verifies the response, encrypts the PO
(into an XML Encryption-schema conformant document) and sends it
off to the vendor's ORS; the PM erases the symmetric key from
their system when done - they don't need it anymore;
e) Vendor's ORS is configured with its own pair of certificates from
the SKMS. When it receives the encrypted PO, it requests the same
symmetric key from the SKMS; the SKMS had escrowed it even before
sending it to the PM; the ORS knows the key-identifier because it
is embedded in the XMLEncryption document;
f) SKMS recieves request; based on access-control rules, it returns
the symmetric key to the ORS, which now decrypts the signed PO &
sends it off to the Order Receiving Group alias. Any receiver on
the vendor's side can now verify the signed PO and process the PO.
An alternate approach is to have the XMLEncryption document go to all
the Order Receiver's on the vendor's side. When the receiver is ready
to process the PO, they request the symmetric key from their SKMS, and
after receiving the key based on their signed request and access control
rules, decrypt the PO and continue processing it.
Using S/MIME-like design, but abstracting the key out of the encrypted
document, this problem - and another more complex problem as shown in
slides 15-17 of this 18-month old presentation:
http://www.oasis-open.org/committees/download.php/24594/ekmi-webinar.pdf
is solved. (Using the purchasing system example, it would be analogous
to the order receivers being able to share the encrypted PO dynamically
with a select sub-group out of a group hundreds of thousands of parts
suppliers to the vendor).
Arshad Noor
StrongAuth, Inc.
Anders wrote:
> When any of you guys have made a *public* write-up on how you
> would address the [related] issues mentioned on p.2 in this document
> http://webpki.org/papers/web/A.R.AppliedPKI-Lesson-1.pdf
> you are ready for the real discussion.
1. How is the purchaser (P) going to select and acquire a suitable
Order Receiver (OR) encryption certificate from the selling organization?
2. How is the buying organization’s Purchasing System Server (PSS)
able to perform its logging, authorization, and control tasks if
purchase orders already have been encrypted by the Purchaser using a
public key from an external selling organization?
3. How is the selling organization’s Order System Server (OSS)
supposed to decipher and validate incoming orders if they are
encrypted by a public key of a specific Order Receiver (ORn)
employee? In case the
designated OR is unavailable, how is OSS going to be able to delegate
order handling to another OR?
4. How are different Order Receivers (ORs) supposed to cooperate if
they cannot see each others’ tasks? Are the particular Order Receiver
and Purchaser also the natural entities for handling associated invoices?
> I know that there is not a single person on this planet who can :-)
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
