[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Rescert] Another attempt to round off the IR-ISP protocol
Thanks for the comments on this spec - we've now edited the comments
into the document and rounded off a few loose ends as well. Hopefully
this version is now close to completion!
The wiki version is at:
http://mirin.apnic.net/resourcecerts/wiki/index.php/IR-ISP_Definition
A plain ascii version is attached to this note
regards,
Geoff
Version 1.0
30 May 2007
1. IR / ISP Resource Certificate Provisioning Protocol
This document defines a framework for certificate management interactions
between a resource issuer ("Internet Registry" or "IR") and a resource
recipient ("Internet Service Provider" or "ISP") through the
specification of a protocol for interaction between the two parties. The
protocol supports the transmission of requests from the ISP, and
corresponding responses from the IR encompassing the actions of
certificate issuance, certificate revocation and certificate status
information reports.
The protocol is implemented as an exchange of XML data objects. The
schema for these XML objects is described in the XML Schema section of
this document.
2. Goals and Non-Goals of this Protocol Specification
The objective is to define a basic set of interactions that allow an ISP
to request certificate issuance, revocation and status information from
the IR, and for a IR to maintain an issued certificate set that is
aligned to the allocation records relating to each ISP. The IR's resource
allocation database (or "IR Back End", or "IRBE") is the authoritative
source of what resource allocations may be certified for an ISP.
It is noted that a resource recipient (ISP) may also under the role of a
resource issuer (IR), such as in the case of a Local Internet Registry
(LIR).
This protocol specification does not encompass signing of objects with
keys that are certified by resource certificates, nor the issuance of
end-entity certificates.
3. Protocol
This protocol is expressed as a request/response interaction, where the
ISP passes a request to the IR, and the IR generates a response. The
intended functionality is that the requestor (the ISP always initiates a
request in this model) poses the request to the other entity (the IR in
this model), and is provided with a response to that operation, in a
style of functionality similar to that of a simple client / server
interaction.
For the reminder of this document the requestor (ISP) is termed the
"client" and the responder (IR) is termed the "server". The "issuer" is
the CA entity on whose behalf the server is operating.
The underlying transport for this protocol is HTTP. The client initiates
an HTTP POST with content type of "application/x-rpki", with the message
as the body. The server's response will similarly be the body of the
response with a content type of "application/x-rpki". The content of the
POST operation will be "well-formed" binary CMS. [This choice of HTTP
transport leaves open the option to use HTTPS if secure channel operation
is desired. Adding additional query elements to the URL will not affect
the operation of this protocol (they are non-meaningful in this
context).]
The request / response mechanism is assumed to be reliable, in that
requests will generate a matching response. The protocol supports
sequential operation, in that multiple requests will have an inferred
sequencing as specified by the client through the relative values of the
msg_ref attribute in each message (where later messages have a higher
value of the msg_ref attribute). Messages will be processed by the server
in order of increasing msg_ref values, and detected out-of-order requests
and duplicate requests will not be processed by the server, and will,
instead, generate an error response. The algorithm to support this
processing is described below.
3.1 Common Message format
+-------------------------------------------------------------------
| <?xml version="1.0" encoding="UTF-8"?>
| <message xmlns="http://www.apnic.net/specs/rescerts/up-down/";
| version="1"
| sender="sender name"
| recipient = "recipient name"
| msg_ref="reference"
| type="message type">
| [payload]
|
| </message>
|
| [Message is signed by the sender using a communications key that has
| been established between sender and recipient entities]
+--------------------------------------------------------------------
version :
value is the version of this protocol. This document describes
version 1.
sender :
value is the agreed name of the message sender, as set at initial
entity-key exchange.
recipient :
value is the agreed name of the message recipient, as set at
initial entity-key exchange.
msg_ref :
value is a positive integer value in a strictly monotonically
increasing sequence, set by the client when generating a query. The
corresponding response message contains the same msg_ref value. The
client must ensure that different msg_ref values are used for each
query, and the server must ensure that messages with duplicate
msg_ref values are detected and rejected. (The requirement for a
strict monotonically increasing sequence of value applies when
messages are sent within a reset_interval time interval of each
other.)
type :
possible values are "list", "list_response", "issue",
"issue_response", "revoke", "revoke_response", and
"error_response".
Conforming parsers MUST reject any document with a version number they do
not understand, or with any elements or attributes they do not
understand. Servers must generate an error response when receiving such a
request. Clients should generate an operator alert error when receiving
such a response.
A message in this protocol is a digitally signed object that makes use of
Cryptographic Message Syntax (CMS) [RFC3852] and is encoded as DER. It
uses the signed-data object contentType OID, 1.2.840.113549.1.7.2. The
attribute id-signingTime (contentType OID 1.2.840.113549.1.9.5) must be
present in the CMS object, in order to implement the msg_ref processing
actions correctly.
The encapsulated content of the CMS wrapping is an XML document. The rest
of this document omits this CMS wrapper and only discusses the XML
document.
Messages are checked using the following tests:
1. Check that the CMS is well-formed
2. Check that the XML is well-formed
3. Check that the XML sender and recipient attributes reference a known
client and this system respectively.
4. Verify the digital signature using the public key provided in the
certificate carried in the CMS
5. Validate the CMS-provided certificate using the Business PKI that is
associated with the sender
6. Use the XML msg_ref and CMS Signing_Time attribute values to detect
that this message is correctly in sequence (using the algorithm
described below)
7. The value of the version number of the message is 1.
The checks should generally be applied in the order specified here.
Errors in tests 1 through 5 would generate an HTTP 400 Bad Data response.
An error in steps 6 or 7 would generate a "Request-Not-Performed"
response.
The handling of the msg_ref values is as follows:
The algorithm is intended to provide for protection against replay
attacks (duplicate message detection) while not holding a large amount
of state on the server or client. It also allows for implementations of
the protocol that use parallel processing on the server side, and for
clients who launch multiple requests. This algorithm places a time
bound on the duplicate detection capability.
Duplicate message detection relies on the server and client both
running an absolute time clock (i.e. a clock that can produce a time
value to a level of granularity of seconds or finer).
The server holds per-client stored last_msg_ref values (initially set
to 0), and per-client stored last_msg_time values (initially set to 0)
and two statically configured time interval values, the reset_interval
value and the allowed_clock_skew_interval value.
The client holds a msg_ref counter which is incremented by one for each
sent message, and initially set to 0.
The algorithm is:
- The client passes its clock value to the server via the Signing
Time attribute of the CMS message wrapper (see above).
- The client increments its (per-server) msg_ref counter and uses
this value as the msg_ref value of the message.
- The client sends the message to the server.
- The server checks if the message is within the allowable clock
skew. If the server detects that the received Signing Time is
outside of the server's clock +/- allowed_clock_skew_interval, then
the message is rejected]] with a time error. The server's clock
value is communicated to the client via the Signing Time attribute
of the CMS message wrapper in the response.
- The server checks that the msg_ref value is valid. If the message's
msg_ref value is 0, or negative, then the message is rejected with
an invalid msg_ref code, and the server's value for last_msg_ref is
placed in the last_msg_processed attribute of the error response.
- If this is a new message channel, or if the message channel has
been idle for a reset_interval period of time, then the server will
set its local msg_ref counter for this client to that of the
incoming message (msg_ref counter reset). i.e. If the last_msg_time
for this client is 0, or if the last_msg_time is less than the
server's current clock value minus the reset_interval, then the
last_msg_ref for this client is set to the msg_ref value in this
message, and the message is accepted for processing.
- The server then checks for out-of-order and duplicate messages. If
the msg_ref value is less than or equal to the last_msg_ref for
this client, then the message is rejected with an incorrect msg_ref
code, and the server's value for last_msg_ref is placed in the
last_msg_processed attribute of the error response.
- Otherwise the local last_msg_ref value is set to the msg_ref value
of the message, and the message is accepted for processing.
The proposed value for allowed_clock_skew_interval is 60 (?) seconds.
The proposed value for reset_interval is 600 (?) seconds
3.2 Control - Resource Class Query
3.2.1 Resource Class List Query
+-------------------------------------------------------------------
| type="list"
+-------------------------------------------------------------------
Payload:
+-------------------------------------------------------------------
| [No message payload is defined for this query]
+-------------------------------------------------------------------
3.2.2 Resource Class List Response
+-------------------------------------------------------------------
| type="list_response"
+-------------------------------------------------------------------
Payload:
+-------------------------------------------------------------------
| <class class_name="class name"
| cert_url="url"
| cert_ski="g(ski)"
| resource_set_as="as resource set"
| resource_set_ipv4="ipv4 resource set"
| resource_set_ipv6="ipv6 resource set"
| suggested_sia_head="[directory url]" >
| <certificate cert_url="url"
| cert_ski="g(ski)"
| cert_aki="g(aki)"
| cert_serial="serial"
| resource_set_as="as resource set"
| resource_set_ipv4="ipv4 resource set"
| resource_set_ipv6="ipv6 resource set"
| req_resource_set_as="as resource set"
| req_resource_set_ipv4="ipv4 resource set"
| req_resource_set_ipv6="ipv6 resource set"
| status="keyword" >
| [certificate]
| </certificate>
| ...
| (repeated for each current certificate where the client is the
| certificate's subject)
|
| <issuer>[issuer's certificate]</issuer>
| </class>
|
| ...
| (repeated for each of the issuer's resource class where the client has
| been allocated resources)
+-------------------------------------------------------------------
Where the client has been allocated resources from multiple issuer's
Resource Classes, then the response will contain multiple class elements,
corresponding to the complete set of the issuer's Resource Classes where
the client holds allocated resources. Those issuer's Resource Classes
where the client holds no allocated resources will not be included in the
response.
Where the client has multiple certificates in a Resource Class with
different public keys (as may occur during a client key rollover), there
will be multiple certificate elements in the response, with distinct
cert_ski values for each of the client's certified public keys.
Where the issuer has issued multiple certificates in a Resource Class
signed with different keys (as may occur during a staged issuer-key
rollover), only the most recent certificate issued with the currently
"active" issuer key will be listed in the response.
Each class element describes a set of resources that are certified within
the scope of a single certificate, referring to a single Resource Class
with a common validation path.
class_name :
value is the issuer-assigned name of the issuer's Resource Class.
cert_url :
in the context of a class, this is the URL of the issuer's CA
certificate (i.e. a reference to the immediate superior
certificate, being the CA-enabled certificate where the issuer is
the certificate's subject)
cert_ski :
in the context of a class, this is the g(ski) value of the issuer's
(certificate issuer's) public key. The g() function is defined via
[RFC4648] as a variation of the Base64 encoding, known as "URL and
Filename safe" encoding applied to the SHA-1 hash value of the
subject public key (ski). This encoding is also described in the
resource page
[http://mirin.apnic.net/resourcecerts/wiki/index.php/G_of_ski].
resource_set_as :
in the context of a class, this is the set of AS numbers and AS
number ranges that the issuer has allocated to the client within
the scope of this Resource Class, presented in ASCII as a comma-
separated list. The list elements are decimal integer values and
ranges of decimal integers specified by the low and high value of
the range with a hyphen delimiter, using the canonical order as
described in [RFC3779], without leading zeros, and with no white
space or punctuation other than the comma and the hyphen range
designator (e.g.: resource_set_as="123,456-789,123456"). If there
are no AS numbers in this Resource Class the empty set will be
represented by a null string value ("") for this attribute.
resource_set_ipv4 :
in the context of a class, this is the set of IPv4 addresses that
the issuer has allocated to the client within the scope of this
Resource Class. The value is presented in ASCII as a comma-
separated list of elements. Each element is either an address
prefix using the notation of <dotted quad>/mask length, or a range
specified as low and high range values in dotted quad notation with
a hyphen delimiter. The list is presented in canonical order, as
described in [RFC3779]. The dotted quad notation is without leading
zeros, and the list contains no white space or punctuation other
than the period, forward slash, hyphen and comma. (e.g.
resource_set_ipv4="1.2.3.0/24,1.2.4.5/32,2.3.4.5-7.8.9.10") If
there are no IPv4 addresses in this Resource Class the empty set
will be represented by a null string value ("") for this attribute.
resource_set_ipv6 :
in the context of a class, this is the set of IPv6 addresses that
the issuer has allocated to the client within the scope of this
Resource Class. The value is presented in ASCII as a comma-
separated list of elements. Each element is either an address
prefix using the notation of <hex nibble sequence>/mask length, or
a range specified as low and high range values in hex nibble
notation with a hyphen delimiter. Trailing zero nibbles are
truncated and represented by '::'. The list is presented in
canonical order, as described in [RFC3779]. The hex nibble sequence
notation is without leading zeros, and the list contains no white
space or punctuation other than the colon, forward slash, hyphen
and comma (e.g.
resource_set_ipv6="2003:A::/32,2001:7ABC::-2001:7FFF"). The XML
Schema data type is [http://www.w3.org/TR/xmlschema-2/#hexBinary]
and value is case insensitive, with the canonical form being upper
case. If there are no IPv6 addresses in this Resource Class the
empty set will be represented by a null string value ("") for this
attribute.
suggested_sia_head : (OPTIONAL)
If this field is present then it indicates a publication namespace
which the server has made available to the client to use for its
own SIA collection. Presence of this field does not mean that the
client has permission from the repository operator to lodge under
this URI, only that the client has permission from the server to
lodge under this URI. The publication protocol
[http://subvert-rpki.hactrn.net/docs/publication-protocol] contains
further details on how this works.
[issuer's certificate] :
value is the Base64 encoding of the DER-encoded issuer's CA
certificate (the CA-enabled certificate where the issuer is the
certificate's subject).
Each certificate element describes the most recently issued current
certificate where the certificate's subject refers to the client for
each active client key pair. A "current" certificate is a non-expired,
non-revoked certificate. If a current certificate exists then the
cert_url, cert_ski, cert_aki, cert_serial, resource_set_as,
resource_set_ipv4, resource_set_ipv6, and [certificate] will be
present. The attributes req_resource_set_as, req_resource_set_ipv4, and
req_resource_set_ipv6 may be present, depending on whether these
attributes were defined in the associated client's certificate request.
If no current certificate has been issued, then no certificate element
will be included in the response.
cert_url :
the URL reference where the certificate issuer has published this
certificate.
cert_ski :
the g(ski) value of the client's public key. The g() function is
defined above.
cert_aki :
the g(aki) value of the server's public key. The g() function is
defined above.
cert_serial :
the serial number of the issued certificate.
resource_set_as :
in this context, the set of AS numbers that are contained in the
resource extension of this certificate, following the syntax
described above.
resource_set_ipv4 :
in this context, the set of IPv4 addresses that are contained in
the resource extension of this certificate, following the syntax
described above.
resource_set_ipv6 :
in this context, the set of IPv6 addresses that are contained in
the resource extension of this certificate, following the syntax
described above.
req_resource_set_as :
the set of AS numbers that were specified in the corresponding
original certificate request that defined the maximal requested
span of the certified AS number set, following the syntax
described above. If this attribute was present in the certificate
request, then the attribute MUST be present in this response,
otherwise it MUST NOT be present.
req_resource_set_ipv4 :
the set of IPv4 addresses that were specified in the
corresponding original certificate request that defined the
maximal requested span of the certified IPv4 address set,
following the syntax described above. If this attribute was
present in the certificate request, then the attribute MUST be
present in this response, otherwise it MUST NOT be present.
req_resource_set_ipv6 :
the set of IPv6 addresses that were specified in the
corresponding original certificate request that defined the
maximal requested span of the certified IPv6 address set,
following the syntax described above. If this attribute was
present in the certificate request, then the attribute MUST be
present in this response, otherwise it MUST NOT be present.
status :
The value "undersize" indicates that the certificate does not
encompass all resources allocated to the client within this
class. The value "match" indicates that the certificate spans
all currently client-allocated resources in this class. The value
"oversize" indicates that the certificate spans more than the set
of resources currently allocated to the client in this class. In
the case that a specific set of number resources were specified
in the original certificate request (as indicated by the presence
of the req_resource_set_* attributes in the response), then the
comparison status value refers to a comparison between the
certified resource set and the intersection of the client's
original requested resource set and the client's current
allocated resource holdings.
[certificate] :
value is the Base64 encoding of the DER-encoded certificate.
3.3 CA - Certificate Issuance
3.3.1 Certificate Issuance Request
+-------------------------------------------------------------------
| type="issue"
+-------------------------------------------------------------------
Payload:
+-------------------------------------------------------------------
| <request
| class_name="class name"
| req_resource_set_as="as resource set"
| req_resource_set_ipv4="ipv4 resource set"
| req_resource_set_ipv6="ipv6 resource set">
| [Certificate request]
| </request>
+-------------------------------------------------------------------
The client must use different key pairs for each distinct resource class.
If any of req_resource_set_* attributes are specified in the request,
then any missing req_resource_set_* attributes are to be interpreted as
specifying the complete set of the corresponding resource type that match
the client's current resource allocation. If the value of any
req_resource_set_* attributes is the null value (""), then this indicates
that no resources of that resource type are to be certified with this
request.
The requested resource set values are held as a local record by the
issuer against the Resource Class and the client's public key. Any
subsequent Certificate Issuance Requests that specify the same Resource
Class and the same client's public key will (re)set the issuer's local
record of the requested resource sets to the most recently specified
values.
class_name :
value is the server's identifier of a Resource Class.
req_resource_set_as : (OPTIONAL)
the set of AS numbers that define the maximal requested span of the
certified AS number set, formatted as per the resource_set_as
attribute of the Resource Class List Response.
req_resource_set_ipv4 : (OPTIONAL)
the set of IPv4 addresses that define the maximal requested span of
the certified IPv4 address set, formatted as per the
resource_set_ipv4 attribute of the Resource Class List Response.
req_resource_set_ipv6 : (OPTIONAL)
the set of IPv6 addresses that define the maximal requested span of
the certified IPv6 address set, formatted as per the
resource_set_ipv6 attribute of the Resource Class List Response.
[Certificate request] :
value is the certificate request. This is a Base-64 encoded DER
version of a request formatted using PKCS#10.
3.3.2 Certificate Issuance Response
+-------------------------------------------------------------------
| type="issue_response"
+-------------------------------------------------------------------
Payload:
+-------------------------------------------------------------------
| <class class_name="class name"
| cert_url="url"
| cert_ski="g(ski)"
| resource_set_as="as resource set"
| resource_set_ipv4="ipv4 resource set"
| resource_set_ipv6="ipv6 resource set" >
| <certificate cert_url="url"
| cert_ski="g(ski)"
| cert_aki="g(aki)"
| cert_serial="serial"
| resource_set_as="as resource set"
| resource_set_ipv4="ipv4 resource set"
| resource_set_ipv6="ipv6 resource set"
| req_resource_set_as="as resource set"
| req_resource_set_ipv4="ipv4 resource set"
| req_resource_set_ipv6="ipv6 resource set"
| status="keyword" >
| [certificate]
| </certificate>
| <issuer>[issuer's certificate]</issuer>
| </class>
+-------------------------------------------------------------------
If the certificate issuer determines that the issued certificate would be
identical in all respects to the most recently issued certificate for
this client, other than the certificate's serial number, were the
certificate to be issued, the issuer may choose to respond with the most
recently issued certificate and not issue a new certificate for this
request.
The definition of the attributes and syntax of the values is the same as
the resource class list response, but the response only references the
(single) named resource class, and the (single) certificate issued
against the client's public key as provided in the corresponding
certificate request.
3.4 Certificate Revocation
3.4.1 Certificate Revocation Request
+-------------------------------------------------------------------
| type="revoke"
+-------------------------------------------------------------------
Payload:
+-------------------------------------------------------------------
| <key class_name="class name"
| ski="[g(ski)]" />
+-------------------------------------------------------------------
This command 'retires' a client's key pair by requesting the issuer to
revoke all certificates for this client that contain the matching public
key, within the scope of a named Resource Class. Individual issued
certificates cannot be revoked within the scope of this protocol.
This command directs the issuer to immediately mark all issued valid
certificates issued by this issuer within the named Resource Class with
this client's SKI value to be marked as revoked, causing the issued
certificates to be withdrawn from the publication repository and to be
listed in the server's subsequent CRLs within this Resource Class.
class_name :
value is the issuer-assigned name of the issuer's Resource Class.
ski :
value is the g(SKI) of the client's public key that is to be
revoked. The g() function is defined above.
3.4.2 Certificate Revocation Response
+-------------------------------------------------------------------
| type="revoke_response"
+-------------------------------------------------------------------
Payload:
+-------------------------------------------------------------------
| <key class_name="class name"
| ski="[g(ski)]" />
+-------------------------------------------------------------------
class_name :
value is the issuer-assigned name of the server's Resource Class.
ski :
value is the g(SKI) of the client's public key that has been marked
for revocation. The g() function is defined above.
3.5 Request-Not-Performed Response
+-------------------------------------------------------------------
| type="error_response"
+-------------------------------------------------------------------
Payload:
+-------------------------------------------------------------------
| <status>[Code]</status>
| <last_msg_processed>[msg_ref_value]</last_msg_processed>
| <description xml:lang="en-US">[Readable text]</description>
+-------------------------------------------------------------------
All states where an error response if to be generated, either due to
detected errors or inconsistencies in the content of the request or
server-side states that prevent the request being performed, generate a
Request-Not-Performed response.
status :
value is one of a defined set of error codes.
last_msg_processed :
value indicates the responder's last processed msg_ref value. This
element MUST be present when an "incorrect msg_ref" status code is
used. It MUST NOT be present in all other cases.
description :
value is a text field. This element MAY be present. It's value has
no defined meaning within the scope of this protocol.
Implementations may assume that some form of human-readable text
may be used here. If the HTTP request that triggered this error
response includes an Accept-Language header as defined in section
14.4 of the HTTP/1.1 specification [RFC2616] then the server will
make a best effort to include a second description element using
the highest ranked preferred language of the client. The en-US
description will always be included if the element is present.
The error code set is:
Code Value Description>
1000+ Client Error
1101 Message too old
1102 msg_ref value is invalid
1103 out of order msg_ref value
1104 version number error
1105 unrecognised request type
1201 request - no such resource class
1202 request - no resources allocated in resource class
1203 request - badly formed certificate request
1301 revoke - no such resource class
1302 revoke - no such key
2000+ Server Error
2001 Internal Server Error - Request not performed
4. XML Schema
The following is a RelaxNG [http://relaxng.org/] compact form schema
describing the IR-ISP Protocol, version 1.
+-------------------------------------------------------------------
| default namespace = "http://www.apnic.net/specs/rescerts/up-down/";
|
| grammar {
| start = element message {
| attribute version { xsd:positiveInteger { maxInclusive="1" } },
| attribute sender { xsd:token { maxLength="1024" } },
| attribute recipient { xsd:token { maxLength="1024" } },
| attribute msg_ref { xsd:positiveInteger {
maxInclusive="999999999999999" } },
| payload
| }
|
| payload |= attribute type { "list" }, list_request
| payload |= attribute type { "list_response"}, list_response
| payload |= attribute type { "issue" }, issue_request
| payload |= attribute type { "issue_response"}, issue_response
| payload |= attribute type { "revoke" }, revoke_request
| payload |= attribute type { "revoke_response"}, revoke_response
| payload |= attribute type { "error_response"}, error_response
|
| list_request = empty
| list_response = class*
|
| class = element class {
| attribute class_name { xsd:token { maxLength="1024" } },
| attribute cert_url { xsd:anyURI { maxLength="1024" } },
| attribute cert_ski { xsd:token { maxLength="1024" } },
| attribute resource_set_as { xsd:string { maxLength="512000" } },
| attribute resource_set_ipv4 { xsd:string { maxLength="512000" } },
| attribute resource_set_ipv6 { xsd:string { maxLength="512000" } },
| attribute suggested_sia_head { xsd:string { maxLength="1024" } }?,
| element certificate {
| attribute cert_ski { xsd:token { maxLength="1024" } },
| attribute cert_aki { xsd:token { maxLength="1024" } },
| attribute cert_serial { xsd:positiveInteger },
| attribute resource_set_as { xsd:string { maxLength="512000" } },
| attribute resource_set_ipv4 { xsd:string { maxLength="512000" } },
| attribute resource_set_ipv6 { xsd:string { maxLength="512000" } },
| attribute req_resource_set_as { xsd:string { maxLength="512000" } },
| attribute req_resource_set_ipv4 { xsd:string { maxLength="512000" } },
| attribute req_resource_set_ipv6 { xsd:string { maxLength="512000" } },
| attribute status { "undersize" | "match" | "oversize" },
| xsd:base64Binary { maxLength="512000" }
| }*,
| element issuer { xsd:base64Binary { maxLength="512000" } }
| }
|
| issue_request = element request {
| attribute class_name { xsd:token { maxLength="1024" } },
| attribute req_resource_set_as { xsd:string { maxLength="512000" } },
| attribute req_resource_set_ipv4 { xsd:string { maxLength="512000" } },
| attribute req_resource_set_ipv6 { xsd:string { maxLength="512000" } },
| xsd:base64Binary { maxLength="512000" }
| }
| issue_response = class
|
| revoke_request = revocation
| revoke_response = revocation
|
| revocation = element key {
| attribute class_name { xsd:token { maxLength="1024" } },
| attribute ski { xsd:token { maxLength="1024" } }
| }
|
| error_response =
| element status { xsd:positiveInteger { maxInclusive="999999999999999" } },
| element last_msg_processed { xsd:positiveInteger { maxInclusive="999999999999999" } }?,
| element description { attribute xml:lang { xsd:language }, xsd:string { maxLength="1024" } }?
| }
+-------------------------------------------------------------------
