Dave Cridland wrote: > On Mon Apr 7 18:10:01 2008, Joe Hildebrand wrote: >> On 4/7/08 10:48 AM, "Dave Cridland" <[EMAIL PROTECTED]> 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 -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
