Re: [security-services] Metadata errata items

[Eric Tiffany <eric@projectliberty.org>]

A little more on the EncryptionMethod metadata issue:

As Kyle mentioned, we ran across this issue during our test event last fall.
I thought we had submitted something to SSTC, but I guess not. In any event,
there are (at least) two issues:

   1. How to interpret the presence of some subset of required encryption
algorithms in metadata (as Kyle has elaborated)

   2. How (and whether) to indicate that the EncryptionMethod entries in
metadata correspond to block encryption or key transport.  The
EncryptionMethod element described in xmlenc (I think) allows both key
transport and block cipher algorithms to be represented, but in the context
of metadata there is no way to designate whether an EncryptionMethod relates
to block cipher or key transport.  It might be possible to infer from the
algorithm URI, but this is unreliable.

So we chose to basically ignore the metadata information.

ET





On 2/29/08 1:54 PM, "Kyle Meadors" <kyle@drummondgroup.com> wrote:

> A minor clarification. The actual wording we agreed was "to support any of
> the ciphers and key transports listed in section 4.2 of [SAMLConf]
> regardless of the metadata values." So we don't specifically ignore
> EncryptionMethod but we don't know exactly what to do with it.
> 
> Kyle Meadors
> DGI
> 
> -----Original Message-----
> From: Kyle Meadors [mailto:kyle@drummondgroup.com]
> Sent: Friday, February 29, 2008 3:42 PM
> To: 'Scott Cantor'; security-services@lists.oasis-open.org
> Subject: RE: [security-services] Metadata errata items
> 
> Scott,
> 
> During last year's 4Q07 SAML 2.0 Liberty interop test, we ran into the
> question about the interpreting and use of EncryptionMethod. Within the
> group of participants, there was a disagreement on whether it indicates that
> any listed encryption methods and transports algorithms are supported ON TOP
> of those required in SAMLConf 4.2 or it indicates the implementation only
> supports those specifically called out in the EncryptionMethod element?
> Also, there was confusion on interpreting EncryptionMethod is only key
> transport algorithms are listed but not block encryption algorithms. In that
> case, would that indicate all encryption algorithms from SAML 4.2 are by
> default supported?
> 
> For the purpose of not delaying the test event, we decided to support all of
> the algorithms from SAMLConf 4.2, but seek guidance from SSTC on the proper
> interpretation post-test.
> 
> To your question, the Liberty interop is temporarily ignoring the
> EncryptionMethod element but waiting direction from SSTC for future actions.
> 
> Kyle Meadors
> DGI
> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: Friday, February 29, 2008 1:06 PM
> To: security-services@lists.oasis-open.org
> Subject: [security-services] Metadata errata items
> 
> I'm working on the errata doc, and thought I'd add some metadata errata
> while I'm doing it.
> 
> First a question:
> 
> What the #$$^$ is EncryptionMethod for? I didn't know when we were writing
> the spec, and having implemented XML Encryption now, I still don't know. I'm
> particularly asking whether it's supposed to reflect the supported
> algorithms for key transport or for actual bulk encryption?
> 
> Is this tested during interops? If so, what gets done with it? I'd really
> like to add some text to this, but I have no idea what to add.
> 
> On to the errata (I'm putting these in the doc, I just wanted them on the
> list for the record):
> 
> - Absence of NameIDFormat
> 
> I think we should explicitly state that the absence of this element doesn't
> imply anything about the formats supported. In other words, listing none
> doesn't mean you don't support any. If this isn't how people interpreted it,
> let me know, but that's what I meant.
> 
> Proposal is to add text at line 661:
> 
> "Omitting this element does not imply that any given format is supported or
> unsupported; it means any such knowledge is exchanged out of band."
> 
> - Multiple KeyDescriptors
> 
> A question was raised by Sun (I think) about how to handle multiple
> KeyDescriptors. I would prefer that the text I'm proposing use the word MUST
> in the first spot because there just shouldn't be any question about this,
> but I used SHOULD for now.
> 
> Proposal is to insert text at line 625:
> 
> "The inclusion of multiple <KeyDescriptor> elements with the same use
> attribute (or no such attribute) indicates that any of the included keys may
> be used by the containing role or affiliation. A relying party SHOULD allow
> for the use of any of the included keys. When possible the signing or
> encrypting party SHOULD indicate as specifically as possible which key it
> used to enable more efficient processing."
> 
> - Semantics of KeyInfo
> 
> I'm not going to do what I'd like to do, which is to insert my bias directly
> into the metadata spec. I am going to propose a profile for PXIX-less
> KeyInfo usage later, but it will be optional of course, so nobody can really
> argue with that. We discussed that on a call.
> 
> What I am going to do is propose that we explicitly note some things that
> are NOT true. Specifically, it is NOT true that a relying party is obligated
> to treat certificates as having any particular semantics at all. It is NOT
> required that their expiration dates be enforced, their extensions examined,
> their CRLs checked, etc. That much I have to insist on. Out of scope means
> out of scope.
> 
> The effect isn't all that dramatic, because it simply makes it legal to
> permit things that might otherwise not be permitted. I just believe we
> should do this to avoid any accusations of "bugs" in implementations.
> 
> So, I'm suggesting this text at line 625:
> 
> "The <ds:KeyInfo> element is a highly generic and extensible means of
> communicating key material. This specification takes no position on the
> allowable or suggested content of this element, nor on its meaning to a
> relying party. As a concrete example, no implications of including an X.509
> certificate by value or reference are to be assumed. Its validity period,
> extensions, revocation status, and other relevant content may or may not be
> enforced, at the discretion of the relying party. The details of such
> processing, and their security implications, are out of scope; they may,
> however, be addressed by other SAML profiles."
> 
> I of course welcome suggestions on the text.
> 
> I should have the updated errata doc uploaded shortly. There should a
> handful to vote on during the next meeting.
> 
> -- Scott
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 

-- 
____________________________________________________
Eric  Tiffany             |  eric@projectliberty.org
Interop Tech  Lead        |  +1 413-458-3743
Liberty Alliance          |  +1 413-627-1778 mobile