On 12/1/09 19:26, Paul Hoffman wrote:
At 1:52 PM +0100 1/12/09, Ian G wrote:
These are word games. What is the definition of these words? If you look in
the RFCs, likely (I have not, please correct me if I am wrong)
A better idea would be for all of us to read them and point out where in the
document it says something.
OK, I did that, for revocation. See the copied snippets below, for
anyone who wants to quickly skim the bits I found.
For example, in the case of "expired", you are wrong. Nothing in RFC 5280 says
that expiration (or, more formally, the end of the certificate validity period) has
anything to do with the CPS.
I guess I didn't explain myself well enough. Here's the logic:
* RFC5280 is an implementation document and doesn't do
semantics much, if at all.
* It does not define the meaning of expiry or revocation.
* By _meaning_, I mean semantics, what outsiders should take
as the message being delivered, implying some hint as to
action.
* RFC5280 does suggest that they work together.
* (I conclude that) RFC5280 suggests that:
*revocation and out-of-validation have the same meaning*.
* But we still don't know what that meaning is.
* (see especially last three paras at bottom.)
* Because the purpose of certs is to do something with them,
for end-users, and that something is intended to be turned
on or off according to expiry and revocation, then I
conclude that the meaning MUST be available to end-users.
* RFC3647, section 4.4.9 says
"Revocation checking requirement for relying parties"
which ties revocation to reliance, within the CPS
* The CA typically ties reliance to an unrevoked and
unexpired cert.
* For sake of today's discussion, let's say the meaning is:
*you MUST NOT rely*
at least as an example of what it could be.
* In PKI concepts, reliance is defined in the CPS
* In CA/secure browsing, reliance is commonly in RPAs.
* I would conclude it should be in one of those two.
* In CAcert, which I audit, there is no exact definition,
but there is sufficient discussion that the meaning is
clear, there is a full stop to the end of any sentance.
Sorry for being so wordy, but this is just yet another example of where
the end-user was totally forgotten in the discussion of secure browsing.
iang
=======================RFC5280 selected snippets
"CAs are responsible for indicating the revocation status of the
certificates that they issue."
3.3. Revocation
"When a certificate is issued, it is expected to be in use for its
entire validity period. However, various circumstances may cause a
certificate to become invalid prior to the expiration of the validity
period. Such circumstances include change of name, change of
association between subject and CA (e.g., an employee terminates
employment with an organization), and compromise or suspected
compromise of the corresponding private key. Under such
circumstances, the CA needs to revoke the certificate.
" An entry MUST NOT be removed
from the CRL until it appears on one regularly scheduled CRL issued
beyond the revoked certificate's validity period.
*this above would make one of my comments wrong, but*
" Once the CA accepts a revocation report as
authentic and valid, any query to the on-line service will correctly
reflect the certificate validation impacts of the revocation.
" (f) revocation request: An authorized person advises a CA of an
abnormal situation requiring certificate revocation.
" This may be accomplished by expiration or
revocation of all CA certificates containing the public key used to
verify the signature on the certificate and discontinuing use of the
public key used to verify the signature on the certificate as a trust
anchor.
" If the DistributionPoint omits the reasons field, the CRL MUST
include revocation information for all reasons. This profile
RECOMMENDS against segmenting CRLs by reason code.
" A complete CRL lists all unexpired certificates, within its scope,
that have been revoked for one of the revocation reasons covered by
the CRL scope. A full and complete CRL lists all unexpired
certificates issued by a CA that have been revoked for any reason.
" The CRL issuer MAY also generate delta CRLs. A delta CRL only lists
those certificates, within its scope, whose revocation status has
changed since the issuance of a referenced complete CRL.
*this above would be more the spirit of unrevokation!*
" This profile defines one private Internet CRL extension but does not
define any private CRL entry extensions.
Environments with additional or special purpose requirements may
build on this profile or may replace it.
" revokedCertificates SEQUENCE OF SEQUENCE {
userCertificate CertificateSerialNumber,
revocationDate Time,
crlEntryExtensions Extensions OPTIONAL
-- if present, version MUST be v2
} OPTIONAL,
crlExtensions [0] EXPLICIT Extensions OPTIONAL
-- if present, version MUST be v2
}
" ......each entry on the revoked certificate
list is defined by a sequence of user certificate serial number,
revocation date, and optional CRL entry extensions.
" The revoked certificate list is optional to support the
case where a CA has not revoked any unexpired certificates that it
has issued.
" Additional information
may be supplied in CRL entry extensions; CRL entry extensions are
discussed in Section 5.3.
" (b) If the certificate is valid and was listed on the referenced
base CRL or any subsequent CRL with reason code
certificateHold, and the reason code certificateHold is
included in the scope of the CRL, list the certificate with
the reason code removeFromCRL.
*Ah, that's what I was thinking about.....*
" (c) If the certificate is revoked for a reason outside the scope
of the CRL, but the certificate was listed on the referenced
base CRL or any subsequent CRL with a reason code included in
the scope of this CRL, list the certificate as revoked but
omit the reason code.
(d) If the certificate is revoked for a reason outside the scope
of the CRL and the certificate was neither listed on the
referenced base CRL nor any subsequent CRL with a reason code
included in the scope of this CRL, do not list the
certificate on this CRL.
The status of a certificate is considered to have changed if it is
revoked (for any revocation reason, including certificateHold), if it
is released from hold, or if its revocation reason changes.
It is appropriate to list a certificate with reason code
removeFromCRL on a delta CRL even if the certificate was not on hold
in the referenced base CRL. If the certificate was placed on hold in
any CRL issued after the base but before this delta CRL and then
released from hold, it MUST be listed on the delta CRL with
revocation reason removeFromCRL.
A CRL issuer MAY optionally list a certificate on a delta CRL with
reason code removeFromCRL if the notAfter time specified in the
certificate precedes the thisUpdate time specified in the delta CRL
and the certificate was listed on the referenced base CRL or in any
CRL issued after the base but before this delta CRL.
" The reason codes associated with a distribution point MUST be
specified in onlySomeReasons. If onlySomeReasons does not appear,
the distribution point MUST contain revocations for all reason codes.
CAs may use CRL distribution points to partition the CRL on the basis
of compromise and routine revocation. In this case, the revocations
with reason code keyCompromise (1), cACompromise (2), and
aACompromise (8) appear in one distribution point, and the
revocations with other reason codes appear in another distribution
point.
" If a CRL includes an issuingDistributionPoint extension with
onlySomeReasons present, then every certificate in the scope of the
CRL that is revoked MUST be *assigned a revocation reason* other than
unspecified. The assigned revocation reason is used to determine on
which CRL(s) to list the revoked certificate, however, *there is no
requirement to include the reasonCode CRL entry extension* in the
corresponding CRL entry.
*my emphasis*
" 5.3.1. Reason Code
The reasonCode is a non-critical CRL entry extension that identifies
the reason for the certificate revocation. CRL issuers are strongly
encouraged to include meaningful reason codes in CRL entries;
however, the reason code CRL entry extension SHOULD be absent instead
of using the unspecified (0) reasonCode value.
The removeFromCRL (8) reasonCode value may only appear in delta CRLs
and indicates that a certificate is to be removed from a CRL because
either the certificate expired or was removed from hold. All other
reason codes may appear in any CRL and indicate that the specified
certificate should be considered revoked.
id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 }
-- reasonCode ::= { CRLReason }
CRLReason ::= ENUMERATED {
unspecified (0),
keyCompromise (1),
cACompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6),
-- value 7 is not used
removeFromCRL (8),
privilegeWithdrawn (9),
aACompromise (10) }
"5.3.2. Invalidity Date
The invalidity date is a non-critical CRL entry extension that
provides the date on which it is known or suspected that the private
key was compromised or that the certificate otherwise became invalid.
This date may be earlier than the revocation date in the CRL entry,
which is the date at which the CA processed the revocation.
" 6.1.3. Basic Certificate Processing
The basic path processing actions to be performed for certificate i
(for all i in [1..n]) are listed below.
....
(3) At the current time, the certificate is not revoked.
....
If any of steps (a), (b), (c), or (f) fails, the procedure
terminates, returning a failure indication and an appropriate reason.
" The algorithm output is the revocation status of the certificate.
" (a) reasons_mask: This variable contains the set of revocation
reasons supported by the CRLs and delta CRLs processed so
far. The legal members of the set are the possible
revocation reason values minus unspecified: keyCompromise,
cACompromise, affiliationChanged, superseded,
cessationOfOperation, certificateHold, privilegeWithdrawn,
and aACompromise. The special value all-reasons is used to
denote the set of all legal members. This variable is
initialized to the empty set.
"8. Security Considerations
" If such a compromise is detected, all
certificates issued to the compromised CA MUST be revoked, preventing
services between its users and users of other CAs
" The availability and freshness of revocation information affects the
degree of assurance that ought to be placed in a certificate. While
certificates expire naturally, events may occur during its natural
lifetime that negate the binding between the subject and public key.
If revocation information is untimely or unavailable, the assurance
associated with the binding is clearly reduced. Relying parties
might not be able to process every critical extension that can appear
in a CRL. CAs SHOULD take extra care when making revocation
information available only through CRLs that contain critical
extensions, particularly if support for those extensions is not
mandated by this profile.
" Similarly, implementations
of the certification path validation mechanism described in Section 6
that omit revocation checking provide less assurance than those that
support it.
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
