-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Robert" == Robert Moskowitz <rgm-sec@htt-consult.com> writes:
Robert> At 02:13 AM 8/8/2001 -0700, Bill Manning wrote:
>> % We chose TXT because we simply wanted to convey a gateway address and a
>> % key, and we wanted to parse it with 10 lines of code, not 10,000.
>>
>> $DEITY help you when you grab a random TXT record... :)
Robert> What about the OPT record?
Robert> RFC 2671
Robert> Then you get IANA to assign an OPT attribute.
As Henry pointed out, they are not be stored in files:
RFC2671 says:
>4.1. One OPT pseudo-RR can be added to the additional data section of
> either a request or a response. An OPT is called a pseudo-RR
> because it pertains to a particular transport level message and not
> to any actual DNS data. OPT RRs shall never be CACHED, FORWARDED,
> OR STORED IN OR LOADED FROM MASTER FILES. The quantity of OPT
> pseudo-RRs per message shall be either zero or one, but not
> greater.
I'm not entirely clear how one could use OPT RRs given that one can not
load them, forward them or cache them. It seems to be a way to insert session
layer information. To make an analogy, more akin to IP options than OIDs.
Robert> But clearly, check out CERT first.
There are several options here:
1) ask for one IANA type between 0x100 and 0xFF00.
type "A" would be for a raw RSA key, replacing the basic TXT
record we currently use for authorization.
2) use a SPKI certificate instead.
3) use a URI-based private certificate type.
Option 1 would require that this document or a future one ask for this.
Option 2 would require introduction of new code to process SPKI into
where there was no previous need for SPKI in an implementation.
Option 3 is the simplest as we just need to establish a stable URI to
designate our usage. Probably "ftp://ftp.ietf.org/rfc/rfcXXXX.txt"
(where XXXX is the assigned number) is the most obvious one.
A variation of option 1 is to write a document asking for a KeyNote option
and include that. That would probably get more support than option 2.
Proceedurally there are two options:
1) include this request in this document. This would make the
document more than "Informational" as it would not describe an
existing system.
2) keep this and use it in a second document that might include other
changes.
The goal of this document is an Informational RFC, so I prefer #1.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface
iQCVAwUBO4AC5YqHRg3pndX9AQHoHQQAwpdXXnhuzD/A1MuRxrjyL2Yhawji4Kkx
I5nmWASvUQTpABH18ElZRJLFrEFuLemePwrWIcL3d4/pFS7bEvbUIw/ILYfm8b3j
Jbs5n/SC9w/SddK9/CG6r9lQCZj48b0WuQCI4a6FJAWJBGgxL2gY2JhDsbSOJ9X0
7Oo1zqAD0Wk=
=amTN
-----END PGP SIGNATURE-----