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] | [List Home]


Subject: RE: [dss] Representing requestor's identity (As a signed attribute ofsignature)


At 10:27 AM 4/29/2003 +0100, Nick Pope wrote:

>Trevor,
>
>I am very confused over what you are suggesting.
>
>The DSS structure is in XML.  If we have a CMS signature it will be carried
>within a subcomponent of this XML.  The information about requestor needs to
>be visible as part of the XML syntax.

Sorry, I guess I'm confusing everyone.  I renamed the subject.  I was 
talking about how to identify the requestor as a signed attribute of a 
DSS-produced signature.

This is necessary *IFF* the DSS is signing with a key that is not 
intrinsically associated with the requestor, but wants the relying party to 
know who the requestor was:
  - If the DSS has the requestor's private key on file and signs with that, 
and includes the requestor's cert in the dsig:KeyInfo, then adding a 
Requestor Identity signed attribute is not necessary.
  - If the DSS signs to indicate "I, as a corporation, approve this 
document" or something, then adding a Requestor Identify signed attribute 
may not be necessary.


>CMS only carries GeneralName within some of the certificate extensions.  It
>does not include GeneralName in any other part of the structure!  Are you
>suggesting that we start re-defining CMS?

I'm suggesting we add a GeneralName as a CMS signed attribute.  This isn't 
really re-defining CMS, but it is augmenting it..  probably we should liase 
with ietf-smime in some way.


>I strongly suggest that we carry the SAML structure when this is used as a
>method of authenticating / authorising the requestor.

I was suggesting that when the DSS wants to not only identify the 
requestor, but give facts about the requestor's authentication (whether it 
was through Kerberos, Biometric, a password, whatever), then the DSS could 
add a SAML Assertion (in place of, or in conjunction with) the simpler 
"name syntax" that just represents the requestor's identity.

Trevor 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]