[Standards] XEP-0189: ASCII?

Peter Saint-Andre stpeter at stpeter.im
Thu May 15 19:11:29 UTC 2008


On 04/10/2008 2:34 PM, Peter Saint-Andre wrote:
> 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?

A further data point (from the vCard RFC):

http://tools.ietf.org/html/rfc2426#section-3.7.2

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- 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/20080515/20e83513/attachment.bin>


More information about the Standards mailing list