Hi, As we agreed in the last CSI meeting, we are issuing the WGLC for draft-ietf-csi-sndp-prob-00.txt Please review the document and send comments before Dec 30 2008. for you convenience, the document can be found at: http://tools.ietf.org/id/draft-ietf-csi-sndp-prob-00.txt Regards, marcelo
Hi, the draft minutes are available at: http://www.ietf.org/proceedings/08nov/minutes/csi.txt Thanks TJ for taking them Send me any comments or corrections that you think are needed. Regards, marcelo
Hi,
there have been some discussion about how to support multiple public key
algorithms in CGAs.
I include some thoughts below to continue the discussion
RFC3972 states that only RSA are supported and there is a mandatory
Public Key filed in the CGA PDS that contains:
The public key MUST be formatted as a DER-encoded
[ITU.X690.2002] ASN.1 structure of the type SubjectPublicKeyInfo,
defined in the Internet X.509 certificate profile [RFC3280]. SEND
SHOULD use an RSA public/private key pair. When RSA is used, the
algorithm identifier MUST be rsaEncryption, which is
1.2.840.113549.1.1.1, and the RSA public key MUST be formatted by
using the RSAPublicKey type as specified in Section 2.3.1 of RFC
3279 [RFC3279]. The RSA key length SHOULD be at least 384 bits.
Other public key types are undesirable in SEND, as they may result
in incompatibilities between implementations. The length of this
field is determined by the ASN.1 encoding.
So we have two options to support alternative public key algorithms in CGAs:
- one option is to allow to include a public key of another algortihm in
the Public Key field. In order to do that, we must provide a way to tell
which algorithm is used.
According to RFC3280,
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }
and
(Continue reading)
hi, Marcelo, We (Tony, Micheala, Mariline and me) are writing two drafts for the agility work: one is the agility support for CGA, the other is the agility support for SeND. Basically the CGA agility will simply let an CGA associated with multiple public keys, in the extension part of Public Key field in the CGA PDS. SeND Agility will deal with how to get agreement on an algorithm which both nodes can use in SeND. We separate the job of two protocols to clarify roles of CGA and SeND in agility, such that CGA will provide enough support when it is used in protocols other than SeND We just had a discussion last night and made more improvement. Tony is sorting out our discussions and will soon send our detailed answer soon. Best, Sean >-----Original Message----- >From: cga-ext-bounces@... >[mailto:cga-ext-bounces@...] On Behalf Of marcelo bagnulo braun >Sent: Monday, December 15, 2008 2:41 AM >To: cga-ext@... >Subject: [CGA-EXT] Public Key algorithm agility in CGAs > >Hi, > >there have been some discussion about how to support multiple >public key algorithms in CGAs. >I include some thoughts below to continue the discussion > >RFC3972 states that only RSA are supported and there is a >mandatory Public Key filed in the CGA PDS that contains:(Continue reading)
Hello Marcelo, As Sean stated, we (Michaela, Sean, Maryline and I) are currently working on some solutions for the problems you exposed. Unfortunately, we didn't finish writing the drafts yet. The comments during the last WG meeting provided us some really good insight. We hope this discussion will make clearer what is possible and what is not. I will try to explain how we envision to solve theses problems. Comments inline. On Sun, 14 Dec 2008, marcelo bagnulo braun wrote: > Hi, > > there have been some discussion about how to support multiple public key > algorithms in CGAs. We think multiple keys can be a good transition mechanism in network that are (or will be) deployed with 3971 version of SEND. I explain why this is good and how we can make it backward compatible with the actual SEND specification. > RFC3972 states that only RSA are supported and there is a mandatory Public > Key filed in the CGA PDS that contains: > > The public key MUST be formatted as a DER-encoded > [ITU.X690.2002] ASN.1 structure of the type SubjectPublicKeyInfo, > defined in the Internet X.509 certificate profile [RFC3280]. SEND > SHOULD use an RSA public/private key pair. When RSA is used, the > algorithm identifier MUST be rsaEncryption, which is(Continue reading)
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(Continue reading)
Hi tony, thanks for the answer your points seem reasonable to me and i am expecting to draft to comment further. please check the other mail i sent about interop, you may want to cover these as well in your draft. some replies in line... Tony Cheneau escribió: > Hello Marcelo, > > As Sean stated, we (Michaela, Sean, Maryline and I) are currently > working on > some solutions for the problems you exposed. Unfortunately, we didn't > finish > writing the drafts yet. The comments during the last WG meeting > provided us > some really good insight. We hope this discussion will make clearer > what is > possible and what is not. > > I will try to explain how we envision to solve theses problems. Comments > inline. > > > On Sun, 14 Dec 2008, marcelo bagnulo braun wrote:(Continue reading)
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: > - 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(Continue reading)
Tony Cheneau escribió: > 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: >> - 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(Continue reading)
Hi again, Comments inline. On Mon, 15 Dec 2008, marcelo bagnulo braun wrote: [...] >> > 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(Continue reading)
RSS Feed8 | |
|---|---|
1 | |
1 | |
1 | |
1 | |
11 | |
1 | |
6 | |
4 | |
9 | |
16 | |
19 | |
9 | |
7 | |
21 | |
27 | |
21 | |
33 | |
4 | |
8 | |
26 | |
1 | |
3 | |
21 | |
4 | |
16 | |
42 | |
6 | |
6 | |
22 | |
1 | |
30 | |
25 | |
12 | |
2 | |
1 |
