On Dec 8, 2007 3:55 AM, D3||||!$ <[EMAIL PROTECTED]> wrote: > Dear All, > > 1) > The RFC 2459 (http://www.ietf.org/rfc/rfc2459.txt) mentions under > heading 5.3.1 (Reason Code) that "CRL entry extension should be absent > instead of using the unspecified (0) reasonCode value." > > Now, if its not meant to be used then why is it specified in the first > place? What is the purpose of this extension??
(0) is in the specification because of the 'should' word there. It's not a 'must'. However, adding the value generally adds no meaning to the statement being made: "This certificate is on the revocation list." If there's a specific reason why it's revoked, you can add to the statement: "because <x happened>". This certificate is on the revocation list because <the private key associated with it was compromised>. (1) This certificate is on the revocation list because <the private key for the certificate issuer was compromised>. (2) This certificate is on the revocation list because <the subject's affiliation changed and the assertion is no longer correct>. (3) This certificate is on the revocation list because <a new credential has been issued for the subject that supersedes this one>. (4) This certificate is on the revocation list because <the subject has ceased operation or is dead>. (5) This certificate is on the revocation list because <the certificate issuer has placed the assertion it has made temporarily on hold>. (6) This certificate is on the revocation list because <the certificate was at one time placed on the revocation list, but should no longer be treated as being on the revocation list>. (8) It is possible that a reason other than those in the specification could have led to the certificate issuer placing the certificate on the revocation list. This (in my view) would be a very useful reason for allowing (0) to show up: This certificate is on the revocation list because <of some reason that cannot be described by the language of the specification>. That would be a useful reason for saying "unspecified". The alternative reading would be: This certificate is on the revocation list because <of some reason I'm not going to specify to you>. > 2) > Consider the web page given below: > http://docs.sun.com/source/816-5533-10/ext.htm#1012064 > > It forewarns us to set the nonRepudiation (1) bit only after carefully > considering their legal consequences. Since I'm not acquainted with > the use of this bit vey well, I cannot figure what exactly could be > the consequenses of setting this bit in a certificate. Could anybody > kindly give me a real-life example of what could possibly happen with > this bit set? I fully understand the meaning of "Non-Repudiation" but > can't figure out the legal aspect of its presence... "Non-repudiation" is a concept from the legal world, specifically as regards contract signatures. (If you sign a contract obligating you to do something, it would be very bad for you to be able to later claim that you didn't sign it and welsh out of the deal.) I believe nonRepudiation was originally intended for organization CAs to be able to say "we know that the key for this certificate is on a device that is secure from copying and that only the subject can authorize the use of", thus enabling it to be used for legal documents. However, it was designed before there was any legal framework for its usage, and I don't know if any legal environment actually recognizes it. > 3) > While using the certutil tool, how do we set the various bits of the > netscape-cert-type extension for a self-signed CA certificate?? This I don't know the answer to. Anyone else? -Kyle H _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
