hi Dalini,
yes your "edit" state would ne quite the same than my suggestion - I addresses this to martin cause it ssemed to me that he missed the point...
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 ;)...
Hmm I dont see a problem or am I missing something ?
As far as I cant see every legal request is a well formated CSR or at least a "Key + Cert" generation request, so we have either a PKCS10 formatted CSR or a kind of DN and some add ons like your pre-shared key for SCEp or a user-pin for encrypting the pkcs12 package - we are driving a CA so the only legal action on this stuff is to make a certificate out of it - nothing more, so why do we need to encode the next action ? Which operation must be approved by the operators else ?
So I suggest to make the signature ONLY on the pkcs10 CSR or a similar structure containing the relevant data - as this is not including the state, we dont have any prolbems that we break the operators signature when changing the state - that is exactly the way we do now - the signature is only on the data objetct which doesnt contain a state information
- 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:
Stupid question - where do you want to configure which kind of request need how much approvals - I would prefer to do this based on a global ruleset, lets say based on the DN and/or the Role of the user - so e.g. I have several OUs in my company and use this attribute for gaining access to ressources - than I will allow a single operator to grant a certifiacate to a sales person, but need at least X operators for a new "geschäftsführer" who can access confidential data. This brings to my mind not to only specifiy the number of operators but also there Role - so an operator cannot sign all kinds of requests
Same thoughts apply to the roles - the creation of a new CA Operator certifiate is more sensible than a new person in business operations
I see we should invent a regular face to face meeting :)
Oli -- Diese Nachricht wurde digital unterschrieben oliwel's public key: http://www.oliwel.de/oliwel.crt Basiszertifikat: http://www.ldv.ei.tum.de/page72
smime.p7s
Description: S/MIME Cryptographic Signature
