PGPData samples [Was Re: Further XML-SIG errata?]

Firstly, here's correcting myself - TrustPacket's are not intended to leave
the secret keyring and should therefore not be part of a PGPKeyPacket.
Instead packet types mentioned in section 10.1 Transferable Public Keys
[RFC2440] should be allowed in a PGPKeyPacket, including user-id packets,
sub-key packets and various types of signature packets (e.g. sub key binding
and revocation).

I am attaching two samples that reflect my understanding of what a
PGPKeyPacket might contain. I'd be interested in comments or opinions.

Regards,
Tommy

On 4/7/05, Tommy Lindberg <tommy.lindberg@gmail.com> wrote:
>
> 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
> >
> >
>