Re: [stir] Second WG Last Call for STIR Certificates Document

Russ Housley <housley@vigilsec.com> Fri, 23 September 2016 19:07 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B27212B8D9 for <stir@ietfa.amsl.com>; Fri, 23 Sep 2016 12:07:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.899
X-Spam-Level:
X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
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 j20nQdUbzhDX for <stir@ietfa.amsl.com>; Fri, 23 Sep 2016 12:07:40 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B56C12B8C8 for <stir@ietf.org>; Fri, 23 Sep 2016 12:07:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7CCB1300A16 for <stir@ietf.org>; Fri, 23 Sep 2016 15:07:39 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id yaDiiYkK2m74 for <stir@ietf.org>; Fri, 23 Sep 2016 15:07:37 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 2B82D3005C5; Fri, 23 Sep 2016 15:07:37 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_90B9C8CB-F343-458D-9D0F-B095312FB96A"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <CAHBDyN4QtYTh8UbSXA90-WNOkQw44RxeHGkVL-76SH9cEwyhCw@mail.gmail.com>
Date: Fri, 23 Sep 2016 15:07:36 -0400
Message-Id: <40257FFD-F52A-4FAB-A9F1-349B8FCA2584@vigilsec.com>
References: <186E1060-A929-4712-85FA-7DEE8172D60A@vigilsec.com> <CCCAF48C-5DB0-44F0-8E02-BF3AE19A456A@vigilsec.com> <CAHBDyN4QtYTh8UbSXA90-WNOkQw44RxeHGkVL-76SH9cEwyhCw@mail.gmail.com>
To: Mary Barnes <mary.ietf.barnes@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/Rm8kQ6xf-x6j4XJ6wMBqJnn_k14>
Cc: IETF STIR Mail List <stir@ietf.org>
Subject: Re: [stir] Second WG Last Call for STIR Certificates Document
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Sep 2016 19:07:42 -0000

Mary:

The object identifiers should be published somewhere so that everyone interprets them the same way, but that should probably be a new first-come-first-serve registry.

Russ


On Sep 15, 2016, at 5:43 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

> Hi Russ,
> 
> Your proposal makes a lot of sense to me.  So, this then removes the dependency on the LoA Registry defined for SAML, correct? 
> 
> Regards,
> Mary.  
> 
> On Thu, Sep 15, 2016 at 11:07 AM, Russ Housley <housley@vigilsec.com> wrote:
> I have found a place where additional clarity is needed in Section 5.1.  The current text is:
> 
> 5.1.  Levels Of Assurance
> 
>    This specification supports different level of assurance (LOA).  The
>    LOA indications, which are Object Identifiers (OIDs) included in the
>    certificate's certificate policies extension [RFC5280], allow CAs to
>    differentiate those enrolled from proof-of-possession versus
>    delegation.  A Certification Policy and a Certification Practice
>    Statement [RFC3647] are produced as part of the normal PKI
>    bootstrapping process (i.e., the CP is written first and then the CAs
>    say how they conform to the CP in the CPS).  OIDs are used to
>    reference the CP and if the CA wishes it can also include a reference
>    to the CPS with the certificate policies extension.  CAs that wish to
>    express different LOAs MUST include the certificate policies
>    extension in issued certificates.  See Section 11 for additional
>    information about the LOA registry.
> 
> This all makes sense to me, but it does not say whether the LOA is inferred from the CertPolicyId or explicitly carried in the PolicyQualifierInfo.  I think that the later is intended because of the reference to an LOA registry.  Please confirm that I got that right.
> 
> For background, RFC 5280 specifies the following ASN.1 for the PolicyQualifierInfo:
> 
>    PolicyQualifierInfo ::= SEQUENCE {
>         policyQualifierId  PolicyQualifierId,
>         qualifier          ANY DEFINED BY policyQualifierId }
> 
> So, I think we need to specify a single OID for the LOA policyQualifierId that is used in all certificates, and then have the qualifier carry an object identifier for the LOA.  Each certificate policy would list the LOA object identifiers that are supported.  If this is the intent, then the IANA considerations should ask for the assignment of the policyQualifierId object identifier.
> 
> That would result in something like this:
> 
>    id-qt-loa OBJECT IDENTIFIER ::= { id-qt TBD1 }
> 
>    id-loa-full OBJECT IDENTIFIER ::= { TBD2 }
>    id-loa-partial OBJECT IDENTIFIER ::= { TBD3 }
>    id-loa-none OBJECT IDENTIFIER ::= { TBD4 }
> 
> Comments?
> 
> Russ
> 
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>