iginal Message-
From: Jari Arkko [mailto:jari.ar...@ericsson.com]
Sent: 25 November 2014 15:21
To: Dearlove, Christopher (UK)
Cc: Martin Thomson; draft-ietf-manet-ibs@tools.ietf.org;
adr...@olddog.co.uk; gen-art@ietf.org
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-manet-ibs-03
FWIW, I have followed this discussion.
I have to say that IBS would not necessarily be my first choice of crypto
solutions, particularly in a standards track spec. But it is interesting. I do
not mind the definition of a new ICV with IBS. But it does have the issues
Stephen and and Martin point
> On 30 Oct 2014, at 09:24, Jari Arkko wrote:
>
> We should add Thomas Clause (the shepherd) into this thread as well.
>
Fabulous, thank you Jari. I will read up on this, try to understand the
proxy-DISCUSS raised by Adrian.
> (Unfortunately, .all doesn’t reach shepherds if they are not WG c
I have a number of problems with this (including at some points not being clear
what exactly is being defined), but I'll start with the first major one. X
generates a public key related to SSK. But that's useless, Y does not know it.
The whole point is that X and Y can be in total ignorance of e
We should add Thomas Clause (the shepherd) into this thread as well.
(Unfortunately, .all doesn’t reach shepherds if they are not WG chairs, as is
the case sometimes.)
Jari
On 29 Oct 2014, at 20:47, Martin Thomson wrote:
> On 29 October 2014 03:52, Dearlove, Christopher (UK)
> wrote:
>> Any
On 29 October 2014 03:52, Dearlove, Christopher (UK)
wrote:
> Any objection that something better can be done needs to provide that
> something better, not just say "asymmetric, therefore something better".
That's a totally fair comment. I was trying for expediency, since
that is fairly obvious
The underlying cryptography is defined in RFC 6507. That is authored from CESG,
who essentially stand in the same relationship to GCHQ as NIST do to the NSA.
Experts in other words. Googling, you can find current CESG interest in
implementing MIKEY-SAKKE (RFC 6509, of which RFC 6507 is a compone
On 28 October 2014 06:37, Dearlove, Christopher (UK)
wrote:
> From my perspective, and with support shown in the WG, this is an option that
> several people want. The need for a trusted authority is a minus point, but
> acceptable by some users and should not be blocked because it is not ideal
>From my perspective, and with support shown in the WG, this is an option that
>several people want. The need for a trusted authority is a minus point, but
>acceptable by some users and should not be blocked because it is not ideal for
>everyone. (The only other so far standardised options, base
All,
This document has completed IETF last call, but it seems to me that this
conversation may not be complete yet. Please continue it and try to reach
resolution.
The document is on the IESG telechat for 11/25 and I am confident that you will
reach some agreement (if only agreement to disagree)
I didn't say this, and perhaps I should have, but while signature uses the
private key, verification uses the sender's identity (included in the
packet/message) and the user-independent public information only.
--
Christopher Dearlove
Senior Principal Engineer, Information Assurance Group
Commu
> I'm not 100% clear on the architecture here, but I've inferred that
> participating nodes receive a private key from the trusted authority and a
> set of public keys for other trusted nodes.
No, and that's where the win is here. You receive a private key (which includes
some public informatio
On 24 October 2014 11:17, Dearlove, Christopher (UK)
wrote:
> I am also not aware of a solution that overcomes this problem without
> introducing different limitations, so it is a question of tradeoffs. This is
> one point in that tradeoff space. If anyone has a clearly superior solution
> that
Martin
Thanks you for your comments.
There are various contexts where an authority having access to the keys is
acceptable - I will just refer to the company I work for as working in a
possible field (as do several other MANET participants). If this were being
offered as the only way to do thi
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document: draft-ietf-manet-ibs-03
15 matches
Mail list logo
