OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]