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)


I am starting to understand where you are coming from.  However, I am loath
to get into changing the CMS structure, even if it is by an extension.

> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: 29 April 2003 19:21
> To: Nick Pope; dss@lists.oasis-open.org
> 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]