From nobody Sat Oct 7 11:37:16 2017 Return-Path: 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 49498134B12; Sat, 7 Oct 2017 11:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 uycmojqQWQUt; Sat, 7 Oct 2017 11:37:12 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 A79E01342F1; Sat, 7 Oct 2017 11:37:11 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id t69so13641053wmt.2; Sat, 07 Oct 2017 11:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=x94bjUdkXDMVmhfXlLTCu4egzpqJb5s7zTtFk52b1YQ=; b=EOZvUU42P0+tY8esykPQSAY9y2rj0TTpR9AOBLFXrBQZCvvFmEmNC9ZDIMCLDxYu/6 30YWiQfRZ+CH9JcVUQaFw1U6EIS4DOKjQCBXG8G9dsIlczbTysJLkHYMBIS7Aw3hjbau hb8+iPVySvPBL9WsFuCUauFPFlqR6lxCUvS5BBcoFXTyz1+fE0p4HddFk789SfaiyNyI +G6jz/oCg1LZslVSsLfxz05SAc2XpVJOocJAArGw7h6fkvDuUOhx0VKsy2CJNygcqAKA iqDC2NfyZfyamRu70UR4hn+DKK2KKPad6ONrv7KUAbfXeKQDjgLozhkgVCMuwN9l0RSB hlHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=x94bjUdkXDMVmhfXlLTCu4egzpqJb5s7zTtFk52b1YQ=; b=f/bGsEUDPhV/N5HdDC0FbN4jcYxpvFi5RORPD4iMmy1n3sYfyOrqSuHIRj9nmXxY+m Fx6WMp6Xhw0kA7+HuwCY6IZyYy5k2mbcwJpD0AshI3p/EO3RR0l5fzuo8PcmUGY4WlE2 UxasxuCcnLb3UdUc0V3GS72t38cQCRxbz15s1VIKT5/N7jonmRP9q6ZfuYS6xtSw0tCl MZ1oCrTUVXBVhocNJkNlO2tnrYeSi/PCDOLtuccDBl9AHfz4jYlGr4p49LyJzI582M6b NNXt6tpGxSVf8kWYhxW0cpGhxE/NAf0JQM/YwrqyUAL4AkGkBJ4E/mNgeQybDXtHWPL3 lZsQ== X-Gm-Message-State: AMCzsaXW9gbKkMO97fqfnys77BHwOBM7hCp6iTvvx9Xi6/KuLEEzVI9x FHZ6+JmAIsznx5Hk+0hJ69tzoZ+Nxjnijg3bryo= X-Google-Smtp-Source: AOwi7QBZLFVdLrLWMfNXYEf4+jrxj4diUUwLrBWsBOZWjHBcNTV7tFqxYWA5m6DkLp6JVlFxkRyWdaDFE3a8I25lnSk= X-Received: by 10.80.174.241 with SMTP id f46mr7882561edd.135.1507401430163; Sat, 07 Oct 2017 11:37:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.220.202 with HTTP; Sat, 7 Oct 2017 11:37:09 -0700 (PDT) In-Reply-To: References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> From: Dmitry Belyavsky Date: Sat, 7 Oct 2017 21:37:09 +0300 Message-ID: To: Nikos Mavrogiannopoulos Cc: "saag@ietf.org" , LAMPS , dev-security-policy@lists.mozilla.org, pkix@ietf.org Content-Type: multipart/alternative; boundary="f403045c18e0c76566055af93e42" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 18:37:14 -0000 --f403045c18e0c76566055af93e42 Content-Type: text/plain; charset="UTF-8" Dear Nicos, Sorry for the delay with my response. On Fri, Sep 22, 2017 at 11:06 AM, Nikos Mavrogiannopoulos wrote: > 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 < > 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. > 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 --f403045c18e0c76566055af93e42 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Nicos,

Sorry for the delay with my= response.

On = Fri, Sep 22, 2017 at 11:06 AM, Nikos Mavrogiannopoulos &l= t;nmav@gnutls.org&= gt; 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 certificate= s
>> [0, 1] and seems quite a flexible approach. Have you considered th= at
>> path?
>>
>> regards,
>> Nikos
>>
>> [0].
>> https://p= 11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-mo= del.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 d= o 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, t= he specification I suggest should allow applying CLPs issued by major vendo= rs (Mozilla etc).
For this purposes the CLPs should be validable = =3D> 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 antic= ipate some ways to distribute CLPs.

1. Major vendo= r-issued CLPs are distributed either by vendors or by OS vendors=C2=A0
(similar to, e.g., ca-certificates package in Debian). In this case w= e should have=C2=A0
certificates to sign these CLPs distributed t= ogether with these bundles.

2. App-specific CLPs m= ay include the key as a part of the application bundle.=C2=A0
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.

<= /div>
Various protocols, such as TAMP (RFC 5934) can be used for transp= ort the CLPs too.
=C2=A0

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

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

<= div>For this purposes I implied that the limitations are provided not by ex= tensions,
but as SEQUENCE of limitations related to the certifica= tes.

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=C2=A0 ::=3D=C2=A0 =C2=A0SEQUENCE OF LimitedCertificate<= br>
LimitedCertificate ::=3D SEQUENCE {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 userCertificate=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CertificateSerialNumber,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 certificateIssuer= =C2=A0 =C2=A0 =C2=A0 =C2=A0Name,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 limitationDate=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Time,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 limitationPropagati= on=C2=A0 =C2=A0Enum,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 fingerprint SEQUENC= E {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 finge= rprintAlgorithm AlgorithmIdentifier,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 finge= rprintValue=C2=A0 =C2=A0 =C2=A0OCTET STRING
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} OPTIONAL,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 limitations=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 SEQUENCE,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} OPTIONAL,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0};


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 stapledExtensions E= xtensions; <----- NEW
}

Sorry, I do not get the difference be= tween the purposes of the field 'limitations'
and 'st= apledExtensions'.


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.
<= /blockquote>

Sure.
=C2=A0

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=C2=A0Subject= Key Identifier (RFC 5280, 4.2.1.2)?
Yes, I agree and I'll up= date 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!
<= /div>

--
SY, Dmitry Belyav= sky
--f403045c18e0c76566055af93e42-- From nobody Sat Oct 7 20:31:24 2017 Return-Path: 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 7C26A13331E; Sat, 7 Oct 2017 20:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 HEoUoE651Y-u; Sat, 7 Oct 2017 20:31:21 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 0B7E2133078; Sat, 7 Oct 2017 20:31:20 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id c82so20174030lfc.6; Sat, 07 Oct 2017 20:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Prd6OgF7t7YAi6BCUrTaOlcSYcyIAeTLoc4K4V2s8j4=; b=d4my61sYNBVlPOeMxkf+5RIyZgwT+SenU42iKIX7D1gHjHZFjYQ9QbPtdqbYqvdlJK BDbsD6rnVLMismMHxOGKkBxVWzlSuLJElKv+iS3c6saW68gOknjcFdzJByXaMCE9xfmr vv/e3jfJxVjyndkmbUn1/9zLibCFYafV4ELlO1+lrykKrVmFQ9XSSAd/uwklsLUoVi0a Z35N6GbkNVuix1qqcikOz1j/8YJigsbgn0zbw0VCGAFM2vYGO6T6WCdb78T5cG9jRkQV RIm0pNPi1WvNv+MuPLAMGknAJSiIMnAlCz5panmQ7V7R1C4L0KrwcH9HDFLg448MQM0d +dHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Prd6OgF7t7YAi6BCUrTaOlcSYcyIAeTLoc4K4V2s8j4=; b=iBX89SxVt7xHfOsdVYSF1u54w/n4Qp5ETvVTEpArRKIGQAitLyI9W/isAFZmYZQipz k5ENfKnvw9eC3DOcnYtEjiPXgqjjBu9FudubH1oEleJ08BjEo1OjwLmEC4AZGtIHys6M Y57N6v5LeM8+Q4E4vUsjtgkZS0P21gqNMOlrYNsMa6Aft111TQFgHrg577qDHDrS2E6O P9JkMgftyMPLz+yZqAhBBud65eVIsEw9V5FZonesJ70ELxa9t42vLRdr7IZmQc08ouSd 5KxKm3q3xZ1faDrQJ/Mo5/NBY0bSFHlGkXRsW1GsrEisNEC61M7vRaeAMXcf77axsqQS h4zg== X-Gm-Message-State: AMCzsaV5jHLfC2832mFSkaGl4RYaDze9kIivgXxTS5DttKgE3HPVNU0S LPJXyXYke+b4iCIVon4uwQ/oNYxRCoKmq5EsJr8= X-Google-Smtp-Source: AOwi7QAXUoA4L06mmq/nwvpTnFH+Ygyomp3o6mS2ux9w29TjL4W7W19ID59obXswesQhxHJXS6zq1S3rwvNxFbK9/P8= X-Received: by 10.25.143.156 with SMTP id s28mr2521530lfk.236.1507433478938; Sat, 07 Oct 2017 20:31:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.28.19 with HTTP; Sat, 7 Oct 2017 20:31:18 -0700 (PDT) In-Reply-To: References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> From: Peter Bowen Date: Sat, 7 Oct 2017 20:31:18 -0700 Message-ID: To: Dmitry Belyavsky Cc: "saag@ietf.org" , LAMPS , "mozilla-dev-security-policy@lists.mozilla.org" , "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [pkix] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 03:31:22 -0000 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 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 From nobody Sun Oct 8 07:16:11 2017 Return-Path: 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 578CF1342E0 for ; Sun, 8 Oct 2017 07:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FUZZY_CPILL=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 5wRe6lB_8329 for ; Sun, 8 Oct 2017 07:16:02 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 18BA913458F for ; Sun, 8 Oct 2017 07:16:01 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id w134so21632860qkb.0 for ; Sun, 08 Oct 2017 07:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=hITRZf9hT6t0xdB4JdfHhLm8th9azff/CNVFokXBUJU=; b=J44fNxJnvKrUn0unURpamhOPuLFH83FExa0gTAYERixcweKmZdLib86G/jDUYD5QAa v1XQnJTXJ8591cdX0syPmey+edKEUTqnZJ82nwjRDgym5wsoxaCYM8neRkLr1llqarjM S5RV5UpGk99EbEkSctS8Dxz9vZ2ag9nQS1q2U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=hITRZf9hT6t0xdB4JdfHhLm8th9azff/CNVFokXBUJU=; b=M4Vmv5v8YS8of6RfYPit9StBJbSS+MSxMAl6VvVbgz/v7w/Njan6USiEExcCo99vCD LjrpzGreZfkWwVodEBgHCRItikrUVkKzdo7se8AN66caNqcSwl7aR7n0e/0XNR+bmk0E O+Pr7X9N+5NrQH0a/ba0MPoEPD9yaThz1vx/osTBHoPQisw5oRNZ6rXuVdZvGRgvQQXT jxjfpamL2jAwNSaKgUabXpqRrCGnIdHD4oq8jnuQGnSKUzZg6YspWMKcT1okc6cqFLz6 SrIO7tRW+hmkINJ8qr3HJa2XdS8I+EXgRIkaOeOT3+RZMpQpf7Vdif6zHDox+ZsLGxuq CfCA== X-Gm-Message-State: AMCzsaUz1pGL46Se9zvp0+NR8CaN5Gnsc/MWC9f3turh8WL+KofaXLYT tTrLkoV5OSHDBhB5bC1BUMNsyQ== X-Google-Smtp-Source: AOwi7QCta0ux/xhB3WHoo64t/jM1QOBHHQ4HNJiyr9MzumkNygno/2cu6IiMLruWKMVQYB8Mg2HPOA== X-Received: by 10.55.18.28 with SMTP id c28mr6029124qkh.297.1507472161100; Sun, 08 Oct 2017 07:16:01 -0700 (PDT) Received: from [192.168.2.246] (pool-173-66-76-215.washdc.fios.verizon.net. [173.66.76.215]) by smtp.googlemail.com with ESMTPSA id n45sm3663687qtf.51.2017.10.08.07.15.59 (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 08 Oct 2017 07:16:00 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.7.6.170621 Date: Sun, 08 Oct 2017 10:16:00 -0400 From: Carl Wallace To: Peter Bowen , Dmitry Belyavsky CC: LAMPS , "" , "mozilla-dev-security-policy@lists.mozilla.org" , "saag@ietf.org" Message-ID: Thread-Topic: [pkix] New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [pkix] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 14:16:04 -0000 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" wrote: >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 >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 > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From nobody Thu Oct 12 05:04:24 2017 Return-Path: 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: References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> From: Nikos Mavrogiannopoulos Date: Thu, 12 Oct 2017 14:03:23 +0200 X-Google-Sender-Auth: cN59JnC25PeuqtWEpUsR4t3QJOQ Message-ID: To: Dmitry Belyavsky Cc: "saag@ietf.org" , LAMPS , dev-security-policy@lists.mozilla.org, pkix@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 12:04:12 -0000 On Sat, Oct 7, 2017 at 8:37 PM, Dmitry Belyavsky wrote: > Dear Nicos, > > Sorry for the delay with my response. > > On Fri, Sep 22, 2017 at 11:06 AM, Nikos Mavrogiannopoulos > wrote: >> >> 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 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