Revocation - Revision history

Tom: /* Problems */

2024-11-15T22:58:13Z

‎Problems

Tom: /* Problems */

2024-11-15T22:55:09Z

‎Problems

Tom: /* Problems */

2024-11-15T22:54:05Z

‎Problems

Tom: /* Problems */

2018-10-03T16:07:00Z

‎Problems

Tom: /* Solutions */

2018-10-03T16:06:26Z

‎Solutions

Tom: /* Solutions */

2018-10-03T16:05:56Z

‎Solutions

Tom: /* Problems */

2018-10-03T16:02:17Z

‎Problems

Tom: /* Full Title or Meme */

2018-10-02T17:15:24Z

‎Full Title or Meme

Tom: /* Solutions */

2018-10-02T17:14:33Z

‎Solutions

Tom: /* Context */

2018-10-02T17:03:39Z

‎Context

@@ Line 10: / Line 10: @@
 *As a general rule any certificate that is issued to any [[Subject]] cannot be guaranteed of [[Revocation]] because it is not possible to know where that certificate has been used.
 *Once a [[Bearer Token]] has been issued to a [[Relying Party]] by a [[Identifier or Attribute Provider]] there is no practical way to issue a [[Revocation]] that will guarantee success.
-* Certificate revocation: Mechanics and meaning Barbara Fox and Brian LaMacchia
+* Certificate revocation: Mechanics and meaning Barbara Fox and Brian LaMacchia<ref>Research Gate https://www.researchgate.net/scientific-contributions/Barbara-Fox-70755466</ref>
 <blockquote>[[Revocation]] of public key certificates is controversial in every aspect: methodology, mechanics, and even meaning. This isn't so surprising, though, when considered in the context of current public key infrastructure (PKI) implementations. PKIs are still immature; consumers, including application developers and end-users, are just beginning to understand the implications of large-scale, heterogeneous PKIs, let alone PKI subtleties such as revocation. In this paper, which is the product of a panel discussion at Financial Cryptography '98, we illustrate some of the semantic meanings possible with current certificate revocation technology and their impact on the process of determining trust relationships among public keys in the PKI. Further, we postulate that real-world financial applications provide analogous and appropriate models for certificate revocation.</blockquote>

@@ Line 11: / Line 11: @@
 *Once a [[Bearer Token]] has been issued to a [[Relying Party]] by a [[Identifier or Attribute Provider]] there is no practical way to issue a [[Revocation]] that will guarantee success.
 * Certificate revocation: Mechanics and meaning Barbara Fox and Brian LaMacchia
-<blockquote>Revocation of public key certificates is controversial in every aspect: methodology, mechanics, and even meaning. This isn't so surprising, though, when considered in the context of current public key infrastructure (PKI) implementations. PKIs are still immature; consumers, including application developers and end-users, are just beginning to understand the implications of large-scale, heterogeneous PKIs, let alone PKI subtleties such as revocation. In this paper, which is the product of a panel discussion at Financial Cryptography '98, we illustrate some of the semantic meanings possible with current certificate revocation technology and their impact on the process of determining trust relationships among public keys in the PKI. Further, we postulate that real-world financial applications provide analogous and appropriate models for certificate revocation.</blockquote>
+<blockquote>[[Revocation]] of public key certificates is controversial in every aspect: methodology, mechanics, and even meaning. This isn't so surprising, though, when considered in the context of current public key infrastructure (PKI) implementations. PKIs are still immature; consumers, including application developers and end-users, are just beginning to understand the implications of large-scale, heterogeneous PKIs, let alone PKI subtleties such as revocation. In this paper, which is the product of a panel discussion at Financial Cryptography '98, we illustrate some of the semantic meanings possible with current certificate revocation technology and their impact on the process of determining trust relationships among public keys in the PKI. Further, we postulate that real-world financial applications provide analogous and appropriate models for certificate revocation.</blockquote>
 ==Solutions==

@@ Line 10: / Line 10: @@
 *As a general rule any certificate that is issued to any [[Subject]] cannot be guaranteed of [[Revocation]] because it is not possible to know where that certificate has been used.
 *Once a [[Bearer Token]] has been issued to a [[Relying Party]] by a [[Identifier or Attribute Provider]] there is no practical way to issue a [[Revocation]] that will guarantee success.
 ==Solutions==

@@ Line 8: / Line 8: @@
 ==Problems==
-*As a general rule any certificate that is issued to any [[Subject]] cannot be [[Revocation|revoked]] because it is not possible to know where that certificate has been used.
+*As a general rule any certificate that is issued to any [[Subject]] cannot be guaranteed of [[Revocation]] because it is not possible to know where that certificate has been used.
 *Once a [[Bearer Token]] has been issued to a [[Relying Party]] by a [[Identifier or Attribute Provider]] there is no practical way to issue a [[Revocation]] that will guarantee success.

@@ Line 12: / Line 12: @@
 ==Solutions==
-* The two canonical ways to [[Revocation|revoke]] any grant is to require that the validity be checked online ([[OCSP]]) or to distribute a list of revoke certificates([[CRL]]).
+* The two canonical ways to [[Revocation|revoke]] any grant (or certificate) is to require that the validity be checked online ([[OCSP]]) or to distribute a list of revoke certificates([[CRL]]).
 * Many mitigations to the [[Revocation]] problem exists, for example giving certificates a very short life time.
 * Issue a [[Refresh Token]] that can be used by the [[Relying Party]] to acquire a fresh access token with a short life time on demand. The IAP would then handle any [[Revocation]] for the user which would have no effect during that short life time.

← Older revision		Revision as of 16:02, 3 October 2018
Line 8:		Line 8:

	==Problems==		==Problems==
		+	*As a general rule any certificate that is issued to any [[Subject]] cannot be [[Revocation\|revoked]] because it is not possible to know where that certificate has been used.
	*Once a [[Bearer Token]] has been issued to a [[Relying Party]] by a [[Identifier or Attribute Provider]] there is no practical way to issue a [[Revocation]] that will guarantee success.		*Once a [[Bearer Token]] has been issued to a [[Relying Party]] by a [[Identifier or Attribute Provider]] there is no practical way to issue a [[Revocation]] that will guarantee success.

@@ Line 1: / Line 1: @@
 ==Full Title or Meme==
-The problem of revoking a grant previously issued on behalf of a [[Subject]] which is a requirement of several privacy regulations.
+The problem of revoking a grant previously issued by an [[Identifier or Attribute Provider]] (IAP) on behalf of a [[Subject]] which is a requirement of several privacy regulations.
 ==Context==

@@ Line 6: / Line 6: @@
 The collection of [[User Private Information]] by a [[Data Controller]] now necessitates the ability [[Authentication|Authenticate]] the [[User]] under a wide range of challenges, like:
 # Simplest of all the [[User]] needs to [[Authentication|Authenticate]] from time to time and on a variety of devices under less than ideal conditions where passwords are mistyped and [[Multi-factor Authentication|Alternate Authentication factors]] are lost or fail.
 ==Problems==