From nobody Tue Mar 5 14:33:56 2019 Return-Path: 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 C46FD131083 for ; Tue, 5 Mar 2019 14:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2CE_m5w9wAax for ; Tue, 5 Mar 2019 14:33:53 -0800 (PST) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A19F1293B1 for ; Tue, 5 Mar 2019 14:33:53 -0800 (PST) Received: by mail-wr1-x430.google.com with SMTP id w6so11223794wrs.4 for ; Tue, 05 Mar 2019 14:33:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=P30cUfYGCuxswKO73IHcvLyoiDDBxHUbBBuSq4AIprs=; b=k4HabUn7rf1UFn3NaPXWkFxlJdrdBSZ2Bts1vSmlhF8fg5R2Z2pcrOZUU3MlmfgLzL B8KWgkOUj4suoh6QuYxaLjr8SbeWV3iM6Rkzwtlq5P2tV1MufaEVRk2LEoXbfHqpOrWM pKM14eQp5WepeQXgTPEQV9S1dFO0DncRXabqanRcim030yp2uTgauEiEls35/4P6xpxj 42xH/qWt3OGWGQaE+bxMukxZsQEFuXUCQFJR0rQ0t7YzjIVaIoJa5C33mjph1nzmGm+f bolKwflCFXEWcO7oNueVRQqqeipjsN3rVrg4SuXCPz7fR8+cYV3zs8IebHlJFTc2DMSE mbpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=P30cUfYGCuxswKO73IHcvLyoiDDBxHUbBBuSq4AIprs=; b=cR82FarkHRTtfqxeIrIfD3xNk1dxxmgYZKDp87ebmVdVBBn8nqJBUbpbHHgWskEClU AuNXw9l289bzfdUJFSCX7v9kcfIXJcOurOQv3FhTN4Qsx0RYgl6uAE6noxKizOjLiISv EAFBNK9ktFg/Qy+Bbh3mSPbmp5LWBz5Cvy6kwiweODFq2WU3Ix2s6Be/mLtiLfDmWreg AwH0L9rfxfKS9FhdyVXzCOU3c3ZyQavqPDC9hxgL4kEnMIz2/bmJA7Di0/YjIF+Rm7ff zNYzwPulxf6MA1MfffZLu+32/sfpJI7BqMF7/MFitkoRIkeNi8Vr2+wCfFZG0rpYdog7 +H0g== X-Gm-Message-State: APjAAAVYQLCI2t6gZSlYIBD3JN2gE8nPvE5wLvbpaD6m52hsme4pxhMB Hc5Yi+uxIoffQsHAV1/A0zHCnDFuY8dB1KLMfv5fGbtC X-Google-Smtp-Source: APXvYqyCKcyxNX0kZSDTX176YycCnlmsGmyqgJbUvyEDaA1nQMzWH6vi+0JoEdxsK9wAUN1TinJZIwrQ+0fqiRirw+c= X-Received: by 2002:adf:fc49:: with SMTP id e9mr810255wrs.2.1551825231891; Tue, 05 Mar 2019 14:33:51 -0800 (PST) MIME-Version: 1.0 From: Alberto Leiva Date: Tue, 5 Mar 2019 16:33:41 -0600 Message-ID: To: sidr@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [sidr] How are thisUpdate and nextUpdate supposed to be formatted? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 22:33:56 -0000 Hello. I'm having a bit of trouble implementing RFC 6486 (RPKI Manifests). In section 4.2, 6486 defines thisUpdate and nextUpdate as GeneralizedTimes: Manifest ::= SEQUENCE { (...) thisUpdate GeneralizedTime, nextUpdate GeneralizedTime, (...) } (https://tools.ietf.org/html/rfc6486#section-4.2) During section 4.2.1, it further states the following: thisUpdate: This field contains the time when the manifest was created. This field has the same format constraints as specified in [RFC5280] for the CRL field of the same name. Problem: RFC 5280 (https://tools.ietf.org/html/rfc5280#section-5.1) defines both CRL fields as Times, not as GeneralizedTimes. Time ::= CHOICE { utcTime UTCTime, generalTime GeneralizedTime } (...) TBSCertList ::= SEQUENCE { (...) thisUpdate Time, nextUpdate Time OPTIONAL, (...) } Further, 5280 states that the usage choice is not arbitrary, but rather, depends on the value that's being conveyed: CRL issuers conforming to this profile MUST encode thisUpdate as UTCTime for dates through the year 2049. CRL issuers conforming to this profile MUST encode thisUpdate as GeneralizedTime for dates in the year 2050 or later. Conforming applications MUST be able to process dates that are encoded in either UTCTime or GeneralizedTime. What I find really strange is that 5280 has rather little to say about thisUpdate in particular, aside from its apparent contradiction to 6486. So when 6486 does little more than reference 5280... what am I supposed to implement? Thanks in advance, Alberto From nobody Tue Mar 5 15:12:05 2019 Return-Path: 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 0E0CA131119 for ; Tue, 5 Mar 2019 15:11:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] 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 9d20VIajKkXt for ; Tue, 5 Mar 2019 15:11:54 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1BC131116 for ; Tue, 5 Mar 2019 15:11:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8E732300AAD for ; Tue, 5 Mar 2019 17:53:36 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id kFQ20Jfhu1xf for ; Tue, 5 Mar 2019 17:53:35 -0500 (EST) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 1357830041F; Tue, 5 Mar 2019 17:53:35 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Russ Housley In-Reply-To: Date: Tue, 5 Mar 2019 18:11:50 -0500 Cc: IETF SIDR Content-Transfer-Encoding: quoted-printable Message-Id: <80A72EB4-1A58-4C2A-8021-2F2AF8857DBF@vigilsec.com> References: To: Alberto Leiva X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [sidr] How are thisUpdate and nextUpdate supposed to be formatted? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 23:12:04 -0000 RFC 5280 says: 5.1.2.4. This Update This field indicates the issue date of this CRL. So, in this case, it should contain the date that the manifest is = created. RFC 5280 supports two date formats for backward compatibility with = X.509v1. In this case, only one format is supported, GeneralizedTime, so the full = 4-digit year is used. RFC 5280 says: 5.1.2.5. Next Update This field indicates the date by which the next CRL will be issued. CRLs might be issued early, but this is a promise that a fresh one will = be issued on or before the nextUpdate date. So, in this case, it is a promise that a manifest will be issued on or = before the nextUpdate date. Russ > On Mar 5, 2019, at 5:33 PM, Alberto Leiva wrote: >=20 > Hello. >=20 > I'm having a bit of trouble implementing RFC 6486 (RPKI Manifests). >=20 > In section 4.2, 6486 defines thisUpdate and nextUpdate as = GeneralizedTimes: >=20 > Manifest ::=3D SEQUENCE { > (...) > thisUpdate GeneralizedTime, > nextUpdate GeneralizedTime, > (...) > } >=20 > (https://tools.ietf.org/html/rfc6486#section-4.2) >=20 > During section 4.2.1, it further states the following: >=20 > thisUpdate: > This field contains the time when the manifest was created. This > field has the same format constraints as specified in [RFC5280] > for the CRL field of the same name. >=20 > Problem: RFC 5280 (https://tools.ietf.org/html/rfc5280#section-5.1) > defines both CRL fields as Times, not as GeneralizedTimes. >=20 > Time ::=3D CHOICE { > utcTime UTCTime, > generalTime GeneralizedTime } >=20 > (...) >=20 > TBSCertList ::=3D SEQUENCE { > (...) > thisUpdate Time, > nextUpdate Time OPTIONAL, > (...) } >=20 > Further, 5280 states that the usage choice is not arbitrary, but > rather, depends on the value that's being conveyed: >=20 > CRL issuers conforming to this profile MUST encode thisUpdate as > UTCTime for dates through the year 2049. CRL issuers conforming to > this profile MUST encode thisUpdate as GeneralizedTime for dates in > the year 2050 or later. Conforming applications MUST be able to > process dates that are encoded in either UTCTime or GeneralizedTime. >=20 > What I find really strange is that 5280 has rather little to say about > thisUpdate in particular, aside from its apparent contradiction to > 6486. So when 6486 does little more than reference 5280... what am I > supposed to implement? >=20 > Thanks in advance, > Alberto >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Wed Mar 6 15:44:01 2019 Return-Path: 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 13DC812008A for ; Wed, 6 Mar 2019 15:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 65RkIeQV05Jt for ; Wed, 6 Mar 2019 15:43:59 -0800 (PST) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 768B21310ED for ; Wed, 6 Mar 2019 15:43:58 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id w6so15350695wrs.4 for ; Wed, 06 Mar 2019 15:43:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PCTV1CWyX6jd9s+RfyoNXuS//AW6NpB3TBBhnzFkyvg=; b=U0ukNa5g+bQ8VPJ3ugJJhqS5VuC23xw8Ogf9gme7R+G3CbLdNpWa2agcd0M9dw9Yh3 Qj1u+2sCMEaHpmE6m/mjKMx8xL0BNmcIUQ4YqCmmpXxuXj9JTM3q7ni12gjJNWe1Mgkj Qd38ECjTLvLe/IYXpgQYqYdLLx1XThqOfFpYrhH9iM4PlJ45qncptznVNGMkPk0jPjkh MoLUK2V5f9bq3q9/fuybDgmH3QhgHaygbuoRmqhaIcNFyJs22A4sZq0Anb5PHhGGhQ9Q EXMpxkPj5ffwOxQ0NX4nybKwVlNny9fbGXBs4NNOL77jXH3UIXXJsseag5Jwd5xXNDkz pNBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PCTV1CWyX6jd9s+RfyoNXuS//AW6NpB3TBBhnzFkyvg=; b=ta10dvil71ZutyOMjoTpGfBKjehpm44+1Jbq0V0H3V5SHJAOjq/neMoRxkxer+/OBt zwicmQM2EpnyuJXT3nAW0gQXsNgG3flySAtYKF6IaGw0tP31qAY0iFiFhgW2PljLyan0 ZCVR++vQlmttQ/fofzQKFDBksj1y79CRE3msk6XZwoKuuozimpoKT9eJT2h2xdqDVYVP 28XltVyV+vty9iCkDgt06NZOiTHIMhMMHdI43a8yxyOHOo6XLzXPZMATuyBTKXqj73HP yqNqzGDwpX6hEj0VlxEGCHxKySv9J1/D8vy75v/58Ad2di0NxqDCTGxACOAy68GGijzQ RHQg== X-Gm-Message-State: APjAAAUT1bQBBH7ZIKGp8jhNycPbpVyKJX8vRgZ1bVetPv+z2LFaZWl1 bfVcKWsEC23xmLiZhFSiN+GvDTP3IYN56IoMRPHIjw== X-Google-Smtp-Source: APXvYqyyQ94t4e7ritHa+eVZTFODRWGJYYQXsZlCJLSzHBbl/fDJSy9VbblU6tH9QS0XZqiLqRAGmOSa1bIzvcojLOI= X-Received: by 2002:adf:fc49:: with SMTP id e9mr5033250wrs.2.1551915836887; Wed, 06 Mar 2019 15:43:56 -0800 (PST) MIME-Version: 1.0 References: <80A72EB4-1A58-4C2A-8021-2F2AF8857DBF@vigilsec.com> In-Reply-To: <80A72EB4-1A58-4C2A-8021-2F2AF8857DBF@vigilsec.com> From: Alberto Leiva Date: Wed, 6 Mar 2019 17:43:45 -0600 Message-ID: To: Russ Housley Cc: IETF SIDR Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [sidr] How are thisUpdate and nextUpdate supposed to be formatted? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 23:44:01 -0000 Thank you for the clarification. On Tue, Mar 5, 2019 at 5:11 PM Russ Housley wrote: > > RFC 5280 says: > > 5.1.2.4. This Update > > This field indicates the issue date of this CRL. > > So, in this case, it should contain the date that the manifest is created. > > RFC 5280 supports two date formats for backward compatibility with X.509v1. > > In this case, only one format is supported, GeneralizedTime, so the full 4-digit year is used. > > RFC 5280 says: > > 5.1.2.5. Next Update > > This field indicates the date by which the next CRL will be issued. > > CRLs might be issued early, but this is a promise that a fresh one will be issued on or before the nextUpdate date. > > So, in this case, it is a promise that a manifest will be issued on or before the nextUpdate date. > > Russ > > > > > On Mar 5, 2019, at 5:33 PM, Alberto Leiva wrote: > > > > Hello. > > > > I'm having a bit of trouble implementing RFC 6486 (RPKI Manifests). > > > > In section 4.2, 6486 defines thisUpdate and nextUpdate as GeneralizedTimes: > > > > Manifest ::= SEQUENCE { > > (...) > > thisUpdate GeneralizedTime, > > nextUpdate GeneralizedTime, > > (...) > > } > > > > (https://tools.ietf.org/html/rfc6486#section-4.2) > > > > During section 4.2.1, it further states the following: > > > > thisUpdate: > > This field contains the time when the manifest was created. This > > field has the same format constraints as specified in [RFC5280] > > for the CRL field of the same name. > > > > Problem: RFC 5280 (https://tools.ietf.org/html/rfc5280#section-5.1) > > defines both CRL fields as Times, not as GeneralizedTimes. > > > > Time ::= CHOICE { > > utcTime UTCTime, > > generalTime GeneralizedTime } > > > > (...) > > > > TBSCertList ::= SEQUENCE { > > (...) > > thisUpdate Time, > > nextUpdate Time OPTIONAL, > > (...) } > > > > Further, 5280 states that the usage choice is not arbitrary, but > > rather, depends on the value that's being conveyed: > > > > CRL issuers conforming to this profile MUST encode thisUpdate as > > UTCTime for dates through the year 2049. CRL issuers conforming to > > this profile MUST encode thisUpdate as GeneralizedTime for dates in > > the year 2050 or later. Conforming applications MUST be able to > > process dates that are encoded in either UTCTime or GeneralizedTime. > > > > What I find really strange is that 5280 has rather little to say about > > thisUpdate in particular, aside from its apparent contradiction to > > 6486. So when 6486 does little more than reference 5280... what am I > > supposed to implement? > > > > Thanks in advance, > > Alberto > > > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr >