On 06/07/2012 07:28 AM, Endi Sukma Dewata wrote: > The cert revocation CLI provides a tool to revoke and unrevoke > certificates. "unrevoke" is really inappropriate term. It suggests that one could unrevoke any revoked certificate where is fact one can only take off hold certificates that are currently on hold.

On 06/07/2012 02:04 PM, Endi Sukma Dewata wrote: > On 6/7/2012 11:38 AM, Andrew Wnuk wrote: >> On 06/07/2012 07:28 AM, Endi Sukma Dewata wrote: >>> The cert revocation CLI provides a tool to revoke and unrevoke >>> certificates. >> >> "unrevoke" is really inappropriate term. It suggests that one could >> unrevoke any revoked certificate where is fact one can only take off >> hold certificates that are currently on hold. > > How about a "revoke" command for permanent revocation only, and > separate "on-hold" and "off-hold" commands for temporary revocation? > Any suggestions? > This is asymmetric case. "on-hold" is just one of many revocation reasons. Certificate can be taken off hold if it was revoked with "on-hold" reason. There are only two operations: certificate revocation and taking certificates off hold.

On 06/08/2012 12:06 PM, Endi Sukma Dewata wrote: > On 6/8/2012 1:12 PM, Andrew Wnuk wrote: >> On 06/07/2012 02:04 PM, Endi Sukma Dewata wrote: >>> On 6/7/2012 11:38 AM, Andrew Wnuk wrote: >>>> On 06/07/2012 07:28 AM, Endi Sukma Dewata wrote: >>>>> The cert revocation CLI provides a tool to revoke and unrevoke >>>>> certificates. >>>> >>>> "unrevoke" is really inappropriate term. It suggests that one could >>>> unrevoke any revoked certificate where is fact one can only take off >>>> hold certificates that are currently on hold. >>> >>> How about a "revoke" command for permanent revocation only, and >>> separate "on-hold" and "off-hold" commands for temporary revocation? >>> Any suggestions? >>> >> This is asymmetric case. "on-hold" is just one of many revocation >> reasons. Certificate can be taken off hold if it was revoked with >> "on-hold" reason. There are only two operations: certificate revocation >> and taking certificates off hold. > > The original "revoke" operation is partially asymmetric (permanent > revocation) and partially symmetric (temporarily on-hold). It might be > more intuitive to create a new "revoke" command that does asymmetric > operation only (no "unrevoke" operation) and separate "on-hold" and > "off-hold" commands for the symmetric operations. > > If we only have "revoke" and "off-hold" only, people might be > thinking, there's an "off-hold" command, so how do I "hold" a cert? It > might not be very obvious that the "revoke" command has an "on-hold" > option which behaves differently from the other revoke reasons. > I tend to agree from a pure CLI perspective. Behind the scenes, "on-hold" is really a revocation reason, but that doesn't mean we need to make the CLI use the exact same terminology. How about having "revoke", "on-hold", and "off-hold" commands? We can still allow one to use the "revoke" command and specify the revocation reason as on-hold, which would be the equivalent of the "on-hold" command.

On 06/08/2012 04:37 PM, Endi Sukma Dewata wrote: > On 6/8/2012 2:19 PM, Nathan Kinder wrote: >> On 06/08/2012 12:06 PM, Endi Sukma Dewata wrote: >>> On 6/8/2012 1:12 PM, Andrew Wnuk wrote: >>>> On 06/07/2012 02:04 PM, Endi Sukma Dewata wrote: >>>>> On 6/7/2012 11:38 AM, Andrew Wnuk wrote: >>>>>> On 06/07/2012 07:28 AM, Endi Sukma Dewata wrote: >>>>>>> The cert revocation CLI provides a tool to revoke and unrevoke >>>>>>> certificates. >>>>>> >>>>>> "unrevoke" is really inappropriate term. It suggests that one could >>>>>> unrevoke any revoked certificate where is fact one can only take >>>>>> off >>>>>> hold certificates that are currently on hold. >>>>> >>>>> How about a "revoke" command for permanent revocation only, and >>>>> separate "on-hold" and "off-hold" commands for temporary revocation? >>>>> Any suggestions? >>>>> >>>> This is asymmetric case. "on-hold" is just one of many revocation >>>> reasons. Certificate can be taken off hold if it was revoked with >>>> "on-hold" reason. There are only two operations: certificate >>>> revocation >>>> and taking certificates off hold. >>> >>> The original "revoke" operation is partially asymmetric (permanent >>> revocation) and partially symmetric (temporarily on-hold). It might be >>> more intuitive to create a new "revoke" command that does asymmetric >>> operation only (no "unrevoke" operation) and separate "on-hold" and >>> "off-hold" commands for the symmetric operations. >>> >>> If we only have "revoke" and "off-hold" only, people might be >>> thinking, there's an "off-hold" command, so how do I "hold" a cert? It >>> might not be very obvious that the "revoke" command has an "on-hold" >>> option which behaves differently from the other revoke reasons. >>> >> I tend to agree from a pure CLI perspective. Behind the scenes, >> "on-hold" is really a revocation reason, but that doesn't mean we need >> to make the CLI use the exact same terminology. >> >> How about having "revoke", "on-hold", and "off-hold" commands? We can >> still allow one to use the "revoke" command and specify the revocation >> reason as on-hold, which would be the equivalent of the "on-hold" >> command. > > +1 > > Some other possibilities: > - revoke/hold/release I like this one. Maybe even "revoke/hold/release-hold"? Plain "release" doesn't seem very descriptive on it's own. I think "release-hold" is more clear. > - revoke/suspend/release > - revoke/enable/disable >

On 6/10/2012 4:55 PM, Andrew Wnuk wrote: > On 06/08/2012 04:56 PM, Nathan Kinder wrote: >>> - revoke/hold/release >> I like this one. Maybe even "revoke/hold/release-hold"? Plain >> "release" doesn't seem very descriptive on it's own. I think >> "release-hold" is more clear. Sounds good. I'll change that in the next patch revision. > "on-hold" and "off-hold" are just two revocation reason values. Official > standard names and values are certificateHold (6) and removeFromCRL (8), > so I am fine with additional helper functions/commands (for hold and > release/remove) as long as revocation will support all standard values > for reason parameter including "certificateHold" and "removeFromCRL". > > CA provides two step revocation to avoid accidental revocation of > incorrect certificates. This is important since revocation operation is > irreversible (with one exception) and it is specially important to avoid > accidental revocation of CA certificate. Do you mean the CA Web UI? In the UI you'd have to go through several pages to find & select the certs and enter the revocation date/reason/comments, but you can still change the inputs in the last (confirmation) page, and once you click Submit the certificate will be revoked immediately, so basically it's still a single step operation. Usually a confirmation page shouldn't allow any input change without navigating to another page first. > I do hope that CLI interface provides secure two step revocation > including protection against accidental revocation of CA certificate. I can change the CLI to ask for a confirmation before executing the operation like this: % pki cert-revoke 0x8 --reason=KEY_COMPROMISE Revoking certificate "0x8". Are you sure (Y/N)? Y ------------------------- Revoked certificate "0x8" -------------------------

And for automation/scripting you can suppress the confirmation: % pki cert-revoke 0x8 --reason=KEY_COMPROMISE --force ------------------------- Revoked certificate "0x8" ------------------------- Is this ok? How about the other add/mod/delete commands, should we confirm each operation that changes the database?

On 6/11/2012 6:30 PM, Andrew Wnuk wrote: >>> I do hope that CLI interface provides secure two step revocation >>> including protection against accidental revocation of CA certificate. >> >> I can change the CLI to ask for a confirmation before executing the >> operation like this: >> >> % pki cert-revoke 0x8 --reason=KEY_COMPROMISE >> Revoking certificate "0x8". >> Are you sure (Y/N)? Y >> ------------------------- >> Revoked certificate "0x8" >> ------------------------- > You not really after confirmation but verification, so you need more > info than just the same serial number. > You want to be sure that you are actually revoking correct certificate, > so maybe serial number and subject name would be enough. Suppose there is a number of certs with the same subject (I'm not sure how common this is), requiring the serial number and the subject name might not be much more helpful than requiring the serial number alone. How about showing the cert info in the confirmation? % pki cert-revoke 0x8 --reason=KEY_COMPROMISE Revoking certificate: Serial Number: 0x8 Issuer: CN=Certificate Authority,O=EXAMPLE-COM Subject: UID=testuser,E=testuser(a)example.com,CN=Test User Status: VALID Not Before: Mon Jun 11 17:29:44 CDT 2012 Not After: Sat Dec 08 16:29:44 CST 2012 Are you sure (Y/N)? Y ------------------------- Revoked certificate "0x8" ------------------------- In the UI you can search the certs based on other criteria such as subject, issuer, validity, etc. In CLI this can be handled by a separate cert-find command. Once you get the serial number you can use it to call cert-revoke. If you know exactly the serial number you want to revoke, you can skip the cert-find and then call cert-revoke with --force to skip the confirmation.

>> Is this ok? How about the other add/mod/delete commands, should we >> confirm each operation that changes the database? Same question, do we need to do the same type of verification/confirmation for other update operations?

On 6/7/2012 9:28 AM, Endi Sukma Dewata wrote: > The cert revocation CLI provides a tool to revoke and unrevoke > certificates. > > Ticket #161 New patch attached. The CLI has been renamed to cert-revoke, cert-hold, and cert-release-hold. Permanent revocation will trigger a confirmation prompt. Self-signed CA cert cannot be revoked.

>>> The cert revocation CLI provides a tool to revoke and unrevoke >>> certificates. >> >> New patch attached. The CLI has been renamed to cert-revoke, cert-hold, >> and cert-release-hold. Permanent revocation will trigger a confirmation >> prompt. Self-signed CA cert cannot be revoked. > > New patch attached. By default the cert-revoke will only revoke non-CA > certs. To revoke CA cert you'd have to add --ca option. New patch attached. It fixes classpath problem in pki script on F17.