On Sep 17, 2013, at 11:26 AM, "Henry B. Hotz" wrote:
> MRL's
Gaaa. Spelling mis-correction. That should have been NRL, as in Naval
Research Lab where Ken Hornstein worked.
--
The opinions expressed in this message are
Thanks for the update. Obviously my info is old, though I have seen issues
with our RSA deployment that suggest things haven't effectively changed much in
their product.
On Sep 16, 2013, at 7:44 PM, Dmitri Pal wrote:
>> Substituting FAST/OTP for SAM doesn't change anything in the back-end
>>
On Sep 15, 2013, at 11:17 AM, Dmitri Pal wrote:
> On 09/13/2013 06:06 PM, Henry B. Hotz wrote:
>> On Sep 13, 2013, at 11:38 AM, Dmitri Pal wrote:
>>
>>>> , ipatokenotpalgorithm
>>> Uses default TOTP we do not support more for now. In future it will be a
&g
On Sep 14, 2013, at 10:25 AM, Simo Sorce wrote:
> On Fri, 2013-09-13 at 15:06 -0700, Henry B. Hotz wrote:
>> On Sep 13, 2013, at 11:38 AM, Dmitri Pal wrote:
>>
>>>> , ipatokenotpalgorithm
>>>
>>> Uses default TOTP we do not support more for no
On Sep 13, 2013, at 11:38 AM, Dmitri Pal wrote:
>> , ipatokenotpalgorithm
>
> Uses default TOTP we do not support more for now. In future it will be a
> global policy I assume.
This is just me, like the sig says.
I would advocate for HOTP, with a bunch of special processing for token counter
I would strongly argue for a separate CA list for PKINIT (service or
workstation login) vice HTTP (web browsing of semi-unknown sites). The trust
models are fundamentally different.
In the former case you are saying who is allowed to issue (conceivably
fraudulent) client certs that allow (conc
Aren't the implementations of name constrains generally buggy, and therefore
not usable in real life?
On Sep 9, 2013, at 9:02 AM, Nalin Dahyabhai wrote:
> On Mon, Sep 09, 2013 at 10:32:08AM -0400, John Dennis wrote:
>> Good point. Isn't there an X509 extension (possibly part of PKIX?) which
>>