OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[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