Oliver Welter wrote:
As soon as the first operator has approved the request, no one is allowed to touch the data as it will break the approval of the preceeding operators - so I see the need for two states
"pending_and_not_reviewed" and "pending_and_currently_processing"
but this is, what i called - if a object enters 'edit' state it gets looked (isn't allowed to change), - so maybe we just need a pre-pending state - because pending is for me the state where the object waits for the decission, but i missed this in the reply to michael - right
or why - don't we call the 'new' state -> reviewed ;)
so it would be: pending (no actions no corrections done) -> reviewed (locked) -> (approved || rejected) depending on decission, but the object data still is locked since it entered reviewed state forever, since there also would be a first signature on it, see below
so if it enters 'reviewed' state - its not allowed to change anymore
huhu - as the RA-System is a online system and a potential target for a security relevant break in, I would feel much better if ALL approval-signaures are appended and checked again by the CA - that is waht we are doing at the moment - otherwise I see a problem when someone breaks in the system and can sign penindg requests with an "ra-key" as I see no chance to really protect such a key...
that was, what i wanted to get clear for everybody since:
object -- 1:n -- action -- 1:1 -- signature
doesn't look like everybody signs, what i would like more too (everybody signs) his 'action'...
but:
now we have this problem, which are michael and martin are talking about: we have one object and we have operators and we have signatures and we have decission making process
usaly the request object would get signed with its NEW state either - approved or rejected - so it can't be changed and its clear what to do on the CA with it, if the signature verifies...
now - you can't sign the object with all its parameters - like the state for example - since - its not clear which state it will become after the first operator signed it (if its more then one ;)...
there may be now different options - how to handle this:
- martin suggested this copy approach
- we could do something like:
- the first operator signs together with state: reviewed
since he did the review - so thats ok
- all intermediary operators 'just' sign there action
which is keeped separatly in the decission making table
- the last operator who makes a decission which leads to
the final decission (either reject or n reached) signes
the objecet again, but changes the state - the CA can now verify the first signature by changing
the state back to reviewed - this must validate
- verifies the second signature with the data like it is
this must validate too- the object gets processed by the CA
- now we could think about, maybe it may be necessary to
add those 'intermediary' actions and signatures too, but
therefor the audit trail exists, if a revalidation of the
process for a special certificate may needed some time in
the future, so i think its not necessary to put this into
the request object too - so my approach would be: always! sign significant state
changes of the objects - like from: pending -> reviewed
and from reviewed->(approved || rejected) - so a request-object would have two signatures in the end
of the day, doesn't matter how many operators have to be
involved into the decission making process
- if we have n=1 there would be the same operator signature
twice, since he reviews and finishes the decission process - the object changes are protected by operator signatures
- no ra-key involved- some more ideas from you: ;) - maybe they are simpler, simple is always good in security - -
- one more thought, what came to my mind, if oli talked about: you can't protect a ra-key, you can't also protect the 'n' of how many operators are needed to sign, since someone could even change the code to ignore the n - so the first operator 'approves' i think
*hmpf*
how can we protect the n?
- review on protecting n: you can protect the n
- the CA must know it too, a atack on the ra could be detected at the CA then... so maybe we should add all signatures, the CA can then recount them the following way:
- an approved request needs: - n-1 signatures with object state 'reviewed' - and 1 with object state 'approved' (the final decission) - all have to be valid operator signatures
- a rejected request needs: - <n signatures with object state 'reviewed' - and 1 with object state 'rejected' (the final decission) - all have to be valid operator signatures
otherwise, you can't never be sure, the decission won't be manipulated - or does i oversee something?
that means i extend my approach from above (how to work on the 'ra'):
- every operator who makes a decission signs the object in state 'reviewed'
- the last behaves like described or should he always sign twice?
(means sign the review and then add the final decission -> change objects state)
- the ca then have to reset the state to 'review' to validate all signatures, except the last one, which 'added' the final decission?
- maybe one can handle this different - other ideas?
- but i think its very importend to protect the state of the object since it decides if the object get exported to the ca and a certificate will be issued or not
so end of long mail ;)
greetings dalini
------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ OpenCA-Devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/openca-devel
