Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt

[Dmitry Belyavsky]

Hello,

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

---------- Forwarded message ----------
From: <interne...@ietf.org>
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 <bel...@gmail.com>



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

[Nikos Mavrogiannopoulos]

On Tue, Sep 12, 2017 at 2:59 PM, Dmitry Belyavsky <bel...@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:

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

[Dmitry Belyavsky]

Dear Nikos

On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos <nm...@gnutls.org>
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 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
>

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

[Nikos Mavrogiannopoulos]

On Wed, Sep 20, 2017 at 3:21 PM, Dmitry Belyavsky <bel...@gmail.com> wrote:
> Dear Nikos
>
> On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos <nm...@gnutls.org>
> 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 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

> I've looked through the specification. It's OK for me, but I do not get
> whether the attached extensions are crypto-protected.

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

>> 4. How do you handle extensions to this format?
>>

> 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

[Dmitry Belyavsky]

Dear Nicos,

Sorry for the delay with my response.

On Fri, Sep 22, 2017 at 11:06 AM, Nikos Mavrogiannopoulos <nm...@gnutls.org>

wrote:

> On Wed, Sep 20, 2017 at 3:21 PM, Dmitry Belyavsky <bel...@gmail.com>
> wrote:
> > Dear Nikos
> >
> > On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos <
> nm...@gnutls.org>
> > 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 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

> > I've looked through the specification. It's OK for me, but I do not get
> > whether the attached extensions are crypto-protected.
>
> 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.
>

Well, the specification I suggest should allow applying CLPs issued by
major vendors (Mozilla etc).
For this purposes the CLPs should be validable => signed.

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

I anticipate some ways to distribute CLPs.

1. Major vendor-issued CLPs are distributed either by vendors or by OS
vendors
(similar to, e.g., ca-certificates package in Debian). In this case we
should have
certificates to sign these CLPs distributed together with these bundles.

2. App-specific CLPs may include the key as a part of the application
bundle.
So CLP is distributed via normal app-distributing channel.

3. Locally created CLPs. This is the case more or less similar to the
p11-glue solution,
if I understand it correctly.

Various protocols, such as TAMP (RFC 5934) can be used for transport the
CLPs too.

>
> >> 4. How do you handle extensions to this format?
> >>
> > 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.
>

For this purposes I implied that the limitations are provided not by
extensions,
but as SEQUENCE of limitations related to the certificates.

Was I wrong in the ASN1 scheme in the current version of my draft?

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

Sorry, I do not get the difference between the purposes of the field
'limitations'
and 'stapledExtensions'.

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

Sure.

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

Do you mean Subject Key Identifier (RFC 5280, 4.2.1.2)?
Yes, I agree and I'll update the draft.

I introduced the fingerprint field to distinguish bogus certs from the
valid ones,
but I think the SKI will be OK for this purpose.

Thank you!

--
SY, Dmitry Belyavsky

[Peter Bowen]

On Tue, Sep 12, 2017 at 5:59 AM, Dmitry Belyavsky via
dev-security-policy <dev-secur...@lists.mozilla.org> 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
TrustAnchorInfo object and that the Trust Anchor List object is
explicitly contemplated as being included in a signed CMS message,
would it not make more sense to start from 5914 and define new
extensions encode constraints not currently defined?

Thanks,
Peter

[Carl Wallace]

Also, RFC 5937 defines how to process the constraints from the 5914
structure.

On 10/7/17, 11:31 PM, "pkix on behalf of Peter Bowen"

>_______________________________________________
>pkix mailing list
>pk...@ietf.org
>https://www.ietf.org/mailman/listinfo/pkix

[Jakob Bohm]

The SKI provides no strong cryptographic binding to the public key or
any other part of the certificate, only an administrative binding which
can be faked.

Providing either the full trusted certificate or a very strong hash of
it's DER form (a so-called "fingerprint") would be needed to make a
trust list meaningful for security purposes. For practical usability
and maximum security, include the full certificate.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Nikos Mavrogiannopoulos]

On Sat, Oct 7, 2017 at 8:37 PM, Dmitry Belyavsky <bel...@gmail.com> wrote:
> Dear Nicos,
>
> Sorry for the delay with my response.
>
> On Fri, Sep 22, 2017 at 11:06 AM, Nikos Mavrogiannopoulos <nm...@gnutls.org>
> wrote:
>>
>> On Wed, Sep 20, 2017 at 3:21 PM, Dmitry Belyavsky <bel...@gmail.com>
>> wrote:
>> > Dear Nikos
>> >
>> > On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos
>> > <nm...@gnutls.org>
>> > 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 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

>> > I've looked through the specification. It's OK for me, but I do not get
>> > whether the attached extensions are crypto-protected.
>>
>> 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.
>
>
> Well, the specification I suggest should allow applying CLPs issued by major
> vendors (Mozilla etc).
> For this purposes the CLPs should be validable => signed.

Hi,
If mozilla or any other organization is willing to deploy such PKI,
that would be great. However for the majority of software, I'd expect
that such files are distributed using the same channel as software,
and thus using the same authentication mechanism for it rather than a
new PKI. For a software distributor to use that optional signing could
work.

>> 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.
> For this purposes I implied that the limitations are provided not by
> extensions,
> but as SEQUENCE of limitations related to the certificates.
>
> Was I wrong in the ASN1 scheme in the current version of my draft?

I do not think that the presented ASN.1 description is valid.
The "limitations SEQUENCE," doesn't define anything in ASN.1
(i..e, it is a sequence of what?).

>
>>
>> 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
>> }
>
>
> Sorry, I do not get the difference between the purposes of the field
> 'limitations'
> and 'stapledExtensions'.

I cannot answer this as I cannot see the syntax of the limitations
field. I thought it was a field intended to spark discussion rather
than anything specific.

regards,
Nikos

[Dmitry Belyavsky]

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, draft-belyavskiy-certificate-limitation-policy-05.txt

has been successfully submitted by Dmitry Belyavskiy and posted to the
IETF repository.

Name: draft-belyavskiy-certificate-limitation-policy

Revision: 05
Title: Certificate Limitation Policy
Document date: 2017-11-25
Group: Individual Submission
Pages: 9
URL: https://www.ietf.org/internet-drafts/draft-belyavskiy-
certificate-limitation-policy-05.txt

Status: https://datatracker.ietf.org/doc/draft-belyavskiy-
certificate-limitation-policy/
Htmlized: https://tools.ietf.org/html/draft-belyavskiy-certificate-

limitation-policy-05
Htmlized: https://datatracker.ietf.org/doc/html/draft-belyavskiy-
certificate-limitation-policy-05
Diff: https://www.ietf.org/rfcdiff?url2=draft-belyavskiy-
certificate-limitation-policy-05

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.

==================

On Thu, Oct 12, 2017 at 3:03 PM, Nikos Mavrogiannopoulos via
dev-security-policy <dev-secur...@lists.mozilla.org> wrote:

> On Sat, Oct 7, 2017 at 8:37 PM, Dmitry Belyavsky <bel...@gmail.com>
> wrote:
> > Dear Nicos,
> >
> > Sorry for the delay with my response.
> >
> > On Fri, Sep 22, 2017 at 11:06 AM, Nikos Mavrogiannopoulos <
> nm...@gnutls.org>
> > wrote:
> >>
> >> On Wed, Sep 20, 2017 at 3:21 PM, Dmitry Belyavsky <bel...@gmail.com>
> >> wrote:
> >>
> >
> > Well, the specification I suggest should allow applying CLPs issued by
> major
> > vendors (Mozilla etc).
> > For this purposes the CLPs should be validable => signed.
>
> Hi,
> If mozilla or any other organization is willing to deploy such PKI,
> that would be great. However for the majority of software, I'd expect
> that such files are distributed using the same channel as software,
> and thus using the same authentication mechanism for it rather than a
> new PKI. For a software distributor to use that optional signing could
> work.
>

I got your point. I'll think about allowing local CLPs to be unsigned.

>
> >> 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.
> > For this purposes I implied that the limitations are provided not by
> > extensions,
> > but as SEQUENCE of limitations related to the certificates.
> >
> > Was I wrong in the ASN1 scheme in the current version of my draft?
>
> I do not think that the presented ASN.1 description is valid.
> The "limitations SEQUENCE," doesn't define anything in ASN.1
> (i..e, it is a sequence of what?).
>

I (hopefully) clarified the ASN.1 description in the new version.

>
> >>
> >> 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
> >> }
> >
> >
> > Sorry, I do not get the difference between the purposes of the field
> > 'limitations'
> > and 'stapledExtensions'.
>
> I cannot answer this as I cannot see the syntax of the limitations
> field. I thought it was a field intended to spark discussion rather
> than anything specific.
>

Now, when the syntax is provided, I hope it's specific enough to continue
the discussion.

--
SY, Dmitry Belyavsky