Re: [pkix] I-D Action:draft-ietf-pkix-new-asn1-07.txt

Paul Hoffman <phoffman@imc.org> Tue, 01 September 2009 00:19 UTC

Return-Path: <phoffman@imc.org>
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 376FE3A6933 for <pkix@core3.amsl.com>; Mon, 31 Aug 2009 17:19:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.563
X-Spam-Level:
X-Spam-Status: No, score=-5.563 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 ye1-uHm+5vM8 for <pkix@core3.amsl.com>; Mon, 31 Aug 2009 17:19:34 -0700 (PDT)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 427043A6B30 for <pkix@ietf.org>; Mon, 31 Aug 2009 17:19:33 -0700 (PDT)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n810Jgi6048184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Aug 2009 17:19:44 -0700 (MST) (envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p06240804c6c2176686e4@[10.20.30.158]>
In-Reply-To: <4A9C49F7.5020908@ieca.com>
References: <20090814011501.D7C073A696C@core3.amsl.com> <4A9C2028.2060500@ieca.com> <p06240808c6c1d5f72291@[10.20.30.158]> <4A9C49F7.5020908@ieca.com>
Date: Mon, 31 Aug 2009 17:19:42 -0700
To: Sean Turner <turners@ieca.com>
From: Paul Hoffman <phoffman@imc.org>
Content-Type: text/plain; charset="us-ascii"
Cc: pkix@ietf.org
Subject: Re: [pkix] I-D Action:draft-ietf-pkix-new-asn1-07.txt
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Sep 2009 00:19:35 -0000

At 6:08 PM -0400 8/31/09, Sean Turner wrote:
>Paul Hoffman wrote:
>>draft-ietf-pkix-new-asn1 has a module for RFC 3281. Jim and I believe that the module in our draft matches RFC 3281 correctly.
>
>Not debating this.

Good. But...

>
>>We can add another module that reflects draft-ietf-pkix-3281update-05.txt  (there is no draft-ietf-pkix-3281bis). However, we do not have any Internet Drafts in draft-ietf-pkix-new-asn1, and I personally think that it is unwise for us to add one at this late state. We could also wait for draft-ietf-pkix-3281update-05.txt to be published as an RFC and add a module for it to draft-ietf-pkix-new-asn1.
>
>I don't think it's too late in the process. 

Agree.

>I'd rather fix this error now than have to publish another RFC later.

Above, you said you were not debating that our module in the draft matches RFC 3281 correctly. Where's the error? Or, did you mean "omission", meaning we do not yet have a module for draft-ietf-pkix-3281update?

>>Personally, I think it is wrong to change the module for RFC 3281 to change bits on the wire from what is represented in RFC 3281.
>
>We did an update ID and it's passed PKIX WG LC and IETF LC and is now sitting in the RFC editor's queue pinned in a cluster with 7 other documents waiting on draft-ietf-pkix-sha2-dsa-ecdsa.  Other than this procedural issue, we'd probably not be having this conversation because it would be an RFC. 

If the WG asks us to add a new module for this draft, we're happy to do it.

>But since draft-ietf-pkix-3281update is already in the RFC editor's queue, I think it's pretty clear that the community wants this change incorporated in to any update of RFC 3281 and in my mind that includes draft-ietf-pkix-new-asn1.  I think it would be bad to have an updated RFC 3281 module that incorporates changes and an RFC with a later number that includes an ASN.1 module that essentially undoes the fixes.  Can't we just assume draft-ietf-pkix-3281update should pop out of the RFC editor's queue first (if only by hours/days) and just make this change now? 

Sure. But early on, there was an agreement that we were adding modules for RFCs, not Internet Drafts. This is the first we have heard of a request for this Internet Draft.

>If not, then I'd advocate waiting for draft-ietf-pkix-3281update to be published as an RFC and adding the updated RFC 3281 module to draft-ietf-pkix-new-asn1.

We could do that as well.

>
>In the original message, I forgot to add that we also need to include the following:
>
> -- Uncomment the following lines to support deprecated clearance
> -- syntax and comment out previous Clearance.
>
> -- Clearance ::= SEQUENCE {
> --  policyId            [0] OBJECT IDENTIFIER,
> --  classList           [1] ClassList DEFAULT {unclassified},
> --  securityCategories  [2] SET OF SecurityCategory  OPTIONAL
> -- }

The WG has to decide whether to document RFC 3281, your non-compatible change, or both. You're assuming on the second choice, but I would rather hear from more people before we change our draft. Our draft is still technically in WG Last Call; the chairs haven't closed it after a month.