draft-day-svrloc-signature-00-nr.txt

Pegasus is an open-source implementationof the DMTF CIM and WBEM standards. It is designed to be por

The Signature Extension comprises an envelope for a Cryptographic
Message Syntax signed-data content type. (See section 5.1 of [CMS].)

.KS
.HDR_2 Signature\ Extension\ Fields

The Signature Extension has the following format: 
.DS L 
   0             1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Extension ID = 0x000?        |Next Ext. Offset (must be zero)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Offset, contd.|               CMS signed-data                 \\
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.DE
.KE 
.HDR_3 CMS\ signed-data\ Field

The CMS signed-data field contains the signature of the SLP message
and accompanying data. The format for the signed-data field is
outlined in section 5.1 of [CMS]. It is a BER-encoded [X.209-88]
buffer that may include at least the following information:

.nr PI 5 
.RS 
.nr step 1 1
.IP \n[step]. 3
Version of the CMS used to sign the message data. 
.IP \n+[step]. 
Algorithms used to generate and sign the message digest. 
.IP \n+[step].
Signed content, which includes a digest of the message data. 
.IP \n+[step].	
Optional Signer information, which may include Public-Key
Certificates. Signer attributes are subject to additional encoding
rules. 
.RE
.in 3 

The list above is generalized. For example, if the signed-data field
contains variable-length attribute data that data must use special
additional rules. See [CMS] for precise details.
.bp
.HDR_3 Size\ of\ signed-data\ Field

There is a paradox involving the size of the signed-data field and the
generation of the signed message digest. 

The SLP header MUST be included in the input for the message digest
contained in the signed-data field. Because the SLP Header includes a
length field, the length of the message including the signature
extension must be part of the input into the message digest contained
in the signature extension.

The message digest and the signature of the message digest are 
fixed-length fields and their length is known prior to generating the
signed digest. This makes it straightforward to calculate the length
of the SLP message, initialize the length field in the SLP header, and
then generate the signed message digest. 

.HDR_2 Contents\ of\ signed-data\ Field

The CMS provides considerable flexibility when generating signed-data
content. For example, it allows multiple signers and multiple
signatures. It also allows a variable number and type of signer
attributes including certificates.

To be consistent with the goals of SLP UAs and SAs SHOULD keep the
signed-data field as simple as possible when generating signature
extensions. A simple signed-data field with only a message digest, a
signature of the message digest, and a subject key identifier makes a
prior calculation of the signed-data length simple and ensures that
generating and verifying signatures of SLP messages requires the
smallest possible overhead.

A signed-data field that contains only a signed message digest and a
subject key identifier can fit easily within the datagram MTU of most
network environments and does not represent an unusual field size relative to
other SLP fields. However, embellishing the signed-data with
additional variable length attributes may quickly cause the SLP
message to exceed the datagram MTU. 

.HDR_2 Omission\ of\ eContent

The CMS referrs to the data being signed for authentication as
"eContent." In this case, the eContent is an SLP Message minus the
signature extension. 

The CMS allows signed content to be either encapsulated within a
signed-data "envelope" or "external." The signature extension requires
the eContent to be "external."
.KS
To quote from section 5.2 of [CMS]: 

.in 5
The optional omission of the eContent within the
EncapsulatedContentInfo field makes it possible to construct
"external signatures."  In the case of external signatures, the
content being signed is absent from the EncapsulatedContentInfo value
included in the signed-data content type.  If the eContent value
within EncapsulatedContentInfo is absent, then the signatureValue is
calculated and the eContentType is assigned as though the eContent
value was present.
.KE
.in 3

In other words, the signed-data field will always contain a signed
digest of the SLP message but not the SLP message itself. 

.RETURN_HDR_1 Use\ of\ the\ Signature\ Extension

Subject to the applicability guidelines in section 2 above, the
Signature extension can provide additional security to SLP by
authenticating the content SLP messages, including other SLP
extensions. It cannot provide privacy and it cannot authenticate the
origin of IP messages. IPSec [AH] is required to authenticate IP headers.

.HDR_2 Input\ to\ signed-data\ Field

When generating a signature extension for an SLP message, the
following data MUST be used as input to the message digest:

.KS
.nr PI 5 
.RS 
.nr step 1 1
.IP \n[step]. 3
SLP Header and message.
.IP \n+[step]. 
Any SLP extension up to but not including the signature extension.
.IP \n+[step].
The Signature extension MUST be the last extension present in an SLP message.
.KE
.RE
.in 3
.KS
.HDR_3 Calculating\ the\ Length\ of\ a\ Signed\ SLP\ Message

The following steps should be used to calculate the length of an SLP
message that includes the signature extension. 

.nr PI 5 
.RS 
.nr step 1 1
.IP \n[step]. 3
Determine the length of the signature extension. The signature
extension will always be 6 bytes larger than the size of the CMS
signed-data field. If the signed-data field will contain any variable
length data such as signer attributes it will be necessary to encode
the signed-data field using a dummy message digest and signature to
obtain its length.
.IP \n+[step]. 
Determine the length of the SLP message, including the length of the
signature extension and all preceeding extensions. 
.IP \n+[step].
Initialize the SLP Header with the length of the message. 
.RE
.in 3
.KE

.RETURN_HDR_2 Signature\ Generation\ Process

The details of generating signatures for a CMS signed-data field are
contained in [CMS] sections 5.4 and 5.5. The following is an overview
for using CMS signed-data in the SLP signature extension. The details
for performing the individual steps are covered in [CMS].

.KS
.nr PI 5
.RS
.nr step 1 1
.IP \n[step]. 3
Generate a message digest of the SLP message beginning with the first
byte of the SLP Header up to and including the last byte of the
message and extensions not including the signature extension. Note that if CMS signed
attributes are to be included in the signed-data field they too must
be input to the message digest. See [CMS] for details. 
.IP \n+[step].
Generate a signature of the digest from step 1. The input to the
signature is the digest and the signer's private key. 
.RE
.KE
.in 3
.KS
.HDR_2 Signature\ Verification\ Process

The details of verifying signatures for a CMS signed-data field are
contained in [CMS] section 5.6. The following is an overview for
verifying signatures in CMS signed-data fields within an SLP signature
extension.

.nr PI 5
.RS
.nr step 1 1
.IP \n[step]. 3
Generate a message digest exactly as in step [1] in section 4.2
above. 
.IP \n+[step]. 
The signer's public key must be obtained separately. 
.IP \n+[step]. 
The input to the signature verification step is the
digest generated in step 1 and the signers public key. The details
depend upon the exact signature algorithm employed but generally include
encrypting the locally generated digest with the signers
public key and comparing the result to the signature contained in the
message. 
.RE
.KE
.in 3

.HDR_1 Acknowledgements

James Kempf was instrumental in the development of this document.
Erik Guttman contributed the basic theory of using
digital signatures with SLP and offered valuable insights 
during the preparation of this document. 
. 
.HDR_1 References

.IP [rfc2608bis] 3
Guttman, E., Kempf, J., Service Location Protocol, Version 2 (work in
progress). draft-guttman-svrloc-rfc2608bis-03.txt, August 2002.

.IP [TLS] 3 
McDonald, Ira, Kempf, J., Day, M., "Upgrading to TLS With
Service Location Protocol", draft-mcdonald-svrloc-tls-00.txt (work in
progress).

.IP [AH] 3
Kent, S., and Atkinson, R., "IP Authentication Header," RFC
2402, November, 1998.
.IP [ESP] 3 
Kent, S., and Atkinson, R., "IP Encapsulating Security Payload
(ESP)," RFC 2406, November, 1998.
.IP [CMS] 3
Housely, R., "Cryptographic Message Syntax", RFC 3369, August, 2002.

.IP [PROFILE] 3
Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
X.509 Public Key Infrastructure: Certificate and CRL
rofile", RFC 3280, April 2002.
.IP [X.209-88] 3 
CCITT.  Recommendation X.209: Specification of Basic
Encoding Rules for Abstract Syntax Notation One (ASN.1).
1988.

.KS
.HDR_1 Author's\ Contact\ Information

Michael Day
IBM
3039 Cornwallis Road
Research Triangle Park, NC 27709
USA
Phone:  [phone]
Email:  [e-mail]

Ira McDonald
High North Inc
221 Ridge Ave
Grand Marais, MI 49839
USA
Phone: [phone]
Email: [e-mail]
.KE

.HDR_1 Full\ Copyright\ Statement

Copyright (C) The Internet Society (2000-2002).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
translate it into languages other than English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."


.TC