Re: [stir] I-D Action: draft-ietf-stir-certificates-06.txt

[Sean Turner <[e-mail]>]

Hi,

This version incorporates text to address:

0. Levels Of Assurance

There was a TBD in s5.  I removed the TBD and added some text explaining how LOA is conveyed as OIDs in certificate's certificate policies extensions.  I threw in some additional wording about how OIDs represent the certification policies and those as well as the certification practice statements (CPSs) are just part of the normal PKI “process”.

I decided to co-opt the LOA profiles defined in RFC 6711.  I requires a SAML Context, but the RFC says non-SAML registrations are accepted.  So, I created sub-registry and instead of a SAML Context you submit your OID.  I included that the expert is expect to ensure that the OID is in the CP.  I almost added “and nothing else, but that’s maybe too much.  We could also get a couple of volunteers to be experts and the STIR-related registries could be farmed to them.

1. Profiling OCSP

We’ve got OCSP, we’ve got it's High-Volume Environment (HVE) profile, we’ve got an extension, we’ve got ECDSA P-256 with SHA-256 signatures.  Unfortunately, these all don’t go together so we had to do some profiling.  Most of it’s pretty straightforward, but a couple of things I wanted to note:

1.a.  draft-ietf-stir-certificates purposely DO NOT update the OCSP or HVE profiles because we’re not trying to say that all OCSP and HVE implementations MUST do what we’re specifying here.  Basically, the STIR profile is not for everybody.

1.b. OCSP has two places to extend requests/responses: one is per request/response and the other allows you to apply an extension to multiple requests/responses.  I think we’re not looking at grouping reqeusts/responses so I switched the location of the extensions from requestExtensions/responseExtensions to request’s singleResponseExtension/responses’ singleExtension.

1.c. As we discussed on the interim call, we need to return “not good” when the status is “unknown”.  I made the server a SHOULD send “not good” only, and clients a MUST treat “unknown” as “not good”.

1.d. The OCSP requires RSA with SHA-256 so we’re good there, but I had to mandate support for ECDSA using P-256 and SHA-256.

1.e. I’m proposing that we embrace SHA-256 for every hash.  Because the HVE profile requires SHA-1 for the hash values used to identify the issuer’s certificate and name and OCSP itself bakes SHA-1 into the optional ResponderId.KeyHash (the other choice is Name but HVE recommends KeyHash be used) I had to add some statements about SHA-256.  I’m thinking this for two reasons: 1) we’re using SHA-256 with our signatures so why have this code to generate these values reuse SHA-256, and 2) I suspect that some (likely Gov’t) weenie is going to ask in the not too distant future “does you product use SHA-1” and if you tick yes you’re going to have explain why (saying on here is probably worth it).

Comments welcome.

spt

> On Jul 07, 2016, at 00:20, [e-mail] wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Secure Telephone Identity Revisited of the IETF.
> 
>        Title           : Secure Telephone Identity Credentials: Certificates
>        Authors         : Jon Peterson
>                          Sean Turner
> 	Filename        : draft-ietf-stir-certificates-06.txt
> 	Pages           : 21
> 	Date            : 2016-07-06
> 
> Abstract:
>   In order to prevent the impersonation of telephone numbers on the
>   Internet, some kind of credential system needs to exist that
>   cryptographically proves authority over telephone numbers.  This
>   document describes the use of certificates in establishing authority
>   over telephone numbers, as a component of a broader architecture for
>   managing telephone numbers as identities in protocols like SIP.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-stir-certificates-06
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-certificates-06
> 
> 
> 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.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir