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

From: Russ Housley <[email-masked]>
Date: Sat, 10 Sep 2016 12:02:26 -0400

A revised document to address the issues raised in the first WG Last Call
on this document was posted yesterday.
(https://www.ietf.org/id/draft-ietf-stir-certificates-08.txt).

This message starts a second two-week WG Last Call for this document,
which will end on 24 September 2016.

Please review the document and send comments on it to the STIR WG mail
list.  Please clearly state your opinion as to whether the document is
ready for publication as a standards-track RFC.  Remember that support
for publication is needed, so if you think the document is ready to go
forward, please say so.

Thanks,
Russ & Robert

---

From: Russ Housley <[email-masked]>
Date: Thu, 15 Sep 2016 12:07:20 -0400

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

---

From: Mary Barnes <[email-masked]>
Date: Thu, 15 Sep 2016 16:43:02 -0500

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 <[email-masked]> wrote:

> 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.
>
> 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.
>
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir
>

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 21 Sep 2016 10:46:38 -0400

This document looks in good shape to me. Few comments below.

Couple of issues with normative language:

= Section 9 =

"This document therefore recommends
   relying on status information."

I think this should either be written as a normative recommendation or use a different word than "recommends."

= Section 9.1 =

"this document
   therefore recommends the use of OCSP in high-volume environments
   (HVE) for validating the freshness of certificates"

I think this should be a normative recommendation.

Nits:

= Section 3 =

delete "could serve as a subject as well"

= Section 4 =

I think the enumerated items would read more clearly if the name of each item was followed by a colon rather than a period (e.g., " ... as well as any special procedures required to dereference the URIs: ... ").

= Section 9.2 =

OLD
why not reuse that mechanism, instead of
   creating a new service that requires additional round trips?

NEW
that mechanism can be reused instead of
   creating a new service that requires additional round trips.

= Section 10 =

s/to creae/to create/

> On Sep 10, 2016, at 12:02 PM, Russ Housley <[email-masked]> wrote:
> 
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 23 Sep 2016 15:07:36 -0400

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 <[email-masked]> 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.  
>