Subject: RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Fri, 14 Jul 2006 01:56:46 -0400

Mike,

As we discussed earlier today (or perhaps yesterday since it's after
midnight), I am now of the opinion that there should be three document
types here.

The longest would be protocol documents (or actually document sets
sometimes) such as DNSSEC and IPSECKEY. Medium sized would be
"algorithm" documents which would specify key and/or signature formats
for use in fields within the RDATA of RRs. Third, shortest, and probably
most frequently changing would be a linking document (or a linking
document per protocol) which would provide implementation requirements
(MUST/SHOULD/etc and limits) and algorithm identifiers which generally
differ per protocol. It is my understand that you would likely find some
arrangement along these lines acceptable.

There would clearly be some start up effort in going to this but it
seems like the cleanest thing to me. Changes would then most often
effect only one document.

Donald

-----Original Message-----
From: Mike StJohns [mailto:[email-masked]] 
Sent: Monday, April 03, 2006 6:25 AM
To: Eastlake III Donald-LDE008; [email-masked]
Subject: RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review

At 10:37 PM 4/2/2006, Eastlake III Donald-LDE008 wrote:
>Hi Mike,
>See below at @@@

Rather than continue this, here's what I think the document needs to be.
I've trimmed the boilerplate at both ends - but I have a xml2rfc file
which generates the full document.  I don't believe there's a need to
obsolete the old document - and doing so would actually void the KEY and
SIG mappings.

Network Working Group                                         M. StJohns
Internet-Draft                                             Nominum, Inc.
Updates: 2536 (if approved)                                April 3, 2006
Expires: October 5, 2006

       Use of the Digital Signature Algorithm with DNSKEY and RRSIG
                     draft-ietf-dnsext-dsa-update-00

Abstract

    This document updates [RFC2536] by providing a mapping of Digital
    Signature Algorithm (DSA) [FIPS1862] keys and signatures for the
    DNSKEY and RRSIG DNS resources records respectively.

StJohns                  Expires October 5, 2006                [Page 1]

Internet-Draft                 dsa-update                     April 2006

Table of Contents

    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .
3
    2.  RFC2536 Updates . . . . . . . . . . . . . . . . . . . . . . . .
3
    3.  DSA Mapping for DNSKEY  . . . . . . . . . . . . . . . . . . . .
3
    4.  DSA/SHA1 Mapping for RRSIG  . . . . . . . . . . . . . . . . . .
3
    5.  Security Considerations . . . . . . . . . . . . . . . . . . . .
3
    6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .
4
    7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . .
4
      7.1.  Normative References  . . . . . . . . . . . . . . . . . . .
4
      7.2.  Informative References  . . . . . . . . . . . . . . . . . .
4
    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . .
5
    Intellectual Property and Copyright Statements  . . . . . . . . . .
6

StJohns                  Expires October 5, 2006                [Page 2]

Internet-Draft                 dsa-update                     April 2006

1.  Introduction

    The DNSKEY and RRSIG records were defined in [RFC4034] as part of
the
    most recent revisions to the DNS Security protocols.  DNSKEY
replaced
    the KEY record in functionality and RRSIG replaced the SIG record.
    This document provides mappings for the DSA for use with the new
    records.

2.  RFC2536 Updates

    [FIPS1862] has replaced "FIPS 186".  None of the changes to FIPS 186
    affect processing described by [RFC2536] or, by derivation, this
    document.

3.  DSA Mapping for DNSKEY

    A DSA public key may be placed in the Public Key field of the DNSKEY
    record.  The format of such a DSA key is identical to the format
    defined in [RFC2536] section 2.  All constraints on DSA keys as
    defined in that document apply to DSA keys in DNSKEY records.  The
    algorithm ID (e.g. the DNSKEY Algorithm field) for a DSA public key
    in a DNSKEY record is 3.

4.  DSA/SHA1 Mapping for RRSIG

    A DSA/SHA1 signature may be placed in the Signature field of an
RRSIG
    record.  The format of such a signature is identical to the format
of
    a DSA/SHA1 signature as defined in [RFC2536] section 3.  The
    determination of the data to be signed and the formation of the
    signature is accomplished using the process defined in that section
    and according to [FIPS1862].  The algorithm ID (i.e. the RRSIG
    Algorithm field) for a DSA/SHA1 signature in an RRSIG record is 3.

    Use of DSA with other hashing algorithms for RRSIG is currently not
    defined.  The algorithm ID 3 may only be used with DSA/SHA1
    signatures.

5.  Security Considerations

    The security considerations described in [RFC2536] continue to
apply.
    Note that [RFC4086] has updated the randomness requirements.  This
    document has no other or additional security concerns.

StJohns                  Expires October 5, 2006                [Page 3]

Internet-Draft                 dsa-update                     April 2006

6.  IANA Considerations

    The IANA considerations described in [RFC2536] continue to apply.
    This document creates no additional IANA actions.

7.  References

7.1.  Normative References

    [FIPS1862]
               National Institute of Standards and Technology, "U.S.
               Federal Information Processing Standard: Digital
Signature
               Standard", January 2000.

    [RFC2536]  Eastlake, D., "DSA KEYs and SIGs in the Domain Name
System
               (DNS)", RFC 2536, March 1999.

    [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
               Rose, "Resource Records for the DNS Security Extensions",
               RFC 4034, March 2005.

7.2.  Informative References

    [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
               Requirements for Security", BCP 106, RFC 4086, June 2005.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>