IETF Logo Mail Archive

Re: [netmod] x509c2n:cert-to-name problem

Randy Presuhn <randy_presuhn@alumni.stanford.edu> Tue, 29 October 2019 16:24 UTC

Return-Path: <randy_presuhn@alumni.stanford.edu>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D67120071 for <netmod@ietfa.amsl.com>; Tue, 29 Oct 2019 09:24:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 kYSmKWk8v-gO for <netmod@ietfa.amsl.com>; Tue, 29 Oct 2019 09:24:57 -0700 (PDT)
Received: from mail-pf1-f196.google.com (mail-pf1-f196.google.com [209.85.210.196]) (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 CDC2A12006E for <netmod@ietf.org>; Tue, 29 Oct 2019 09:24:57 -0700 (PDT)
Received: by mail-pf1-f196.google.com with SMTP id c7so8758981pfo.12 for <netmod@ietf.org>; Tue, 29 Oct 2019 09:24:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=UrFgUtV8ZBOXjwUINs752G4hbYswXQRSFR7I8/Kze+k=; b=VOLpLIIT9A7d+pyV0o2duFg6H6IohMJOSKBbW2MbcWp3GNsHmzSeM0i55cL0Kh+MVM yyDL2MlYKomsKzIL3yDaRqoHB+88lRFeCs1ICh324si4M8zDjV21etU1PgDdqmDjFBhl n3Fy7D9wrjZsF9P4m4u5Y84tjJF2ccOUGwUYKzw9eyjYPtFpuUvwgcqTZdbASYLsXh42 Heng1vHmB3t877mXugva8TUXWq18YA+6TZPTTh9ChMx/zvAZdXZSbg4VrltGGuxV1bBR vLUxkMZ+9WkCB+pJsTjllXqZKF7FVAzPQLZJUv8jiVCsuh71CF6/btWtscq0XYZM0175 FxJQ==
X-Gm-Message-State: APjAAAWJxTMaDBKmS0EMvNCfLK1ZYJhC7CfOJpw1UPQFNytJJ/V7lNrz Mrb6rKxHhN/tiLEz69YTmkph5d5CwY0=
X-Google-Smtp-Source: APXvYqw+/kUkgFPJaHR3+KZ5C7kChg2i/uZXXfhBK5pPFsetqNc8H+LvFV17Futp4Smthh52ECz4Jg==
X-Received: by 2002:a63:81:: with SMTP id 123mr28899933pga.47.1572366296832; Tue, 29 Oct 2019 09:24:56 -0700 (PDT)
Received: from [192.168.1.105] (c-73-231-235-186.hsd1.ca.comcast.net. [73.231.235.186]) by smtp.gmail.com with ESMTPSA id l62sm15001333pfl.167.2019.10.29.09.24.56 for <netmod@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Oct 2019 09:24:56 -0700 (PDT)
To: "netmod@ietf.org" <netmod@ietf.org>
References: <0100016e0416c312-13b65019-1c32-4fc8-b8b2-f2b7cc591a00-000000@email.amazonses.com> <20191028.102216.1541488608391720310.mbj@tail-f.com> <f508c9f9-8493-88dc-7468-edc8dbe11776@alumni.stanford.edu> <20191029.105349.2169510354890358887.mbj@tail-f.com> <20191029100839.vzbnpaw5wv3xivr2@anna.jacobs.jacobs-university.de>
From: Randy Presuhn <randy_presuhn@alumni.stanford.edu>
Message-ID: <b832bfa1-5a55-5f98-e610-3eb37c59e5a6@alumni.stanford.edu>
Date: Tue, 29 Oct 2019 09:24:50 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0
MIME-Version: 1.0
In-Reply-To: <20191029100839.vzbnpaw5wv3xivr2@anna.jacobs.jacobs-university.de>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Antivirus: Avast (VPS 191028-0, 10/28/2019), Outbound message
X-Antivirus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/LmfyJkaeJISUd3CjNoClrkIqOD8>
Subject: Re: [netmod] x509c2n:cert-to-name problem
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Oct 2019 16:25:00 -0000

Hi -

> On Tue, Oct 29, 2019 at 10:53:49AM +0100, Martin Bjorklund wrote:
>> Randy Presuhn <randy_presuhn@alumni.stanford.edu> wrote:
>>> Hi -
>>>
>>> On 10/28/2019 2:22 AM, Martin Bjorklund wrote:
>>> ....
>>>> No, in many SMIv2 objects, a zero-length value is used for optional
>>>> nodes (due to the way the protocol (SNMP) works).
>>> This comes as a complete surprise to me.  References?
>> I don't have any references at hand, so let me re-phrase:
>>
>>    No, in many SMIv2 objects, a zero-length value is used for optional
>>    nodes.
>>
>> (where "optional" means optional to set, not optional to implement)

No, for set operations DEFVAL in SMIv2 governs "missing" objects.
(RFC 1442 7.9 or any of its successors.)

The decision to define sentinel values is entirely up to the MIB 
designer.  Zero-length
string is a possible choice only for stuff built with OCTET STRING as 
the underlying
type.  But it's still a value, and in no way makes something "optional."

*Any* object/instance might appear to be "missing" for retrieval due to 
the operation of
VACM or its proprietary predecessors.  It's been that way since, like, 
forever.
See for example RFC 1157 section 4.1.2 to get an idea how ancient this is.

Randy

v2.30.2 | Report a Bug | By Email | System Status