On Apr 13, 2013, at 4:24 PM, Stefan Santesson ste...@aaa-sec.com wrote:
These are the three possible states of a serial number. It must always
be in ONE of these states.
As long as you assume that a certificate signed by the CA cannot be
non-issued i.e. CA knows what certificates it issued.
On Apr 11, 2013, at 10:37 PM, Stefan Santesson ste...@aaa-sec.com wrote:
To put it simply. Given how OCSP is designed, the only way to allow good
to represent a white-list, is if revoked can be returned for everything
else.
I realize it's unfair of me to take this quote out of context.
a cert was on the white list (and to know the responder has the white
list), or merely not on the black list. (Yes, I'm repeating myself. Am I
making more sense, or just wasting everyone's time?)
/Stefan
On 4/8/13 9:35 PM, Henry B. Hotz h...@jpl.nasa.gov wrote:
Actually, what I get from
Actually, what I get from this and all the other discussions is that it's
unclear if the updated OCSP satisfies the suitability for the intended
purpose test. Or at least it fails the KISS principle w.r.t. that.
Rephrasing: an OCSP client should be able to tell from an OCSP response if:
a)
I was thinking that if it's a proprietary OTP, we can still use it even if the
algorithm is secret. If we know we're getting a clear text OTP value and we
have an (unspecified) method of verifying it against some external
infrastructure, that's enough to use otp-preauth.
However I don't think
Could we define a new section for the PSKC registry instead of a whole new
registry? (Agree we don't need all this info.)
On Aug 26, 2011, at 8:48 AM, Simon Josefsson wrote:
gareth.richa...@rsa.com writes:
Some form of identifier will be required for the otp-algID in the
PA-OTP-CHALLENGE
On Aug 24, 2011, at 5:45 PM, david.bl...@emc.com wrote:
In section 2.4, the following sentence is potentially confusing:
For example,
event-based tokens may drift since the counter on the token is
incremented every time the token is used but the counter on the
server is only
I don't believe any of my desirements justifies holding up publication.
Practically speaking, I'm most interested in the disconnected case. It
should also be the easiest to test thoroughly. I also believe the draft is
good enough for this case. I would very much like to see client code
On Aug 19, 2011, at 7:48 AM, Sam Hartman wrote:
Greg == Greg Hudson ghud...@mit.edu writes:
87
Greg On Fri, 2011-08-19 at 08:53 -0400, gareth.richa...@rsa.com wrote:
I had always thought the same way as Sam, that clients would be
required to implement all of the options since there
On Sep 22, 2010, at 9:44 AM, Paul Hoffman wrote:
At 10:21 AM -0600 9/22/10, Peter Saint-Andre wrote:
On 9/14/10 12:51 AM, Stefan Santesson wrote:
General:
I would consider stating that server certificates according to this profile
either MUST or SHOULD have the serverAuth EKU set since it
On Sep 22, 2010, at 10:09 AM, Peter Saint-Andre wrote:
2. A human user has explicitly agreed to trust a service that
provides mappings of source domains to target domains, such as a
dedicated discovery service or an identity service that securely
redirects requests from
11 matches
Mail list logo
