update commentary about non-implemented OpenPGPCertificateEmbedded
authorDaniel Kahn Gillmor <dkg@fifthhorseman.net>
Wed, 23 Mar 2011 19:30:50 +0000 (15:30 -0400)
committerDaniel Kahn Gillmor <dkg@fifthhorseman.net>
Wed, 23 Mar 2011 19:30:50 +0000 (15:30 -0400)
openpgp2x509

index c131e5ff0769c59876c03a8de45f25bb5bd80bff..38d1ee4406db65483a2661e306035ade53eae96b 100755 (executable)
@@ -82,10 +82,16 @@ my $algos = {
 # https://tools.ietf.org/html/rfc4880#section-11.1 , in "raw"
 # (non-ascii-armored) form.
 
-# this is the same as NullSignatureUseOpenPGP, but with the OpenPGP
-# material transported in-band in addition.
+# If it were implemented, it would be the same as
+# NullSignatureUseOpenPGP, but with the OpenPGP material transported
+# in-band in addition.
 
-# this has a few downsides:
+## NOTE: There is no implementation of the OpenPGPCertificateEmbedded,
+## and maybe there never will be.  Another approach would be to
+## transmitting OpenPGP signature packets in the TLS channel itself,
+## with an extension comparable to OCSP stapling.
+
+# the OpenPGPCertificateEmbedded concept has a few downsides:
 
 # 1) data duplication -- the X.509 Subject Public Key material is
 #    repeated (either in the primary key packet, or in one of the