Werner, I think what Vincent meant was that you don't address community
feedback ("The Document Editor is responsible for ensuring that the
contents of the document accurately reflect the decisions that have been
made by the working group.").
That e-mail is an example of that: there is list of things done or to be
done (which is very welcome, I look forward to X448) but zero replies to
the points what Vincent wrote.
Kind regards,
Wiktor
On 20.04.2020 11:01, Werner Koch wrote:
On Fri, 17 Apr 2020 10:35, Ronald Tse said:
The said issues would be better resolved by finalizing the RFC 4880bis
document and publishing it.
Except for some unimportant details we already had rough consensus on
the I-D a long time ago. There are even at least 3 interoperable
implementations of the new features.
With the attacks on the keyserver in the last summer there was the idea
to add countermeasures to the I-D. They are now specified (attestation
key signatures) and I am not aware of technical problems with that
proposal. I do regularly publish revisions of the I-D to keep it from
expiring. Since -09 these are in the queue:
722ed9e * Typo fix
30d8397 * Introduce the Key Block subpacket to align OpenPGP with CMS.
669f73f * Typo fix
6fd718d * Revert to the RFC4880 requirement of having a User ID.
Right, the Key Block subpacket[1] has not yet been discussed but I hope
this is non-controversial because it is another workaround for the
keyserver problems and allows for better decentralized use. Experience
has show that this is very useful and should, similar to S/MIME, not be
done at the MIME level.
Open editorial tasks are:
- Clarify how MPIs are used with 25519 and X448.
(Gniibe proposed a change last fall)
- Add X448
- Fix some fallout with the recently done markup language change.
- Final proof reading
Salam-Shalom,
Werner
[1]
--8<---------------cut here---------------start------------->8---
Key Block
(1 octet with value 0, N octets of key data)
This subpacket MAY be used to convey key data along with a signature
of class 0x00, 0x01, or 0x02. It MUST contain the key used to create
the signature; either as the primary key or as a subkey. The key
SHOULD contain a primary or subkey capable of encryption and the
entire key must be a valid OpenPGP key including at least one User ID
packet and the corresponding self-signatures.
Implementations MUST ignore this subpacket if the first octet does not
have a value of zero or if the key data does not represent a valid
transferable public key.
--8<---------------cut here---------------end--------------->8---
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp
--
https://metacode.biz/@wiktor
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp