Re: [woes] New WOES charter proposal

As John points out, there's a significant anti-X.509/ASN.1 bias among web developers at this point.  It may not be "reasonable" or "fair", but it's nonetheless in play - in part because essentially all modern development tools and languages can parse JSON, whereas the same can't be said of ASN.1 (or XML, for that matter).  For us to succeed in winning developer mindshare end-to-end, we need to address the need to represent keys in formats they're comfortable with.

Have a look at the JSON Web Key (JWK):  http://tools.ietf.org/html/draft-jones-json-web-key spec.  It's about as simple a JSON representation of public keys as you can get.  It doesn't do everything.  (But then, that's kind of the point!)

Looking forward to seeing most of you in Quebec!

				-- Mike

-----Original Message-----
From: John Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Friday, July 15, 2011 7:10 PM
To: Stephen Farrell
Cc: Mike Jones; woes@ietf.org; Dave CROCKER
Subject: Re: [woes] New WOES charter proposal

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: woes-bounces@ietf.org [mailto:woes-bounces@ietf.org] On Behalf 
>> Of Stephen Farrell
>> Sent: Friday, July 15, 2011 5:36 PM
>> To: Dave CROCKER
>> Cc: woes@ietf.org
>> 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
>> woes@ietf.org
>> https://www.ietf.org/mailman/listinfo/woes
>> 
>> 
> _______________________________________________
> woes mailing list
> woes@ietf.org
> https://www.ietf.org/mailman/listinfo/woes