Hello,
I've just uploaded the new version of my draft.
The main difference from the previous one is more or less described syntax
of
specific limitations mentioned in text.
The answers on the question raised by Nikos are below.
=
A new version of I-D,
On Tue, Sep 12, 2017 at 5:59 AM, Dmitry Belyavsky via
dev-security-policy wrote:
> Here is the new version of the draft updated according to the discussion on
> mozilla-dev-security list.
Given that RFC 5914 already defines a TrustAnchorList and
On Wed, Sep 20, 2017 at 3:21 PM, Dmitry Belyavsky wrote:
> Dear Nikos
>
> On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos
> wrote:
>>
>>
>> 4. How do you handle extensions to this format?
>>
>> Overall, why not use X.509 extensions to store such
Dear Nikos
On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos
wrote:
>
> 4. How do you handle extensions to this format?
>
> Overall, why not use X.509 extensions to store such additional
> constraints? We already (in the p11-kit trust store in Fedora/RHEL
> systems) use
Dear Nikos,
On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos
wrote:
> On Tue, Sep 12, 2017 at 2:59 PM, Dmitry Belyavsky
> wrote:
> > Hello,
> >
> > Here is the new version of the draft updated according to the discussion
> on
> > mozilla-dev-security
5 matches
Mail list logo