IETF 93 - Open PGP meeting DKG Chairing Agenda *** Agenda Bashing No changes to the agenda *** Working group state review *** Uniform Data Fingerprint - PHB presenting SF - Worried about the issue of trying to solve a generic problem. This may be a harder problem than the group wants to try and solve. PHB - Looking to propose something that is capable of doing more than one thing, but not forcing it. (various people) There was an question on how one knows what a hash is for. The response is basically that the verifier is going to know what they are looking for and can check that the content matches what is desireable as part of the fingerprint check. Nested hash construction allows for checking different content types by enumeration without having to hash the underlying content multiple times. However there is an issue that a new version of the software requires a new distribution of all of the fingerprints. Questions on adopting as a draft SF - As AD, this may be too early in the process to look at adopting this. *** DKG - Fingerprint Questions Robin Wilson - Phil's talk gave some ideas of what needs to be fingerprinted. If content type is the level to be tracked, then that is what needs to be fingerprinted. SF - Question is do you want OpenPGP only keys or broader to generic public keys in which case SPKI is a better answer. Rich Salz (RS) - need to defined the "bytes on the wire". If generically useful then a separate document makes sense. DKG - Point of fingerprints is just for human consumption. DKG - If collision attacks are an issue for fingerprints, then one needs to have very long fingerprints in order to avoid them - i.e. on the length of 160 bits not 128 bits to make the work factor too large. This means that truncation is probably not reasonable. TK - humans are sloppy about doing the comparison of fingerprints anyway. So longer may not be better. *** Elliptic Curves SF - Would worry about getting to far ahead of the CFRG work. RS - Really want to match CRGG WK - Shoud allow Ed25519 as a MAY algorithm even if not the output of CFRG. SF - Ed25519 is not going to be an output of CFRG because it will have some tweaks to it. He does not believe that the current OpenPGP implementation will match CFRG output. *** Symmetric Crypto (AEAD) BF: Might want to look at some sponge based methods as well. There are some IP issues around OCB that need to be addressed. A license has been done for TLS and could possibly be gotten for OpenPGP as well. This would need to be looked into. DKG: One of the questions that needs to be looked at is the signaling of what algorithms are going to be supported. *** Mandatory to Implement No significant discussion here *** Public key format WK: Fingerprint and hardwired expiration time maybe DKG: Can probably change algorithms w/o changing format - but expiration time is a different question *** Revocation and Expiry SF: Having a manditory expiration seems to have been a drastic error in X.509. Forcing a date at which roll over on small devices has been a mistake. BF and DKG: Discussion on how expiration could be done. Either as an optional on the creators end or by having a hard date in the spec of no more than x. HUMM: Sense of the room was they they did not have an opinion on the issue, but nobody hummed to say they wanted manditory expiration. SF: Should do a survey of what is used for reasons and see if people are actually using the different extensions DKG: Will propose to do a strong revocation in all cases to the list - simpler is better BF: May want to make superceeded be deprecated but could be kept with current semantics for existing key revocations. RW: Relatively few people are revoking keys based on what has been true with my consumers of keys. keys being superceeded has been the only reason that I have seen. Never seen a compropise issue. (various) Superceeded can be done by re-issuing the cert with an expiration time of "now" without doing a revocation. SF: It may be that expanding guidance on what happens may be more useful than making the protocol do this in some hard way. WK: Adding a comment with the revocation as a note to self may be a useful addition. Also it would be useful to have a fingerprint pointing foward to the the new key. *** Cleanup (SF, DKG, PHB): Discussion about what the ways exist that can potentially be used to use the compression to potentially use a CRIME type attack. There are reasons because of long term storage that doing compression may be something that is highly desirable. It is not clear that currently the attack space is clear enough to need anything more than better guidence. (BF, WK): Moving from key ids to fingerprints is both highly desirable. But the transition may need to be thought out before proceeding. *** Drafting plans Request for reviewers RW, RS to review/edit terminology section, Request for authors: WK - will do the new fingerprint revision authoring - reviewing DKG, CDL *** Open Mic Peter ? - Currently nothing in the document about key rings. says it is out of scope and DANE is looking at putting this in records. Partly a request for review on the drafts WK: We have CERT records w/ PGP and IPGP types. P?: Dane has decided to use a different DNS record type. Desire in DANE was to have a single use key. Currently document calls getgpg to format the blob. No interop. SF: The DANE work is about to start IETF last call. Request for reviews of that draft and if we need to do additional work here, let's do it w/o getting into the critical path. Short discussion on wanting to loosen the rules for the notation data id types in the IANA registry. The rules could be loosened either as a new draft or as part of the bis draft to either be expert review or something even looser.