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