For review: RI Trust Community Process

[Greg Chittim]

A new agenda item for tomorrow's call will be to review a draft
version of the Rhode Island Trust Community process for identity
proofing and certificate issuance. The process diagram as it stands
has been posted to the wiki at: http://wiki.directproject.org/HISP+Rules+of+the+Road+Meeting+-+June+24

Please review if you are able in advance of tomorrow's meeting, and we
look forward to discussion a real world implementation of our
discussions over the past few weeks.

[Brett Peterson]

Greg:

Thanks for posting this. This is a very helpful document.

I have to leave early from the call today, but I have several questions so I thought I'd send them to the group and give you a chance to see them ahead of time.

1. In the IdP/CA row, there is a box entitled "Store Organizational Private Key". The HISP will not be sending the IdP/CA the private key so it cannot be stored there. Did you mean to refer to some other piece of data or should that box be removed?

2. In the HISP row, the "Generate Organizational Certificate Request" box includes the phrase "including Public Key and URI". Where, specifically, should the URI go in the standard Certificate Signing Request?

3. Should the term "Certificate Service Request" be changed to the more standard "Certificate Signing Request" throughout the document? A certificate signing request is a well-known data object submitted to CAs that (upon signature and attribute additions by the CA) results in an X.509 certificate.

4. In the HISP box that starts with "Create/Generate Mechanism for Two-factor authentication of Administrator," are you stating that RIQI requires two-factor authentication for HISP administrative functions?

5. In the decision box leading into the circled item (1) in the Provider row, the question is "Need to Create Individual Accounts"? Could this be changed to "Need to Create Individual Identities"? A Direct account associated with a Direct address tied to an organizational certificate does not need to go through a process of getting an individual identity/certificate. My assumption is that the entire right side of the diagram (for obtaining an individual cert) will not be used often (at least initially).

6. How does the workflow handle a provider who has already joined RITC but has not gone through a HISP signup process? Or is joining RITC intended to be synonymous with enrolling with RITC and signing up with a HISP?

7. In the "Organizational Certificate Assumptions" box, I don't quite understand the meaning of the last bullet: "HISPs have ability to generate a sub-org certificate either directly or via a third party".

8. In the "Certificate Contains" box, what, specifically, does this mean: "Reference to covered entity policy". Are you stating a specific policy OID (tied to the provider) must somehow be in the certificate?

Those are my initial questions. My biggest concerns are questions 4 and 5.

Thanks again for creating this. It's great work.

Brett

Brett Peterson
Chief Architect

ABILITY
Butler Square
100 North 6th St.
Suite 900A
Minneapolis, MN 55403
p 612-460-4319
e Brett.P...@ABILITYnetwork.com
www.abilitynetwork.com 

[Boris]

Great questions, Brett, I had some of the same on my mind. In addition, calling an entity an Identity provider (a well defined term in the identity management space), where such entity has *no* role (at least as visible in this diagram) in assuring the identity seems like a stretch. In a sense, CA in this scenario simply trusts the HISP or RIQI to do its due diligence in assuring the identity and binding various pieces together (public key, - where CA does not even know that the entity is ever in possession of the matching private key! - URI of some nature, name, etc.) and signifies this trust with its signature. Such role for the CA seems somewhat contrived and fully unnecessary - all it does is packages the public key (nobody creates the private key cert as it would seem?) into the X.509 cert and signs the cert. For what it is worth, any of the two entities (HISP or RIQI) involved in identity verification can do that and serve as trust anchors.

[will ross]

Fwiw, Redwood MedNet imposes two factor authentication on all Administrator accounts HISP or not.

- - - - - - - -

[wr]

- - - - - - - -

will ross
project manager
redwood mednet
216 west perkins street, suite 206
ukiah, california 95482 usa
707.462.6369 [office]
707.462.5015 [fax]
www.redwoodmednet.org

- - - - - - - -

[Greg Chittim]

Brett -

Thanks for the feedback. All good questions. Preliminary answers included below. Looking forward to the discussion at 3pm.

Greg

 

----Original Message-----

From: hisp-rules-...@googlegroups.com [mailto:hisp-rules-...@googlegroups.com] On Behalf Of Brett Peterson
Sent: Friday, June 24, 2011 9:40 AM
To: hisp-rules-...@googlegroups.com
Subject: RE: For review: RI Trust Community Process

 

Greg:

 

Thanks for posting this. This is a very helpful document.

 

I have to leave early from the call today, but I have several questions so I thought I'd send them to the group and give you a chance to see them ahead of time.

 

1. In the IdP/CA row, there is a box entitled "Store Organizational Private Key". The HISP will not be sending the IdP/CA the private key so it cannot be stored there.  Did you mean to refer to some other piece of data or should that box be removed?

This is referencing an Org sub-ca signing certificate that would be used to support issuance of Org-sponsored individual Direct Address certificates when required be Org policy. The Org Direct digital certificate is generated and held by the HISP.

 

2. In the HISP row, the "Generate Organizational Certificate Request" box includes the phrase "including Public Key and URI". Where, specifically, should the URI go in the standard Certificate Signing Request?

The URI (URL) would identify a CA or CA endpoint for the CSR submission by the HISP. It would not be required within the CSR.

 

3. Should the term "Certificate Service Request" be changed to the more standard "Certificate Signing Request" throughout the document? A certificate signing request is a well-known data object submitted to CAs that (upon signature and attribute additions by the CA) results in an X.509 certificate.

Correct,  “Certificate Signing Request” should be the preferred term.

 

4. In the HISP box that starts with "Create/Generate Mechanism for Two-factor authentication of Administrator," are you stating that RIQI requires two-factor authentication for HISP administrative functions?

Yes, although HISPs may have different administrator authentication policies, two factor authentication is the preferred method.

 

5. In the decision box leading into the circled item (1) in the Provider row, the question is "Need to Create Individual Accounts"?  Could this be changed to "Need to Create Individual Identities"?  A Direct account associated with a Direct address tied to an organizational certificate does not need to go through a process of getting an individual identity/certificate. My assumption is that the entire right side of the diagram (for obtaining an individual cert) will not be used often (at least initially).

“Need to Create Individual Identities” seems more correct for this step although this may result in creation of an individual account in some cases. This model provides optional support for generation of Org-sponsored individual Direct Address certificates (and Org-sponsored individual signing certificates should they be useful to the org).

 

6. How does the workflow handle a provider who has already joined RITC but has not gone through a HISP signup process? Or is joining RITC intended to be synonymous with enrolling with RITC and signing up with a HISP?

The latter. Joining the RITC without a HISP has little practical meaning . The workflow for this case is indicated through the “HISP Organizational Member Enrollment Process” where RITC issues the Provider a temporary credential and a URI to be used when setting up their account with a HISP. The temporary credential serves both as a reference to the Provider’s RITC account and as a “voucher” for issuance of a Direct Digital Certificate.

 

7. In the "Organizational Certificate Assumptions" box, I don't quite understand the meaning of the last bullet:  "HISPs have ability to generate a sub-org certificate either directly or via a third party".

The indicates that the HISP can, at the option of the Organization, generate and use Organization-sponsored Direct “individual” certs (aka Direct “Address” certificates) signed by the Organization as a sub-CA of the RITC-CA.

 

8. In the "Certificate Contains" box, what, specifically, does this mean:  "Reference to covered entity policy".  Are you stating a specific policy OID (tied to the provider) must somehow be in the certificate?

This is intended to indicate that the Certificate Policy for this certificate type (referenced via OID) requires that the subject’s status as a Covered Entity be established in conjunction with the proofing process.

 

Those are my initial questions.  My biggest concerns are questions 4 and 5.

 

Thanks again for creating this.  It's great work.

 

Brett

 

Brett Peterson

Chief Architect

 

ABILITY

Butler Square

100 North 6th St.

Suite 900A

Minneapolis, MN 55403

p 612-460-4319

e Brett.P...@ABILITYnetwork.com

www.abilitynetwork.com 

 

-----Original Message-----

From: hisp-rules-...@googlegroups.com [mailto:hisp-rules-...@googlegroups.com] On Behalf Of Greg Chittim

Sent: Thursday, June 23, 2011 3:29 PM

To: HISP Rules of the Road

Subject: For review: RI Trust Community Process

 

A new agenda item for tomorrow's call will be to review a draft version of the Rhode Island Trust Community process for identity proofing and certificate issuance. The process diagram as it stands has been posted to the wiki at: http://wiki.directproject.org/HISP+Rules+of+the+Road+Meeting+-+June+24

 

Please review if you are able in advance of tomorrow's meeting, and we look forward to discussion a real world implementation of our discussions over the past few weeks.