Re: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-profile-15.txt

Ties de Kock <tdekock@ripe.net> Wed, 28 June 2023 15:58 UTC

Return-Path: <tdekock@ripe.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952ECC14E513 for <sidrops@ietfa.amsl.com>; Wed, 28 Jun 2023 08:58:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYGefs3mWpXQ for <sidrops@ietfa.amsl.com>; Wed, 28 Jun 2023 08:58:05 -0700 (PDT)
Received: from mail-mx-2.ripe.net (mail-mx-2.ripe.net [IPv6:2001:67c:2e8:11::c100:1312]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17AF2C15107A for <sidrops@ietf.org>; Wed, 28 Jun 2023 08:58:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version:Content-Type ; bh=W01E3SQ/aQSOdt3AmAiyhYAAVF12fEF1/Yi3h2LkHaA=; b=O/Hp8gv4eZXuJRXEJw4bJfsD YhIgUTDIdIOhkm/Bge2QbqG1u3YrbUIqD9Nw2SZ24cOOR1ZNwhzfMs/2JHLqAVqp/KBnpiCNAoa6G ELRAaY/DUI8630/CjTPnmGmr4550AVd7O8nZMI9OOCYCCJwchENWNn8cA63lMcDy3pPLV1Conva94 OHFSlKTz3o8CgU2lePsDlnFSZ6s8dwuDAGILwstSSy021O23atVnaD2Xsyy72GyL60vlXHAkqICvs 4Rr7HuxlV0h06016r31uj+GoJPzUtLQKvH+x7X82ul0PcWdQR/58aJgc+MbEMNfnw62ilGiQmRYQ9 W5AiYnJ2WA==;
Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:35044) by mail-mx-2.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <tdekock@ripe.net>) id 1qEXYN-00FKbJ-21; Wed, 28 Jun 2023 15:57:59 +0000
Received: from sslvpn.ripe.net ([193.0.20.230] helo=smtpclient.apple) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <tdekock@ripe.net>) id 1qEXYN-0007P3-1e; Wed, 28 Jun 2023 15:57:59 +0000
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
From: Ties de Kock <tdekock@ripe.net>
In-Reply-To: <20230628173307.29fefec2@glaurung.nlnetlabs.nl>
Date: Wed, 28 Jun 2023 17:57:48 +0200
Cc: Job Snijders <job=40fastly.com@dmarc.ietf.org>, sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0F5C0507-3B6B-4E62-9683-98EB6ED7D5AC@ripe.net>
References: <168621843689.33017.6897451444105786551@ietfa.amsl.com> <ZIGogKIH4Srb8Nxt@snel> <20230628173307.29fefec2@glaurung.nlnetlabs.nl>
To: Martin Hoffmann <martin@nlnetlabs.nl>
X-Mailer: Apple Mail (2.3731.600.7)
X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e1910c8d77f04f869eb287abc766a8a699
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/4yts4vOxIFsZTjMz-Zol3J3LCWE>
Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-profile-15.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Jun 2023 15:58:09 -0000

Hi all,

> On 28 Jun 2023, at 17:33, Martin Hoffmann <martin@nlnetlabs.nl> wrote:
> 
> Hi,
> 
> Job Snijders wrote:
>> 
>> The internet-draft changes is best viewed by comparing -13 and -15:
>> https://author-tools.ietf.org/iddiff?url1=draft-ietf-sidrops-aspa-profile-13&url2=draft-ietf-sidrops-aspa-profile-15
>> 
>> An example object is available here:
>> rsync://chloe.sobornost.net/rpki/RIPE-nljobsnijders/5m80fwYws_3FiFD7JiQjAqZ1RYQ.asa
> 
> I think that object as well as the example object in the draft are not
> actually correct according to the ASN.1 module definition in the draft.
> 
> The module is opened with
> 
> | DEFINITIONS IMPLICIT TAGS ::=
> 
> and the version field is defined as
> 
> | version [0]   INTEGER DEFAULT 0,
> 
> This means the version should use an implicit tag whereas the objects
> use an explicit tag:
> 
> |    [0] (1 elem)
> |       INTEGER 1
> 
> (and implicit tag would be:
> 
> |    [0] (1 byte) 01
> 
> ) 
> 
> I _think_ this is an error in the module definitions. All X.509 and CMS
> modules seem to use explicit tags for their version fields.

Good catch Martin.

I _think_ I have a test object with the implicit tag:

MIIGcQYJKoZIhvcNAQcCoIIGYjCCBl4CAQMxDTALBglghkgBZQMEAgEwgdwGCyqGSIb3DQEJ
EAExoIHMBIHJMIHGgAEBAgUAoHansjCBuQIEAKQ5RgIECr9npgIEF/QQ0wIEIeg5wwIEJeaw
QAIEMEAtFwIEOwR1uQIEUL6x0QIEWQSabwIEdGFFpAIEdKWXBAIFAIulazQCBQCPsBdFAgUA
lr1nQAIFAJ+MBVsCBQChU9aiAgUAobTY4QIFAKZl+n8CBQCxhcZMAgUAt64mYwIFALteSUYC
BQC8rEIkAgUAwRb1UAIFAMxkh7wCBQDauA1OAgUA319JhQIFAN/RfQ8CBQD8g4auoIIDuzCC
A7cwggKfoAMCAQICAQowDQYJKoZIhvcNAQELBQAwETEPMA0GA1UEAxMGaXNzdWVyMB4XDTIz
MDYyODE1NTA0OFoXDTI0MDYyODE1NTE0OFowETEPMA0GA1UEAxMGaXNzdWVyMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAluBJm57COR3jP++618nXpywQDvG+gzJiB4+Aqlgi
tNTC7YDmPh/je7EfPxqB7rarYZ9y3uM7IIocc2knMrTdRrQ5tlPOT4aKT1bziIUCtZOMl+Fn
YGjUKDePLS+dq2fcBpWlhUVO1WvLHwBgR8b6uG02BsqnZkM2YJl/JXLMDmejOxv/6gvryPfa
jzLA3REdE1ZnZmEemOObPDb6eSCgORk8TKomlSAki5DeOuOdt1Vuk/yrzzWhVqb3zV/Zj1ZC
oB3LotX59lMarVSPUqYx984IY/upsSvYtpy4rd6iVcwnkSBsW9ugrAbc8E9k9tC21V3we94r
yDYqQYqvfHfZlwIDAQABo4IBGDCCARQwHQYDVR0OBBYEFCPmK6BjAlGQGtM+dnFW+saYm86g
MB8GA1UdIwQYMBaAFCPmK6BjAlGQGtM+dnFW+saYm86gMA4GA1UdDwEB/wQEAwIHgDBBBggr
BgEFBQcBAQQ1MDMwMQYIKwYBBQUHMAKGJXJzeW5jOi8vY2VydGlmaWNhdGUvcmVwb3NpdG9y
eS9jYS5jZXIwRwYIKwYBBQUHAQsEOzA5MDcGCCsGAQUFBzALhityc3luYzovL2NlcnRpZmlj
YXRlL3JlcG9zaXRvcnkvZmlsZW5hbWUuYXNhMBgGA1UdIAEB/wQOMAwwCgYIKwYBBQUHDgIw
HAYIKwYBBQUHAQgBAf8EDTALoAkwBwIFAKB2p7IwDQYJKoZIhvcNAQELBQADggEBACfC1r3C
L/ZDzomBnxB3kBVHgr+c6f7E1XTkCCc/6CIUpgwNttcYfZDCxhH+PpZXWF86Z3m/pFE+LAOM
KtHJJxpG6Fo5Hc/H7Y1rCRBFZI+KjQmkhGh0Nm4SrjqpoSJxsLei+iQqM2lENsHxdc6BUUXG
pHXnVrIiXvqjomALj01lv4+GVbNcvR+6dQ1DdRuh7vE9mwl8OMXAmtkHuNKIcPXTTaz7SQC4
cEV3Iu12iet8QmusDQ6erRwA2G1SSjQTd3ojALtrlahV36DWuB2Yunn897SFiMiwQSQQvNwO
/exv58ZpHG1kAwNaPEoUk1PyNYCBp+lXgjteHR4LSTKKtyAxggGqMIIBpgIBA4AUI+YroGMC
UZAa0z52cVb6xpibzqAwCwYJYIZIAWUDBAIBoGswGgYJKoZIhvcNAQkDMQ0GCyqGSIb3DQEJ
EAExMBwGCSqGSIb3DQEJBTEPFw0yMzA2MjgxNTUwNDhaMC8GCSqGSIb3DQEJBDEiBCCdoOo3
8x1yHfzfVD7HqaQQGRCouUrYXAq8Q4upEwCtxDANBgkqhkiG9w0BAQsFAASCAQB686pmUl3b
uo9lYXNRjNGk2pNvnY7tmI6jehy0+y8NGaa8mPk6FX62X+FcXWuKaqXvWZBZnZhCSFWHDfmC
HX0pw6C+V3T4HEvKXkJG2OEPC8cOt1TpUWURgE4tmsw3B5W4yPnnQo+UZxdr5Y51SEGUx/YY
NEPTGX2d0pVhI7TwgwyXw3Q2BRrqlUxCKLI7m8UWBLIfLAqdoVKnH3suTMxToMkcX06G0lX+
Phfej72hbcmqiS6plnB+fdlBvFARebV7w7o1kqNRdKSYSHVVkIlISuLWx1luKpFm7DUk57jX
C1vWYKh6Hh6Rke1RLe3yM3Qnrdarl3HmlWvFf2L45X5L

I have updated a branch of our implementation to accept both implicitly and
explicitly tagged objects (but warn about explicit tags).

> While we are at it, I would like to again raise the suggestion to not
> use a version 1 here but rather stick to 0 and use a different
> content type OID. The older and newer definitions are not compatible,
> so a new OID feels more appropriate than a version change.

I agree that this would be simpler to get right than what we see with this tagged version.

Kind regards,
Ties