Shibboleth Developers

[<>]

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.