Pki4ipsec minutes – IETF64  by Will Ivancic (an innocent bystander)

Agenda for PKI4IPSEC
Profiling Use of PKI in IPSEC WG  

TUESDAY, November 8, 2005
1740-1840 Afternoon Session III 
Salon 1 
AREA: SEC 

Min	Items

10 - Blue sheets, scribe, and agenda bashing

20 - Profile Document -06 revision update. EKU issue. WG Last Call?

http://www.ietf.org/internet-drafts/draft-ietf-pki4ipsec-ikecert-profile-06.txt

Stefan Santesson – sent comments to mail list regarding EKU.   

Bill Sommerfeld -  many implementations may want to include a knob to turn this off.  Probably should not be a requirement, but might need a knob to turn this off.

Stefan – Even if we know people will implement, 

Comment from somewhere - People may be stuck using a certificate.  Want a switch to be used for security policy reasons.

Tim Polk (NIST)- EKU is for people to know how to use the extension.  If extension is non-critical, you do not have to process this extension.  If you want to handle critical EKUs one needs this.

Bill Sommerfeld – Question:  in a layered modular implementation using PKI, what does the critical bit mean if library supports it but application doesn’t understand this?

Tim Polk – CA being operated without a good understanding of the use of EKU is most of the problem.  One can be specific and say "use only for these applications," or one can say "it is there, use it as one wishes."

Stefan – EKU is defined to mean a specific extension.  We cannot redefine the meaning here.  The text is doing this.

Gregory – We really are not redefining it here.  We are saying that we do not care how this is used.

Jim Schaad - Difference between implementers doing things and us helping people doing things that is just right.

Bill Sommerfeld – adding an EKU is not critical. Should resolve conflict with RFC3280.

Michael Richardson – with respect to PKI people, we are trying to clean up a mess.  Without proper text, buyers cannot backup and policy their vendors.   Leave text as is.  It says “buy configuration”.

Stefan – If one can process this extension one has to process it.  If you cannot process it and it is non-critical, then that is OK.  

Tim Polk – change bullet to say if the implementation cannot process …. Then ….   If an implementation is configured.  If CANNOT process than we do not care.    We cannot just say we will ignore extensions if they are there.  

Tero Kivinen – maybe not have the extension.  Regardless of what we put, people will probably do what they want.  It will be in product regardless of what we say.

Richard Gray.    WG will write profile x509.  Not data constructs

Tim Polk – causes additional problems if last bullets over ride first bullets.

Stefan – Does not agree with wording “should not”.


Request from chairs to resolve.  Should we allow to ignore if non-critical?  


Gregory Lebovitz – if we do not encourage people to put switch in, there will be problems. 

Michael Richardson – message has to be sent to PKI library vendors that we need switch.


Gregory Lebovitz –   …….

Stefan – to disallow or not allow a library to carry an implementation is not good.  This is an application issue and should not be performed in the library.

Gregory Lebovitz – Will this be in products provided by vendors?

There is a reason to do this.  It is consistent within the document that this switch exists.

Tim Polk – maybe so, but this is not a good idea.  May create security risks.  If there isn’t a constraint on how the key is used, then constraint shouldn’t be there.  Extensions are not in there by accident.

Stefan – What is the problem?  Are we stuck with CA issued stuff that we cannot use.   Should we write protocols that allow us to ignore what we do not like.

Gregory – We are on 7 years of one path.  Agree with Stefan in principal, but reality says otherwise.

Tim Polk – The problem is there is not a stable set of requirements.  This document helps get a stable set of requirements.  If we do not hold people to requirements, we will not get anywhere.  We need to give implementers a stable target or do we allow continual work arounds.

Bill Sommerfeld – Perhaps we need to put in an escape clause.  

Tim Polk – Agrees with Bill’s suggestion.  Should be seriously considered – perhaps placed at the appendix.

Russ Housley – Frustrated.  Issue Last call, Fix it, and be done with it.  The issue is very small aspect and the rest needs to get out.

Michael Richardson -  need to consider Internationalization and Nationalization issues.  When IDs come in from elsewhere, we need to consider them.

Gregory – 


Tero Kivinen – do we want to say something about HASHes for signing algorithms? 

Bill – algorithm choice within the certificate is implementer's choice.  Perhaps indicate reference to current best practices, etc….

Gregory – should we remove bullet – put escape clauses for everything or should we leave bullet and ignore is non-critical?  

Sharon Boeyen – Make statement upfront that EKU is not required.  

Gregory – This is already in text 

Stefan – prefers general escape clause.  Thus there is no violation.  

Tim Polk – The text is what CAs should do.  Not until one gets to logic flows does one get to implementation.   Still add in security section something about denial of service.   You do not need to support this EKU extension if you are a client.  However, if you do process this, here is how to process it.

Gregory – it is one out of one thousand customers that uses this.  Now certs have EKUs.  Now they are using EKUs for other things.  Or they issued a bunch of certificates with EKUs but now do not want them used for IPSec.  So this is a corner case.

Bill – just added text to mail list.   

Stefan – Bill’s text carries security implications.  So something needs to be in security section to address this.

Tim Polk – agrees with Stefan.

Gregory – Proposal is go add Bill’s text to 4.1.3 Intro, remove some text in 4.1.3.2 and 4.1.3.12 and add text in security section. (Gregory captured text on screen.)

Paul Knight – text will be put into document, sent to mail list and put out for last call.

Michael Richardson – this is exactly why we have face-to-face meetings, to work things out and reach a consensus.

Final two items on the agenda will be addressed on the mailing list:

20 - requirements document. review. Path to WG last call?
      http://www.ietf.org/internet-drafts/draft-ietf-pki4ipsec-mgmt-profile-rqts-03.txt

10 - Re-charter to:
        - remove CMC profile work. We seem to be out of steam on this.
        - update the dates
      http://www.ietf.org/html.charters/pki4ipsec-charter.html