Re: [woes] New WOES charter proposal

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
> 
> 