Tree Hints for the Resource Public Key Infrastructure (RPKI)
draft-kwvanhove-sidrops-rpki-tree-hints-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Koen van Hove | ||
| Last updated | 2021-11-09 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-kwvanhove-sidrops-rpki-tree-hints-00
Internet Engineering Task Force K.W. van Hove
Internet-Draft University of Twente
Intended status: Standards Track 9 November 2021
Expires: 13 May 2022
Tree Hints for the Resource Public Key Infrastructure (RPKI)
draft-kwvanhove-sidrops-rpki-tree-hints-00
Abstract
In the Resource Public Key Infrastructure (RPKI), holders of IP
address space can become a Certification Authority (CA), optionally
hosting their repository. They can also delegate (part of) their
resources to subordinate CAs, who in turn may do the same. This CA
hierarchy forms a tree structure. Relying Party (RP) software walks
this tree and determines the current valid objects. An underlying
assumption is that this tree is finite and kept at a reasonable size.
This assumption is not guaranteed to hold. This document proposes a
new Tree Hint object on RPKI manifests that can add constraints for
use in RP processing that ensure this assumption holds.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 13 May 2022.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
van Hove Expires 13 May 2022 [Page 1]
Internet-Draft RPKI Tree Hints November 2021
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Definition . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Tree Hint Content-Type . . . . . . . . . . . . . . . . . 5
4.2. Tree Hint eContent . . . . . . . . . . . . . . . . . . . 5
4.2.1. version . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.2. limits . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.3. exceptionList . . . . . . . . . . . . . . . . . . . . 6
5. Validation . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. maxDescendants . . . . . . . . . . . . . . . . . . . . . 7
6.2. connectionRetryCount . . . . . . . . . . . . . . . . . . 7
6.3. connectionTimeout . . . . . . . . . . . . . . . . . . . . 8
6.4. connectionTransferTime . . . . . . . . . . . . . . . . . 8
6.5. maxRepositorySize . . . . . . . . . . . . . . . . . . . . 8
6.6. maxTransferSize . . . . . . . . . . . . . . . . . . . . . 8
6.7. minTransferSpeed . . . . . . . . . . . . . . . . . . . . 9
6.8. maxObjectSize . . . . . . . . . . . . . . . . . . . . . . 9
6.9. maxPrefixPairs . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
In the RPKI, holders of IP address space can host their own
repositories and act as their own CA. They have full control over
that repository and any objects signed by their CA. They may, for
example, sign one or more certificates that hold a subset of the
resources from the parent certificate. These certificates may
reference publication points in the same repository or different
ones. These new certificates can, in turn, do the same, ad
infinitum. The nested structure of CAs forms a tree structure. The
root of these trees are defined by the Trust Anchor Locators (TALs)
[RFC8630]. RP software is assumed to walk this tree, visit every
node, and retrieve all objects (e.g. Manifests [RFC6486], Route
van Hove Expires 13 May 2022 [Page 2]
Internet-Draft RPKI Tree Hints November 2021
Origin Authorizations [RFC6482], Ghostbuster records [RFC6493], other
certificates [RFC6481], etc.). RP software collects all information
from the objects and processes it. It is important to note that RP
software needs to visit every repository and consider every object
CAs put on manifests. If it would exclude any repository or CA, then
a BGP advertisement that should be valid can become invalid. For
example, if a ROA for the prefix 2001:DB8::/32 and AS64496 is
included, but the ROA for 2001:DB8:123::/48 and AS64497 (from another
CA) is not, then a BGP speaker performing ROV validation may falsely
reject the latter, more specific, announcement.
For RP software to fully walk the tree, the tree needs to be finite
and reasonably sized. However, the size of the tree can only be
determined while traversing the tree - RP software cannot verify
these properties in advance. A malicious CA could, for example,
create its children in an ad-hoc fashion while RP software is
discovering it, thereby violating the implicit assumption that the
tree is finite. That specific behaviour can be countered by RP
software by setting a maximum depth for a certificate chain.
However, at 10 children per child, the number of repositories would
already reach 1111111111 (10^0 + 10^1 + ... + 10^9) after a modest 10
levels. With other strategies, such as serving gigabytes of data and
simulating a very low bandwidth, a malicious repository can violate
our second assumption that the tree is reasonably sized. Using
malicious repository content, any CA can cause the process to take so
unreasonably long that RP software does not finish processing in a
reasonable amount of time (possibly years). The size and structure
of nodes in the RPKI tree varies. For example, a NIR may have a
legitimate need for hundreds of child-CAs, while a regular CA under
the same parent does not. This diversity makes heuristics unsuitable
for detecting this issue adequately, only discarding the malicious
repository and its children, without heavily restricting the freedom
of the structure of RPKI or causing false positives capping future
growth.
Other limits may be needed as well. For example, a large repository
may be several gigabytes in size, especially after a key roll, but if
every repository is gigabytes in size, this may become problematic.
Likewise, there may be valid reasons for splitting a prefix into many
subprefixes, or authorising subprefixes for many autonomous system
numbers (ASNs), but allowing any party to add limitless prefix-ASN
pairs may overflow BGP Origin Validation tables. Setting a fixed
limit may be problematic in these cases.
A new RPKI object (tree hint) is added on manifest to mitigate this
issue by providing RP software prior knowledge about limits before
walking the tree.
van Hove Expires 13 May 2022 [Page 3]
Internet-Draft RPKI Tree Hints November 2021
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Scope
The scope of the Tree Hint object is to provide guidance for RP
software regarding the expected structure of the tree, as well as
impose requirements on other aspects of the CA and its repository.
Following the information in the Tree Hint object is RECOMMENDED.
However, local policy may prevail over the data in a Tree Hint
object.
3. Structure
A Tree Hint is consists of a single object on the manifest of a CA.
This object contains limits. These limits are imposed on each of the
subtrees of children of this CA. For example, if a 5 GB limit on the
maximum size of a repository is imposed, then that means that each
direct child of this CA and its descendants is allowed to have a
repository up to 5 GB as the sum of that child and its children.
This means that a limit cannot be circumvented by delegating
resources to children of children.
Each CA may define its own Tree Hint object. Taking the previous
example, if a 5 GB limit is imposed on CA "Foo", then Foo may also
create a Tree Hint object to impose a limit of 1 GB for Foo's
children, for example "Bar". Note that both the limit imposed on Bar
by Foo, and the parent of Foo, apply to Bar, as well as the limit
imposed by all parents in the chain of Bar up to the root. In case
of conflict, the most strict limit MUST be used.
van Hove Expires 13 May 2022 [Page 4]
Internet-Draft RPKI Tree Hints November 2021
In some cases a limit is not sufficient for a specific child. In
those cases, an exception can be made. The Tree Hint object contains
a list of exceptions. An exception consists of the
subjectKeyIdentifier (SKI) of the child's certificate, and a new set
of limits. If a limit is defined for this SKI, this value MUST then
be used instead of the global limit for this level. Note that a
stricter limit at a higher level may still take precedence over the
exception. Additionally, an exception MAY only override a subset of
the global limits for a SKI. In case an exception is made for this
SKI, a limit is defined at a global level, and this limit does not
appear in the exception, then the value at the global level MUST be
used. Exceptions SHOULD only be created if absolutely necessary, and
custom values SHOULD be subject to human review. Exceptions MUST
only be created for direct children (CAs for which the CA certificate
is on the manifest the Tree Hint is on).
By using reasonable values at the top level, it can be assumed that
the tree can be traversed in reasonable time, whilst keeping the
flexibility of the tree structure as it is currently.
4. Definition
The Tree Hint object uses the template for RPKI digitally signed
objects [RFC6488], which defines a Cryptographic Message Syntax
[RFC3370] wrapper for the Tree Hint content as well as a generic
validation procedure for RPKI signed objects.
If a Tree Hint object is present, it MUST be included in the
manifest. Having more than one Tree Hint object leads to ambiguity,
therefore there MUST NOT be more than one Tree Hint object present in
a manifest. The Tree Hint object MAY contain references to Subject
Key Identifiers (SKIs) that are not present.
4.1. Tree Hint Content-Type
The content-type for a Tree Hint is defined as xxxxx and has the
numerical value of xxxxx.
This OID MUST appear both within the eContentType in the
encapContentInfo object as well as the content-type signed attribute
in the signerInfo object (see [RFC6488]).
4.2. Tree Hint eContent
The content of a Tree Hint contains a global value for the limits
imposed on the children of the current CA, as well as possibly a list
of exceptions for children where the global limit does not suffice.
A Tree Hint is formally defined as:
van Hove Expires 13 May 2022 [Page 5]
Internet-Draft RPKI Tree Hints November 2021
TreeHint ::= SEQUENCE {
version [0] INTEGER DEFAULT 0,
limits Limit (0..MAX),
exceptionList SEQUENCE SIZE (0..MAX) OF Exception
}
Exception ::= SEQUENCE {
ski OCTET STRING,
limits Limit (0..MAX)
}
Limit ::= SEQUENCE {
oid OBJECT IDENTIFIER,
limit OCTET STRING
}
Note that this content appears as the eContent within the
encapContentInfo (see [RFC6488]). The
4.2.1. version
The version number of the TreeHint MUST be 0.
4.2.2. limits
The limits encodes a set of limits imposed by this CA on the
children. Each limit is an object identifier, along with the
specifics of this limit in encoded form.
4.2.3. exceptionList
The exceptionList encodes the set of exceptions to the global limits
defined in "limits". Every entry contains the subjectKeyIdentifier
(SKI) as used on the child CA, and a new limit value for that entry.
This limit value SHOULD be more lenient than the limit before setting
the exception, although this is not guaranteed. If an exception is
present for the SKI, then it overrides the global limit value for
that SKI.
5. Validation
In order to validate the limits, RP software should construct the
chain of certificates from the current certificate up to the root.
For each limit, RP software should check for each certificate in this
chain whether an exception exists for this value, or, when absent,
whether that certificate defines a global limit. Then the most
strict limit of all limits present in the chain should be used as
limit. Which value is the most strict is defined by the definition
van Hove Expires 13 May 2022 [Page 6]
Internet-Draft RPKI Tree Hints November 2021
of the limit itself. If a limit is absent from the entire chain, a
reasonable default SHOULD be used. Root CAs SHOULD define all
limits.
6. Limits
Limits are aimed to be extensible, as future additions and
discoveries may warrant the inclusion of new limits.
6.1. maxDescendants
maxDescendants is a cummultative maximum for the amount of
descendants each of its direct children may include in the object
tree. BGPsec Router Certificates [RFC8209] are not counted because
they do not add child-objects to the validation tree. At a value of
0, each child may not delegate any of its resources to a subordinate
CA. At a value of 3, each child may delegate its resources at most 3
times. This can either be to 3 direct children, or to a child, that
has a child, that has a child, or a combination of the two. What
matters is the sum of all CAs below it, not how it is structered.
After this limit is reached, RP software SHOULD stop processing any
further children of the CA whose limit was reached. This does not
affect the amount of EE certificates used for signing objects like
manifests and ROAs - those are not affected by this limit.
If at level 0 a Tree Hint object is created with a maxDescendants
limit with a value of 10, then a child at level 1 may also create a
Tree Hint object with a maxDescendants value of, for example, 4. In
case the value of the level below is higher than the level above, for
example, if the maxDescendants value for level 1 in the previous
example was 200 (which is larger than 10), RP software MUST use the
lower of the two values. In general, RP software MUST use the lowest
maxDescendants for all the levels defined above it up to the root.
The maxDescendants field contains the maximum for the amount of
children each child CA below this CA may at most have. This number
SHOULD be lower than the effective maxDescendants value for this CA.
A value higher than or equal to the effective maxDescendants value
will cause the children to have an effective maxDescendants value
equal to the effective maxDescendants value of this CA minus one.
maxDescendants ::= INTEGER
6.2. connectionRetryCount
connectionRetryCount is a value for the times RP software should try
to connect to this repository before giving up. This value SHOULD be
lower or equal than the effective connectionRetryCount of this CA.
van Hove Expires 13 May 2022 [Page 7]
Internet-Draft RPKI Tree Hints November 2021
connectionRetryCount ::= INTEGER
6.3. connectionTimeout
connectionTimeout is a value for the timeout RP software should use
try to connect to this repository before ending this try. This value
is in milliseconds. This value SHOULD be lower or equal than the
effective connectionTimeout of this CA.
connectionTimeout ::= INTEGER
6.4. connectionTransferTime
connectionTransferTime is a value for the maximum timeout RP software
should use try to transfer data from this repository. This value is
in milliseconds. This value SHOULD be lower or equal than the
effective connectionTransferTime of this CA.
connectionTransferTime ::= INTEGER
6.5. maxRepositorySize
maxRepositorySize is a value for the maximum size a repository may
have in uncompressed file form. RP software SHOULD reject the entire
repository if the size exceeds this value. This size is in bytes.
This value SHOULD be lower than the effective maxRepositorySize of
this CA divided by the amount of children, minus the size of the
current repository, in order to avoid a legitimate repository not
being visited by RP software.
maxRepositorySize ::= INTEGER
6.6. maxTransferSize
maxTransferSize is a value for the maximum size a repository may have
in transport, either as XML over RRDP [RFC8182], or via RSYNC. RP
software SHOULD reject the entire repository if the size exceeds this
value. This size is in bytes. This value SHOULD be lower or equal
than the effective maxTransferSize of this CA divided by the amount
of children, minus the size of the current repository, in order to
avoid a legitimate repository not being visited by RP software.
maxTransferSize ::= INTEGER
van Hove Expires 13 May 2022 [Page 8]
Internet-Draft RPKI Tree Hints November 2021
6.7. minTransferSpeed
minTransferSpeed is a value for the minimum transfer speed a
repository should have in transport. RP software MAY reject the
entire repository if the speed is lower than this value. This speed
is in bytes per second. This value SHOULD be higher or equal than
the effective minTransferSpeed of this CA.
minTransferSpeed ::= INTEGER
6.8. maxObjectSize
maxObjectSize is a value for the maximum size an object in a
repository may have in uncompressed file form. RP software SHOULD
reject the object if the size exceeds this value. This size is in
bytes. This value SHOULD be lower or equal than the effective
maxObjectSize of this CA.
maxObjectSize ::= INTEGER
6.9. maxPrefixPairs
maxPrefixPairs is a value for the maximum amount of unique ASN-prefix
pairs in ROAs. For example, creating a ROA for one ASN and 5
prefixes counts as 5 pairs. Likewise, creating ROAs for one prefix
and 5 ASNs also counts as 5 pairs. Creating ROAs for 5 ASNs and 5
prefixes counts as 25 pairs. This value SHOULD be lower than the
effective maxPrefixPairs of this CA divided by the amount of
children, minus the amount of ASN-prefix pairs signed by the current
CA, in order to avoid a legitimate ASN-prefix pair not being included
by RP software.
maxPrefixPairs ::= INTEGER
7. IANA Considerations
This document registers the following RPKI Signed Object:
Name: Tree Hint
OID: xxx
Reference: [RFCxxxx] (this document)
This document registers the following three-letter filename extension
for RPKI repository objects in the registry:
Filename extension: trh
van Hove Expires 13 May 2022 [Page 9]
Internet-Draft RPKI Tree Hints November 2021
RPKI Object: Tree Hint
Reference: [RFCxxxx] (this document)
This document registers the following RPKI Tree Hint Limits:
Name: maxDescendants
OID: xxx
Reference: [RFCxxxx] (this document)
Name: connectionRetryCount
OID: xxx
Reference: [RFCxxxx] (this document)
Name: connectionTimeout
OID: xxx
Reference: [RFCxxxx] (this document)
Name: connectionTransferTime
OID: xxx
Reference: [RFCxxxx] (this document)
Name: maxRepositorySize
OID: xxx
Reference: [RFCxxxx] (this document)
Name: maxTransferSize
OID: xxx
Reference: [RFCxxxx] (this document)
Name: minTransferSpeed
OID: xxx
Reference: [RFCxxxx] (this document)
van Hove Expires 13 May 2022 [Page 10]
Internet-Draft RPKI Tree Hints November 2021
Name: maxObjectSize
OID: xxx
Reference: [RFCxxxx] (this document)
Name: maxPrefixPairs
OID: xxx
Reference: [RFCxxxx] (this document)
8. Security Considerations
This document contains security enhancements for the tree discovery
process in the RPKI protocol. Tree Hints can prevent a number of
denial of service attacks against RP instances.
There may be Tree Hints published at the root level with very large
allowances for, for example, maxDescendants, thereby effectively
negating the protections offered. The same precautions described in
[RFC8630] apply here as well. Additionally, the Tree Hint profile
uses the Signed Object profile [RFC6488]; those precautions apply to
the Tree Hint too.
CAs should be careful with setting their limits when it comes to
delegating their resources. In the case of maxDescendants, if the
maxDescendants value times the amount of children of a CA is higher
than the effective maxDescendants value of that CA, then one or more
children may cause the maximum amount of children to be exceeded,
even if none act malicious. This may cause routing data to not be
retrieved. For example, take a CA A with three children: AA, AB, and
AC. A has an effective maxDescendants of 10, and sets its
maxDescendants value to 5, which thus applies to AA, AB, and AC. If
both AA and AB decide to fully use their five children, for example
by creating AAA, AAB, AAC, AACA, AACB, ABA, ABAA, ABAAA, ABAAAA, and
ABAAAAA, then RP software may no longer check AC, as AA and AB
together already hit the effective maxDescendants of A. Note that
the retrieval order is not defined, thus different RP software may
decide to first retrieve AA, AB, and AC, and exclude a different CA,
for example ABAAAAA. Similar concerns apply to the other limits as
well.
This may lead to RP software not retrieving data from certain CAs,
which can lead to partial data. The threat that comes with partial
data is that, for example, a BGP advertisement that should be valid,
may become invalid, as the ROA for the advertisement is missing, and
the less-specific prefix does have a ROA that was retrieved. When
van Hove Expires 13 May 2022 [Page 11]
Internet-Draft RPKI Tree Hints November 2021
choosing limits, careful consideration must be taken to ensure that
malicious actors cannot disrupt RPKI, whilst the data from valid
actors is still retrieved.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002,
<https://www.rfc-editor.org/info/rfc3370>.
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
Resource Certificate Repository Structure", RFC 6481,
DOI 10.17487/RFC6481, February 2012,
<https://www.rfc-editor.org/info/rfc6481>.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482,
DOI 10.17487/RFC6482, February 2012,
<https://www.rfc-editor.org/info/rfc6482>.
[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski,
"Manifests for the Resource Public Key Infrastructure
(RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012,
<https://www.rfc-editor.org/info/rfc6486>.
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object
Template for the Resource Public Key Infrastructure
(RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
<https://www.rfc-editor.org/info/rfc6488>.
[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI)
Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493,
February 2012, <https://www.rfc-editor.org/info/rfc6493>.
[RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
"The RPKI Repository Delta Protocol (RRDP)", RFC 8182,
DOI 10.17487/RFC8182, July 2017,
<https://www.rfc-editor.org/info/rfc8182>.
van Hove Expires 13 May 2022 [Page 12]
Internet-Draft RPKI Tree Hints November 2021
[RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for
BGPsec Router Certificates, Certificate Revocation Lists,
and Certification Requests", RFC 8209,
DOI 10.17487/RFC8209, September 2017,
<https://www.rfc-editor.org/info/rfc8209>.
[RFC8630] Huston, G., Weiler, S., Michaelson, G., Kent, S., and T.
Bruijnzeels, "Resource Public Key Infrastructure (RPKI)
Trust Anchor Locator", RFC 8630, DOI 10.17487/RFC8630,
August 2019, <https://www.rfc-editor.org/info/rfc8630>.
Appendix A. ASN.1 Module
van Hove Expires 13 May 2022 [Page 13]
Internet-Draft RPKI Tree Hints November 2021
RPKITreeHint { xxx }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
-- IMPORTS NOTHING --
-- TreeHint Content Type: OID
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
id-ct-rpkiTreeHint OBJECT IDENTIFIER ::= { xx }
-- TreeHint Content Type: eContent
TreeHint ::= SEQUENCE {
version [0] INTEGER DEFAULT 0,
limits Limit (0..MAX),
exceptionList SEQUENCE SIZE (0..MAX) OF Exception
}
Exception ::= SEQUENCE {
ski OCTET STRING,
limits Limit (0..MAX)
}
Limit ::= SEQUENCE {
oid OBJECT IDENTIFIER,
limit OCTET STRING
}
END
Author's Address
Koen van Hove
University of Twente
Email: koen@koenvh.nl
van Hove Expires 13 May 2022 [Page 14]