At 09:58 PM 7/13/98 -0700, Jim Schaad (Exchange) wrote:
1. Section 12.2.1 - The DSA section is referering to our D-H draft. I
expect it should be refering to a FIPS standard.
I thought the whole idea of our D-H draft was so we didn't have to rely on
the FIPS draft, which is still a draft and not finished. Did I get
something wrong here?
2. Section 12.2.1 - Should include a statement to the effect that if the
parameters are omitted they are inherited from the signing certificate. (I
may be wrong on this statement.)
Opinions from the rest of the crowd on this?
3. Section 12.3 - Must include our varient of D-H --- see our D-H draft.
Don't reference X9.42 Static D-H.
Ah, whoops. I guess I got mixed up about where our D-H was.
4. Section 12.3.1 - I don't like the inclusion of des in this OID. I need
to be able to operation in a completely exportable manner and I want the RFC
to support this in an OPTIONAL mode. Additionally this should refer(?) to
our D-H draft rathern than X9.42.
Russ stated a preference about not doing parameters on OIDs, just making
the OID what it was supposed to be fully. I tend to agree with him, in that
we have had lots of history of people getting the parameters wrong.
OID+parameter seems unnecessary if we have OIDs for any of the desired
parameters, yes?
5. Section 12.4 -- I though that I had talked Russ into providing something
which contained other than 3-DES key wrapping as an optional.
Yes, but this section describes what is used in the spec, with is only
tripleDES. If I generalize this and say "for tripleDES, this is xyz", there
is more of a chance someone will get it wrong. If you use this for
something other than tripleDES, you have to say what the values used in it
are, so you're going to have to write a doc anyways. I'm happy to make it
more general if you specify what other algs you want values for, and give
the values.
6. Section 12.3.1 and section 12.4 -- It does not make sense that the Key
Agreement OID uses the word des, but the wrapping is actually done with
3-DES.
I think I agree. Others?
7. Section 12.4 -- Need a statement on step 5 if the pad octects are
constant or random. I assume that they are random bits.
Others?
8. Section 12.4 -- Step 6. "Encrypt the result with the Triple-DES keys.
..."
OK.
9. Section 12.4 -- Unwrap - Step #2 does not make sense. Suggest "Check
the parity of the resulting content encryption key. If any is incorrect
then there is an error." The encryption key may be RC2-40 and therefore not
have parity bits.
Well, we're only describing tripleDES here. I will certainly make this
change if I generalize the section.
10. Section 12.5.1 and Section 12.5.2 -- "CBCParameter ::= IV" -- missing
'='
Good catch.
11. Section 12.6.2 - HMAC-SHA1 does not contain a paragraph describing the
parameters. I don't remember there being any paraemters.
Can someone familiar with this let me know definitively whether or not
there are parameters?
--Paul Hoffman, Director
--Internet Mail Consortium