Subject: Re: [Emu] Issue 33: Certificate enrollment

From: "Dan Harkins" <[email-masked]>
Date: Tue, 6 Mar 2012 11:05:54 -0800 (PST)

Hi Joe,

  Here are my 4 suggestions to address certificate enrollment:

1. Add New section
------------------

3.9 Certificate Provisioning Within the Tunnel

   Provisioning of a peer's certificate is supported in TEAP by performing
   the Simple PKI Request/Response from [RFC5272] using PKCS#10 and
   PKCS#7 TLVs, respectively. A peer sends the Simple PKI Request using a
   PKCS#10 CertificateRequest encoded into the body of a PKCS#10 TLV (see
   section 4.2.14). The TEAP Server issues a Simple PKI Response using a
   PKCS#7 degenerate "certs-only" message encoded into the body of a PKCS#7
   TLV (see section 4.2.13).

   The Simple PKI Request/Response generation and processing rules of
   [RFC5272] SHALL apply to TEAP, with the exception of error conditions.
   In the event of an error, the TEAP Server SHOULD respond with an Error
   TLV using the most descriptive error code possible; it MAY ignore
   the PKCS#10 request which generated the error.

2. Modify 4.2.4
---------------

Add error codes

     2003 Unsupported Algorithm in CertificateSigning request
     2004 Unsupported Extensions in CertificateSigning request
     2005 Bad Identity in CertificateSigning request
     2006 Bad CertificateSigning request
     2007 Internal CA Error
     2008 General PKI Error

3. Modify 4.2.13
----------------

Old text

4.2.13. PKCS#7 TLV

   The PKCS#7 TLV is sent by the EAP server to the peer inside the
   Server-Trusted-Root TLV.  It contains PKCS#7-wrapped [RFC2315] X.509
   certificates.  The format consists of a certificate or certificate
   chain in a Certificates-Only PKCS#7 SignedData message as defined in
   [RFC2311].

   The PKCS#7 TLV is always marked as optional, which cannot be
   responded to with a NAK TLV.  TEAP server implementations that claim
   to support the dynamic provisioning defined in this document SHOULD
   support this TLV.  TEAP peer implementations MAY support this TLV.

   If the PKCS#7 TLV contains a certificate or certificate chain that is
   not acceptable to the peer, then the peer MUST ignore the TLV.

New text

4.2.13. PKCS#7 TLV

   The PKCS#7 TLV is used by the EAP server to deliver (a) certificate(s)
   to the peer. The format consists of a certificate or certificate chain
   in a degenerate certificates-only PKCS#7 SignedData Content as defined
   in [RFC2311].

   When used in response to a Trusted-Server-Root TLV request from the peer,
   the EAP server MUST send the PKCS#7 TLV inside a Trusted-Server-Root TLV.
   When used in response to a PKCS#10 certificate enrollment request from
   the peer, the EAP server MUST send the PKCS#7 TLV without a
   Trusted-Server-Root TLV.

   The PKCS#7 TLV is always marked as optional, which cannot be responded
   to with a NAK TLV. TEAP implementations that support the
   Trusted-Server-Root TLV or the PKCS#10 TLV MUST support this TLV.

   Peers MUST NOT assume that the certificates in a PKCS#7 are in any
   order. TEAP Servers SHOULD include all intermediate certificates needed
   to form complete certificate paths to one or more trust anchors, and not
   just return the newly issued certificate(s). TEAP Servers MAY return
   CRLs in the CRL bag. TEAP Servers MAY return self-signed certificates.
   Peers that handle self-signed certificates or trust anchors MUST
   NOT implicitly trust these certificates merely due to their presence
   in the certificate bag.

   Note:
   Peer's are advised to take great care in deciding whether to use a
   received certificate as a trust anchor. The authenticated nature of the
   tunnel in which a PKCS#7 bag is received can provide a level of
   authenticity to the certificates contained therein. Peers are advised
   to take into account the implied authority of the EAP server and to
   constrain the trust it can achieve through the trust anchor received
   in a PKCS#7 TLV.

4. Remove reference to RFC5422
------------------------------

  regards,

  Dan.

On Wed, February 29, 2012 10:29 pm, Joe Salowey wrote:
>
> On Feb 29, 2012, at 10:09 PM, Dan Harkins wrote:
>
>>
>> On Wed, February 29, 2012 9:57 pm, Joe Salowey wrote:
>>> The current tunnel method draft contains TLVs for PKCS#10 and PKCS#7
>>> TLVs.
>>>
>>> The purpose of either of these TLVs is not well described.   I think we
>>> need to describe the purpose of these TLVs better or remove them.
>>>
>>> The PKCS#10 TLV makes a brief reference to the Simple PKI request of
>>> CMS
>>> (RFC 5272), but does not provide much more description than that
>>> reference.
>>>
>>> The PKCS#7 TLV doesn't really describe it usage.  It could be used to
>>> carry the enrollment response, or it could be used to send a root
>>> certificate to the peer in the case where an inner method is used to
>>> authenticate the tunnel.
>>>
>>> It doesn't seem that either of these is a complete enough
>>> specification.
>>>
>>> Does someone care enough about this functionality to provide better and
>>> more complete test for it?
>>
>>  I care about this functionality and will be willing to describe
>> the syntax of these messages but what test are you talking about?
>>
>
> [Joe] Thanks Dan, I was thinking of walking on hot coals...  Ooops, I
> meant text.
>
>>  Dan.
>>
>>
>
>

---

From: Joe Salowey <[email-masked]>
Date: Thu, 8 Mar 2012 20:37:24 -0800

Thanks Dan,

Lets update the draft and have some discussion of it in the Paris meeting.

Cheers,

Joe