Subject: [CGA-EXT] Crypto agility - interop

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 15 Dec 2008 15:05:04 +0100

Hi,

We are chartered to provide crypto agility support for SeND and CGAs. 
That include both public key algorithm and hash algorithm agility.
So far, only CGAs have hash algorithm agility defined and we have some 
drafts covering the remaining pieces.
Now, i guess it makes sense to look at the big picture of how to provide 
agility for all these and draw some big lines about how this should be 
supported.

So, first we have identified the main elements that use the algortihms 
and they are:
- the certificates contain both a public key and use a hash
- the SEND protocol itself sends the RSA signature option and use hash 
algorithm.
- the CGA includes a public key and uses a hash algorithm

Next, we should agree of what level of backward compatibility we aim for.
First, it should be noted that SEND has two different behaviours. Some 
messages are in the request response format and another ones are just a 
message (like the periodic RADV).
Second, it should be noted that the public key and the hash algorithm 
are tightly coupled to the CGA and also to the certificates.

So, types of nodes and elements can we have in a scenario with crypto 
agility?

for hosts
H1- we can have a host that only supports crypto suite 1 and has no 
capabilities of doing any operations of algorithms that are not part of 
this crypto suite (e.g. the node supports only RSA and SHA1 and it is 
not capable of verifying ECC nor MD5 nor any other algorithm). this node 
has generated its own CGA with this suite of algorithms.
H2- we can have a host that supports multiple crypto algorithm suite but 
has only one CGA, generated with one of the crypto suites. So, in this 
case, the node has generated its CGA with crypto suite1, but he can also 
verify CGAs, and certs and signatures using other crypto suites.
H3- we then can have a host that supports multiple crypto suites and 
that he has generated as many different CGAs as crypto suites it supports.
H4- we can also have a node that supports multiple crypto suites and 
that he has generated one CGA that includes multiple public keys, one 
per public key algorithm it supports but using a single hash function 
though.

for routers
R1- a router with a single certificate generated with a given crypto 
suite. The router supports only the crypto suite that was used for 
generating the cert and it cannot perform crypto operations for other 
algorithms
R2- a router with a single cert generated with a given crypto suite, but 
that it is capable of validating other crypto suites.
R3- a router with multiple certs with different crypt suites. The router 
supports multiple crypto suites and can validate the different suites.

Hosts following current SEND specs are essentially H1 type and routers 
are R1 type, since only RSA and SHA1 is supported

One question we can ask ourselves is what type of hosts and routers will 
be accetable under the crypto agility scheme?

Then, what type of interop can we expect?

One option is to have a type H1 host supporting crypto suite 1 that 
tries to communicate with another host or router of type H1/R1 but that 
uses a different crypto suite. Of course, in this case, they won't be 
able to use SEND for the communication and they will fall back to normal 
ND. I guess that what is needed in this is a mean to allow the hosts and 
routers to tell that the crypto suite is different than the one they 
support. I understand that is already available in SEND

Another option is to have a host of type H2 communicating with a router 
of type R2. even though they have used differnet crypt suites to 
generate their CGAs and certs, they support each other crypto suites. In 
this case, if they can identify the crypto suite used by each other, 
they should be able to communicate. If the crypt suites are not 
overlapping, i guess they need to fall back to plain ND.

Another option is that we have two hosts of type H3 communicating. this 
is complicated cause they need to find the right coupling between the 
different CGAs they have. It is probbaly possible, but it probably 
involves some form of probing.

Another option is for a host of type H4 communicate with a host of type 
H1. In this case, if one of the public keys used by the H4 host is 
supported by the H1 host, the communication could be possible, but hte 
problem is how to choose which is the right public key to use to sign 
the messages.

Another option is for a host of type H3 to communicate with a host of 
type H1. In this case, is similar to the one of two hosts of type H3, 
and the problem is how to find the right CGA to use.

So, there are many other combinations.

I think the first thing we need to do is to define whoch of the host and 
routers types we are going to support and then define what inerop modes 
are we going to allow.

Regards, marcelo

_______________________________________________
CGA-EXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cga-ext

---

From: Tony Cheneau <[email-masked]>
Date: Mon, 15 Dec 2008 17:38:22 +0100 (CET)

Hi,

Comments inline.

On Mon, 15 Dec 2008, marcelo bagnulo braun wrote:

[...]

> So, first we have identified the main elements that use the algortihms and 
> they are:
> Second, it should be noted that the public key and the hash algorithm are 
> tightly coupled to the CGA and also to the certificates.
>
> capabilities of doing any operations of algorithms that are not part of this 
> crypto suite (e.g. the node supports only RSA and SHA1 and it is not capable 
> of verifying ECC nor MD5 nor any other algorithm). this node has generated 
> its own CGA with this suite of algorithms.
> H2- we can have a host that supports multiple crypto algorithm suite but has 
> only one CGA, generated with one of the crypto suites. So, in this case, the 
> node has generated its CGA with crypto suite1, but he can also verify CGAs, 
> and certs and signatures using other crypto suites.
> H3- we then can have a host that supports multiple crypto suites and that he 
> has generated as many different CGAs as crypto suites it supports.
> H4- we can also have a node that supports multiple crypto suites and that he 
> has generated one CGA that includes multiple public keys, one per public key 
> algorithm it supports but using a single hash function though.
>
> for routers
> R1- a router with a single certificate generated with a given crypto suite. 
> The router supports only the crypto suite that was used for generating the 
> cert and it cannot perform crypto operations for other algorithms
> R2- a router with a single cert generated with a given crypto suite, but that 
> it is capable of validating other crypto suites.
> Hosts following current SEND specs are essentially H1 type and routers are R1 
> type, since only RSA and SHA1 is supported
>
> One question we can ask ourselves is what type of hosts and routers will be 
> accetable under the crypto agility scheme?
I personally think we should have H4 type and R3 type that would provides 
the wider compatibility with older nodes. This is the type of 
hosts/routers we define in our draft.

H4 type are only required during a transition phase, once a specific 
crypto suite is adopted, they will act as H2 type of nodes.
We can rule out H3 type as it is really hard to bind two CGA addresses 
together (you have to prove you know the two secret, and sometime, you 
can't prove it to a node that don't support the correct crypto suite).

I am not sure R2 will work. Only one certificate, validating multiple 
crypto suite: this involves multiple keys, right? How do we link the 
certificate and the multiple keys ?

R3 seems more fitted. Routers being more powerful.

> One option is to have a type H1 host supporting crypto suite 1 that tries to 
> communicate with another host or router of type H1/R1 but that uses a 
> different crypto suite. Of course, in this case, they won't be able to use 
> SEND for the communication and they will fall back to normal ND. I guess that 
> what is needed in this is a mean to allow the hosts and routers to tell that 
> the crypto suite is different than the one they support. I understand that is 
> already available in SEND
Falling back is a good alternative when there is no other choice, for the 
RFC3971 nodes.

> Another option is to have a host of type H2 communicating with a router of 
> type R2. even though they have used differnet crypt suites to generate their 
> CGAs and certs, they support each other crypto suites. In this case, if they 
> can identify the crypto suite used by each other, they should be able to 
> communicate. If the crypt suites are not overlapping, i guess they need to 
> fall back to plain ND.
Right.

> Another option is that we have two hosts of type H3 communicating. this is 
> complicated cause they need to find the right coupling between the different 
> CGAs they have. It is probbaly possible, but it probably involves some form 
> of probing.
In our draft, in the best case scenario (which I believe would be the more 
common), we have 2 messages (as many as in SEND), when things goes wrong, 
we have 3 messages.
Basically, good case is just like:
- Node A supports Type 1 and Type 2 crypto suite (in this preference 
order)
- Node B supports Type 1 and Type 3 crypto suite (in this preference 
order)
- Node A send a NS signed with Type 1 to Node B. The Supported Signature 
Algorithm option indicates which Type of crypto suite Node A supports.
- Node B verify the signature, everything is OK, it builds up a NA signing 
with Node A preferred crypto suite (First crypto suite to appear in the 
list inside the Supported Signature Option): Type 1.
- Node A receives the message and checks the signature.

Worst case:
- Node A supports Type 2 and Type 1 crypto suite (in this preference 
order)
- Node B supports Type 3 and Type 1 crypto suite (in this preference 
order)
- Node A send a NS signed with Type 2 to Node B. The Supported Signature
   Algorithm option indicates which Type of crypto suite Node A supports.
- Node B try to verify the signature: it doesn't support Type 2. It
   checks the crypto suite available to communicate with A with the help
   of the Supported Signature Algorithm option. It chooses Type 1. It
   signs the NA with Type 1, add to the message its Supported Signature
   Option that indicate that the initial message need to be resent. This
   message is sent.
- Node A receives the message and checks the signature. The Supported
   Signature Option indicates that node A has to has to send again the
   informations. The option indicates which crypto suite is available:
   Type 1. It re-sends a NS or maybe a NA with the Type 1 crypto suite.

> Another option is for a host of type H4 communicate with a host of type H1. 
> In this case, if one of the public keys used by the H4 host is supported by 
> the H1 host, the communication could be possible, but hte problem is how to 
> choose which is the right public key to use to sign the messages.
Not a trivial problem. If a H4 type node send a message to a node he
knows nothing of, after a timeout delay, it may try to resent the packet
using a H1 type mechanism. Basically, here, it means that we will sign
using with a RSA signature using a RSA Public Key located in the Public
Key field of the CGA PDS.

> routers types we are going to support and then define what inerop modes are 
> we going to allow.
I agree.

Regards,
 	Tony Cheneau

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 15 Dec 2008 18:31:08 +0100

Tony Cheneau escribió:
>> So, first we have identified the main elements that use the 
>> algortihms and they are:
>> - the SEND protocol itself sends the RSA signature option and use 
>> hash algorithm.
>> First, it should be noted that SEND has two different behaviours. 
>> Some messages are in the request response format and another ones are 
>> just a message (like the periodic RADV).
>> capabilities of doing any operations of algorithms that are not part 
>> of this crypto suite (e.g. the node supports only RSA and SHA1 and it 
>> is not capable of verifying ECC nor MD5 nor any other algorithm). 
>> this node has generated its own CGA with this suite of algorithms.
>> H2- we can have a host that supports multiple crypto algorithm suite 
>> but has only one CGA, generated with one of the crypto suites. So, in 
>> this case, the node has generated its CGA with crypto suite1, but he 
>> can also verify CGAs, and certs and signatures using other crypto 
>> suites.
>> R2- a router with a single cert generated with a given crypto suite, 
>> but that it is capable of validating other crypto suites.
>> R3- a router with multiple certs with different crypt suites. The 
>> router supports multiple crypto suites and can validate the different 
>> suites.
>>
>> Hosts following current SEND specs are essentially H1 type and 
>> routers are R1 type, since only RSA and SHA1 is supported
>>
>> One question we can ask ourselves is what type of hosts and routers 
>> will be accetable under the crypto agility scheme?
> I personally think we should have H4 type and R3 type that would 
> provides the wider compatibility with older nodes. This is the type of 
mmm, but the problem is that one of the motivations for all this cryptp 
agility work is that we will have some nodes with very limited resources 
and that they cannot execute RSA much less they will be able to execute 
multiple algorithms. I don't know if we can assume that they can 
validate using multiple algorithms though.... (i.e. don't know if they 
are H1 or H2)
So, i think we will have at least 3 type of nodes:
We will have cureent send nodes, that are H1 for hosts and R1 for routers
We will have new types of nodes that will only support one crypto suite 
but will not be RSA (these are the limited devices). I don't know if we 
will have R1 of these too, or will only be hosts...
We will also then have some normal nodes will be H1, H2, H3 or H4 or R1 
or R2 or R3 is up to us to decide.
In other words, H1 are a reality, then new resource limited nodes will 
be either H1 or H2 (not clear to me)
Then we need to understnad if there is a case for the other options, H3 
or H4 or we cna simply rule out some of these...

> crypto suite is adopted, they will act as H2 type of nodes.
not really cause they are likely to be able to interact with multiple 
types of H1 nodes. I mean an H$ node not only can validate multiple H1 
nodes, but its credentials can be validated by different H1 nodes, which 
is soemthing that a H2 node cannot provide
> can't prove it to a node that don't support the correct crypto suite).

i think i agree we could rule out H3, but i woudl preffer to keep in the 
dicussion for a while, to see if someone can come up with a reason for that
please note that i am not sure we can rule out R3 though...

> certificate and the multiple keys ?

R2 means that the router has a single certificate, but himself is able 
to validate multiple crypto suites. That would acually make sense to 
me... i mean, i am not sure we will be able to get people to deploy 
multiple certificates in parallel....
> R3 seems more fitted. Routers being more powerful.
The problem with R3 is that you need multiple certs per router and i am 
not sure how realistic that is from a deployment perspective...

>> tries to communicate with another host or router of type H1/R1 but 
>> that uses a different crypto suite. Of course, in this case, they 
>> won't be able to use SEND for the communication and they will fall 
>> back to normal ND. I guess that what is needed in this is a mean to 
>> allow the hosts and routers to tell that the crypto suite is 
>> different than the one they support. I understand that is already 
>> available in SEND
> Falling back is a good alternative when there is no other choice, for 
> the RFC3971 nodes.
>
>> Another option is to have a host of type H2 communicating with a 
>> router of type R2. even though they have used differnet crypt suites 
>> to generate their CGAs and certs, they support each other crypto 
>> suites. In this case, if they can identify the crypto suite used by 
>> each other, they should be able to communicate. If the crypt suites 
>> are not overlapping, i guess they need to fall back to plain ND.
> Right.
>
>> Another option is that we have two hosts of type H3 communicating. 
>> this is complicated cause they need to find the right coupling 
>> between the different CGAs they have. It is probbaly possible, but it 
>> probably involves some form of probing.
> In our draft, in the best case scenario (which I believe would be the 
> more common), we have 2 messages (as many as in SEND), when things 
> goes wrong, we have 3 messages.
> - Node A send a NS signed with Type 1 to Node B. The Supported 
> Signature Algorithm option indicates which Type of crypto suite Node A 
> supports.
> - Node B verify the signature, everything is OK, it builds up a NA 
> signing with Node A preferred crypto suite (First crypto suite to 
> appear in the list inside the Supported Signature Option): Type 1.

As i mentioned in my reply to the other email, you should note that a 
node can support a set of crypto suites that it can validate and a 
different set of crypto suites that it has credentials.
I mean, for instance a node may have only a RSA CGA but it is able to 
validate both ECC and RSA
So, how do you express the difference?
you need to express it?

>> Another option is for a host of type H4 communicate with a host of 
>> type H1. In this case, if one of the public keys used by the H4 host 
>> is supported by the H1 host, the communication could be possible, but 
>> hte problem is how to choose which is the right public key to use to 
>> sign the messages.
right, but it can resend signing it with a different key if itfinds out 
that the other node supports a different algorithm, right?

>> I think the first thing we need to do is to define whoch of the host 
>> and routers types we are going to support and then define what inerop 
>> modes are we going to allow.
> I agree.
>
>
one more question, how does hash agility fits into all this?

regards, marcelo

---

From: Tony Cheneau <[email-masked]>
Date: Mon, 15 Dec 2008 21:14:35 +0100 (CET)

Hi again,

Comments inline.

[...]

> agility work is that we will have some nodes with very limited resources and 
> that they cannot execute RSA much less they will be able to execute multiple 
> algorithms. I don't know if we can assume that they can validate using 
> multiple algorithms though.... (i.e. don't know if they are H1 or H2)
> We will have new types of nodes that will only support one crypto suite but 
> will not be RSA (these are the limited devices). I don't know if we will have 
> R1 of these too, or will only be hosts...
> We will also then have some normal nodes will be H1, H2, H3 or H4 or R1 or R2 
> or R3 is up to us to decide.
> In other words, H1 are a reality, then new resource limited nodes will be 
> either H1 or H2 (not clear to me)
> Then we need to understnad if there is a case for the other options, H3 or H4 
> or we cna simply rule out some of these...
>
Hum, I indeed wasn't clear. To me, a H4 node is a node that is capable
of handling multiple cryto suites and  have multiple public keys linked
to its CGA. It is only "capable of", meaning that it can also choose to
use only one crypto suite, hence one public key. So the lightweight node
are only showing capabilities of H1 node + negotiation support, while
having the same set of capabilities as H4 type nodes.

Simply put, if we specify the behavior of H4 type nodes, by using a
small subset of their capabilities, we can emulate H2 and H1 type nodes.

> not really cause they are likely to be able to interact with multiple types 
> of H1 nodes. I mean an H$ node not only can validate multiple H1 nodes, but 
> its credentials can be validated by different H1 nodes, which is soemthing 
> that a H2 node cannot provide
This is true. But in a wide deployment of similar nodes, it may be more
preferable to only carry one type of Public Key in order to save the
bandwidth. We should at least allow this behavior.

> please note that i am not sure we can rule out R3 though...
OK.

> R2 means that the router has a single certificate, but himself is able to 
> validate multiple crypto suites. That would acually make sense to me... i 
> mean, i am not sure we will be able to get people to deploy multiple 
> certificates in parallel....
That makes sense. I will read more on certificate to understand how we
can do that. For now, I'm wondering how a node can check a certificate
if it doesn't support the Signature Algorithm of the certificate.

> The problem with R3 is that you need multiple certs per router and i am not 
> sure how realistic that is from a deployment perspective...
Right.

> As i mentioned in my reply to the other email, you should note that a node 
> can support a set of crypto suites that it can validate and a different set 
> of crypto suites that it has credentials.
Yes, good comment. We need to express in some specific cases. Still, we
can use the same "Supported Signature Algorithm" option and use a flag
to differentiate between crypto suite it uses to build addresses and
others.

[...]

> right, but it can resend signing it with a different key if itfinds out that 
> the other node supports a different algorithm, right?
Yes. It means that the H4 type node will be able to emulate the behavior of a H1
type node if it supports the same cryto suite. In our current solution,
we use the Public Key field of the CGA PDS to store the Public Key that
can be used with H1 type nodes (e.g. store a RSA key to communicate with
RFC3971 nodes).

[...]
> one more question, how does hash agility fits into all this?
We are pretty independent of this work right now, but it is clear that
the security level of a CGA is related to the hash algorithm and to the
length of its Public Key(s).

Regards,
 	Tony Cheneau

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 15 Dec 2008 23:02:44 +0100

Tony Cheneau escribió:
>>> >  H1- we can have a host that only supports crypto suite 1 and has 
>>> no >  capabilities of doing any operations of algorithms that are 
>>> not part of >  this crypto suite (e.g. the node supports only RSA 
>>> and SHA1 and it is >  not capable of verifying ECC nor MD5 nor any 
>>> other algorithm). this node >  has generated its own CGA with this 
>>> suite of algorithms.
>>> >  H2- we can have a host that supports multiple crypto algorithm 
>>> suite but >  has only one CGA, generated with one of the crypto 
>>> suites. So, in this >  case, the node has generated its CGA with 
>>> crypto suite1, but he can also >  verify CGAs, and certs and 
>>> signatures using other crypto suites.
>>> >  H3- we then can have a host that supports multiple crypto suites 
>>> and >  that he has generated as many different CGAs as crypto suites 
>>> it >  supports.
>>> >  H4- we can also have a node that supports multiple crypto suites 
>>> and >  that he has generated one CGA that includes multiple public 
>>> keys, one >  per public key algorithm it supports but using a single 
>>> hash function >  though.
>>> > >  for routers
>>> >  R1- a router with a single certificate generated with a given 
>>> crypto >  suite. The router supports only the crypto suite that was 
>>> used for >  generating the cert and it cannot perform crypto 
>>> operations for other >  algorithms
>>> >  R2- a router with a single cert generated with a given crypto 
>>> suite, but >  that it is capable of validating other crypto suites.
>>> router >  supports multiple crypto suites and can validate the 
>>> different suites.
>>> routers >  are R1 type, since only RSA and SHA1 is supported
>>> > >  One question we can ask ourselves is what type of hosts and 
>>> routers will >  be accetable under the crypto agility scheme?
>>> provides
>> mmm, but the problem is that one of the motivations for all this 
>> cryptp agility work is that we will have some nodes with very limited 
>> resources and that they cannot execute RSA much less they will be 
>> able to execute multiple algorithms. I don't know if we can assume 
>> that they can validate using multiple algorithms though.... (i.e. 
>> don't know if they are H1 or H2)
>> We will have new types of nodes that will only support one crypto 
>> suite but will not be RSA (these are the limited devices). I don't 
>> know if we will have R1 of these too, or will only be hosts...
>> We will also then have some normal nodes will be H1, H2, H3 or H4 or 
>> R1 or R2 or R3 is up to us to decide.
>> In other words, H1 are a reality, then new resource limited nodes 
>> will be either H1 or H2 (not clear to me)
>> Then we need to understnad if there is a case for the other options, 
>> H3 or H4 or we cna simply rule out some of these...
>>

mmm, maybe, not sure if it the clearer approach though.
having explicitly called out the different common cases, would provide 
some clarity, i guess
>> types of H1 nodes. I mean an H$ node not only can validate multiple 
>> H1 nodes, but its credentials can be validated by different H1 nodes, 
>> which is soemthing that a H2 node cannot provide

sure, if we can handle a single pk, that is clearly preferred
but i think that a scenario where ECC and RSA need to be used 
simultaneously may not be too rare
I mean, RSA cause it is the most common algorithm and cause the certs 
are likely to use RSA
ECC for the lighweight nodes

(Moreover, you can also have the cases of different key lenghts, not 
sure how it fits in all this...)

>> i think i agree we could rule out H3, but i woudl preffer to keep in 
>> the dicussion for a while, to see if someone can come up with a 
>> reason for that
>> R2 means that the router has a single certificate, but himself is 
>> able to validate multiple crypto suites. That would acually make 
>> sense to me... i mean, i am not sure we will be able to get people to 
>> deploy multiple certificates in parallel....

but there are two cases here:
suppose the cert is signed with RSA
-one case is that the node that has a ECC based CGA, and only supports 
ECC validation. So no luck here. This node cannot read the cert
- a different case is a node that has an ECC CGA but it is also able to 
validate RSA signatures (even though it doens't have a RSA public key). 
there is no problem here. The node can understand and validate the cert

makes sense?
>> The problem with R3 is that you need multiple certs per router and i 
>> am not sure how realistic that is from a deployment perspective...
> Right.
>
>
>>> Signature
>>> signing
well, i was just noting that there are different roles
not sure if we need to idnetify them but seemed to me that the 
disucssion was getting a bit confused about this

> [...]
>
>>> >  Another option is for a host of type H4 communicate with a host 
>>> of type >  H1. In this case, if one of the public keys used by the 
>>> H4 host is >  supported by the H1 host, the communication could be 
>>> possible, but hte >  problem is how to choose which is the right 
>>> public key to use to sign >  the messages.
>> right, but it can resend signing it with a different key if itfinds 
>> out that the other node supports a different algorithm, right?

mmm, do you mean that you change the CGA Parameter data strcuture? i.e. 
that you change the key you store in the Public key filed?
If that's the case, this is a problem cause changing the order of the 
keys would result in a different CGA
but maybe i am misunderstanding soemthing

> length of its Public Key(s).
but when we talk about crypto suites, wouldn't that include the hash 
algorithm as well?

Regards, marcelo

---

From: Tony Cheneau <[email-masked]>
Date: Tue, 16 Dec 2008 12:25:26 +0100 (CET)

Hi,

Comments inline.

[...]

> having explicitly called out the different common cases, would provide some 
> clarity, i guess
I was just trying to show why (to my mind) it may be preferable to have
H4 type nodes functionality from the start in the protocol.
I agree with you to split the nodes into different categories.
Maybe it also would be interesting to differentiate nodes from their
ability to negotiate or not.

> but i think that a scenario where ECC and RSA need to be used simultaneously 
> may not be too rare
> I mean, RSA cause it is the most common algorithm and cause the certs are 
> likely to use RSA
Right.

> (Moreover, you can also have the cases of different key lenghts, not sure how 
> it fits in all this...)
You mean something like a node generating its CGA with a 384-bit RSA PK
and a 1024-bit RSA PK. When the node is sending packet, neighbors may
decide not to listen to the "not strong enough" 384-bit RSA ?
Or something else ?

> -one case is that the node that has a ECC based CGA, and only supports ECC 
> validation. So no luck here. This node cannot read the cert
> validate RSA signatures (even though it doens't have a RSA public key). there 
> is no problem here. The node can understand and validate the cert
>
> makes sense?
It totally makes sense.

>> > >  more
> not sure if we need to idnetify them but seemed to me that the disucssion was 
> getting a bit confused about this
Yes, you were outlining that they may be different part to negotiate.
Here is what I think should be negotiated for crypto agility:
- does a node can check  crypto suite X, Y ?
- does a node possess a CGA using crypto suite X,Y (in order for another
   node to be able to check it) ?
- does a node offer long enough keys so I can trust them ?

Do you agree ?

>> > >  of type >  H1. In this case, if one of the public keys used by the H4 
>> > >  host is >  supported by the H1 host, the communication could be 
> mmm, do you mean that you change the CGA Parameter data strcuture? i.e. that 
> you change the key you store in the Public key filed?
> If that's the case, this is a problem cause changing the order of the keys 
> would result in a different CGA
No, we don't change it. When building the CGA, we choose the Public Key
that will be in the Public Key field of the CGA PDS. This Public Key is
somewhat the "fallback" Public Key. The "limitation" is that the CGA PDS
can only carry one Public Key this way and that the Public Key will
remain the same during all the CGA lifetime.
To illustrate, if I were to build just now a CGA, I will put a RSA
Public Key inside the Public Key field, just to assure backward
compatibility with RFC3971 nodes (even if I don't plan to use it but
rather an ECC PK stored in CGA PDS extension fields)).

Is it more clearer ?

> but when we talk about crypto suites, wouldn't that include the hash 
I thought you were originally speaking of the RFC4982. Now I realise
that you may be speaking of the hash algorithm used to compute the
signature.  This hash algorithm is totally bound to the type of
Signature Algorithm that is used. Some standards are recommending a set
of specific Hash function to compute the signature. This is the case for
PKCS#1 v1.5 used in SEND (which propose MD2, MD5, SHA-1, SHA-256,
SHA-384, SHA-512). RFC3971 decided to use SHA-1. We could decide to
impose couple of value like (RSA,SHA1), (ECDSA,SHA1), (ECDSA,SHA-256)
and it would be up to the receiver to decide whether it want to support
or not certain combination of hash/signature. Negotiation process would
be on those couples. Does that seem reasonable ?

Regards,
 	Tony Cheneau

---

From: shenshuo 00102542 <[email-masked]>
Date: Tue, 16 Dec 2008 21:14:35 +0800

hi, 
Comments in line:

> >> >  We will have cureent send nodes, that are H1 for hosts and 
> R1 for 
> >> >  routers
> >>  Hum, I indeed wasn't clear. To me, a H4 node is a node that is 
> capable>>  of handling multiple cryto suites and  have multiple 
> public keys linked
> I was just trying to show why (to my mind) it may be preferable to 
> haveH4 type nodes functionality from the start in the protocol.

My understanding is: 
H1 is already there so it should be considered. (notice that H1 include both rsa-only node or ecc-only node according to the definition of definition);
H2 is the type that can be transfered to H4: need to generated a new CGA covering multiple keys. There is no divice ability difference between H2 and H4. If requireing a new multi-key CGA is not too much, it is fair to rule out H2.
H3: According to previous discussions, I also agree that H3 can be ruled out.
H4: I think this is the type gaining best compatibility.

> > ECC for the lighweight nodes
I believe the benefit of carrying multiple signatures: possiblly save message round in negotiation, also easy for RADV message. Clearly there will be a tradeoff of bandwidth and negotiation simplicity, so I don't know.
Also I want to point out that the rsa signature has to be the first one for compatibility with rsa-only node. And we have to change the law in 3971 that all the options after signature option should be ignored (ignored for both signature verification and NDP processing purposes).

> >> > >   We can rule out H3 type as it is really hard to bind two 
> CGA 
> >> > >   addresses
> >> > >   together (you have to prove you know the two secret, and 
> sometime, 
> >> > >   you
> >> > >   can't prove it to a node that don't support the correct 
> crypto 
> >> > >   suite).
> >> > 
> >> >  dicussion for a while, to see if someone can come up with a 
> reason for 
> >> >  that
> >>  can do that. For now, I'm wondering how a node can check a 
> certificate>>  if it doesn't support the Signature Algorithm of 
> the certificate.
> >
For the second case described above: if this router is talking to a ecc-only node, no problem; if this router is talking to a old rsa-only host, the router can trust the host, but the host can not trust the router because the host don't understand ecc. So can we conclude that knowing an extra rsa in this case does not help?

> >> > >  common), we have 2 messages (as many as in SEND), when 
> things goes 
> >> > >  wrong,
> >> > >   we have 3 messages.
> >> > >   - Node A supports Type 1 and Type 2 crypto suite (in this 
> preference>> > >   order)
> >> > >   - Node B supports Type 1 and Type 3 crypto suite (in this 
> preference>> > >   order)
> >> > >   Algorithm option indicates which Type of crypto suite 
> Node A 
> >> > >   supports.
> >> > >  with Node A preferred crypto suite (First crypto suite to 
> appear in 
> >> > >  the
> - does a node possess a CGA using crypto suite X,Y (in order for 
> another   node to be able to check it) ?
> >> > >   knows nothing of, after a timeout delay, it may try to 
> resent the 
> >> > >  packet
> >> > >   using a H1 type mechanism. Basically, here, it means that 
> we will 
> >> > >   sign
> >> > >   using with a RSA signature using a RSA Public Key located 
> in the 
> >> > >  Public
> >>  Yes. It means that the H4 type node will be able to emulate 
> the behavior
> >>  of a H1
> >>  type node if it supports the same cryto suite. In our current 
> solution,>>  we use the Public Key field of the CGA PDS to store 
> the Public Key that
> and it would be up to the receiver to decide whether it want to 
> supportor not certain combination of hash/signature. Negotiation 
> process would
There are Hash functions bounded within signature algorithm and also Hash funtions used by 3972 and 3971(for example, when generating a CGA). For the Hash functions bounded within signature algorithms, I think it's proper to just refer to other PK standards. For the agility of hash functions used by 3972 and 3971, we haven't yet considered to solve it together with signature agility. But I think it worth discussions.

Sean

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 16 Dec 2008 17:33:04 +0100

> ability to negotiate or not.
but this is up to us to define it, right?
I mean, i don't think we shou define multiple behaviour if we can avoid it.
I mean, i undersntad that a node cannot support heavy weight algorithms, 
but wouldn't a node couldn't be able to retry as you proposed before?
...
> decide not to listen to the "not strong enough" 384-bit RSA ?
right
i mean once we have the means to negotiate, we could use it as well for 
this (but this is secondary, i guess)

> Or something else ?

....
> - does a node offer long enough keys so I can trust them ?

the certs are missing i think...
I mean, you have the CGA and the certs that use a public key algorithm, 
right?

...
>> mmm, do you mean that you change the CGA Parameter data strcuture? 
>> i.e. that you change the key you store in the Public key filed?

right
> be on those couples. Does that seem reasonable ?
right
my point is that this work needs to be coordinated with Suresh and Ana 
and Sheng, who are working in the hash agility work

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 16 Dec 2008 17:47:56 +0100

> H2 is the type that can be transfered to H4: need to generated a new CGA covering multiple keys. There is no divice ability difference between H2 and H4. If requireing a new multi-key CGA is not to…
mmm, i am not so sure about this
I mean, one question that i have with respect to this is whehter 
validating is cheaper than signing?
I mean, wouldn't be possible that a node has not enough processing power 
to generate an RSA key and sign using the key, but it is capable of 
verifying RSA signatures?
(i really don't know the answer to this and maybe verifying is as 
expensive as signing... i simply don't know)

...
> I believe the benefit of carrying multiple signatures: possiblly save message round in negotiation, also easy for RADV message. Clearly there will be a tradeoff of bandwidth and negotiation simplic…
i think we need some numbers here....
how many signatures can be carried in a SEND packet?

> Also I want to point out that the rsa signature has to be the first one for compatibility with rsa-only node. And we have to change the law in 3971 that all the options after signature option shoul…
don't understand what do you mean here, could you expand?

...
>>> -one case is that the node that has a ECC based CGA, and only 
>>>       
>> supports ECC 
>>     
>>> - a different case is a node that has an ECC CGA but it is also 
>>>       
>> able to 
>>     
>>> validate RSA signatures (even though it doens't have a RSA 
>>>       
>> public key). there 
>>     
not sure i understand
in the case we were cosndiering above, the cert is signed with RSA, so 
if the node understand RSA it can validate the cert, so problem solved...

...
> There are Hash functions bounded within signature algorithm and also Hash funtions used by 3972 and 3971(for example, when generating a CGA). For the Hash functions bounded within signature algorithms, I think it's proper to just refer to other PK standards.
don't understand...
you mean the RSA signature used in SEND? this is defined in rfc3971, so 
it is wihtin the scope of the hash agility work afaict
regards, marcelo

>  For the agility of hash functions used by 3972 and 3971, we haven't yet considered to solve it together with signature agility. But I think it worth discussions.
>
> Sean
>
>
>
>

---

From: Sean Shen <[email-masked]>
Date: Wed, 17 Dec 2008 18:47:05 +0800

hi, 
Comments in line:

>> My understanding is: 
>> H1 is already there so it should be considered. (notice that H1 
>> include both rsa-only node or ecc-only node according to the 
>> definition of definition);
>> H2 is the type that can be transfered to H4: need to 
>generated a new CGA covering multiple keys. There is no divice 
>ability difference between H2 and H4. If requireing a new 
>multi-key CGA is not too much, it is fair to rule out H2.
>>   
>I mean, one question that i have with respect to this is 
>whehter validating is cheaper than signing?
>I mean, wouldn't be possible that a node has not enough 
>processing power to generate an RSA key and sign using the 
>key, but it is capable of verifying RSA signatures?
>(i really don't know the answer to this and maybe verifying is 
>as expensive as signing... i simply don't know)
For rsa, validating is cheaper than signing. So the situation you described
is possible. 
What I mean is, If an H2 can already generate an CGA associated with one key
and own another key, he can also generate an CGA associated with two keys.
Possiblly we can use this way to reduce combination of different
hosts/routers. 
The question is that: is it proper to require "have the ability to perform
an algorithm A"<==>"have a public key for algorithm A".
For the "<==", I think it's easier to be accepted, a device should have the
ability to play the algorithm A if it has the key of algorithm A;
For the "==>", I think this is fairly reasonable especially for terminal
devices. If an device want to save resouce, it probably just want the
ability of playing one algorithm. 
This equivalence will certainly make problems easier, :). But probably we
should include this question in the draft to ask the wg whether we have that
luxury.

>> I believe the benefit of carrying multiple signatures: 
>possiblly save message round in negotiation, also easy for 
>RADV message. Clearly there will be a tradeoff of bandwidth 
>and negotiation simplicity, so I don't know.
>>   

>> Also I want to point out that the rsa signature has to be 
>the first one for compatibility with rsa-only node. And we 
>have to change the law in 3971 that all the options after 
>signature option should be ignored (ignored for both signature 
>verification and NDP processing purposes).
>>
>>   
What I mean is that: as defined in 3971, the receiver MUST ignore any
options that come after the first RSA Signature option.  (The options are
ignored for both signature verification and NDP processing purposes.) So
This law has to be changed if new SeND message want to carry multiple
signatures, don't know yet whether it can cause trouble.
For the order of these signatures on a SeND message, (if rsa signature is
used) the RSA signaure should be the first one, otherwise an old RSA-only
node can not recognize ECC PDS & signature options before the rsa signature
option.   If we define an order for signature option positions, this order
may not match the order of user's preference of different algorithms, maybe
it's doable, I haven't think of other negative reasons, but seems to me it's
not an very comfortable way.  

>> For the second case described above: if this router is 
>talking to a ecc-only node, no problem; if this router is 
>talking to a old rsa-only host, the router can trust the host, 
>but the host can not trust the router because the host don't 
>understand ecc. So can we conclude that knowing an extra rsa 
>in this case does not help?
>>
>>   
>not sure i understand
>in the case we were cosndiering above, the cert is signed with 
>RSA, so if the node understand RSA it can validate the cert, 
>so problem solved...
I guess what you mean is that two sides can trust each other by using
different signatures as long as both sides can validate what they received.
For example, one side use RSA signature, the other side use ECDSA, when they
are both able to validate two algorithms, SeND can be performed. Is my
understanding correct?
If we allow this happen, what if one algorithm is not safe anymore, then one
node can not enforce to use a secure algorithm and the other node can choose
the unsecure algorithm. 

Best,

Sean

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 17 Dec 2008 14:55:36 +0100

> For rsa, validating is cheaper than signing. So the situation you described

ok, so do you think is reasonable to impose that all nodes must be able 
to validate RSA signatures? (even light weigth nodes?)
> and own another key, he can also generate an CGA associated with two keys.
sure, this is not the case i am concerned about

right

right

> ability of playing one algorithm. 
but i guess this depends on what resoruces are constrained in the device.
If what is constrained is processing power, then it may make sense to 
have a device that for instacne does not have a RSA key, but it is 
capable of validating RSA signatures, since as you mentioned above, 
validating RSA signatures is cheaper than signing, right?

> This equivalence will certainly make problems easier, :).
not really
if we can asusme that all the nodes can validate rsa signatures (even if 
they don't have an rsa key), this really simplifies the problem imho

>  But probably we
>>> H3: According to previous discussions, I also agree that H3 
>>>       
>> can be ruled out.
>>     
right, this needs to be changed if we want to inlcude multiple 
signatures but i guess we will need to update rfc3971 to support crypto 
agility, so no problem here

> option.  
right
>  If we define an order for signature option positions, 

why do we need an order in addition to keeping rsa first?
> this order
don't see a problem here

right
> are both able to validate two algorithms, SeND can be performed. Is my
yes

> node can not enforce to use a secure algorithm and the other node can choose
that's what you need the negotiation for, right?
I mean, this is the same than with CGAs right?

Regards, marcelo

---

From: Sean Shen <[email-masked]>
Date: Thu, 18 Dec 2008 17:02:57 +0800

Hi, 
Comments in line:

>>> ability difference between H2 and H4. If requireing a new multi-key 
>>> CGA is not too much, it is fair to rule out H2.
>>>     
>>>>   
>>>>       
>>> I mean, wouldn't be possible that a node has not enough processing 
>>> power to generate an RSA key and sign using the key, but it is 
>>> capable of verifying RSA signatures?
>> For rsa, validating is cheaper than signing. So the situation you 
>> described is possible.
>>   
>
>ok, so do you think is reasonable to impose that all nodes 
>must be able to validate RSA signatures? (even light weigth nodes?)
I don't think the it's proper to impose all nodes must be able to validate
RSA signature. Especially when we are looking for general agility solutions,
we should not consider one particular algorithm different from others.
Besides, to impose rsa validation is too strong, for the nodes which only
want ECC for key size and speed reasons, this requirement is not proper.  

>> What I mean is, If an H2 can already generate an CGA associated with 
>> one key and own another key, he can also generate an CGA 
>associated with two keys.
>>   
>> The question is that: is it proper to require "have the ability to 
>> perform an algorithm A"<==>"have a public key for algorithm A".
>> For the "<==", I think it's easier to be accepted, a device should 
>> have the ability to play the algorithm A if it has the key of 
>> algorithm A;
>>   
>right
>
>> For the "==>", I think this is fairly reasonable especially for 
>> terminal devices. If an device want to save resouce, it 
>probably just 
>> want the ability of playing one algorithm.
>>   
>If what is constrained is processing power, then it may make 
>sense to have a device that for instacne does not have a RSA 
>key, but it is capable of validating RSA signatures, since as 
>you mentioned above, validating RSA signatures is cheaper than 
>signing, right?
Even if  what is constrained is only processing power, installing RSA only
for validating RSA signature will not help saving power compared with ECC. I
mean, if a terminal can use ECDSA for signature, it can just use ECDSA for
validation,     
Comparing ECDSA validation speed and RSA validation speed is a little
complex: overall, RSA algirithm complexity increase exponentially while
ECDSA algorithm complexity increase sub-exponentialy; on the same level of
cryptographic strength, ECDSA validation is a little slower but on the same
level with RSA validation when key sizes are shorter than 300 bits, when key
sizes are over 300 bits, ECDSA validation is more and more faster than RSA
validation. 
So overall, if a terminal can use ECDSA, it does not need RSA only for
validation in order to save power. If the purpose is compatibility with old
RSA only routers, the RSA only nodes can not validate terminal's ECDSA
signature, SeND can not be performed anyway. 

>if we can asusme that all the nodes can validate rsa 
>signatures (even if they don't have an rsa key), this really 
>simplifies the problem imho
>
>>  But probably we
>> should include this question in the draft to ask the wg whether we 
>> have that luxury.
>>
>>
>>   
>>> possiblly save message round in negotiation, also easy for RADV 
>>> message. Clearly there will be a tradeoff of bandwidth and 
>>> negotiation simplicity, so I don't know.
>>>     
>>>>   
>>>>       
>>> the first one for compatibility with rsa-only node. And we have to 
>>> change the law in 3971 that all the options after signature option 
>>> should be ignored (ignored for both signature verification and NDP 
>>> processing purposes).
>>>     
>>>>   
>>>>       
>> options that come after the first RSA Signature option.  
>(The options 
>> are ignored for both signature verification and NDP processing 
>> purposes.) So This law has to be changed if new SeND message want to 
>> carry multiple signatures, don't know yet whether it can 
>cause trouble.
>>   
>signatures but i guess we will need to update rfc3971 to 
>support crypto agility, so no problem here
>
>> For the order of these signatures on a SeND message, (if rsa 
>signature 
>> is
>> used) the RSA signaure should be the first one, otherwise an old 
>> RSA-only node can not recognize ECC PDS & signature options 
>before the 
>> rsa signature option.
>right

What I mean is that keeping rsa first itself is an ordering action.

>> this order
>> may not match the order of user's preference of different 
>algorithms, 
>> maybe it's doable, I haven't think of other negative reasons, but 
>> seems to me it's not an very comfortable way.
>>
>>   
>don't see a problem here

Ok. So the only tradeoff is about bandwidth and negotiation simplicity.

>>>>>> suppose the cert is signed with RSA -one case is that the node 
>>>>>> that has a ECC based CGA, and only
>>>>>>       
>>>>>>           
>>>>> supports ECC
>>>>>     
>>>>>         
>talking to 
>>> a old rsa-only host, the router can trust the host, but the 
>host can 
>>> not trust the router because the host don't understand ecc. 
>So can we 
>>> conclude that knowing an extra rsa in this case does not help?
>>>     
>>>>   
>>>>       
>>> not sure i understand
>>> in the case we were cosndiering above, the cert is signed with RSA, 
>>> so if the node understand RSA it can validate the cert, so problem 
>>> solved...
>>>     
>> For example, one side use RSA signature, the other side use ECDSA, 
>> when they are both able to validate two algorithms, SeND can be 
>> performed. Is my understanding correct?
>>   
>yes
>
>> If we allow this happen, what if one algorithm is not safe anymore, 
>> then one node can not enforce to use a secure algorithm and 
>the other 
>> node can choose the unsecure algorithm.
>>
>>   

Ok, agree. Negotions will work here. A node can indicate the accepted
algorithms and reject unaccepted.  

best, 

Sean

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 18 Dec 2008 10:24:08 +0100

> we should not consider one particular algorithm different from others.
but the fact is that rsa is different cause it is alreadys pecified, and 
the cga have by default an rsa key and so on

> want ECC for key size and speed reasons, this requirement is not proper.  
but you mentioned that RSA validation is cheaper than rsa signing, so 
maybe these light weigth nodes can do rsa valdiation...

My point is unless we properly scope the types of nodes we want to 
support and what are the requirements, we are arguing in the abstract. I 
guess niether you nor me can have an auhtoritative voice on this... 
maybe we should ask some people more involved on these light weight 
devices to figure out what are reasonable assumptions to make.

> sizes are over 300 bits, ECDSA validation is more and more faster than RSA
right, i am not arguing with that
I am just saying that there are 3 levels of power and CPU and memory 
consuption
The lowest level if ECC only
The intermediate level is ECC and RSA validation
The highest level is ECC and RSA validation plus RSA signing (wihc 
requires having a RSA key pair)

I guess the point is whehter the intermediate level is good enough or we 
need to aim for the lowest level

> signature, SeND can not be performed anyway. 
well, the node could trust the router and verify the prefixes and the 
default gateway, but i agree that we can't do full send

regards, marcelo

---

From: Sean Shen <[email-masked]>
Date: Thu, 18 Dec 2008 18:34:54 +0800

>multi-key 
>processing 
>>> ok, so do you think is reasonable to impose that all nodes must be 
>>> able to validate RSA signatures? (even light weigth nodes?)
>>>     
>> I don't think the it's proper to impose all nodes must be able to 
>> validate RSA signature. Especially when we are looking for general 
>> agility solutions, we should not consider one particular 
>algorithm different from others.
>>   
>but the fact is that rsa is different cause it is alreadys 
>pecified, and the cga have by default an rsa key and so on
>
>> Besides, to impose rsa validation is too strong, for the nodes which 
>> only want ECC for key size and speed reasons, this 
>requirement is not proper.
>>
>>   
>but you mentioned that RSA validation is cheaper than rsa 
>signing, so maybe these light weigth nodes can do rsa valdiation...

Yes, they can do it if power consumption is the only constraint.

>
>My point is unless we properly scope the types of nodes we 
>want to support and what are the requirements, we are arguing 
>in the abstract. I guess niether you nor me can have an 
>auhtoritative voice on this... 
>maybe we should ask some people more involved on these light 
>weight devices to figure out what are reasonable assumptions to make.
>
Light weight devices venders and CHES conference people will be interested
in this. Wider comments will be helpful, I will go ahead and explore. 

>> Even if  what is constrained is only processing power, 
>installing RSA 
>> only for validating RSA signature will not help saving power 
>compared 
>> with ECC. I mean, if a terminal can use ECDSA for signature, 
>it can just use ECDSA for
>> validation,     
>> complex: overall, RSA algirithm complexity increase exponentially 
>> while ECDSA algorithm complexity increase sub-exponentialy; on the 
>> same level of cryptographic strength, ECDSA validation is a little 
>> slower but on the same level with RSA validation when key sizes are 
>> shorter than 300 bits, when key sizes are over 300 bits, ECDSA 
>> validation is more and more faster than RSA validation.
>>   
>I am just saying that there are 3 levels of power and CPU and 
>memory consuption The lowest level if ECC only The 
>intermediate level is ECC and RSA validation The highest level 
>is ECC and RSA validation plus RSA signing (wihc requires 
>having a RSA key pair)
>
>I guess the point is whehter the intermediate level is good 
>enough or we need to aim for the lowest level
Personally I think this depend on different devices, also depend on an
vendor's preference: an Certicom product probably don't want RSA at all, an
EMC product may not like ECDSA either, an third vendor might try to gain
best compatibility if device ability alowed... 
I think this is a important one, we will include this question in the draft
for more comments.

>> validation in order to save power. If the purpose is compatibility 
>> with old RSA only routers, the RSA only nodes can not validate 
>> terminal's ECDSA signature, SeND can not be performed anyway.
>>
>>   
>well, the node could trust the router and verify the prefixes 
>and the default gateway, but i agree that we can't do full send
>

best,

Sean

---

From: Tony Cheneau <[email-masked]>
Date: Thu, 18 Dec 2008 16:26:01 +0100 (CET)

Hi Marcelo and Sean,

Comments inline.

[...]

> but the fact is that rsa is different cause it is alreadys pecified, and the 
> cga have by default an rsa key and so on
I agree with Sean. RSA as already been specified, but at least, if we want
to include a support for RSA, it must be a "SHOULD" rather than a
"MUST".

> but you mentioned that RSA validation is cheaper than rsa signing, so maybe 
> these light weigth nodes can do rsa valdiation...
>
> My point is unless we properly scope the types of nodes we want to support 
> and what are the requirements, we are arguing in the abstract. I guess 
> niether you nor me can have an auhtoritative voice on this... maybe we should 
> ask some people more involved on these light weight devices to figure out 
> what are reasonable assumptions to make.
Concerning  this point, an intern in our lab wrote a report on CGA/SEND
performances using ECC/ECDSA (not only that, but this is was is
concerning us here).
You can download it at:
http://www-lor.int-evry.fr/%7Emaknavic/Rapports_Recherche/RR-Boudguiga-CGA-Performance.zip
Interesting part are in Chapter 5, especially when comparing CGA
signature generation/verification time between RSA and ECDSA and also in
lightweight nodes (a Nokia Tablet PC).
It may help have a more realistic comparison between RSA and ECDSA.

> The highest level is ECC and RSA validation plus RSA signing (wihc requires 
> having a RSA key pair)
>
> I guess the point is whehter the intermediate level is good enough or we need 
> to aim for the lowest level
Maybe it sounds stupid, but maybe we should allow the 3 levels at once
in the spec. Each administrator will then choose the more suited
solution. To me (from a practical standpoint), we can have the 3 levels
without increasing complexity.

Regards,
 	Tony

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 18 Dec 2008 20:40:27 +0100

Tony Cheneau escribió:
>>> validate
>> but the fact is that rsa is different cause it is alreadys pecified, 
>> and the cga have by default an rsa key and so on
>> support and what are the requirements, we are arguing in the 
>> abstract. I guess niether you nor me can have an auhtoritative voice 
>> on this... maybe we should ask some people more involved on these 
>> light weight devices to figure out what are reasonable assumptions to 
>> make.

good input!
>> I guess the point is whehter the intermediate level is good enough or 
>> we need to aim for the lowest level
but imho the key question is whether we can assume that everyone is able 
to validate RSA or not
supporting the 3 levels as you say, basically means you cannot assume 
that and all the simplicatins that would result from that would vanish
(i mean, if a device has an RSA key, then he can assume that everynode 
will be able to validate its signature for instance

Regards, marcelo