Acme corp utilizes monster.com for its hiring process. Acme has a site
license for access to monster.com, however the agreement limits acme to
10 concurrent users. To keep within this contraint Acme limits the
employees that can access monster.com. It utilizes dmd0 and achieves
this by having a user property called dix:/monster.com/user-key.
Employees that are allowed to use monster.com have this property set.
An acme employee with the right to access monster.com goes to that
site's login page. Here, they type in their homesite
"intranet.acme.com", a homesite on acme's intranet. Monster.com
requests the attribute "dix:/monster.com/user-key" via DIX. The user is
bounced to their homesite, they authenticate and then they get bounced
back to the membersite monster.com with the property set and the message
signed.
The interesting aspect of the above scenario is that monster.com cannot
communicate with the server "intranet.acme.com" it is behind the
companies firewall. It is also worth mentioning that acme, like all
large multinationals, has "intranet.acme.com" locked away deep inside a
data center. It can talk to its ldap server and a database server, but
nothing else and certainly not "monster.com"
It is in scenarios such as these that "push" excels. However in the
current draft the verification step is a "pull" step and so dmd0 cannot
support acme. Has there been any thoughts as to how DIX can allow
parties to sign the message without requiring the "pull" verification step?
I could imagine specifying in core or in an extension attributes such as
dix:/signature-X509, dix:/signature-X509-subjectname and
dix:/signature-X509-certificate. Then monster and acme can relay
messages without any "pull" operation.
What is preventing these extensions at the moment is the current
canonicalization algorithm and so I guess all of this was a very long
winded way of asking whether the canonicalization algorithm described in
section 5.10.2.7 can be changed to something like.
"For each name-value pair within the message, with the exception of any
parameters starting with "dix:/signature", treat as a ......... "
Rob
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
