Re: Draft typos and errors

At 21:54 11/6/2000 -0800, hal@finney.org wrote:
>Some spelling errors I spotted:
>
>signaute in 6.4.2
>canonicalizationalgorithms in 6.5
>sytnax in 7.2

Noted and fixed!

>It would probably be a good idea to go over the draft with a good spell
>checker.  Be nice if you could find one that ignores every word that
>starts with "x". ;-)

I've done it a few times, but it is a harrowing process given all the 
terminology and XML, and I expect/hope we're getting pretty low on typos 
given all the eyeballs running over the spec.

>A few other points: in the example in 4.4.4 there are three </X509Data>
>tags but only two <X509Data>s.

Ok.

>In 6.4.2 there is a description of how bignums are stored, but this
>information is needed earlier, in 6.4.1 in order to store the P,Q,G,
>etc. values for DSA keys.

Yikes. I presume (one of the authors of this section might want to correct 
me) that there are supposed to be 3 complete well formed X509 child elements 
of KeyInfo (and that there is no nesting), so:

    <KeyInfo>
      <X509Data> <!-- two pointers to certificate-A -->
        <X509IssuerSerial>
          <X509IssuerName>CN=TAMURA Kent, OU=TRL, O=IBM,
            L=Yamato-shi, ST=Kanagawa, C=JP</X509IssuerName>
          <X509SerialNumber>12345678</X509SerialNumber>
        </X509IssuerSerial>
        <X509SKI>31d97bd7</X509SKI>
      </X509Data>
      <X509Data><!-- single pointer to certificate-B -->
        <X509SubjectName>Subject of Certificate B</X509SubjectName>
      </X509Data>
      <X509Data> <!-- certificate chain -->
        <!--Signer cert, issuer CN=arbolCA,OU=FVT,O=IBM,C=US, serial 4-->
        <X509Certificate>MIICXTCCA..</X509Certificate>
        <!-- Intermediate cert subject CN=arbolCA,OU=FVTO=IBM,C=US
             issuer,CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US -->
        <X509Certificate>MIICPzCCA...</X509Certificate>
        <!-- Root cert subject CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US -->
        <X509Certificate>MIICSTCCA...</X509Certificate>
      </X509Data>
    </KeyInfo>

>Also, this text suggests making "an even number of bytes".  Two problems,
>first it is not really an "even" number in the sense of being divisible by
>2, but rather an "integral" or "whole" number.  Second, the word "byte"
>could be better replaced by "octet".  If you search the doc you find
>a few other places where this substitution should be made (everywhere
>except in reference to the byte order mark (BOM)).

Ok, we've been trying to use octet consistently (8 bits) since "byte" is 
sometimes used to represent n-bit words... The instances where I see we 
still used bytes (and are now changed include):

>4.3.3.1  The URI Attribute
>1. Each disallowed character is converted to [UTF-8] as one or more 
>/+octets+/.

>2. Any octets corresponding to a disallowed character are escaped with the 
>URI escaping mechanism (that is, converted to %HH, where HH is the 
>hexadecimal notation of the octet value).

>6.4.2 PKCS1
>... The integer value is first converted to a "big endian" bitstring. The 
>bitstring is then padded with leading zero bits so that the total number of 
>bits == 0 mod 8 (so that there are /+whole+/ number of /+octets+/) If the 
>bitstring contains entire leading /+octets+/ that are zero, these are 
>removed (so the high-order /+octet+/ is always non-zero).



__
Joseph Reagle Jr.
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Tuesday, 7 November 2000 14:33:59 UTC