From dev-return-18670-archive-asf-public=cust-asf.ponee.io@ws.apache.org Mon Jul 1 08:42:02 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 3BCB8180670 for ; Mon, 1 Jul 2019 10:42:02 +0200 (CEST) Received: (qmail 56782 invoked by uid 500); 1 Jul 2019 08:42:01 -0000 Mailing-List: contact dev-help@ws.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ws.apache.org Delivered-To: mailing list dev@ws.apache.org Received: (qmail 56770 invoked by uid 99); 1 Jul 2019 08:42:01 -0000 Received: from mailrelay1-us-west.apache.org (HELO mailrelay1-us-west.apache.org) (209.188.14.139) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Jul 2019 08:42:01 +0000 Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 68208E0DDB for ; Mon, 1 Jul 2019 08:42:00 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 27CBA25FF9 for ; Mon, 1 Jul 2019 08:42:00 +0000 (UTC) Date: Mon, 1 Jul 2019 08:42:00 +0000 (UTC) From: "Colm O hEigeartaigh (JIRA)" To: dev@ws.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (WSS-652) MTOM Content-Id handling doesn't comply with RFC2392: .NET issues MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/WSS-652?page=3Dcom.atlassian.ji= ra.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1687601= 6#comment-16876016 ]=20 Colm O hEigeartaigh commented on WSS-652: ----------------------------------------- Yes, I just deployed a new SNAPSHOT, e.g.: =C2=A0 [https://repository.apache.org/content/groups/snapshots/org/apache/wss4j/ws= s4j-ws-security-dom/2.2.4-SNAPSHOT/] =C2=A0 Note that WSS4J depends on a SNAPSHOT version of XML Security as well at th= e moment, I deployed that SNAPSHOT too. > MTOM Content-Id handling doesn't comply with RFC2392: .NET issues > ----------------------------------------------------------------- > > Key: WSS-652 > URL: https://issues.apache.org/jira/browse/WSS-652 > Project: WSS4J > Issue Type: Bug > Affects Versions: 2.2.3 > Reporter: Mike M. > Assignee: Colm O hEigeartaigh > Priority: Blocker > Fix For: 2.3.0, 2.2.4 > > > We found an issue when a CXF server is being called from a .NET client wi= th WebService Security and MTOM in place. The relevant part of the stack tr= ace looks like this: > {code} > Caused by: org.apache.wss4j.common.ext.WSSecurityException: Attachment no= t found > at org.apache.wss4j.dom.util.EncryptionUtils.decryptEncryptedData= (EncryptionUtils.java:215) > at org.apache.wss4j.dom.processor.EncryptedKeyProcessor.decryptDa= taRef(EncryptedKeyProcessor.java:602) > at org.apache.wss4j.dom.processor.EncryptedKeyProcessor.decryptDa= taRefs(EncryptedKeyProcessor.java:533) > at org.apache.wss4j.dom.processor.EncryptedKeyProcessor.handleTok= en(EncryptedKeyProcessor.java:232) > at org.apache.wss4j.dom.processor.EncryptedKeyProcessor.handleTok= en(EncryptedKeyProcessor.java:90) > at org.apache.wss4j.dom.engine.WSSecurityEngine.processSecurityHe= ader(WSSecurityEngine.java:340) > at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMess= ageInternal(WSS4JInInterceptor.java:320) > ... 54 common frames omitted > Caused by: org.apache.wss4j.common.ext.WSSecurityException: Attachment no= t found > at org.apache.wss4j.dom.util.EncryptionUtils.decryptXopAttachment= (EncryptionUtils.java:376) > at org.apache.wss4j.dom.util.EncryptionUtils.decryptEncryptedData= (EncryptionUtils.java:207) > ... 60 common frames omitted > {code} > So at first, it looks like the incoming message has issues with Attachmen= t IDs. Our actual request looks like this (shortened for readability): > {code} > POST /myservice HTTP/1.1 > Host: localhost > MIME-Version:1.0 > Content-Type:multipart/related; type=3D"application/xop+xml";start=3D"";boundary=3D"uuid:fad7c6a9-85d1-498b-a456-748c87de4d7d+= id=3D1";start-info=3D"text/xml" > --uuid:fad7c6a9-85d1-498b-a456-748c87de4d7d+id=3D1 > Content-ID: > Content-Transfer-Encoding: 8bit > Content-Type: application/xop+xml;charset=3Dutf-8;type=3D"text/xml" > > > [...] > > [...] > > =09 > =09=09 > > =09 > [...] > > [...] > > > [...] > > > --uuid:fad7c6a9-85d1-498b-a456-748c87de4d7d+id=3D1 > Content-ID: > Content-Transfer-Encoding: binary > Content-Type: application/octet-stream > [...binary data...] > --uuid:fad7c6a9-85d1-498b-a456-748c87de4d7d+id=3D1-- > {code} > Now, if you compare {{}}'s {{href}} value with the {{Content= -ID}} in the attachment part header, you'll see that it is the same value, = just URL-Encoded in the former. > As weird as this may seem, It's actually specified that way in those loca= tions:=20 > https://www.w3.org/TR/xop10/#xop_href > {quote} > The href attribute information item has: > A [normalized value] which is a representation of a URI referencing the p= art of the package containing the data logically included by the [owner ele= ment] (i.e., the xop:Include element information item). The [normalized val= ue] MUST be a valid URI per the cid: URI scheme (see [RFC 2392]). In additi= on, the [normalized value] MUST be a valid lexical form of the XML Schema x= s:anyURI datatype (see [XML Schema Part 2: Datatypes Second Edition]3.2.17 = anyURI). > {quote} > https://tools.ietf.org/html/rfc2392 > {quote} > 2. The MID and CID URL Schemes > The URLs take the form > content-id =3D url-addr-spec > message-id =3D url-addr-spec > url-addr-spec =3D addr-spec ; URL encoding of RFC 822 addr-spec > cid-url =3D "cid" ":" content-id > {quote} > So the value of {{}}'s {{href}} attribute must always be URL= -Encoded. > As for the attachment part header, RFC2392 specifies the following: > {quote} > A "cid" URL is converted to the corresponding Content-ID message > header [MIME] by removing the "cid:" prefix, converting the % encoded > character to their equivalent US-ASCII characters, and enclosing the > remaining parts with an angle bracket pair, "<" and ">". > Reversing the process and converting URL special characters to their > % encodings produces the original cid. > {quote} > It looks to us as if CXF didn't take that URL-Encoding from the Specifica= tions into account when looking up MIME Attachments. > When I tried to reproduce the issue by forcing some special characters (i= n the form of a prepended "http://") into the generated Attachement-ID in {= {org.apache.xml.security.stax.impl.util.IDGenerator}}, it became apparent t= hat when CXF generates those Attachement-IDs, it doesn't take the URL Encod= ing into account either. It generated: > {code} > > [...] > Content-ID: > {code} > ... which violates the spec imho as {{}}'s {{href}} contains= non-URL-Encoded characters. > That last bit (CXF generating messages) wouldn't be too much of an issue = to me personally, but CXF failing with what appears to be Spec-Compliant me= ssages must be considered a bug imho. > To reiterate: this issue prevents CXF from being compatible with the .NET= SOAP / WebService Security stack and is a blocker for us. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org For additional commands, e-mail: dev-help@ws.apache.org