Deb Cooley <debcool...@gmail.com> wrote:
>> I don't understand your comment.
>> Mutual Authentication = Server Authentication + Client Authentication.
>> In section 7.3, paragraph we are explaining that the client
authentication
>> uses a different kind of key.
> [DC] I guess you could add that to the terminology section. From what I
> could see you are using mutual auth and client auth interchangeably.
okay, that's a bug, and we discussed it today about how to make it clearer.
> Although, I'm not sure even I understand what it means for client auth to
> use a 'different kind of key'.
poor choice of words on my part!
I mean, the registrar-agent certificate might be from a different CA:
an IDevID rather than an LDevID for instance.
We imagine the Registrar-Agent is likely an APP running on some rugidized
tablet.
I think that Registrar-Agents will be provisioned over EST in that situation,
with a more traditional RFC7030 password authenticated flow.
BUT, if the tablet had an IDevID in it, then BRSKI could be used.
Few off-the-shelf tablets would come with an IDevID [%], but a bespoke tablet
might well come that way.
We've agreed to remove the paragraph in question, which was trying to
clarify, but it clearly only confused.
==== stop here
[%]- I have been thinking a lot over the past 3-4 years about how to get an
IDevID-ish object deployed into virtual appliances, or smart-device apps.
I tested the waters for WIMSE, whether or not that fit into it's
charter, and it seems to be unclear. But there is a fundamental
existential question: what does it mean for vendor X to say that object
Y exists, if object Y can be snapshotted, cloned and downloaded again
and again? Vs defending against spammers/DoS.
Today, private keys are built-in to apps and that key might be used to
get a proper credential, but I'm very nervous about that.
ps: please start a new thread here.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
