From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Date: Wed, 23 Mar 2011 19:30:50 +0000 (-0400)
Subject: update commentary about non-implemented OpenPGPCertificateEmbedded
X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=ebc3be8b98238af1ad1286356031c950c26eb349;p=monkeysphere-validation-agent.git

update commentary about non-implemented OpenPGPCertificateEmbedded
---

diff --git a/openpgp2x509 b/openpgp2x509
index c131e5f..38d1ee4 100755
--- a/openpgp2x509
+++ b/openpgp2x509
@@ -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