On 8/5/11 2:49 PM, Phillip Hallam-Baker wrote:
On Fri, Aug 5, 2011 at 2:13 PM, Sean Turner <turn...@ieca.com
<mailto:turn...@ieca.com>> wrote:
On 8/5/11 12:27 PM, Phillip Hallam-Baker wrote:
Question: What exactly is a 'raw key' in any case?
I believe the people that want this are trying to avoid X.509. I'd
bet a $1 it won't end up just being the 'raw key' there's going to
be parameters, etc. If you look at what Mike's proposing in
http://datatracker.ietf.org/__doc/draft-jones-json-web-key/
<http://datatracker.ietf.org/doc/draft-jones-json-web-key/> which I
believe is one draft on offer as input, it already includes more
than just the key - as it should.
At some point he will add a criticality flag but call it something else.
Like Conditions. There was some guy who did that in SAML...
nothing like designing a protocol by committee ;)
I am not even opposed to eventually creating a whole new cert format.
Just as long as we don't fool ourselves into thinking that this is the
easy option, its not.
I have never assumed that the charter item for a 'raw key' implied
that it was *the* way to convey the public key in the resulting
JSON-structures for signatures/encryption. I have always assumed
there would be some faction that would want an option to refer
to|point to|include a certificate.
Given the way certain charters have been used to lay claim to 'own'
certain issues in the recent past I would like this to be explicit in
the charter. I don't want to end up having a four month argument as to
whether to do it.
I have no problem with adding something along the line of:
OLD:
The resulting solutions will support both JSON-encoded public keys and
X.509 public key certificates.
I purposely choose "support" and didn't specify which is the MTI. We
can have that debate when writing the spec.
do others have an issue with this?
spt
We can fight about what the required mechanism is when we actually
write the spec. I've gotten the impression that regardless of the
choice that wins a 'bare key' JSON format is needed - hence the
charter item.
No, I don't think that there should be a required mechanism as I don't
think this is going to be used on its own.
Specifically for my protocol, Web Confirmation Protocol (WCP) support
for certificates is definitely going to be a MUST for authenticating
inbound confirmation requests. But support for raw keys is going to be a
MUST for interaction between the service and the client.
--
Website: http://hallambaker.com/
_______________________________________________
woes mailing list
woes@ietf.org
https://www.ietf.org/mailman/listinfo/woes
