Re: [pkix] [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt

Nikos Mavrogiannopoulos <nmav@gnutls.org> Thu, 12 October 2017 12:04 UTC

Return-Path: <n.mavrogiannopoulos@gmail.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A555913449D; Thu, 12 Oct 2017 05:04:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63ajlBVraiIq; Thu, 12 Oct 2017 05:04:05 -0700 (PDT)
Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57FCF1330AD; Thu, 12 Oct 2017 05:04:05 -0700 (PDT)
Received: by mail-qk0-x242.google.com with SMTP id k123so918593qke.3; Thu, 12 Oct 2017 05:04:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=TCqPnYL4yBFTpRdUr7jblVhd2/TZXBoC9g9GpOVcukw=; b=aZXngVJolKmB5qKUZjBFNqxaUs8suE/ETIDub7xnI/rT+nQHZLaUuVVxKauMy15SQl NiayiBih/spKuPqfB5qJOaHmS9GjeJ9HNGgvA37jw8lnBCDk2EbaYvqSA5m0ei7nkOkg sv3NLA+4/haizzyfcGWWp5F81ZFhsbFQ44OENQhZLKOAZs5UKpqRAP8u4JGk2LcAOw8N 9ur5kwX7Gtr6ZxJv/kfwqpXnQoOLLhI7QgfZ1FcgHQtlKFgnIqML57kDMxcH9jQ5zbD0 ta9CNvc65Rvl/gYYcZDoBDyH45yjPQn4cr5FVyO1A6j1yZ7Dww2F4XJe0gGKyE09YSRa fLuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=TCqPnYL4yBFTpRdUr7jblVhd2/TZXBoC9g9GpOVcukw=; b=jtH/xx4PZJeubpu9imObBWTgZWsb4S5rKlKC0PYmGSneDmVgx+UIMzCnx01TuZBO7n IfSO0WXJj/hPQLbCfrQrO+PAHdWfgRPtj9Wje/s3+ZEjog464MPiQG1fBJo3717IqnjX jhv4bvi5DYWIJdFZitlMaSSuqDFCbvqvgmP1du+kO/IATdH0MAD8tvRjHpAc0AqgFond U/wW4yfCB8v9dPtidQCKVykqHH86bBRVHyWY9DQDckM21O51qTubtTE8hSTPW8ogVCm9 xlyu2XgsxnVYyNGKWPsFpuIowgDUkolzfigmQ5eJmXAl93mJup3Fj4SNDKd784nMAhY0 nRLg==
X-Gm-Message-State: AMCzsaVahLQ+z/0u6a05EuuukAw9XeywMeKayRxjPiNkajxy6ToIevKM lVJUHXu36Ee81P9ZwQVKWtoVq0j/rWaVaBW5+uA=
X-Google-Smtp-Source: ABhQp+S0Ize0DihDopeTfONoJZR2DeYX/5+R4CCzu9p+nsV8RV6f60RHcvV0Rz8eAsTf15MGKkks+OErQseG4cYvesE=
X-Received: by 10.55.119.5 with SMTP id s5mr59984qkc.233.1507809844422; Thu, 12 Oct 2017 05:04:04 -0700 (PDT)
MIME-Version: 1.0
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.12.148.1 with HTTP; Thu, 12 Oct 2017 05:03:23 -0700 (PDT)
In-Reply-To: <CADqLbzLatQzsRTiCos4oD5p_8TLZ_Pt2zGkksEjt7hAV-CfSbA@mail.gmail.com>
References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> <CADqLbz+OB86s4E-Ntr6eaEow+sBtxscJ703nGN+PAS7zQmJ==Q@mail.gmail.com> <CAJU7zaLsza65gvERm__njLYM82jGWx9ht_QwHi+e6WQAtFKsZA@mail.gmail.com> <CADqLbz+-86OoH6wJQj4cu4daCUmh6mDPCkmVhbBYnLgv9AmOHw@mail.gmail.com> <CAJU7za+TVnhmyATbwdzC4B0Ci3CtdxrqPTzVQnP9BfN_RX+8kw@mail.gmail.com> <CADqLbzLatQzsRTiCos4oD5p_8TLZ_Pt2zGkksEjt7hAV-CfSbA@mail.gmail.com>
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Date: Thu, 12 Oct 2017 14:03:23 +0200
X-Google-Sender-Auth: cN59JnC25PeuqtWEpUsR4t3QJOQ
Message-ID: <CAJU7zaJXLy-xMpL_q98ZrG1fdkdhv8uANYViCN7M_mLOd6rtCg@mail.gmail.com>
To: Dmitry Belyavsky <beldmit@gmail.com>
Cc: "saag@ietf.org" <saag@ietf.org>, LAMPS <spasm@ietf.org>, dev-security-policy@lists.mozilla.org, pkix@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/McBSAIQO7rCXAI8MslLSYWE-a8w>
Subject: Re: [pkix] [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Oct 2017 12:04:12 -0000

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