IETF Logo Mail Archive

Re: [sidr] Validation reconsidered and X.509v3 extension OIDs

Tim Bruijnzeels <tim@ripe.net> Wed, 20 July 2016 14:52 UTC

Return-Path: <tim@ripe.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67FAD12B031 for <sidr@ietfa.amsl.com>; Wed, 20 Jul 2016 07:52:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.187
X-Spam-Level:
X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnZ707BH30Oo for <sidr@ietfa.amsl.com>; Wed, 20 Jul 2016 07:52:55 -0700 (PDT)
Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B18512B032 for <sidr@ietf.org>; Wed, 20 Jul 2016 07:52:55 -0700 (PDT)
Received: from nene.ripe.net ([193.0.23.10]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from <tim@ripe.net>) id 1bPsrj-0009XM-EM; Wed, 20 Jul 2016 16:52:52 +0200
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-118.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1bPsrj-000214-8F; Wed, 20 Jul 2016 16:52:51 +0200
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset="us-ascii"
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <1c97d2b8-485d-b208-8cf9-43fdcf27646a@bbn.com>
Date: Wed, 20 Jul 2016 16:52:51 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <C5B75708-CB4B-48B9-81B6-AF9BEC2A2F84@ripe.net>
References: <20160719111830.12A97412B25E@minas-ithil.hactrn.net> <1c97d2b8-485d-b208-8cf9-43fdcf27646a@bbn.com>
To: Stephen Kent <kent@bbn.com>
X-Mailer: Apple Mail (2.3124)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: ----------
X-RIPE-Spam-Report: Spam Total Points: -10.7 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071908b09aa541a7f6d23e750d8be8b6fa3d
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/3vruDfE4_x2Sfu__GIJaWGjPC6U>
Cc: sidr@ietf.org
Subject: Re: [sidr] Validation reconsidered and X.509v3 extension OIDs
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jul 2016 14:52:59 -0000

Hi,

So, to be clear I think this is the related text in section 9 of RFC 6487:

   A new document will be issued as an update to this RFC.  The CP for
   the RPKI [RFC6484] will be updated to reference the new certificate
   profile.  The new CP will define a new policy OID for certificates
   issued under the new certificate profile.

And references in 6484 (CP) to 6487 should be reviewed and reference the validation-reconsidered instead (since it updates the profile), and we should have another OID instead of the one section 1.2. But there is no need to use a different OID for the RFC3779 extensions used. Right?

..just trying to make sure I am looking at the right things here, please correct me if the above is wrong.

Thanks
Tim







> On 20 Jul 2016, at 16:22, Stephen Kent <kent@bbn.com> wrote:
> 
> Rob,
> 
> I agree with your suggestion to create a new OID for this purpose. This can be noted in the document under discussion.
> 
> I also agree with Russ's comment that the cert policy needs to be updated to reflect the fact that use either OID is OK (if we stick with one policy OID).
> 
> Steve
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

v2.23.0 | Report a Bug | By Email