[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed Up/Down protocol description
There is one item here that I'm just not sure about:
Minor question: shouldn't we introduce a maximum length here? I'd
hate to reserve space for multi-megabyte blobs in a database for this :-)
I have no idea in XML whether such a restriction is good / bad /
indifferent / whatever.
***Does anyone have experience in this area of attempting to bound
the length of text elements in XML-based protocols?
Geoff
further comments interleaved....
Rob,
Thanks indeed for your review comments
Version 1.0
22 May 2007
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 ISP 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 IR in
order of increasing msg_ref values, and detected out-of-order requests
and duplicate requests will not be processed by the IR, and will,
instead, generate an error response. The algorithm to support this
processing is described below.
This would imply some mechanism for serializing requests (per child)
on the server side, even though the HTTP server - and, presumably,
the database behind it - would be capable of handling concurrent
requests. Is this really the intention?
Not quite. There is the intention to ensure that implicit order in
the child's requests are at least detected by the parent, if not acted upon.
i.e. if the child does a sequence of
issue, issue, revoke
and launches these requests without waiting for the response from the
previous request then there is the risk that the parent would process
this in the order of
issue revoke issue
In the protocol operation as described the parent would perform the
issue and the revoke, then generate an out of order on the second issue.
This measure does not preclude parallel operation in an
implementation - it does infer that the parent implements some form
of mutex, either by explicit serialization of all operations, or by
explicit use of mutexes in an otrherwise parallel implementation.
3.1 Common Message format
-------------------------
----------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
Is there a real reason why we're using UTF instead of something
simpler? While browsing through the messages, I could find no
attributes that really needed UTF (unless a sender/recipient will be
spelled with Kanji or something).
Messages are checked using the following sequence of 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
If there's going to be a 'Terminology' section for this document,
it'd be nice to describe the term 'Business PKI' there.
There was one some months ago. It seems to be rather superfluous in
this context. If you want to write a standalone common terminology
document, it could be useful.
Errors in steps 1 through 5 would generate an "HTTP 400 Bad Data"
response. An error in steps 6 or 7 would generate a well-formed protocol
error response as described in the msg-ref processing algorithm
The handling of the msg_ref values is as follows:
I may oversimplify things here, but why is the strictly increasing
msg_ref value not enough for replay protection? If the server
receives a msg_ref value less or equal to the last processed (per
that client), it can reply with out-of-order/already-processed
replies. Why is there a need for timings, clock sync, etc.?
Sure, the msg_ref value can go large after a while, but nowadays
that shouldn't be a problem with 64 bit (or even unbounded) integers...
Ensure that child and parent can implement the protocol with minimal
state, ensure that the protocol is resistant to replay attacks and
ensure that parent or child can perform a complete state reset and
allow the other party to sync back in to the new state without adding
to the protocol itelf.
3.2.2 Resource Class List Response
----------------------------------
class_name
value is the issuer-assigned name of the issuer's Resource Class.
Minor question: shouldn't we introduce a maximum length here? I'd
hate to reserve space for multi-megabyte blobs in a database for this :-)
I have no idea in XML whether such a restriction is good / bad /
indifferent / whatever.
***Does anyone have experience in this area of attempting to bound
the length of text elements in XML-based protocols?
This idea might be applicable to other text type fields too.
status
The value "undersize" indicates that the certificate does not
encompass all resources allocated to the ISP within this class.
The value "match" indicates that the certificate spans all
currently ISP-allocated resources in this class. The value
"oversize" indicates that the certificate spans more than the
currently ISP-allocated resources 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
Typo: req_resource_set_*
ack
comparison status value refers to a comparison between the
certified resource set and the intersection of the original
requested resource set and the current ISP-allocated resource
set.
So the IR is only being nice to provide this flag? After all, the
ISP can determine this on its own.
well the child can _assume_ it on its own, but cannot _confirm_ it.
The explicit echoing of the child's request is a means of
confirmation that the state is held by the parent.
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 ISP must use different key pairs for each distinct resource class.
I believe this is a "MUST".
IETF-speak :-)
If any of req_resource_set_* attributes are specified in the request,
then any missing req_resource_set-* attributes are to be interpreted as
Typo again (or is that a "copo"? :-)
ack
specifying the complete set of the corresponding resource type that match
the ISP's current 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 Subject's public key. Any
I'm getting overloaded with the terms IR/server/Issuer vs. ISP/client/Subject.
this has been fixed as per Randy's earlier comments
subsequent Certificate Issuance Requests that specify the same Resource
Class and the same Subject's public key will (re)set the Issuer's local
record of the requested resource sets to the most recently specified
values.
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 child's key pair by requesting the parent to
revoke all certificates for this child that contain the matching public
key, within the scope of a named Resource Class. Individual issued
certificates cannot be revoked within this protocol.
"within the scope of a named Resource Class" is redundant as the
client MUST use different keys for different classes. It's not
confusing though.
will leave as is.
This command directs the IR to immediately mark all issued valid
certificates issued by this IR within the named Resource Class with this
ISP's SKI value to be marked as revoked, causing the issued certificates
to be withdrawn from the publication respository and to be listed in the
IR's subsequent CRLs within this Resource Class.
I'd rather reverse this and say: "... causing the issued
certificates to be listed in the IR's subsequent CRLs and
potentially to be withdrawn from the publication repository.". This
is again because the CRL is THE authoritative source of revocation,
not the non-existence in a repository.
I don't think the sentence as it stands places a relative priority
one way or the other - I can reverse it, but I don't see this as
affecting an implementation either way!
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 issuer's Resource Class.
ski
value is the g(SKI) of the ISP's public key that has been marked
for revocation.
I wonder if it would help the ISP to receive the list of serial
numbers for the revoked certificates. Maybe not.
I had also thought "not".
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>
Do we really need the "xml:lang" attribute?
Byron had said "yes"
----------------------------------------------------
Messages that fail (envelope / outer wrapper) signature validation do not
generate any response.
Well, in a way they do: HTTP/400. So it may be clearer to say they
"only generate HTTP 400 ..." response.
This text removed as this is already covered earlier and this is just
a confusing addition.
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.
Hmmm. So the presence of a tag depends on the content (!) of another
tag? That seems weird...
but is useful in the described algorithm
And that's all!
thanks!
Geoff
