In SAML meta-data using keyinfo is not uncommon in a number of federations.
Some use self signed x.509 certs but that is recommended against by some federations. If we look at existing examples of JSON encryption/signature they all avoid or provide options to having to parse a x.509 certificate. The anti x.509 bias amongst some developer communities can be a real roadblock in my experience. John Bradley On 2011-07-15, at 9:56 PM, Stephen Farrell wrote: > > Hi Mike, > > On 16/07/11 02:13, Mike Jones wrote: >> Some use cases require a compact, URL-safe data representation. For >> instance, this is needed when the data is passed in a URL query parameter - >> particularly for feature phone browsers that may limit URLs to 1024 or >> sometimes even 256 characters. That's one concrete example of something not >> covered by CMS. > > Note that no-one afaik is suggesting using ASN.1 encoding, so > any JSON specific payload encoding stuff has to be work for woes > to do. I would assume that that's up for debate all right, but > don't see that it has anything to do with CMS, same as CMS > doesn't itself say anything about MIME body parts which is > handled in another S/MIME RFC entirely. > > So, unless I'm missing something this is not a missing bit > of CMS but rather an additional, payload-related (from the > crypto p-o-v) requirement that you're expressing. > >> Some end-to-end use cases require a JSON key representation and ways of >> referring to them. That's another concrete example of something not covered >> in CMS. > > So some way to identify keys is clearly needed all right and I tend > to agree that that's an area where CMS is too X.509 specific in that > CMS dives inside the X.509 structure. > > But there are well known choices, as I mentioned in a mail yesterday, > so I still don't see that there's a real need for a JSON > representation for keys, (though it might still be sensible), can > you clarify when you'd need to say refer to an RSA public exponent > specifically, or to an ECC parameter? > > While I think XMLDSIG's KeyInfo is better than IssuerAndSerialNumber, > I'm not at all sure anyone really uses the <Exponent> element for > anything that wouldn't work just as well with the base64 encoding > of an X.509 blob. But its been a while, so maybe RSAKeyValue is more > useful than I recall. > > If there's never a need to refer to the RSA public exponent or > equivalents for other algorithms, then you don't need a way to > represent keys in JSON, but rather a way to put some key > representation or key identifier inside square brackets in a > well defined way. The latter, done smartly, should take a whole > lot less effort to get right would be my guess. > > S. > >> >> -- Mike >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Stephen Farrell >> Sent: Friday, July 15, 2011 5:36 PM >> To: Dave CROCKER >> Cc: [email protected] >> Subject: Re: [woes] New WOES charter proposal >> >> >> >> On 16/07/11 01:23, Dave CROCKER wrote: >>> >>> On 7/14/2011 1:45 PM, Stephen Farrell wrote: >>>>> The first requirement is for proponents to provide much more >>>>> explicit details about what is being proposed in the use of CMS. >>> ... >>>> Well, I don't really follow your logic there, but we're not aiming to >>>> do a new thing here. >>> ... >>>> Anyway the path for developing yet another crypto format is a pretty >>>> well trodden one and IMO CMS is the best current starting point for >>>> that process, so I think its entirely reasonable to ask people why >>>> they disagree with that. >>>> >>>> It does of course presume familiarity with CMS, but then that should >>>> be a prerequisite for working on woes, really. >>> >>> >>> Steve, >>> >>> Oh. This working group is merely a CMS encoding exercise? That was >>> not at all clear previously. >>> >>> I suspect I am not the only one who missed this as the anchoring and >>> inflexible premise to the work. (For reference, that requires even >>> stronger language than is in the current draft.) >> >> Maybe you could put [] around the sarcasm, given that this is JSON related? >> :-) >> >> I asked for examples of what's not covered by CMS but is needed here. I did >> that actually wanting to get an answer since I may well be missing >> something. (So far, no substantive answer has been offered.) I was not >> trying to score some rhetorical points. >> >> S. >> _______________________________________________ >> woes mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/woes >> >> > _______________________________________________ > woes mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/woes _______________________________________________ woes mailing list [email protected] https://www.ietf.org/mailman/listinfo/woes
