Dear Nikos,

On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos <n...@gnutls.org>
wrote:

> On Tue, Sep 12, 2017 at 2:59 PM, Dmitry Belyavsky <beld...@gmail.com>
> wrote:
> > Hello,
> >
> > Here is the new version of the draft updated according to the discussion
> on
> > mozilla-dev-security list.
>
> Hi,
>  It seems that most of the details of the underlying format are
> missing. As far as I understand it is mostly an intentions document at
> this point right? I have few comments:
>

The format will be CRL-like.

>
> 1. requiredX509extensions: What's the reasoning behind this? If these
> extensions are required and not present why keep the root certificate
> in the trust store?
>

The main intended case is "require Certificate Transparency".
Currently using the CT is not mandatory for all CAs.


>
> 2. What is the difference between issuedNotAfter and trustNotAfter?
> The description text is unclear to me.
>

issuedNotAfter - we do not trust to the certificates issued after the date.
trustNotAfter - we do not trust certificates after the date XXX, if they
have notAfter > XXX


>
> 3. applicationNameConstraints: very useful, however it is unclear from
> the ASN.1 description how are these stored.
>

I'm not so familiar with ASN1 format. I think that syntax from RFC5280 will
fit here.

>
> 4. How do you handle extensions to this format?
>
> Simillary to CRL. Do you have ideas of the extensions?


> 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 the notion of stapled extensions to limit certificates
> [0, 1] and seems quite a flexible approach. Have you considered that
> path?
>
> regards,
> Nikos
>
> [0]. https://p11-glue.freedesktop.org/doc/storing-trust-policy/
> storing-trust-model.html
> [1]. http://nmav.gnutls.org/2016/06/restricting-scope-of-ca-
> certificates.html
>

Thank you very much, I'll look at it.

-- 
SY, Dmitry Belyavsky
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to