[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [dss] Identified Requester with single keypair/cert
The Identified Requester use case had an interesting idea: "The Digital Signature Server may sign all data with its own private key and simply include the name or identifier of the requester(s) within the scope of the data that is signed." This raises some questions: a) how to include a name within the signature (in XML DSIG, CMS, etc.) b) what does the service's cert look like? For (a), both XML DSIG and CMS can have signed attributes in signatures. It would be easy to stick in a name, or maybe even a SAML Assertion about the originator. For (b), RFC 3183 (DOMSEC) might be a guide. It uses a naming convention where a cert with a name like "domain-signing-authority@Acme.com" can apply signatures with the semantics "this mail came from someone within this domain". An MTA can apply these signatures to outbound email. So maybe a "delegated-signing-authority@Acme.com" would be trusted to produce signatures associated with a particular user in the Acme.com domain. An interesting point is that such a signature could be applied by either an "inline" trusted third party like an MTA, or an "online" trusted third party like a DSS service. So this is getting out of scope, but I guess my point is, if the group wants to support the above case, it might be desirable to also push the concepts of originator-associated signatures and delegated-signer certs, in groups like ietf-smime or ietf-pkix. Trevor
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC