Shibboleth Developers

[Dan McLaughlin <>]

It is my finding that as of Shibboleth SP 2.4.2 the default behavior
of the MetadataGenerator no-longer complies with the GFIPM
Cryptographic Trust Model requirements:

"6. Two <KeyDescriptor> elements MUST be present within
<SPSSODescriptor>. One <KeyDescriptor> element MUST specify the
signing key for this SP, and the value of its use attribute MUST be
“signing.” The other <KeyDescriptor> element MUST specify the
encryption key for this SP, and the value of its use attribute must be
“encryption.”"

--

Thanks,

Dan McLaughlin
Technology Consortium, LLC

http://www.tech-consortium.com

NOTICE: This e-mail message and all attachments transmitted with it
are for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is strictly prohibited. The contents of
this e-mail are confidential and may be subject to work product
privileges. If you are not the intended recipient, please contact the
sender by reply e-mail and destroy all copies of the original message.



On Wed, Apr 20, 2011 at 12:13 AM,  
<>
 wrote:
> I'm not sure the GFIPM specs are wrong, they are just more constrained than 
> the SAML specs.  The SAML specs allow duplication of the certificates with 
> use tags or no duplication and no use tags.  I think any product that is 
> conformant with the SAML spec should conform with the GFIPM spec; at least 
> that was our intent when we developed the GFPM specs.  The additional 
> constraints are intended to simplify interoperability testing.  Those 
> specific issues regarding how the federation publishes it's SAML 2 Metadata 
> seem like very much a federation specific issue.  It won't be uncommon for 
> a federation to have additional requirements for the contents of the SAML 2 
> Metadata for a given entity for various reasons (from something as simple 
> as mandating points of contact to more complex and requiring specific 
> profile support).
>
> Shibboleth is compatible with the GFIPM specs (as far as I have tested), 
> those requiremnts as met by Shibboleth (both IDP and SP) are about 
> consuming metadata.
>
> ________________________________________
> From: 
> 
>  
> []
>  on behalf of Dan McLaughlin 
> []
> Sent: Wednesday, April 20, 2011 12:38 AM
> To: 
> <>
> Cc: 
> 
> Subject: [Shib-Dev] SP 2.4.2 & Novell Access Manager 3.1.3
>
> Today, while working on a Novell Access Manager IDP 3.1.3 & Shibboleth
> SP 2.4.2 interop, we ran into issues using encrypted assertions
> because NAM was expecting two KeyDescriptor's--one with the
> KeyDescriptor use="signing" and a second KeyDescriptor
> use="encryption".
>
> Prior to upgrading to Shibboleth SP 2.4.2, the SP metadata included
> two KeyDescriptor's within the SPSSODescriptor element. One
> KeyDescriptor included the optional use attribute for signing, and the
> other KeyDescriptor included the optional use attribute for
> encrypting.   As of SP 2.4.2 the default behavior of the
> MetadataGenerator has changed so the SPSSODescriptor element only
> includes one KeyDescriptor element and the optional "use" attribute is
> no-longer defined.
>
> It's my understanding, that as of Shibboleth SP 2.4.2 the use
> attribute has been removed because it's unnecessary based on the SAML
> 2.0 specification.  I was able to find the SAML V2.0 Metadata
> Specification 
> (http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf),
> which states that the "use" attribute is optional. I also found the
> SAML V2.0 Errata
> (http://docs.oasis-open.org/security/saml/v2.0/sstc-saml-approved-errata-2.0.pdf),
> which states "If the use attribute is omitted, then the contained key
> information is applicable to both of the above uses."
>
> The SAML 2.0 Metadata specification and SAML 2.0 Errata both seem
> support the new behavior of the latest SP MetadataGenerator, so it
> would seem that NAM's current interpretation of the specification is
> incorrect.
>
> Thoughts?
>
> While researching the issue above I stumbled across a recently release
> document "GFIPM Cryptographic Trust Model"
> (http://it.ojp.gov/docdownloader.aspx?ddid=1338) which supports the
> previous SP behavior and NAM's current behavior, but directly
> contradicts the SAML 2.0 Metadata specification, the SAML 2.0  Errata,
> and the recent change made in SP 2.4.2.
>
> "Two <KeyDescriptor> elements MUST be present within
> <SPSSODescriptor>. One <KeyDescriptor> element MUST specify the
> signing key for this SP, and the value of its use attribute MUST be
> “signing.” The other <KeyDescriptor> element MUST specify the
> encryption key for this SP, and the value of its use attribute must be
> “encryption.”"
>
> It seems that the GFIPM Cryptographic Trust Model requirements are
> based on the behavior of the previous release of the Shibboleth SP and
> not necessarily GFIPM's interpretation of the SAML 2.0 specification.
>
> Question...
>
> Does the GFIPM Cryptographic Trust Model requirements need to be fixed
> or does Shibboleth 2.4.2 no-longer meet the requirements?
>
> --
>
> Thanks,
>
> Dan McLaughlin
> Technology Consortium, LLC
> 
> http://www.tech-consortium.com
>
> NOTICE: This e-mail message and all attachments transmitted with it
> are for the sole use of the intended recipient(s) and may contain
> confidential and privileged information. Any unauthorized review, use,
> disclosure or distribution is strictly prohibited. The contents of
> this e-mail are confidential and may be subject to work product
> privileges. If you are not the intended recipient, please contact the
> sender by reply e-mail and destroy all copies of the original message.