| | | | | | | | |
|
|
|
You're here: Home |
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 protocolerror 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.
I tried to find the answer to my question in the above, but failed.I still believe that msg_ref is enough for replay protection (and synchronization too), and that that is the minimum we need - no need to clock syncs and the rest.
3.2.2 Resource Class List Response ----------------------------------class_namevalue 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?
Note that I did not refer to the length in the XML protocol, but in RE/IRBE storage ("blobs in a database"). XML can handle practically anything, but database fields have to have a maximum length. I can agree on RobL's 256 suggestion (or practically any number that we set in advance).
This command directs the IR to immediately mark all issued validcertificates 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 theIR'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!
Your wording suggests that removing objects from the repository is a must. I tried to express that CRLing is a must, and removing from repository is a should.
----------------------------------------------------Messages that fail (envelope / outer wrapper) signature validation do notgenerate 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_processedvalue indicates the responder's last processed msg_ref value. This element MUST be present when an "incorrect msg_ref" status code isused. 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
I'm still not convinced that we need that algorithm (see above).OTOH, I wonder what Byron would say to the above conditional presence, as I think it prevents automatic schema validation.
Cheers, Robert
And that's all!thanks! Geoff
