[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed Up/Down protocol description
Hello,
I'm back from home, and trying to catch up with the traffic you generated
here :-) I've read through all the previous emails, and I'm trying not to be
redundant with my comments. (Many of my comments on 0.9.7 were discussaed
anyway.)
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?
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.
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...
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 :-)
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_*
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.
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".
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"? :-)
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.
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.
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.
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.
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?
----------------------------------------------------
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.
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...
And that's all!
Cheers,
Robert
