September 2004 - Ietf-types

Pre review of 3GPP MIME type for RTP payload format
by Magnus Westerlund 28 Oct '04

28 Oct '04

Hi, I would like to have a pre registration request review of the below propsed MIME type for a RTP payload format. This registration request is intended to use the updated registration procedure based on specification available from other standards body. The specification that the registration belongs to can be found in the following 3GPP contribution: http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_32/Docs/S4-040460.zip Which is the specification delta that included the RTP payload format defined within to the following specification: http://www.3gpp.org/ftp/Specs/latest/Rel-6/26_series/26234-600.zip The registration template for this looks like the following: ------------------------------------------------------------ MIME media type name: audio, video, text, application, image MIME subtype name: rtp.enc.aescm128 Required parameters: opt: The payload type number of the payload type contained in the encrypted payload. An integer value between 0-127. rate: The timestamp rate of this payload type, which shall be the same as that of the original payload type. This is an integer value between 1 and 2^32. ContentID: The OMA DRM content ID [75] used to identify the content when establishing a crypto context. The value is an RFC 2396 [60] URI, which shall be quoted using <">. RightsIssuerURL: The right issuer URL as defined by OMA DRM [75]. The value is an URI in accordance with RFC 2396 [60], which shall be quoted using <">. IVnonce: The value of this parameter is the nonce that forms the IV as specified by the crypto transform, encoded using Base 64 [69]. Optional parameters: SelectiveEncryption: Indicates if this stream is selectively encrypted. Allowed values are 0 (false) and 1 (true). If not present, selective encryption shall not be used. Please note that unless this indicator is integrity protected, it fulfils no purpose. Encoding considerations: This type is only defined for transfer via RTP (RFC 3550). Security considerations: See considerations raised in RTP RFC 3550 [9] and any applicable profile like RFC 3551 [10] or RFC 3711 [72]. Further see 3GPP TS 26.234, Release 6, Annex K for comments on security issues. The main issues that exists are: - This RTP payload format only confidentiality protects the RTP payload, thus header information is leaked, similarly to SRTP. - The use of stream ciphers as AES CM and no integrity protection allows an attacker to purposefully attack the content of the encrypted RTP payload by switching individual bits. - The usage of selective encryption without integrity protection allows for an attacker to perform any replacements of complete RTP payloads and packets it desires. - The payload format makes the receiver vulnerable to denial of service attacks that inserts RTP packets into the stream, that the receiver then interprets as being encrypted thus wasting computational resources. To prevent this attack, authentication needs to be used. Interoperability considerations: Published specification: 3GPP TS 26.234, Release 6. Open Mobile Alliance DRM Content Format V2.0 Applications which use this media type: Third Generation Partnership Project (3GPP) Packet-switched Streaming Service (PSS) clients and servers, which supports the Open Mobile Alliance's specification of Digital Rights Management version 2.0. Additional information: Magic number(s): N/A File extension(s): N/A Macintosh File Type Code(s): N/A Person & email address to contact for further information: magnus.westerlund(a)ericsson.com Intended usage: Common Author/Change controller: 3GPP TSG SA ---- End of template --- Hope for comments within a week. Otherwise any changes within 3GPP will be more difficult. Thanks Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund(a)ericsson.com

3 6

Comments on draft-freed-media-types-reg-01.txt
by Magnus Westerlund 27 Oct '04

27 Oct '04

Hi Ned and John, I have now reviewed your document and have some comments and questions. MW1: Section 3.4: Based on all arguments I have heard about any experimental tree, they should be strongly discouraged to be used at all. The motivation, is that if one defines a experimental type in a test application. The application becomes a success, suddenly you have an deployed base of something you didn't intended to. Then trying to change the type leads to interoperability issues, and may in best case result in usage of two different names for the same type. I think it might be better to recommend that one simply uses a real type, and tries to register it as soon as possible. MW2: Section 4.2.1, third paragraph: "Beyond plain text, there are many formats for representing what might be known as "rich text". An interesting characteristic of many such representations is that they are to some extent readable even without the software that interprets them. It is useful, then, to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form. In the absence of appropriate interpretation software, it is reasonable to show subtypes of "text" to the user, while it is not reasonable to do so with most non textual data. Such formatted textual data should be represented using subtypes of "text"." When one has limited usage, like say "only for usage in RTP" I think there are need to consider some wider interpretation of what "to some extent readable" means. We had an example in the 3GPP timed text discussion, where the RTP payload format consists of embedded UTF-8 or UTF-16 strings in an otherwise binary format. However for RTP that is the common case. Should such any clarification on the performance of such consideration be written into this spec or do it belong to a further registration document in relation do a specific domain of usage? ME3: Section 4.3: Parameters only applicable to a specific domain of usage? Certain types will be (are) registered for several domain of usage, however the different domain may require that different parameters are used. I can give you an example in RFC 3267 that has quite many parameters for RTP usage, but none for the file format. How is it supposed to be indicated that this is the case? MW4: Section 4.3: Syntax rules for parameters? I think the syntax (ABNF) definition of the parameter values need to be properly defined. Otherwise it is hard to make any assumption about what is potential to be used in protocols. I think it also needs to take the current used protocols like, mail, HTTP, SDP into account. MW5: Section 4.9: I think the draft hints in section 4.2 that with certain limited usage, another document may further define how the media types should be treated, and what to think of. However I think it might be worth being a bit more clear on what such a document should do. In addition to defining any further restrictions on registration, I think it should define a "name" for this application to be used in the "Restriction on Usage" heading in the template. MW6: I think further clarification on the coupling between the "intended usage" and the "Restriction on usage" is needed. For example, is one allowed to use "Common" when the restriction of usage says: Only for use in RTP? And is the classification of what is common, limited usage, or obsolete depending on the domain? MW7: Section 10: Actually I find the labeling of "Author/Change controller:" a bit confusing. In my view there can be a big difference between Author and Change controller. For example in my proposed registration of audio/rtp.enc.aescm128 where I am the author and the direct recipient of any comments at the initial stage. However the change control over this type belongs to 3GPP. And although the contact person exist, that might be even a third entity in some cases. Might it not be wise to split them into separate cases to clarify this? Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund(a)ericsson.com

6 20

Minor error in CCXML media type registration.
by Chris Lilley 29 Sep '04

29 Sep '04

Hello www-voice, In Appendix I - CCXML Media Type http://www.w3.org/TR/2004/WD-ccxml-20040430/#ccxml-mime-definition the sentence >> Several CCXML instructions may cause arbitrary URIs to be referenced. >> In this case, the security issues of RFC1738, section 6, should be >> considered. should instead reference RFC 2396, section 7 which updates (and largely replaces) RFC 1738. 2396 is itself being updated, but is not yet an RFC. http://www.ietf.org/rfc/rfc2396.txt http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group Member, W3C Technical Architecture Group

1 0

MIME registration for application/gdiff
by Lisa Dusseault 24 Sep '04

24 Sep '04

I'm trying to register a MIME type officially for application/gdiff. This type was defined in a W3C NOTE several years ago: <http://www.w3.org/TR/NOTE-gdiff-19970901> That Note defines the MIME type but apparently the authors never registered the MIME type with IANA. Now we'd like to use gdiff in applications where we'd be using the MIME type so having it officially registered would be nice. For example in: <http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-05.txt> I submitted the registration through the IANA web form six weeks ago but haven't gotten a response other than the automated form submission response. Is this smoothly underway or is there anything else I need to or can optionally do to help this registration out? Is there anywhere to see the status of requests? Thanks, Lisa Dusseault PS I had to subscribe to this list to get my posting accepted -- I first sent this message in August but it disappeared into a black hole. Lisa

3 2

for review: draft -02 of application/samlmetadata+xml registration
by Jeff.Hodges＠KingsMountain.com 21 Sep '04

21 Sep '04

this rev of the application/samlmetadata+xml reflects the enhancements recently suggested by Martin & Graham. thanks, JeffH Registration of MIME media type application/samlmetadata+xml <@@NOTE: This document is: sstc-saml-2.0-application-samlmetadata-registration-02 Jeff Hodges <Jeff.Hodges(a)Sun.com> 21-Sep-2004 This document is intended to be included in sstc-saml-metadata-2.0-cd-02 [SAMLv2Meta] (ie the next time it is rev'd), as an appendix. Please see http://www.w3.org/2002/06/registering-mediatype.html for an overview of the intricities involved when a non-IETF organization registers a MIME media type in the "standards tree" (aka "IETF tree"). Please also note that that doc is W3C-specific, and is only pointed to here as a source for overall information rather than normative procedures. The below registration material is intended to satisfy the requirements stated in draft-freed-media-type-reg-01.txt (which superseded draft-freed-mime-p4-04.txt). This "NOTE" is intended to be removed upon copying this document's content into [SAMLv2Meta]. Acknowledgments: Thanks to Ned Freed, Larry Masinter, Graham Klyne, and Chris Lilley for their comments on prior drafts of this registration. The security considerations section leverages that of http://www.iana.org/assignments/media-types/application/vnd.paos+xml, by John Kemp. > To: ietf-types(a)iana.org Subject: Registration of MIME media type application/samlmetadata+xml Introduction This document defines a MIME media type -- application/samlmetadata+xml -- for use with the XML serialization of Security Assertion Markup Language metadata. SAML is a work product of the OASIS Security Services Technical Committee [SSTC]. The SAML specifications define XML-based constructs with which one may make, and convey, security assertions. Using SAML, one can assert that an authentication event pertaining to some subject has occurred and convey said assertion to a relying party, for example. SAML profiles require agreements between system entities regarding identifiers, binding support, endpoints, certificates, keys, and so forth. Such information is treated as metadata by SAML v2.0. [SAMLv2Meta] specifies this metadata, as well as specifying metadata publication and resolution mechanisms. If the publishing protocol permits MIME-based identification of content types, then use of the application/samlmetadata+xml MIME media type is required. MIME media type name: application MIME subtype name: samlmetadata+xml Required parameters: none Optional parameters: charset Same as charset parameter of application/xml [RFC3023]. Encoding considerations: Same as for application/xml [RFC3023]. Security considerations: Per their specification, samlmetadata+xml typed objects do not contain executable content. However, these objects are XML-based [XML], and thus they have all of the general security considerations presented in section 10 of [RFC3023]. SAML metadata [SAMLv2Meta] contains information whose integrity and authenticity is important identity provider and service provider public keys and endpoint addresses, for example. To counter potential issues, the publisher may sign samlmetadata+xml typed objects. Any such signature should be verified by the recipient of the data - both as a valid signature, and as being the signature of the publisher. Additionally, various of the publication protocols, e.g. HTTP-over-TLS/SSL, offer means for ensuring the authenticity of the publishing party and for protecting the metadata in transit. [SAMLv2Meta] also defines prescriptive metadata caching directives, as well as guidance on handling HTTPS redirects, trust processing, server authentication, and related items. For a more detailed discussion of SAML v2.0 metadata and its security considerations, please see [SAMLv2Meta]. For a discussion of overall SAML v2.0 security considerations and specific security-related design features, please refer to the SAML v2.0 specifications listed in the below bibliography. The specifications containing security-specific information are explicitly listed. Interoperability considerations: SAML v2.0 metadata explicitly supports identifying the protocols and versions supported by the identified entities. For example, an identity provider entity can be denoted as supporting SAML v2.0, SAML v1.1 [SAMLv1.1], Liberty ID-FF 1.2 [LAPFF], or even other protocols if they are unambiguously identifiable via URI [RFC2396]. This protocol support information is conveyed via the protocolSupportEnumeration attribute of metadata objects of the RoleDescriptorType. Published specification: [SAMLv2Meta] explicitly specifies use of the application/samlmetadata+xml MIME media type. Applications which use this media type: Potentially any application implementing SAML v2.0, as well as those applications implementing specifications based on SAML, e.g. those available from the Liberty Alliance [LAP]. Additional information: Magic number(s): In general, the same as for application/xml [RFC3023]. In particular, the XML root element of the returned object will have a namespace-qualified name with: - a local name of: EntityDescriptor, or AffiliationDescriptor, or EntitiesDescriptor - a namespace URI of: urn:oasis:names:tc:SAML:2.0:metadata (the SAMLv2.0 metadata namespace) File extension(s): none Macintosh File Type Code(s): none Person & email address to contact for further information: This registration is made on behalf of the OASIS Security Services Technical Committee (SSTC) Please refer to the SSTC website for current information on committee chairperson(s) and their contact addresses: http://www.oasis-open.org/committees/security/. Committee members should submit comments and potential errata to the securityservices(a)lists.oasis-open.org list. Others should submit them by filling out the web form located at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev= Additionally, the SAML developer community email distribution list, saml-dev(a)lists.oasis-open.org, may be employed to discuss usage of the application/samlmetadata+xml MIME media type. The "saml-dev" mailing list is publicly archived here: http://lists.oasis-open.org/archives/saml-dev/. To post to the "saml-dev" mailing list, one must subscribe to it. To subscribe, send a message with the single word "subscribe" in the message body, to: saml-dev-request(a)lists.oasis-open.org. Intended usage: COMMON Author/Change controller: The SAML specification sets are a work product of the OASIS Security Services Technical Committee (SSTC). OASIS and the SSTC have change control over the SAML specification sets. Bibliography [LAP] "Liberty Alliance Project". See http://www.projectliberty.org/ [LAPFF] "Liberty Alliance Project: Federation Framework". See http://www.projectliberty.org/resources/specificat [OASIS] "Organization for the Advancement of Structured Information Systems". See http://www.oasis-open.org/ [RFC2396] T. Berners-Lee, R. Fielding, L. Masinter, Uniform Resource Identifiers (URI): Generic Syntax. IETF RFC 2396, August 1998. Available at http://www.ietf.org/rfc/rfc2396.txt [RFC3023] M. Murata, S. St.Laurent, D. Kohn, "XML Media Types", IETF Request for Comments 3023, January 2001. Available as http://www.rfc-editor.org/rfc/rfc3023.txt [SAMLv1.1] OASIS Security Services Technical Committee, "Security Assertion Markup Language (SAML) Version 1.1 Specification Set". OASIS Standard 200308, August 2003. Available as http://www.oasis-open.org/committees/download.php /3400/oasis-sstc-saml-1.1-pdf-xsd.zip [SAMLv2.0] OASIS Security Services Technical Committee, "Security Assertion Markup Language (SAML) Version 2.0 Specification Set". WORK IN PROGRESS. Available at http://www.oasis-open.org/committees/security/ [SAMLv2Bind] S. Cantor et al., "Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004. Document ID sstc-saml-bindings-2.0-cd-01, WORK IN PROGRESS. See http://www.oasis-open.org/committees/security/ [SAMLv2Core] S. Cantor et al., "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004. Document ID sstc-saml-core-2.0-cd-01, WORK IN PROGRESS. See http://www.oasis-open.org/committees/security/ [SAMLv2Meta] S. Cantor et al., Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0. OASIS SSTC, August 2004. Document ID sstc-saml-metadata-2.0-cd-01. See http://www.oasis-open.org/committees/security/ [SAMLv2Prof] S. Cantor et al., "Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004. Document ID sstc-saml-profiles-2.0-cd-01, WORK IN PROGRESS. See http://www.oasis-open.org/committees/security/ [SAMLv2Sec] F. Hirsch et al., "Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004, WORK IN PROGRESS. Document ID sstc-saml-sec-consider-2.0-cd-01. See http://www.oasis-open.org/committees/security/ [SSTC] "OASIS Security Services Technical Committee". See http://www.oasis-open.org/committees/security/ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C.M. and E. Maler, François Yergeau, "Extensible Markup Language (XML) 1.0 (Third Edition)", World Wide Web Consortium Recommendation REC-xml, Feb 2004, Available as http://www.w3.org/TR/REC-xml/ --- end

1 0

for review: draft -03 of application/samlassertion+xml registration
by Jeff.Hodges＠KingsMountain.com 21 Sep '04

21 Sep '04

this rev of the application/samlassertion+xml reflects the enhancements recently suggested by Martin & Graham. thanks, JeffH Registration of MIME media type application/samlassertion+xml <@@NOTE: This document is: sstc-saml-2.0-application-samlassertion-registration-03 Jeff Hodges <Jeff.Hodges(a)Sun.com> 21-Sep-2004 This document supersedes draft-hodges-saml-mediatype-02.txt. It is intended to be included in sstc-saml-bindings-2.0-cd-02 (ie the next time [SAMLv2Bind] is rev'd), as an appendix. Please see http://www.w3.org/2002/06/registering-mediatype.html for an overview of the intricities involved when a non-IETF organization registers a MIME media type in the "standards tree" (aka "IETF tree"). Please also note that that doc is W3C-specific, and is only pointed to here as a source for overall information rather than normative procedures. The below registration material is intended to satisfy the requirements stated in draft-freed-media-type-reg-01.txt (which superseded draft-freed-mime-p4-04.txt). This "NOTE" is intended to be removed upon copying this document's content into [SAMLv2Bind]. Acknowledgments: Thanks to Ned Freed, Larry Masinter, Graham Klyne, and Chris Lilley for their comments on prior drafts of this registration. The security considerations section leverages that of http://www.iana.org/assignments/media-types/application/vnd.paos+xml, by John Kemp. > To: ietf-types(a)iana.org Subject: Registration of MIME media type application/samlassertion+xml Introduction This document defines a MIME media type -- application/samlassertion+xml -- for use with the XML serialization of SAML (Security Assertion Markup Language) assertions. The SAML specification sets -- [SAMLv1.0], [SAMLv1.1], [SAMLv2.0] -- are work products of the OASIS Security Services Technical Committee [SSTC]. The SAML specifications define XML-based constructs with which one may make, and convey, security assertions. Using SAML, one can assert that an authentication event pertaining to some subject has occured and convey said assertion to a relying party, for example. SAML assertions, which are explicitly versioned, are defined by [SAMLv1Core], [SAMLv11Core], and [SAMLv2Core]. MIME media type name: application MIME subtype name: samlassertion+xml Required parameters: none Optional parameters: charset Same as charset parameter of application/xml [RFC3023]. Encoding considerations: Same as for application/xml [RFC3023]. Security considerations: Per their specification, samlassertion+xml typed objects do not contain executable content. However, SAML assertions are XML-based objects [XML]. As such, they have all of the general security considerations presented in section 10 of [RFC3023], as well as additional ones, since they are explicit security objects. For example, samlassertion+xml typed objects will often contain data that may identify or pertain to a natural person, and may be used as a basis for sessions and access control decisions. To counter potential issues, samlassertion+xml typed objects contain data that should be signed appropriately by the sender. Any such signature must be verified by the recipient of the data - both as a valid signature, and as being the signature of the sender. Issuers of samlassertion+xml objects containing SAMLv2 assertions may also encrypt all, or portions of, the assertions [SAMLv2Core]. In addition, SAML profiles and protocol bindings specify use of secure channels as appropriate. [SAMLv2.0] incorporates various privacy-protection techniques in its design. For example: opaque handles, specific to interactions between specific system entities, may be assigned to subjects. The handles are mappable to wider-context identifiers (e.g. email addresses, account identifiers, etc) by only the specific parties. For a more detailed discussion of SAML security considerations and specific security-related design techniques, please refer to the SAML specifications listed in the below bibliography. The specifications containing security-specific information have been explicitly listed for each version of SAML. Interoperability considerations: SAML assertions are explicitly versioned. Relying parties should ensure that they observe assertion version information and behave accordingly. See "Chapter 4 SAML Versioning" in [SAMLv1Core], [SAMLv11Core], or [SAMLv2Core], as appropriate. Published specification: [SAMLv2Bind] explicitly specifies use of the application/samlassertion+xml MIME media type. However, it is conceivable that non-SAMLv2 assertions (i.e. SAMLv1 and/or SAMLv1.1) might in practice be conveyed using SAMLv2 bindings. Applications which use this media type: Potentially any application implementing SAML, as well as those applications implementing specifications based on SAML, e.g. those available from the Liberty Alliance [LAP]. Additional information: Magic number(s): In general, the same as for application/xml [RFC3023]. In particular, the XML root element of the returned object will have a namespace-qualified name with: - a local name of: Assertion - a namespace URI of: one of the version-specific SAML assertion XML namespace URIs, as defined by the appropriate version-specific SAML "core" specification (see bibliography). With SAMLv2.0 specifically, the root element of the returned object may be either <saml:Assertion> or <saml:EncryptedAssertion>,where "saml" represents any XML namespace prefix that maps to the SAMLv2.0 assertion namespace URI: urn:oasis:names:tc:SAML:2.0:assertion File extension(s): none Macintosh File Type Code(s): none Person & email address to contact for further information: This registration is made on behalf of the OASIS Security Services Technical Committee (SSTC) Please refer to the SSTC website for current information on committee chairperson(s) and their contact addresses: http://www.oasis-open.org/committees/security/. Committee members should submit comments and potential errata to the securityservices(a)lists.oasis-open.org list. Others should submit them by filling out the web form located at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev= Additionally, the SAML developer community email distribution list, saml-dev(a)lists.oasis-open.org, may be employed to discuss usage of the application/samlassertion+xml MIME media type. The "saml-dev" mailing list is publicly archived here: http://lists.oasis-open.org/archives/saml-dev/. To post to the "saml-dev" mailing list, one must subscribe to it. To subscribe, send a message with the single word "subscribe" in the message body, to: saml-dev-request(a)lists.oasis-open.org. Intended usage: COMMON Author/Change controller: The SAML specification sets are a work product of the OASIS Security Services Technical Committee (SSTC). OASIS and the SSTC have change control over the SAML specification sets. Bibliography [LAP] "Liberty Alliance Project". See http://www.projectliberty.org/ [OASIS] "Organization for the Advancement of Structured Information Systems". See http://www.oasis-open.org/ [RFC3023] M. Murata, S. St.Laurent, D. Kohn, "XML Media Types", IETF Request for Comments 3023, January 2001. Available as http://www.rfc-editor.org/rfc/rfc3023.txt [SAMLv1.0] OASIS Security Services Technical Committee, "Security Assertion Markup Language (SAML) Version 1.0 Specification Set". OASIS Standard 200205, November 2002. Available as http://www.oasis-open.org/committees/download.php /2290/oasis-sstc-saml-1.0.zip [SAMLv1Bind] Prateek Mishra et al., "Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML)", OASIS, November 2002. Document ID oasis-sstc-saml-bindings-1.0. See http://www.oasis-open.org/committees/security/ [SAMLv1Core] Phillip Hallam-Baker et al., "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML)", OASIS, November 2002. Document ID oasis-sstc-saml-core-1.0. See http://www.oasis-open.org/committees/security/ [SAMLv1Sec] Chris McLaren et al., "Security Considerations for the OASIS Security Assertion Markup Language (SAML)", OASIS, November 2002. Document ID oasis-sstc-saml-sec-consider-1.0. See http://www.oasis-open.org/committees/security/ [SAMLv1.1] OASIS Security Services Technical Committee, "Security Assertion Markup Language (SAML) Version 1.1 Specification Set". OASIS Standard 200308, August 2003. Available as http://www.oasis-open.org/committees/download.php /3400/oasis-sstc-saml-1.1-pdf-xsd.zip [SAMLv11Bind] E. Maler et al. "Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML)". OASIS, September 2003. Document ID oasis-sstc-saml-bindings-1.1. http://www.oasis-open.org/committees/security/ [SAMLv11Core] E. Maler et al. "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML)". OASIS, September 2003. Document ID oasis-sstc-saml-core-1.1. http://www.oasis-open.org/committees/security/ [SAMLv11Sec] E. Maler et al. "Security Considerations for the OASIS Security Assertion Markup Language (SAML)". OASIS, September 2003. Document ID oasis-sstc-saml-sec-consider-1.1. http://www.oasis-open.org/committees/security/ [SAMLv2.0] OASIS Security Services Technical Committee, "Security Assertion Markup Language (SAML) Version 2.0 Specification Set". WORK IN PROGRESS. Available at http://www.oasis-open.org/committees/security/ [SAMLv2Bind] S. Cantor et al., "Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004. Document ID sstc-saml-bindings-2.0-cd-01, WORK IN PROGRESS. See http://www.oasis-open.org/committees/security/ [SAMLv2Core] S. Cantor et al., "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004. Document ID sstc-saml-core-2.0-cd-01, WORK IN PROGRESS. See http://www.oasis-open.org/committees/security/ [SAMLv2Prof] S. Cantor et al., "Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004. Document ID sstc-saml-profiles-2.0-cd-01, WORK IN PROGRESS. See http://www.oasis-open.org/committees/security/ [SAMLv2Sec] F. Hirsch et al., "Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004, WORK IN PROGRESS. Document ID sstc-saml-sec-consider-2.0-cd-01. See http://www.oasis-open.org/committees/security/ [SSTC] "OASIS Security Services Technical Committee". See http://www.oasis-open.org/committees/security/ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C.M. and E. Maler, François Yergeau, "Extensible Markup Language (XML) 1.0 (Third Edition)", World Wide Web Consortium Recommendation REC-xml, Feb 2004, Available as http://www.w3.org/TR/REC-xml/ --- end

1 0

Re: Please review: DRAFT Reg of application/samlassertion+xml
by Jeff.Hodges＠KingsMountain.com 21 Sep '04

21 Sep '04

> At 09:28 20/09/04 -0700, Jeff.Hodges(a)KingsMountain.com wrote: > >Ok, how about this... > > > > > >Magic number(s): > > In general, the same as for application/xml [RFC3023]. In > > particular, the XML root element of the returned object will be > > <Assertion>, and will be in one of the version-specific SAML > > assertion XML namespaces, as defined by the appropriate version- > > specific SAML "core" specification (see bibliography). > > > > With SAMLv2.0 specifically, the root element of the returned > > object may be either <saml:Assertion> or <saml:EncryptedAssertion>, > > where "saml" represents any XML namspace prefix that maps to the > > SAMLv2.0 assertion namespace URI: > > > > urn:oasis:names:tc:SAML:2.0:assertion. > > I think the intent here is pretty clear and correct, but I find myself > fretting a little at the wording in case of possible misunderstanding, so > here's my suggestion for the 1st para: > > [[ > Magic number(s): > In general, the same as for application/xml [RFC3023]. In > particular, the XML root element of the returned object will > have a namespace-qualified name with: > - local name: Assertion > - namespace URI: one of the version-specific SAML assertion > XML namespace URIs, as defined by the appropriate version- > specific SAML "core" specification (see bibliography). > ]] > > I'm not sure that this is better; mainly, I aimed to avoid the (very > slight) implication that the root element would always be introduced > by the literal <Assertion>. In any case, your 2nd paragraph makes the > situation clear, so use or ignore my thoughts as you see fit. ScottC and I chatted about this and feel yer right and it's worth it to express it as you have above. So thanks again for the salient comments. a rev of both reg's incorp'g the above will be forthcoming. JeffH

1 0

Re: for review: draft -01 of application/samlmetadata+xml registration
by Jeff.Hodges＠KingsMountain.com 21 Sep '04

21 Sep '04

> There is now a third edition of XML. The reference section > should be updated. good catch, thanks. > >Please see http://www.w3.org/2002/06/registering-mediatype.html > >for an overview of the intricities involved when a non-IETF organization > >registers a MIME media type in the "standards tree" (aka "IETF > >tree"). > > Again, this document only applies to media types from W3C. however, I think it's worthwhile for one from any non-ietf SDO to take a look at (u guys did a good job on it). So i've added an extra admonishment to the preface NOTE wrt this. Also note that the preface NOTE won't be sent to the iesg (unless someone thinks it'd add value to that submission), and the preface NOTE will be deleted when the reg's are copied into our (OASIS SSTC SAML) specs. thanks, JeffH

1 0

Re: Please review: DRAFT Reg of application/samlassertion+xml
by Jeff.Hodges＠KingsMountain.com 21 Sep '04

21 Sep '04

> On Monday, September 20, 2004, 12:23:33 PM, Graham wrote: > > GK> That wording looks OK to me. > > GK> One additional point to consider, but I think it's marginal: the case when > GK> the default namespace is a SAML namespace. (In practice, I think anyone > GK> who knows enough about XML to use this stuff will understand that case is > GK> implied, but maybe it's better to be explicit.) > > I agree (especially in a section on magic numbers and by extension, > magic strings) its better to avoid any mention of potentially magical > prefixes in the registration document. > > Just state the URI of the namespace or namespaces. Since this is a +xml > type, its okay to assume that an XML processor is being used rather than > plain text regexps and so on. State the element local name and its > namespace, and you are all set. > Ok, how about this... Magic number(s): In general, the same as for application/xml [RFC3023]. In particular, the XML root element of the returned object will be <Assertion>, and will be in one of the version-specific SAML assertion XML namespaces, as defined by the appropriate version- specific SAML "core" specification (see bibliography). With SAMLv2.0 specifically, the root element of the returned object may be either <saml:Assertion> or <saml:EncryptedAssertion>, where "saml" represents any XML namspace prefix that maps to the SAMLv2.0 assertion namespace URI: urn:oasis:names:tc:SAML:2.0:assertion. JeffH

3 2

for review: draft -01 of application/samlmetadata+xml registration
by Jeff.Hodges＠KingsMountain.com 21 Sep '04

21 Sep '04

Registration of MIME media type application/samlmetadata+xml <@@NOTE: This document is: sstc-saml-2.0-application-samlmetadata-registration-01 Jeff Hodges <Jeff.Hodges(a)Sun.com> 20-Sep-2004 This document is intended to be included in sstc-saml-metadata-2.0-cd-02 (ie the next time [SAMLv2Meta] is rev'd), as an appendix. Please see http://www.w3.org/2002/06/registering-mediatype.html for an overview of the intricities involved when a non-IETF organization registers a MIME media type in the "standards tree" (aka "IETF tree"). The below registration material is intended to satisfy the requirements stated in draft-freed-media-type-reg-01.txt (which superseded draft-freed-mime-p4-04.txt). This "NOTE" is intended to be removed upon copying this document's content into [SAMLv2Meta]. Acknowledgments: Thanks to Ned Freed, Larry Masinter, Graham Klyne, and Chris Lilley for their comments on prior drafts of this registration. The security considerations section leverages that of http://www.iana.org/assignments/media-types/application/vnd.paos+xml, by John Kemp. > To: ietf-types(a)iana.org Subject: Registration of MIME media type application/samlmetadata+xml Introduction This document defines a MIME media type -- application/samlmetadata+xml -- for use with the XML serialization of Security Assertion Markup Language metadata. SAML is a work product of the OASIS Security Services Technical Committee [SSTC]. The SAML specifications define XML-based constructs with which one may make, and convey, security assertions. Using SAML, one can assert that an authentication event pertaining to some subject has occurred and convey said assertion to a relying party, for example. SAML profiles require agreements between system entities regarding identifiers, binding support, endpoints, certificates, keys, and so forth. Such information is treated as metadata by SAML v2.0. [SAMLv2Meta] specifies this metadata, as well as specifying metadata publication and resolution mechanisms. If the publishing protocol permits MIME-based identification of content types, then use of the application/samlmetadata+xml MIME media type is required. MIME media type name: application MIME subtype name: samlmetadata+xml Required parameters: none Optional parameters: charset Same as charset parameter of application/xml [RFC3023]. Encoding considerations: Same as for application/xml [RFC3023]. Security considerations: Per their specification, samlmetadata+xml typed objects do not contain executable content. However, these objects are XML-based [XML], and thus they have all of the general security considerations presented in section 10 of [RFC3023]. SAML metadata [SAMLv2Meta] contains information whose integrity and authenticity is important identity provider and service provider public keys and endpoint addresses, for example. To counter potential issues, the publisher may sign samlmetadata+xml typed objects. Any such signature should be verified by the recipient of the data - both as a valid signature, and as being the signature of the publisher. Additionally, various of the publication protocols, e.g. HTTP-over-TLS/SSL, offer means for ensuring the authenticity of the publishing party and for protecting the metadata in transit. [SAMLv2Meta] also defines prescriptive metadata caching directives, as well as guidance on handling HTTPS redirects, trust processing, server authentication, and related items. For a more detailed discussion of SAML v2.0 metadata and its security considerations, please see [SAMLv2Meta]. For a discussion of overall SAML v2.0 security considerations and specific security-related design features, please refer to the SAML v2.0 specifications listed in the below bibliography. The specifications containing security-specific information are explicitly listed. Interoperability considerations: SAML v2.0 metadata explicitly supports identifying the protocols and versions supported by the identified entities. For example, an identity provider entity can be denoted as supporting SAML v2.0, SAML v1.1 [SAMLv1.1], Liberty ID-FF 1.2 [LAPFF], or even other protocols if they are unambiguously identifiable via URI [RFC2396]. This protocol support information is conveyed via the protocolSupportEnumeration attribute of metadata objects of the RoleDescriptorType. Published specification: [SAMLv2Meta] explicitly specifies use of the application/samlmetadata+xml MIME media type. Applications which use this media type: Potentially any application implementing SAML v2.0, as well as those applications implementing specifications based on SAML, e.g. those available from the Liberty Alliance [LAP]. Additional information: Magic number(s): In general, the same as for application/xml [RFC3023]. In particular, the XML root element of the returned object will be one of <EntityDescriptor>, <AffiliationDescriptor>, or <EntitiesDescriptor>, and will be in the SAMLv2.0 metadata namespace: urn:oasis:names:tc:SAML:2.0:metadata File extension(s): none Macintosh File Type Code(s): none Person & email address to contact for further information: This registration is made on behalf of the OASIS Security Services Technical Committee (SSTC) Please refer to the SSTC website for current information on committee chairperson(s) and their contact addresses: http://www.oasis-open.org/committees/security/. Committee members should submit comments and potential errata to the securityservices(a)lists.oasis-open.org list. Others should submit them by filling out the web form located at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev= Additionally, the SAML developer community email distribution list, saml-dev(a)lists.oasis-open.org, may be employed to discuss usage of the application/samlmetadata+xml MIME media type. The "saml-dev" mailing list is publicly archived here: http://lists.oasis-open.org/archives/saml-dev/. To post to the "saml-dev" mailing list, one must subscribe to it. To subscribe, send a message with the single word "subscribe" in the message body, to: saml-dev-request(a)lists.oasis-open.org. Intended usage: COMMON Author/Change controller: The SAML specification sets are a work product of the OASIS Security Services Technical Committee (SSTC). OASIS and the SSTC have change control over the SAML specification sets. Bibliography [LAP] "Liberty Alliance Project". See http://www.projectliberty.org/ [LAPFF] Liberty Alliance Project: Federation Framework". See http://www.projectliberty.org/resources /specifications.php#box1 [OASIS] " Organization for the Advancement of Structured Information Systems". See http://www.oasis-open.org/ [RFC2396] T. Berners-Lee, R. Fielding, L. Masinter, Uniform Resource Identifiers (URI): Generic Syntax. IETF RFC 2396, August 1998. Available at http://www.ietf.org/rfc/rfc2396.txt [RFC3023] M. Murata, S. St.Laurent, D. Kohn, "XML Media Types", IETF Request for Comments 3023, January 2001. Available as http://www.rfc-editor.org/rfc/rfc3023.txt [SAMLv1.1] OASIS Security Services Technical Committee, "Security Assertion Markup Language (SAML) Version 1.1 Specification Set". OASIS Standard 200308, August 2003. Available as http://www.oasis-open.org/committees/download.php /3400/oasis-sstc-saml-1.1-pdf-xsd.zip [SAMLv2.0] OASIS Security Services Technical Committee, "Security Assertion Markup Language (SAML) Version 2.0 Specification Set". WORK IN PROGRESS. Available at http://www.oasis-open.org/committees/security/ [SAMLv2Bind] S. Cantor et al., "Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004. Document ID sstc-saml-bindings-2.0-cd-01, WORK IN PROGRESS. See http://www.oasis-open.org/committees/security/ [SAMLv2Core] S. Cantor et al., "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004. Document ID sstc-saml-core-2.0-cd-01, WORK IN PROGRESS. See http://www.oasis-open.org/committees/security/ [SAMLv2Meta] S. Cantor et al., Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0. OASIS SSTC, August 2004. Document ID sstc-saml-metadata-2.0-cd-01. See http://www.oasis-open.org/committees/security/ [SAMLv2Prof] S. Cantor et al., "Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004. Document ID sstc-saml-profiles-2.0-cd-01, WORK IN PROGRESS. See http://www.oasis-open.org/committees/security/ [SAMLv2Sec] F. Hirsch et al., "Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004, WORK IN PROGRESS. Document ID sstc-saml-sec-consider-2.0-cd-01. See http://www.oasis-open.org/committees/security/ [SSTC] "OASIS Security Services Technical Committee". See http://www.oasis-open.org/committees/security/ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C.M. and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium Recommendation REC-xml, October 2000, Available as http://www.w3.org/TR/REC-xml --- end

2 1