From sidr-bounces@ietf.org Wed Apr 04 00:58:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYxZ8-0005RA-9N; Wed, 04 Apr 2007 00:57:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYxZ6-0005R4-TB for sidr@ietf.org; Wed, 04 Apr 2007 00:57:48 -0400 Received: from geoff.telstra.net ([203.50.0.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYxZ5-0000PR-2o for sidr@ietf.org; Wed, 04 Apr 2007 00:57:48 -0400 Received: from gihm3.apnic.net (dhcp4.potaroo.net [203.10.60.4]) by geoff.telstra.net (8.13.6/8.13.6) with ESMTP id l344vc6G099866; Wed, 4 Apr 2007 14:57:38 +1000 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20070404142624.015c32f8@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 04 Apr 2007 14:59:01 +1000 To: Robert Kisteleki , sidr@ietf.org From: Geoff Huston Subject: Re: [Sidr] draft-ietf-sidr-res-certs-05.txt comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org At 08:38 PM 26/03/2007, Robert Kisteleki wrote: >Hello, > >Please find my comments below for discussion. Thank you indeed for this review. I've responded to each of your comments in turn. I have raised some followup questions in some of these response, and I'd appreciate your views on these questions! Geoff >1. Typo at the bottom of page 6: RSA-SHA-384 OID is {pkcs-1 12}, not >{pkcs-1 11} agreed >2. In 3.9.5: Just as with the AIA, CRLDP should not appear in a root >certificate. I looked for this in RFC3280 and could not find such a constraint for CRLDP, but could find it for the AIA. I propose adding the text to the CRLDP section (3.9.5) This extension MUST be present and it is non-critical. [new text ->] There is one exception; where a CA distributes its public key in the form of a "self-signed" certificate, the CRLDP MUST be omitted. I also propose adding the following para to the AIA section (3.9.6) As noted in Section 4.2.1.1 of RFC3280, there is one exception; where a CA distributes its public key in the form of a "self-signed" certificate, the authority key identifier MAY be omitted. >3.In 4, last paragraph: "... Where two or more CRLs issued by a >single CA are present in a certificate repository, the CRL with the >highest value of the "CRL Number" field supersedes all other CRLs >issued by this CA." > >When doing a rekey, a CA may have more than one key pair working in >parallel, therefore must issue more than one CRL. In this case, the >highest CRL number does not supersede all CRLs by that CA. I've consulted section 5.2.3 of RFC 3280 and the text is that a CRL Number "conveys a monotonically increasing sequence number for a given CRL scope and CRL issuer. This extension allows users to easily determine when a particular CRL supersedes another CRL." Section 4 of this draft already defines the scope as "all certificates issued by this CA" and the "The CRL Issuer is the CA" So even when re-keying in the CA, RFC3280 appears to indicate that the highest CRL supersedes all other CRL. I don't propose changing the text at this point, as it appears that the draft's text is already consistent with RFC 3280. (I must admit that I'm a bit at sea when thinking about a certificate issued with CA's key pair A being revoked with CA's key pair B, but my interpretation of the text in 3280 appear to allow precisely that!) >4. In 4.5, Signature can be RSA-SHA-256 only. Looking back at 3.3, I >miss RSA-SHA-384 and RSA-SHA-512 from here. There is no a priori requirement that the same algorithms options be present for CRLs. and yes, the profile says only SHA-256. Do you see merit in adding RSA-SHA-384 and RSA-SHA-512 for CRLs? >5. In 5, I miss an introductory paragraph stating something like "a >resource certificate request can be either PKCS#10 or CRMF". Without >it, it is quite unclear why two different request formats are described below. ok - I'll add "A resource certificate request MAY use either of PKCS#10 or Certificate Request Message Format (CRMF). There is no requirement for a CA Issuer to support both request formats, and the choice of formats is a matter for the Issuer and Subject to resolve." Is this suitable? >6. In 5.1.1, signatureAlgorithm: again RSA-SHA-384 and RSA-SHA-512 >options are missing. noted - new text added as per 3.3 >7. In 5.2.2, Resource Class: As the subject can also use PKCS#10 >which does not have this option, I don't really see why is this >field is a MUST. Also, when generating a request, the subject may >not be aware of exactly which resource class that request/keypair >will be used with, in which case this field cannot be filled in. Yes, it appears that the subject and issuer have to figure out which CA is the target of the request through mechanisms other than control fields in the request itself. I'll remove the test. Should Authenticator Control be removed as well? >8. Section 5.3 starts with "This profile allows the following >extensions to appear..." and then goes on describing fields which >"MUST be omitted". I find this a bit confusing. rewording : "The following extensions may appear in a PKCS#10 or CRMF Certificate Request. This profile places the following additional constraints on these extensions." >9. Section 5.3 lists the "SubjectInformationAccess" field twice, >with slightly different text. I believe the second appearance should >be simply omitted. agreed >10. Same duplicate with SubjectAlternateName (also in 5.3). agreed >11. At the very end of 5.3: I think the CA should not alter the >SubjectInformationAccess requested by the subject. There is a reason >why the subject asked for any particular URL: that is the adress >they will be able to publish to. If the CA deliberately changes >this, then the subject may end up with an unusable certificate. agreed s/MAY/MUST/ >12. In 6.1 we see "The only exception to the "no loop" condition >would be where a putative trust anchor may issue a self-signed root >certificate." This is confusing: "a self-signed certificate" by >definition cannot be issued by anyone else but itself. The may be >signed by the trust anchor key though. Its probably better to remove this sentence, and add the following The trust anchor information, describing a CA that serves as a trust anchor, includes the following: (1) the trusted issuer name, (2) the trusted public key algorithm, (3)the trusted public key, (4)optionally, the trusted public key parameters associated with the public key, and (5) a resource set, consisting of a set of IPv4 resources, IPv6 resources and AS number resources. The trust anchor information may be provided to the path processing procedure in the form of a self-signed certificate. >13. In 6.3.: "... from the Root Trust Anchors via ..." The term >"Root Trust Anchor" is strange for me. > s/Root Trust Anchor/trust anchor CAs/ ? >14. In the example in Appendix A, the SIA value is syntactically >wrong according to 3.9.7, as it does not end with '/'. Also, >although it is theoretically not wrong, I miss the '.cer' extension >from the end of the AIA value. > will fix! >Cheers, >Robert thanks, Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Apr 04 04:03:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ0RP-0006eZ-8S; Wed, 04 Apr 2007 04:02:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ0RN-0006d8-U3 for sidr@ietf.org; Wed, 04 Apr 2007 04:02:01 -0400 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ0RM-0008G6-Ek for sidr@ietf.org; Wed, 04 Apr 2007 04:02:01 -0400 Received: by postman.ripe.net (Postfix, from userid 4008) id D7BCF2418F; Wed, 4 Apr 2007 10:01:53 +0200 (CEST) Received: from herring.ripe.net (herring.ripe.net [193.0.1.203]) by postman.ripe.net (Postfix) with ESMTP id 2807E24073; Wed, 4 Apr 2007 10:01:53 +0200 (CEST) Received: from [127.0.0.1] (chimp.ripe.net [193.0.1.199]) by herring.ripe.net (Postfix) with ESMTP id 22DFC2F583; Wed, 4 Apr 2007 10:01:53 +0200 (CEST) Message-ID: <46135B6E.4060507@ripe.net> Date: Wed, 04 Apr 2007 10:01:50 +0200 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Geoff Huston Subject: Re: [Sidr] draft-ietf-sidr-res-certs-05.txt comments References: <7.0.0.16.2.20070404142624.015c32f8@apnic.net> In-Reply-To: <7.0.0.16.2.20070404142624.015c32f8@apnic.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_05 X-RIPE-Spam-Status: N 0.192750 / -2.9 X-RIPE-Signature: 1a21997b9f08ca176d54c34f4a45fb8f X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org Hello, > (I must admit that I'm a bit at sea when thinking about a certificate > issued with CA's key pair A being revoked with CA's key pair B, but my > interpretation of the text in 3280 appear to allow precisely that!) We may have to ask for some guidance from the PKIX folk on this one. >> 4. In 4.5, Signature can be RSA-SHA-256 only. Looking back at 3.3, I >> miss RSA-SHA-384 and RSA-SHA-512 from here. > > There is no a priori requirement that the same algorithms options be > present for CRLs. and yes, the profile says only SHA-256. Do you see > merit in adding RSA-SHA-384 and RSA-SHA-512 for CRLs? It only seems logical to allow it here too. >> 7. In 5.2.2, Resource Class: As the subject can also use PKCS#10 which >> does not have this option, I don't really see why is this field is a >> MUST. Also, when generating a request, the subject may not be aware of >> exactly which resource class that request/keypair will be used with, >> in which case this field cannot be filled in. > > Yes, it appears that the subject and issuer have to figure out which CA > is the target of the request through mechanisms other than control > fields in the request itself. I'll remove the test. > > Should Authenticator Control be removed as well? I believe it could be useful, so we probably want allow it. >> 12. In 6.1 we see "The only exception to the "no loop" condition would >> be where a putative trust anchor may issue a self-signed root >> certificate." This is confusing: "a self-signed certificate" by >> definition cannot be issued by anyone else but itself. The may be >> signed by the trust anchor key though. > > Its probably better to remove this sentence, and add the following > > The trust anchor information, describing a CA that serves as a trust > anchor, includes the following: > (1) the trusted issuer name, > (2) the trusted public key algorithm, > (3)the trusted public key, > (4)optionally, the trusted public key parameters associated with the > public key, and > (5) a resource set, consisting of a set of IPv4 resources, IPv6 > resources and AS number resources. > > The trust anchor information may be provided to the path processing > procedure in the form of a self-signed certificate. I believe that regarding a TA: - (1) is optional - (5) is optional - A URL for top-down chaining (practically a "starting SIA") is useful, therefore optional. Cheers, Robert > thanks, > > Geoff > > _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Apr 04 05:04:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ1OU-0008Sk-8D; Wed, 04 Apr 2007 05:03:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ1OS-0008Nr-Sb for sidr@ietf.org; Wed, 04 Apr 2007 05:03:04 -0400 Received: from geoff.telstra.net ([203.50.0.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ1OR-0007JY-6C for sidr@ietf.org; Wed, 04 Apr 2007 05:03:04 -0400 Received: from gihm3.apnic.net (dhcp4.potaroo.net [203.10.60.4]) by geoff.telstra.net (8.13.6/8.13.6) with ESMTP id l3492sdt001099; Wed, 4 Apr 2007 19:02:54 +1000 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20070404185505.0274db78@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 04 Apr 2007 19:04:17 +1000 To: Robert Kisteleki From: Geoff Huston Subject: Re: [Sidr] draft-ietf-sidr-res-certs-05.txt comments In-Reply-To: <46135B6E.4060507@ripe.net> References: <7.0.0.16.2.20070404142624.015c32f8@apnic.net> <46135B6E.4060507@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org >>The trust anchor information, describing a CA that serves as a >>trust anchor, includes the following: >> (1) the trusted issuer name, >> (2) the trusted public key algorithm, >> (3)the trusted public key, >> (4)optionally, the trusted public key parameters associated with >> the public key, and >> (5) a resource set, consisting of a set of IPv4 resources, IPv6 >> resources and AS number resources. >>The trust anchor information may be provided to the path processing >>procedure in the form of a self-signed certificate. > >I believe that regarding a TA: >- (1) is optional >- (5) is optional >- A URL for top-down chaining (practically a "starting SIA") is >useful, therefore optional. Hmm - 1 through 4 are a direct cut and past from RFC3280 - I don't see the logic that turns (1) into optional here given that it is part of the trust anchor information describing a trusted CA. (5) is based on the implications of a resource certificate attribute - saying you trust a given CA is fine, but in the context of a resource PKI the statement is "I trust a CA with regard to being authoritative to certify the following resources. Accordingly, (5) does not appear to be optional in this context. I note that any reference to an SIA is not present in RFC 3280 - given that this document defines a particular profile of that specification for use in a RPKI context, then why is a URL necessary here in this profile, but not in the more general case as described in RFC3280? thanks, Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Apr 04 10:11:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6Bw-0000QA-Il; Wed, 04 Apr 2007 10:10:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6Bu-0000Q0-Je for sidr@ietf.org; Wed, 04 Apr 2007 10:10:26 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ6Bt-00068g-Ae for sidr@ietf.org; Wed, 04 Apr 2007 10:10:26 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HZ6Bq-0004Ya-3r; Wed, 04 Apr 2007 10:10:22 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <7.0.0.16.2.20070404142624.015c32f8@apnic.net> References: <7.0.0.16.2.20070404142624.015c32f8@apnic.net> Date: Wed, 4 Apr 2007 10:10:20 -0400 To: Geoff Huston From: Stephen Kent Subject: Re: [Sidr] draft-ietf-sidr-res-certs-05.txt comments Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org At 2:59 PM +1000 4/4/07, Geoff Huston wrote: >... >>3.In 4, last paragraph: "... Where two or more CRLs issued by a >>single CA are present in a certificate repository, the CRL with the >>highest value of the "CRL Number" field supersedes all other CRLs >>issued by this CA." >> >>When doing a rekey, a CA may have more than one key pair working in >>parallel, therefore must issue more than one CRL. In this case, the >>highest CRL number does not supersede all CRLs by that CA. > >I've consulted section 5.2.3 of RFC 3280 and the text is that a CRL >Number "conveys a monotonically increasing sequence number for a >given CRL scope and CRL issuer. This extension allows users to >easily determine when a particular CRL supersedes another CRL." > >Section 4 of this draft already defines the scope as "all >certificates issued by this CA" and the "The CRL Issuer is the CA" > >So even when re-keying in the CA, RFC3280 appears to indicate that >the highest CRL supersedes all other CRL. When a CA is re-keyed, that establishes a new scope, so there will be two CRL sequences, one for the old key and one for the new key. I realized this last year when Robert and I were discussing this topic and I sent a message trying to clarify the conclusion we reached back then. Both the old and new CRLs need to be present in parallel, until all the old certs expire or until the old CA cert expires, whichever comes first. The sequences for both sets of CRLs are numbered independently. >>4. In 4.5, Signature can be RSA-SHA-256 only. Looking back at 3.3, >>I miss RSA-SHA-384 and RSA-SHA-512 from here. > >There is no a priori requirement that the same algorithms options be >present for CRLs. and yes, the profile says only SHA-256. Do you see >merit in adding RSA-SHA-384 and RSA-SHA-512 for CRLs? all of the text that talks about multiple hash algorithms has a problem, i.e., it does not establish what a CA and an RP MUST support. We need to be more explicit here. We cannot allow a CA to use algorithms that we do not require ALL RPs to support. > >>12. In 6.1 we see "The only exception to the "no loop" condition >>would be where a putative trust anchor may issue a self-signed root >>certificate." This is confusing: "a self-signed certificate" by >>definition cannot be issued by anyone else but itself. The may be >>signed by the trust anchor key though. > >Its probably better to remove this sentence, and add the following > >The trust anchor information, describing a CA that serves as a trust >anchor, includes the following: > (1) the trusted issuer name, > (2) the trusted public key algorithm, > (3)the trusted public key, > (4)optionally, the trusted public key parameters associated with >the public key, and > (5) a resource set, consisting of a set of IPv4 resources, IPv6 >resources and AS number resources. > >The trust anchor information may be provided to the path processing >procedure in the form of a self-signed certificate. I agree with this TA description, although I would delete the word "trusted" from the items, because its redundant. 1-4 are defined in 3280 and 5 is defined as the additional set of parameters needed by 3779, so this is correct. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Apr 04 21:01:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZGLG-0004aQ-0w; Wed, 04 Apr 2007 21:00:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZGLE-0004aL-Ot for sidr@ietf.org; Wed, 04 Apr 2007 21:00:44 -0400 Received: from crash.telstra.net ([203.50.0.185] helo=dic-mail.telstra.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZGLB-0008U0-0W for sidr@ietf.org; Wed, 04 Apr 2007 21:00:44 -0400 Received: from gihm3.apnic.net (geoff.telstra.net [203.50.0.18]) by dic-mail.telstra.net (8.12.11/8.12.11) with ESMTP id l3510WRB016755; Thu, 5 Apr 2007 11:00:33 +1000 Message-Id: <7.0.0.16.2.20070405105606.0161ad80@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 05 Apr 2007 11:01:56 +1000 To: Robert Kisteleki , sidr@ietf.org From: Geoff Huston Subject: Re: [Sidr] draft-ietf-sidr-res-certs-05.txt comments In-Reply-To: <7.0.0.16.2.20070404142624.015c32f8@apnic.net> References: <7.0.0.16.2.20070404142624.015c32f8@apnic.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org > >>3.In 4, last paragraph: "... Where two or more CRLs issued by a >>single CA are present in a certificate repository, the CRL with the >>highest value of the "CRL Number" field supersedes all other CRLs >>issued by this CA." >> >>When doing a rekey, a CA may have more than one key pair working in >>parallel, therefore must issue more than one CRL. In this case, the >>highest CRL number does not supersede all CRLs by that CA. > >I've consulted section 5.2.3 of RFC 3280 and the text is that a CRL >Number "conveys a monotonically increasing sequence number for a >given CRL scope and CRL issuer. This extension allows users to >easily determine when a particular CRL supersedes another CRL." > >Section 4 of this draft already defines the scope as "all >certificates issued by this CA" and the "The CRL Issuer is the CA" > >So even when re-keying in the CA, RFC3280 appears to indicate that >the highest CRL supersedes all other CRL. > >I don't propose changing the text at this point, as it appears that >the draft's text is already consistent with RFC 3280. > >(I must admit that I'm a bit at sea when thinking about a >certificate issued with CA's key pair A being revoked with CA's key >pair B, but my interpretation of the text in 3280 appear to allow >precisely that!) After thinking about this some more, I propose the following text "The CRL Number extension conveys a monotonically increasing sequence number of positive integers for a given CA and scope. This extension allows users to easily determine when a particular CRL supersedes another CRL. The highest CRL Number value supersedes all other CRLs issued by the CA with the same scope." And to define the scope of the CRL in the PKI as follows: "The scope of the CRL MUST be "all certificates issued by this CA using a given key pair". The contents of the CRL are a list of all non-expired certificates issued by the CA using a given key pair that have been revoked by the CA. [...] The profile allows the issuance of multiple current CRLs with different scope by a single CA, with the scope being defined by the key pair used by the CA." Is this text clearer? Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Apr 04 22:36:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZHpL-0004Wv-3h; Wed, 04 Apr 2007 22:35:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZHpK-0004Wp-3d for sidr@ietf.org; Wed, 04 Apr 2007 22:35:54 -0400 Received: from mint.apnic.net ([202.12.29.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZHpI-0005l8-Am for sidr@ietf.org; Wed, 04 Apr 2007 22:35:54 -0400 Received: from [202.12.29.163] (dhcp163.apnic.net [202.12.29.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id DEB5AD5F31; Thu, 5 Apr 2007 12:35:46 +1000 (EST) Message-ID: <46146080.8000102@apnic.net> Date: Thu, 05 Apr 2007 12:35:44 +1000 From: Robert Loomans Organization: APNIC - http://www.apnic.net/ User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Geoff Huston Subject: Re: [Sidr] draft-ietf-sidr-res-certs-05.txt comments References: <7.0.0.16.2.20070404142624.015c32f8@apnic.net> <46135B6E.4060507@ripe.net> <7.0.0.16.2.20070404185505.0274db78@apnic.net> In-Reply-To: <7.0.0.16.2.20070404185505.0274db78@apnic.net> X-Enigmail-Version: 0.94.3.0 OpenPGP: id=C6B3AE7E; url=http://robert.loomans.org/0xC6B3AE7E.asc X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1638611021==" Errors-To: sidr-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1638611021== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000308090203010905050600" This is a cryptographically signed message in MIME format. --------------ms000308090203010905050600 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > I note that any reference to an SIA is not present in RFC 3280 - given > that this document defines a particular profile of that specification > for use in a RPKI context, then why is a URL necessary here in this > profile, but not in the more general case as described in RFC3280? I think it is in the nature of the PKI. Most other PKIs know a priori where to find the certificate store, or they are provided with the cert chain with a request. "Enterprise" applications are probably just know. For S/MIME, HTTPS and most other internet applications provide the cert chain. I don't believe that many other PKIs have the need to retrieve all of the published objects, starting just from TA material. I have echoes of a conversation with Steve Kent or Russ Housley playing in my head, but the closest I can come to a quote is that we appear to have one of the few useful applications of SIA. So I suspect that it just hasn't come up before. I think that the TA material in our profile appears to be (1) through (4) that we inherit from 3280, (5) that we get from 3779, and in this profile we should probably add a (6) for the URL.... Which will be the SIA, if the TA is provided as a self-signed cert. Alternatively, if there isn't a URL in the TA material, where do we start pulling pulling certs from? Rob -- Robert Loomans Email: robertl@apnic.net Programmer/Analyst, APNIC Phone: +61 7 3858 3100 http://www.apnic.net Fax: +61 7 3858 3199 --------------ms000308090203010905050600 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK5jCC BW8wggRXoAMCAQICAhmqMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UE ChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5h Z2VyQGFwbmljLm5ldDAeFw0wNjA4MTYyMzQ0MjJaFw0wNzA4MTYyMzQ0MjJaMEgxCzAJBgNV BAYTAkFQMREwDwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTAL BgNVBAUTBDY1NzAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDIGKArFelrgnyK QHEZnvLP8bvR3jwpKRmaBp8+PrCJRA8ELT3L4ZtY98cYyjAIfFYdt/n9gQjagRaltoEW4bkK Z9cS91onYYCt70xnMzwJrh3ms3rDUeXK5JQqUv3AYpQLfvC5ICV+FBNuIQ26b2hzUgiyOP89 Lc9YHJ2E02ACHKlfsYyWD/vWCd8UOQYyuijkPgHvCncHaEjuSekg8JnWqi9GQtWLt7EmtsLb /D8Yn6beScKex4KK2GZtD8fGyQoCXj25DBSU9OLXE8bDc0V1z8N/RU6TA8paLS+iculoBu1G NXRE3sdyTIS+OXsgwLh6xrY5Lnowow/HkQ7Ckn7hAgMBAAGjggIaMIICFjAJBgNVHRMEAjAA MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklD IENsaWVudCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQU3b65o54yQEQn+fF94hWGnIeCdlUwgbsG A1UdIwSBszCBsIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFV MQ4wDAYDVQQKEwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQD EyVBUE5JQyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkB FhNjYW1hbmFnZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0 MB4GA1UdEgQXMBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0 cHM6Ly93d3cuYXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0 dHBzOi8vd3d3LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZo dHRwczovL3d3dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOC AQEAjhazoKEg7sVuzPifVcwRZYSJq7JApAMyGx0RrxqtmMp/lp2vzB89ducRVq+FUfXQXaJc q4FZmJ+1WyncU/p6yJK0z6/FXMf/5eqk6PTC5NJt/yNBifYBV5MYCwuukY0c2b/io4JojR3D kfmuIkmbZPcCep6rDqrwLHIMLjZmL1U1uVlSnhbX8HdHrsURsroRtfXNlWYTnk/dFLBPRmIV 1RhjVODH72qw+fTcSNWWF5jcIPHXj6LeCxSm24xqbKzMuCEUgdWpFtlSK+utIWXrhvzOKK4C xOE1kPsx7lGfGZ+RsLtB6BGx5UC1NotAB9r2UBxkmiJV79kKjOE8rwMcgjCCBW8wggRXoAMC AQICAhmqMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMx GzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmlj Lm5ldDAeFw0wNjA4MTYyMzQ0MjJaFw0wNzA4MTYyMzQ0MjJaMEgxCzAJBgNVBAYTAkFQMREw DwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTALBgNVBAUTBDY1 NzAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDIGKArFelrgnyKQHEZnvLP8bvR 3jwpKRmaBp8+PrCJRA8ELT3L4ZtY98cYyjAIfFYdt/n9gQjagRaltoEW4bkKZ9cS91onYYCt 70xnMzwJrh3ms3rDUeXK5JQqUv3AYpQLfvC5ICV+FBNuIQ26b2hzUgiyOP89Lc9YHJ2E02AC HKlfsYyWD/vWCd8UOQYyuijkPgHvCncHaEjuSekg8JnWqi9GQtWLt7EmtsLb/D8Yn6beScKe x4KK2GZtD8fGyQoCXj25DBSU9OLXE8bDc0V1z8N/RU6TA8paLS+iculoBu1GNXRE3sdyTIS+ OXsgwLh6xrY5Lnowow/HkQ7Ckn7hAgMBAAGjggIaMIICFjAJBgNVHRMEAjAAMBEGCWCGSAGG +EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklDIENsaWVudCBD ZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQU3b65o54yQEQn+fF94hWGnIeCdlUwgbsGA1UdIwSBszCB sIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFVMQ4wDAYDVQQK EwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQDEyVBUE5JQyBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkBFhNjYW1hbmFn ZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0MB4GA1UdEgQX MBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0cHM6Ly93d3cu YXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0dHBzOi8vd3d3 LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwczovL3d3 dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAjhazoKEg 7sVuzPifVcwRZYSJq7JApAMyGx0RrxqtmMp/lp2vzB89ducRVq+FUfXQXaJcq4FZmJ+1Wync U/p6yJK0z6/FXMf/5eqk6PTC5NJt/yNBifYBV5MYCwuukY0c2b/io4JojR3DkfmuIkmbZPcC ep6rDqrwLHIMLjZmL1U1uVlSnhbX8HdHrsURsroRtfXNlWYTnk/dFLBPRmIV1RhjVODH72qw +fTcSNWWF5jcIPHXj6LeCxSm24xqbKzMuCEUgdWpFtlSK+utIWXrhvzOKK4CxOE1kPsx7lGf GZ+RsLtB6BGx5UC1NotAB9r2UBxkmiJV79kKjOE8rwMcgjGCA8YwggPCAgEBMIGVMIGOMQsw CQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNl czEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAG CSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmljLm5ldAICGaowCQYFKw4DAhoFAKCCAgUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDA1MDIzNTQ0WjAj BgkqhkiG9w0BCQQxFgQUG9WeiGgU+eqvipdxMYbe9QN8zn8wUgYJKoZIhvcNAQkPMUUwQzAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgaYGCSsGAQQBgjcQBDGBmDCBlTCBjjELMAkGA1UEBhMCQVUxDjAMBgNV BAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNVBAMTJUFQTklD IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0BCQEWE2NhbWFu YWdlckBhcG5pYy5uZXQCAhmqMIGoBgsqhkiG9w0BCRACCzGBmKCBlTCBjjELMAkGA1UEBhMC QVUxDjAMBgNVBAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNV BAMTJUFQTklDIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0B CQEWE2NhbWFuYWdlckBhcG5pYy5uZXQCAhmqMA0GCSqGSIb3DQEBAQUABIIBAHoLGXc7CjYl lP0FV1L5sRsqEQyW/N9xFkBryhEcXx4WNTebbX+DgAN2SyZ72wkZA5TKfNPcJpjw6Cks4nh9 vSVZgpa6zSs/lZCQXU9lZjisZKtxx5DLGVRJamTlucD23XkShaTEvqAMu26f9r2r3SLmw0Oe xG1BC45lBERAbjmR9gJpRScCqemmE5/hdzSjJtKzAFDh8hyDEldHXAmNaStEyKpgylMXJ9gs sO1WKFOS/C5GjAmxWUtRekzGBA8NFSN9BjoLYTm5vyf0on+Kd1dniM8H2FwMKa1AIPq6q165 ushPDgQlzrPam15hqOnu0inAcUXmBbVar3u+mQEvyngAAAAAAAA= --------------ms000308090203010905050600-- --===============1638611021== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr --===============1638611021==-- From sidr-bounces@ietf.org Fri Apr 06 17:29:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZvzL-0001dw-SP; Fri, 06 Apr 2007 17:28:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZvzK-0001aD-42 for sidr@ietf.org; Fri, 06 Apr 2007 17:28:54 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZvzI-0001RV-Ty for sidr@ietf.org; Fri, 06 Apr 2007 17:28:54 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HZvzD-0006ay-5a; Fri, 06 Apr 2007 17:28:47 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <7.0.0.16.2.20070405105606.0161ad80@apnic.net> References: <7.0.0.16.2.20070404142624.015c32f8@apnic.net> <7.0.0.16.2.20070405105606.0161ad80@apnic.net> Date: Fri, 6 Apr 2007 17:28:46 -0400 To: Geoff Huston From: Stephen Kent Subject: Re: [Sidr] draft-ietf-sidr-res-certs-05.txt comments Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org >... >After thinking about this some more, I propose the following text > > >"The CRL Number extension conveys a monotonically increasing >sequence number of positive integers for a given CA and scope. This >extension allows users to easily determine when a particular CRL >supersedes another CRL. The highest CRL Number value supersedes all >other CRLs issued by the CA with the same scope." > >And to define the scope of the CRL in the PKI as follows: The scope of the CRL is the set of certificates issued by this CA under a given key. Thus the CRL contains the list of all revoked, non-expired certificates issued by the CA using that key. >[...] > The profile allows the issuance of multiple current CRLs with different scope by a single CA, with the scope being defined by the key used by the CA. Thus if a CA acquires a new certificate, containing a new public key (a re-key of the CA), the CA will begin issuing a separate sequence of CRLs under that new key. In contrast, if a CA acquire a new certificate but uses the same public key in that certificate (a certificate renewal) the extant CRL sequence is maintained. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Apr 06 21:33:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZznK-0001tu-HN; Fri, 06 Apr 2007 21:32:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZznJ-0001tg-96 for sidr@ietf.org; Fri, 06 Apr 2007 21:32:45 -0400 Received: from geoff.telstra.net ([203.50.0.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZznB-00047l-GS for sidr@ietf.org; Fri, 06 Apr 2007 21:32:45 -0400 Received: from gihm3.apnic.net (gih-dialin.telstra.net [203.50.0.66] (may be forged)) by geoff.telstra.net (8.13.6/8.13.6) with ESMTP id l371WHxT072201; Sat, 7 Apr 2007 11:32:18 +1000 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20070407113156.0037c6c8@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Sat, 07 Apr 2007 11:33:36 +1000 To: Stephen Kent From: Geoff Huston Subject: Re: [Sidr] draft-ietf-sidr-res-certs-05.txt comments In-Reply-To: References: <7.0.0.16.2.20070404142624.015c32f8@apnic.net> <7.0.0.16.2.20070405105606.0161ad80@apnic.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org At 07:28 AM 7/04/2007, Stephen Kent wrote: >>... >>After thinking about this some more, I propose the following text >> >> >>"The CRL Number extension conveys a monotonically increasing >>sequence number of positive integers for a given CA and scope. This >>extension allows users to easily determine when a particular CRL >>supersedes another CRL. The highest CRL Number value supersedes all >>other CRLs issued by the CA with the same scope." >> >>And to define the scope of the CRL in the PKI as follows: > >The scope of the CRL is the set of certificates issued by this CA >under a given key. Thus the CRL contains the list of all revoked, >non-expired certificates issued by the CA using that key. > >>[...] >The profile allows the issuance of multiple current CRLs with >different scope by a single CA, with the scope being defined by the >key used by the CA. Thus if a CA acquires a new certificate, >containing a new public key (a re-key of the CA), the CA will begin >issuing a separate sequence of CRLs under that new key. In contrast, >if a CA acquire a new certificate but uses the same public key in >that certificate (a certificate renewal) the extant CRL sequence is maintained. thanks Steve for this text - I agree with this description of the CRL scope (as does Rob Kisteleki I believe), and I will add this text to the draft. regards, Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Apr 10 10:44:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbHZd-0008C0-AI; Tue, 10 Apr 2007 10:43:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbHZc-0008Bu-AN for sidr@ietf.org; Tue, 10 Apr 2007 10:43:56 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbHZa-0006BL-SP for sidr@ietf.org; Tue, 10 Apr 2007 10:43:56 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HbHZW-0005SY-4p for sidr@ietf.org; Tue, 10 Apr 2007 10:43:50 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20070327221703.EC8873F474@pecan.tislabs.com> References: <20070327221703.EC8873F474@pecan.tislabs.com> Date: Tue, 10 Apr 2007 10:43:47 -0400 To: sidr@ietf.org From: Stephen Kent X-Spam-Score: 0.7 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Subject: [Sidr] new ROA format X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1712064672==" Errors-To: sidr-bounces@ietf.org --===============1712064672== Content-Type: multipart/alternative; boundary="============_-1035906266==_ma============" --============_-1035906266==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Folks, In response to the discussion on the list, and at the meeting, I want to suggest a new format for ROAs, which addresses some of the issues that have been discussed. First, I note that the original format reused much of the RFC 3779 format for representing address space. However, on further reflection, we should probably use a smaller subset of that format, just the part that represents address prefixes, not address ranges. I say that because we will be using the content of a ROA to generate route filters or in a similar fashion, and BGP advertises only prefixes, not the arbitrary ranges that 3779 can express. Making a change just to accommodate prefixes (vs. ranges) we get some simplification of the format: RouteOriginAttestation ::= SEQUENCE { version [0] INTEGER DEFAULT 0, asID ASID, ipAddrBlocks ROAIPAddrBlocks } ASID ::= INTEGER ROAIPAddrBlocks ::= SEQUENCE of ROAIPAddressFamily ROAIPAddressFamily ::= SEQUENCE { addressFamily OCTET STRING (SIZE (2..3)), addresses SEQUENCE OF IPAddress } -- Only two address families are allowed: IPv4 and IPv6 IPAddress ::= BIT STRING Note that this is just a subset of the 3779 ASN.1, so it retains the advantage of reusing that syntax, and that should make comparison against the cert used to verify a ROA easier than if we adopt a different syntax. It allows multiple prefixes to be associated with one AS in each ROA. Additionally, there were suggestions about what controls we should make available to a ROA signer, to express the semantics of the ROA. The simplest one, other than my ill-conceived exact match suggestion, was a proposal by Geoff for a flag to say exact match vs. inclusion. There was also a suggestion from Curtis to allow for a mask length range, e.g., prefix/len1 [-len2]. Larry enumerated 4 prefix range operators taken from RPSL, which support even more expressiveness. It is important to note that the ASCII syntax used in the latter two suggestions above is not directly compatible with the ASN.1 used in 3779. That prefix syntax is binary, and RFC 3779 has defined a canonical representation for it already (something we do for most digitally signed objects). So we would need to employ a different encoding to represent any of these more sophisticated prefix expression options, if we still want to keep the syntax in the ROA easy to match against the 3779 extension in the cert. Another observation is that an address space holder can generate multiple ROAs to express constraints that might not be expressible via a single ROA if we adopt less expressive prefix range controls. Of course we have to balance complexity of such controls against the repository bloat that could arise if one had to generate lots of ROAs. So, I'd like to ask the WG what level of expressiveness do we believe is required in ROAs? For example, what has the experience been using the RPSL range operators, e.g., do we see IRR entries that use all four of the ones Larry cited, or do most entries use only a subset, and if so, which subset? Can we get by with just a flag indicating whether a ROA confers authorization to advertise exactly the prefix contained in it, or the prefix and all more specifics? Since the RIRs and others are already developing code to deal with ROAs, it is important that we make progress on selecting format sooner, rather than later :-) . Steve --============_-1035906266==_ma============ Content-Type: text/html; charset="us-ascii" new ROA format
Folks,

In response to the discussion on the list, and at the meeting, I want to suggest a new format for ROAs, which addresses some of the issues that have been discussed.

First, I note that the original format reused much of the RFC 3779 format for representing address space.  However, on further reflection, we should probably use a smaller subset of that format, just the part that represents address prefixes, not address ranges. I say that because we will be using the content of a ROA to generate route filters or in a similar fashion, and BGP advertises only prefixes, not the arbitrary ranges that 3779 can express.  Making a change just to accommodate prefixes (vs. ranges) we get some simplification of the format:

      RouteOriginAttestation ::= SEQUENCE {
        version [0] INTEGER DEFAULT 0,
        asID   ASID,
        ipAddrBlocks ROAIPAddrBlocks }
 
      ASID ::= INTEGER
   
      ROAIPAddrBlocks ::= SEQUENCE of ROAIPAddressFamily
   
      ROAIPAddressFamily ::= SEQUENCE {
        addressFamily OCTET STRING (SIZE (2..3)),
        addresses SEQUENCE OF IPAddress }
      -- Only two address families are allowed: IPv4 and IPv6
   
      IPAddress ::= BIT STRING

Note that this is just a subset of the 3779 ASN.1, so it retains the advantage of reusing that syntax, and that should make comparison against the cert used to verify a ROA easier than if we adopt a different syntax. It allows multiple prefixes to be associated with one AS in each ROA.

Additionally, there were suggestions about what controls we should make available to a ROA signer, to express the semantics of the ROA. The simplest one, other than my ill-conceived exact match suggestion, was a proposal by Geoff for a flag to say exact match vs. inclusion. There was also a suggestion from Curtis to allow for a mask length range, e.g., prefix/len1 [-len2].  Larry enumerated 4 prefix range operators taken from RPSL, which support even more expressiveness.

It is important to note that the ASCII syntax used in the latter two suggestions above is not directly compatible with the ASN.1 used in 3779. That prefix syntax is binary, and RFC 3779 has defined a canonical representation for it already (something we do for most digitally signed objects). So we would need to employ a different encoding to represent any of these more sophisticated prefix expression options, if we still want to keep the syntax in the ROA easy to match against the 3779 extension in the cert.

Another observation is that an address space holder can generate multiple ROAs to express constraints that might not be expressible via a single ROA if we adopt less expressive prefix range  controls.  Of course we have to balance complexity of such controls against the repository bloat that could arise if one had to generate lots of ROAs.

So, I'd like to ask the WG what level of expressiveness do we believe is required in ROAs? For example, what has the experience been using the RPSL range operators, e.g., do we see IRR entries that use all four of the ones Larry cited, or do most entries use only a subset, and if so, which subset? Can we get by with just a flag indicating whether a ROA confers authorization to advertise exactly the prefix contained in it, or the prefix and all more specifics?

Since the RIRs and others are already developing code to deal with ROAs, it is important that we make progress on selecting format sooner, rather than later :-) .

Steve



--============_-1035906266==_ma============-- --===============1712064672== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr --===============1712064672==-- From sidr-bounces@ietf.org Tue Apr 10 15:51:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbMLx-00076T-2x; Tue, 10 Apr 2007 15:50:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbMLs-00075m-IR; Tue, 10 Apr 2007 15:50:04 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbMLs-0000kZ-Ad; Tue, 10 Apr 2007 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 8414032912; Tue, 10 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HbMLq-0002n0-E6; Tue, 10 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 10 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: sidr@ietf.org Subject: [Sidr] I-D ACTION:draft-ietf-sidr-res-certs-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Profile for X.509 PKIX Resource Certificates Author(s) : G. Huston, et al. Filename : draft-ietf-sidr-res-certs-06.txt Pages : 30 Date : 2007-4-10 This document defines a standard profile for X.509 certificates for the purposes of supporting validation of assertions of "right-to-use" of an Internet Number Resource (IP Addresses and Autonomous System Numbers). This profile is used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of- use" of the IP addresses and AS numbers that are described in the associated Resource Certificate. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-res-certs-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sidr-res-certs-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sidr-res-certs-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-10141709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sidr-res-certs-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sidr-res-certs-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-10141709.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Tue Apr 10 18:28:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbOoU-0001P0-Kg; Tue, 10 Apr 2007 18:27:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbOoU-0001NG-3A for sidr@ietf.org; Tue, 10 Apr 2007 18:27:46 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbOoR-0000JB-Qe for sidr@ietf.org; Tue, 10 Apr 2007 18:27:46 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 10 Apr 2007 18:27:43 -0400 X-IronPort-AV: i="4.14,392,1170651600"; d="scan'208"; a="118180466:sNHT45189088" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3AMRhcs032542; Tue, 10 Apr 2007 18:27:43 -0400 Received: from [64.101.199.95] (dhcp-64-101-199-95.cisco.com [64.101.199.95]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3AMRhGd026470; Tue, 10 Apr 2007 22:27:43 GMT Message-ID: <461C0F5E.5080909@cisco.com> Date: Tue, 10 Apr 2007 18:27:42 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Stephen Kent Subject: Re: [Sidr] new ROA format References: <20070327221703.EC8873F474@pecan.tislabs.com> In-Reply-To: X-Enigmail-Version: 0.94.3.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1367; t=1176244063; x=1177108063; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[Sidr]=20new=20ROA=20format |Sender:=20 |To:=20Stephen=20Kent=20; bh=Zaf+4UutqODLJpNOkOYwBrd67o6zvvk6X18KvJ7WKmQ=; b=kv1NRgS9G+Ta1VO/KF7hmbP/Q2N9izuhvWcR5wVHI51V27jg7JJQVjyu3ZPIIQ8+4PRP5Ojm FAoxpnYdOZZDX2bx5UP3lGv/OruSLgRDyJd+6swZzlYoEEVBxKBNpZOK; Authentication-Results: rtp-dkim-1; header.From=riw@cisco.com; dkim=pass (si g from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Note that this is just a subset of the 3779 ASN.1, so it retains the > advantage of reusing that syntax, and that should make comparison > against the cert used to verify a ROA easier than if we adopt a > different syntax. It allows multiple prefixes to be associated with one > AS in each ROA. I would much prefer to see the prefix/length format in the ROA, just from the operational usefulness and human readability perspectives.... > Additionally, there were suggestions about what controls we should make > available to a ROA signer, to express the semantics of the ROA. The > simplest one, other than my ill-conceived exact match suggestion, was a > proposal by Geoff for a flag to say exact match vs. inclusion. I would really like to see this suggestion incorporated. > There was > also a suggestion from Curtis to allow for a mask length range, e.g., > prefix/len1 [-len2]. Larry enumerated 4 prefix range operators taken > from RPSL, which support even more expressiveness. I'm ambivalent on this one. Either way is fine with me. :-) Russ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGHA9eER27sUhU9OQRAmwtAJ9542ilwQ+MiBUAc+rEMvEINnp5/ACgk0jD MOZIL/7jtsj/Ax9HbjcLE7I= =I9/w -----END PGP SIGNATURE----- _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Apr 16 12:06:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTic-0003dG-FG; Mon, 16 Apr 2007 12:06:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTia-0003cz-PY for sidr@ietf.org; Mon, 16 Apr 2007 12:06:16 -0400 Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdTiZ-0006Ci-Ig for sidr@ietf.org; Mon, 16 Apr 2007 12:06:16 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l3GG4MnX007809 for ; Mon, 16 Apr 2007 12:04:22 -0400 (EDT) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAxla48o; Mon, 16 Apr 07 12:02:51 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 5E61C3F463; Mon, 16 Apr 2007 12:01:44 -0400 (EDT) To: sidr@ietf.org Message-Id: <20070416160144.5E61C3F463@pecan.tislabs.com> Date: Mon, 16 Apr 2007 12:01:44 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: sandy@tislabs.com Subject: [Sidr] last opportunity to amend minutes X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org I set Apr 9 as the deadline for minutes changes, which is a week ago. I'll be uploading the minutes real soon now (they must be in by Friday), so if you have changes you meant to make (especially if you know who Mr. XX is), please post to the list even sooner now. --Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr