Subject: [lamps] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt

From: Dmitry Belyavsky <[email-masked]>
Date: Tue, 12 Sep 2017 15:59:33 +0300

Hello,

Here is the new version of the draft updated according to the discussion on
mozilla-dev-security list.

---------- Forwarded message ----------
From: <[email-masked]>
Date: Tue, Sep 12, 2017 at 3:55 PM
Subject: New Version Notification for draft-belyavskiy-certificate-l
imitation-policy-04.txt
To: Dmitry Belyavskiy <[email-masked]>

A new version of I-D, draft-belyavskiy-certificate-limitation-policy-04.txt
has been successfully submitted by Dmitry Belyavskiy and posted to the
IETF repository.

Name:           draft-belyavskiy-certificate-limitation-policy
Revision:       04
Title:          Certificate Limitation Policy
Document date:  2017-09-11
Group:          Individual Submission
Pages:          7
URL:            https://www.ietf.org/internet-drafts/draft-belyavskiy-certif
icate-limitation-policy-04.txt
Status:         https://datatracker.ietf.org/doc/draft-belyavskiy-certifica
te-limitation-policy/
Htmlized:       https://tools.ietf.org/html/draft-belyavskiy-certificate-li
mitation-policy-04
Htmlized:       https://datatracker.ietf.org/doc/html/draft-belyavskiy-cert
ificate-limitation-policy-04
Diff:           https://www.ietf.org/rfcdiff?url2=draft-belyavskiy-certific
ate-limitation-policy-04

Abstract:
   The document provides a specification of the application-level trust
   model.  Being provided at the application level, the limitations of
   trust can be distributed separately using cryptographically protected
   format instead of hardcoding the checks into the application itself.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-- 
SY, Dmitry Belyavsky

---

From: "Dr. Pala" <[email-masked]>
Date: Tue, 12 Sep 2017 09:16:14 -0600

Hi Dmitry,

could you please summarize the discussion that happened in the 
mozilla-dev-security?

Cheers,
Max

On 9/12/17 6:59 AM, Dmitry Belyavsky wrote:
> Hello,
>
> Here is the new version of the draft updated according to the 
> discussion on mozilla-dev-security list.
>
> From: <[email-masked] <mailto:[email-masked]>>
> Subject: New Version Notification for 
> draft-belyavskiy-certificate-limitation-policy-04.txt
> To: Dmitry Belyavskiy <[email-masked] <mailto:[email-masked]>>
>
>
>
> A new version of I-D, 
> draft-belyavskiy-certificate-limitation-policy-04.txt
> URL: 
> https://www.ietf.org/internet-drafts/draft-belyavskiy-certificate-limitation-policy-04.txt 
> <https://www.ietf.org/internet-drafts/draft-belyavskiy-certificate-limitation-policy-04.txt>
> Status: 
> https://datatracker.ietf.org/doc/draft-belyavskiy-certificate-limitation-policy/ 
> <https://datatracker.ietf.org/doc/draft-belyavskiy-certificate-limitation-policy/>
> Htmlized: 
> https://tools.ietf.org/html/draft-belyavskiy-certificate-limitation-policy-04 
> <https://tools.ietf.org/html/draft-belyavskiy-certificate-limitation-policy-04>
> Htmlized: 
> https://datatracker.ietf.org/doc/html/draft-belyavskiy-certificate-limitation-policy-04 
> <https://datatracker.ietf.org/doc/html/draft-belyavskiy-certificate-limitation-policy-04>
> Diff: 
> https://www.ietf.org/rfcdiff?url2=draft-belyavskiy-certificate-limitation-policy-04 
> <https://www.ietf.org/rfcdiff?url2=draft-belyavskiy-certificate-limitation-policy-04>
>
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org 
> <http://tools.ietf.org>.
>
> The IETF Secretariat
>
>
>
>
> -- 
> SY, Dmitry Belyavsky
>
>
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Dmitry Belyavsky <[email-masked]>
Date: Tue, 12 Sep 2017 22:54:12 +0300

Dear Max,

The letter that seems the most significant for me is here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/--aa6dYHhrc/xbozEdS2BgAJ

This letter enumerates the lion's share of limitations currently applied by
Mozilla, if I am correct.

On Tue, Sep 12, 2017 at 6:16 PM, Dr. Pala <[email-masked]> wrote:

> Here is the new version of the draft updated according to the discussion
> on mozilla-dev-security list.
>
> URL:            https://www.ietf.org/internet-
> drafts/draft-belyavskiy-certificate-limitation-policy-04.txt
> Status:         https://datatracker.ietf.org/
> doc/draft-belyavskiy-certificate-limitation-policy/
> Htmlized:       https://tools.ietf.org/html/d
> raft-belyavskiy-certificate-limitation-policy-04
> Htmlized:       https://datatracker.ietf.org/
> doc/html/draft-belyavskiy-certificate-limitation-policy-04
> Diff:           https://www.ietf.org/rfcdiff?
> url2=draft-belyavskiy-certificate-limitation-policy-04
>
> Abstract:
> Spasm mailing [email-masked]://www.ietf.org/mailman/listinfo/spasm
>
>
>

-- 
SY, Dmitry Belyavsky

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 13 Sep 2017 08:39:21 +0200

> 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:

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?

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

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

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 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

---

From: Dmitry Belyavsky <[email-masked]>
Date: Wed, 13 Sep 2017 14:22:16 +0300

Dear Nikos,

> this point right? I have few comments:

The format will be CRL-like.

> extensions are required and not present why keep the root certificate

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

> 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

> 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.

> Simillary to CRL. Do you have ideas of the extensions?

> [1]. http://nmav.gnutls.org/2016/06/restricting-scope-of-ca-

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

-- 
SY, Dmitry Belyavsky

---

From: Dmitry Belyavsky <[email-masked]>
Date: Wed, 20 Sep 2017 16:21:56 +0300

Dear Nikos

> [1]. http://nmav.gnutls.org/2016/06/restricting-scope-of-ca-

I've looked through the specification. It's OK for me, but I do not get
whether the attached extensions are crypto-protected.
I'm ready to cooperate with you if there is any interest.

-- 
SY, Dmitry Belyavsky

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 22 Sep 2017 10:06:31 +0200

On Wed, Sep 20, 2017 at 3:21 PM, Dmitry Belyavsky <[email-masked]> wrote:
>> [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

No, as these values are inserted by the administrator of the system,
or us (the distributor of the software), we didn't feel we needed the
introduction of additional PKI.

How do you see the infrastructure on the
draft-belyavskiy-certificate-limitation-policy? Who do you envision
signing these structures? (I assume that distribution of data will be
done by software distributors?)

> Simillary to CRL. Do you have ideas of the extensions?

One problem with that is the fact that the existing CRL extensions are
about extending attributes of the CRL, rather than adding/removing
attributes to the certificate in question.

To bring the stapled extensions to your proposal, you'd need the
Extensions and Extension fields from RFC5280, and
add into limitedCertificates structure (I'll split it on the example
below for clarity) the following field.

LimitedCertificates  ::=   SEQUENCE OF LimitedCertificate

LimitedCertificate ::= SEQUENCE {
                userCertificate         CertificateSerialNumber,
                certificateIssuer       Name,
                limitationDate          Time,
                limitationPropagation   Enum,
                fingerprint SEQUENCE {
                    fingerprintAlgorithm AlgorithmIdentifier,
                    fingerprintValue     OCTET STRING
                                     } OPTIONAL,
                limitations          SEQUENCE,
                                   } OPTIONAL,
                                 };

                stapledExtensions Extensions; <----- NEW
}

Another difference between this profile and the p11-kit one, is that
the extensions/revocation here is done on the certificate, while in
p11-kit is done on the public key. Both approaches have pros and cons.

Another question. I also noticed the fingerprint field above. Is that
to distinguish between same CAs with different keys? In that case
using the SubjectPublicKeyIdentifier may be sufficient, and more
natural as this is how certificates with matching DNs/serials are
distinguished.

regards,
Nikos