[CGA-EXT] about draft-krishnan-cgaext-send-cert-eku-03.txt
marcelo bagnulo braun <marcelo@it.uc3m.es> Sat, 14 March 2009 14:38 UTC
Return-Path: <marcelo@it.uc3m.es>
X-Original-To: cga-ext@core3.amsl.com
Delivered-To: cga-ext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2EAC3A6A05 for <cga-ext@core3.amsl.com>; Sat, 14 Mar 2009 07:38:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.422
X-Spam-Level:
X-Spam-Status: No, score=-6.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j84vZiU5ctaa for <cga-ext@core3.amsl.com>; Sat, 14 Mar 2009 07:38:07 -0700 (PDT)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id C522D3A68A6 for <cga-ext@ietf.org>; Sat, 14 Mar 2009 07:38:05 -0700 (PDT)
Received: from marcelo-bagnulos-macbook-pro.local (205.pool85-53-145.dynamic.orange.es [85.53.145.205]) by smtp02.uc3m.es (Postfix) with ESMTP id 104AC6563F7; Sat, 14 Mar 2009 15:38:40 +0100 (CET)
Message-ID: <49BBC170.4010008@it.uc3m.es>
Date: Sat, 14 Mar 2009 15:38:40 +0100
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Suresh Krishnan <suresh.krishnan@ericsson.com>, Ana Kukec <anchie@fer.hr>, cga-ext@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16518.007
Subject: [CGA-EXT] about draft-krishnan-cgaext-send-cert-eku-03.txt
X-BeenThere: cga-ext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: CGA and SeND Extensions <cga-ext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cga-ext>
List-Post: <mailto:cga-ext@ietf.org>
List-Help: <mailto:cga-ext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Mar 2009 14:38:08 -0000
Hi, good work I think this is in good shape, but i am really far from being an expert on this (as my question below reflect) I have some comments and questions. 2. Introduction Secure Neighbor Discovery [RFC3971] Utilizes X.509v3 certificates for performing router authorization. It uses the X.509 extension for IP addresses to verify whether the router is authorized to advertise the mentioned IP addresses. s/addresses/prefixes The SEND specification does not describe the set of extensions that need to be supported This is strictly true, right? I mean section 6.3.1. Router Authorization Certificate Profile of the send spec does define the cert profile. 4.1. Extended Key Usage Values The inclusion of the router authorization value indicates that the certificate has been issued for allowing the router to advertise prefix(es) that are mentioned using the X.509 extensions for IP addresses and AS identifiers [RFC3779] I understnad that this means that the router is auhtorized to advertise the prefix included in the RADV ND message, right? I think this shoudl be described more explicitly, I mean, the main contribution of the draft is to define these EKU, so it should if very precisely, right? would these apply to DHCP prefix delegation for instance? The inclusion of the owner authorization value indicates that the certificate has been issued for allowing the node to use the address(es) or prefix(es) that are mentioned using the X.509 extensions for IP addresses and AS identifiers [RFC3779] i am not sure what do you mean about this Are you aiming for the case we use SEND with non cga addresses? If so, it should be more clearly stated. In particualr, i fail to understnad why a host could announce more that one address i.e. why prefixes are acceptbale. Maybe describing thesecould help then the draft reads: Inclusion of multiple values indicates that the certified public key is appropriate for use by a node performing more than one of these functions. send-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) TBA1 } id-kp-sendRouter OBJECT IDENTIFIER ::= { send-kp 1 } id-kp-sendProxy OBJECT IDENTIFIER ::= { send-kp 2 } id-kp-sendOwner OBJECT IDENTIFIER ::= { send-kp 3 } I don't understnad what do you mean by the data strcuture you include here... could you clarify? (is it just an example? if, so, please tag it as one) then... Certificate-using applications MAY require the extended key usage extension to be present in a certificate, and they MAY require a particular KeyPurposeId value to be present (such as id-kp-sendRouter or id-kp-sendProxy) where are these keypurposeid are defined? maybe additng a reference would be useful then it reads 5. Backward Compatibility The disadvantages of this model are related to the fact that the SEND specification was developed before the standardization of the RPKI. Hence, SEND is not completely compliant with the RPKI specifications since it defines its own IP prefix validation routine and it is not suitable for the use with CRLs, while the RPKI suports only CRLs. This means that SEND implementations supporting this profile will not be able to interoperate with legacy SEND implementations. I don't fully understnad the implications of this I mean, what needs to be changed in a current send implementation to be compatible with this new format? I mean, the optimal would be that current send implementations accept RPKI certs but skip the new extensions and that new send implementations are able to read the new extensions defined by this document. is this not possible? I am missing the part where you actually defines the EKU values for the 3 usages you have defined... wouldn't this be in the IANA cosiderations part of the draft? If not, shouldn't this be somehwere else? I mean, i understnad you are assigning 3 values of a registry for that usage? Or does this work in a different way? Regards, marcelo
- [CGA-EXT] about draft-krishnan-cgaext-send-cert-e… marcelo bagnulo braun
- Re: [CGA-EXT] about draft-krishnan-cgaext-send-ce… Ana Kukec
- Re: [CGA-EXT] about draft-krishnan-cgaext-send-ce… marcelo bagnulo braun
- Re: [CGA-EXT] about draft-krishnan-cgaext-send-ce… Ana Kukec
- Re: [CGA-EXT] about draft-krishnan-cgaext-send-ce… marcelo bagnulo braun
- Re: [CGA-EXT] about draft-krishnan-cgaext-send-ce… Ana Kukec