Minutes for OPENPGP at IETF-93
minutes-93-openpgp-1

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.