Thanks Dan, Lets update the draft and have some discussion of it in the Paris meeting.
Cheers, Joe On Mar 6, 2012, at 11:05 AM, Dan Harkins wrote: > > 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
