[Standards] XEP-0189: ASCII?

Peter Saint-Andre stpeter at stpeter.im
Thu Apr 10 20:34:20 UTC 2008

Dave Cridland wrote:
> On Mon Apr  7 18:10:01 2008, Joe Hildebrand wrote:
>> On 4/7/08 10:48 AM, "Dave Cridland" <dave at cridland.net> wrote:
>> > For X.509 certificates, you can - <X509Certificate/> simply contains
>> > a base64 encoding of the DER certificate, so no problem there - any
>> > additional information is being duplicated from it.
>> Isn't it likely that this is the cowpath that will get paved?  If so, is
>> there any reason we can't make the XEP more accessible to someone
>> looking at
>> implementing it by just removing everything but that?  If there needs to
>> some other cert type in the future, it could use a different namespace.
> All this junk^Wvaluably expressive XML comes from xmldsig, so it's not
> ours to mangle.
> For X.509, I asked an X.509 expert here in the office, who said that
> having the attributes easily accessible for non-X.509 aware clients
> might be useful, and certainly did no harm.
> I'm not clear if the DSA/PGP etc keys have the same properties, here -
> are they being stored in a format that's actually useful?

As far as I can tell, no. At least that's my sense for PGP, where the
storage format is a "Key Material Packet" as defined in Section 5.5 of
RFC 2440 (not ASCII output as defined in Section 6 of RFC 2440). The
situation seems to be similar for DSA and RSA keys.

I wonder if we need separate nodes for different pubkey types and simply
provide pointers to those nodes from the "base" pubkey node?


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080410/a9a0a9d5/attachment.bin>

More information about the Standards mailing list