[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Metadata errata items
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]