W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2005

Re: Further XML-SIG errata?

From: Tommy Lindberg <tommy.lindberg@gmail.com>
Date: Thu, 7 Apr 2005 12:07:50 +0100
Message-ID: <18ec59cc050407040773d437a9@mail.gmail.com>
To: Joseph Reagle <reagle@w3.org>
Cc: jose.kahan@w3.org, w3c-ietf-xmldsig@w3.org

I think Jose may be referring to an issue I raised in the XKMS working
group some time ago:
http://www.w3.org/2001/XKMS/Drafts/cr-issues/issues.html#332-tl2. 
Although XKMS is mentioned throughout, this is an XMLSIG issue.

I have implemented the PGP related features of XMLSIG.  I needed this
for my application - an implementation of XKMS.  The problem I ran
into was that of interpreting section 4.4.5 in XMLSIG - unambigously. 
It seems to exclude the use of any other PGP packet type than Key
Material Packets in an PGPKeyPacket element.  This makes it only
marginally more useful than a ds:KeyValue (for asymmetric algorithms
supported by both XMLSIG and PGP) the only advantage beeing the PGP
format/encoding/decoration .

More to the point, an XKMS client that is performing trust management
itself, rather than delegating it to an XKMS responder would be well
served if PGP SignaturePacket's and TrustPacket's were also allowed.

The current wording of section 4.4.5 also allows for secret key
packets in a <PGPKeyPacket> which is probably not desirable.

Perhaps one thing that could be done would be to explicitly document
all PGP packet types that can be used as content in a <PGPKeyPacket>
element.  It may of course be more descriptive to have additional
elements to carry the additional PGP packets, but I can't assess if
that is meaningful with respect to processing.

Regards,
Tommy

On Apr 1, 2005 4:19 PM, Joseph Reagle <reagle@w3.org> wrote:
> 
> On Wednesday 30 March 2005 09:44, Jose Kahan wrote:
> > For SHA-1, can this be done just with errata or do we need
> > to do a new edition of the spec?
> 
> This is a serious problem, but I don't think this is a mistake of the
> specification itself, or should be substantively addressed in the errata
> document. We could pointed out as an informational item, though I expect
> for anyone who cares, they would know. When I left, the W3C Recommendation
> updating/revision/errata process was being hammered out -- and I thought it
> might even be getting too formal -- so I don't know if there is now a sense
> of how this problem should be addressed. In particular, I doubt many of the
> other W3C specifications that had this sort of security concern. What is
> the IETF doing? Is there some policy there on how to update specifications
> that are dependent on algorithms that are now considered weak?
> 
> Or, instead of revising the whole of the specification, we could go Rich's
> route and post a new small specification, though I think it should be a
> recommendation rather than a note if it has any compliance claims.
> 
> > I know that PGP support in XML-DSIG is underspecified, it would
> > be good to complete it, if possible with errata or with a note.
> 
> That has always been a "it would be nice" but no one ever stepped up to the
> plate. Even the open source XMLsec library never implemented it. (Though
> these folks seem to have had some experience:
>  http://giftfile.org/lists/archive/giftfile-dev/2004q4/000002.html
> )
> 
> If substantive  work or to be started again I would be more concerned with
> questions of integrating the existing errata, updating some of the
> algorithm references for security, and addressing some of the shifts in the
> XML landscape (i.e., InfoSet, XPath 2.0), outlined in:
>  http://www.w3.org/2002/02/xmlsec-horizon
> 
>
Received on Thursday, 7 April 2005 11:07:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:40 UTC