Subject: RE: use of objectDigestInfo

From: Carlisle Adams <[email-masked]>
Date: Mon, 21 Jun 1999 09:49:17 -0400

Hi Stephen,

> ----------
> From: 	Stephen Farrell[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	Monday, June 21, 1999 5:44 AM
> To: 	[email-masked]
> Cc: 	[email-masked]
> Subject: 	use of objectDigestInfo
> 
> 
> A while back there was some discussion of SPKI and X.509 ACs
> (before that thread got taken over by encrypted attributes).
 
Yes, please let us move on from the encrypted attribute discussion.  Some
people see a need for them; others don't.  The normal standards way to solve
this dilemma is to make them OPTIONAL.  Guess what?  The draft already does
this -- problem solved!

Denis is perfectly free to write a profile for his environment that says
"never use this" and others are free to write a profile for their
environment that says "use this if needed".  I see no reason whatsoever to
remove this from the current draft.  Let's save our energy for arguing over
mandatory things, incorrect things, insecure things, or missing
functionality (if any of these situations arise)...

> As far as I know (and this may be completely wrong) this wasn't
> the original (X.509) idea for the objectDigestInfo field - the idea
> was that this field could contain a hash over e.g. some
> java bytecode, and whenever you download the bytecode, you also
> get the AC and could decide what you'll let the downloaded
> classes do. (Doesn't really matter, point is, it wasn't
> only intended for a hashed key/cert.)
 
(...some text deleted...)

> - if owner.objectDigestInfo is used then a DigestedObjectInfo 
>   extension must be present which must use the wellKnownObject
>   choice
 
Comparing this paragraph with the one just above it, it seems to me that
this may create an artificial and unnecessary dichotomy between
X.509-compliant implementations and PKIX-compliant implementations.

What I would suggest instead (and perhaps this is what you intended in the
first place) is not that "a DigestedObjectInfo extension must be present
which must use the wellKnownObject choice", but rather that PKIX-compliant
implementations MUST "support (i.e., understand and be able to process) a
DigestedObjectInfo extension that uses the wellKnownObject choice".  In
other words, the wellKnownObject choice will be guaranteed to be understood
by PKIX-compliant implementations, not that this is the only choice they're
allowed to use.

> Reactions?
 
Only to note that this whole proposal applies to the issuer field as well
(it has already been agreed that the issuer choice in X.509 will be extended
to include objectDigestInfo).

Carlisle.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 21 Jun 1999 15:39:46 +0100

Carlisle,

> by PKIX-compliant implementations, not that this is the only choice they're

Couldn't this mess up interop somewhat? It would mean that a
compliant implementation may not be able to verify a compliant
AC, due to the fact that the implementation doesn't know what 
thing should be digested. Maybe this needs some more thought?
(I guess I'm not sure what the security and implementation
implications are if the AC validation module doesn't know
what the owner field represents.)

If it solved the problem, I'd be quite open to adding more 
wellKnownObject's.

> to include objectDigestInfo).

Speaking of which, if the FPDAM is to change this way, and since
use of the objectDigestInfo requires a v2 AC, would it be possible
to add the extra field unto the ObjectDigestInfo structure? 

E.g. if ObjectDigestInfo was defined as something like ...

        ObjectDigestInfo ::= SEQUENCE {
              digestAlgorithm     AlgorithmIdentifier,
              objectDigest        OCTET STRING,
              digestedObjectType  CHOICE {
                       wellKnownObject      INTEGER {
                                -- ...values
                       },
                       otherObject          OBJECT IDENTIFIER
              } OPTIONAL
        }

...then there'd be no need for a new extension (*much* nicer).

BTW: The draft currently mandates the the issuer MUST use a DN
(section 4.3.3). One consequence will be that use of objectDigestInfo 
for the issuer is non-compliant. I'd recommend sticking with this, 
(since it parallels 2459), but would be interested to see if anyone 
has a problem with this - if so, send a digest of your objection:-)

Regards,
Stephen.