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" <[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?
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/
smime.p7s
Description: S/MIME Cryptographic Signature
