Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt

From: Sharon Boeyen <[email-masked]>
Date: Fri, 27 Oct 2000 08:53:27 -0400

Hi Dave, I want to clear up one point that you raised, from an X.509
perspective:

--stuff deleted--

> 
> The profile does not specify how to handle an AC where both entityName
> and baseCertificateID are present; it treats them as mutually 
> exclusive
> options.  What should happen if both are included in the AC and
> entityName matches and baseCertificateID does not, or vice versa?  I
> suggest that the AC profile formalize the mutual exclusion assumption
> and say:
> 
>    If the holder field uses the entityName option, the holder 
> field MUST
>    NOT include baseCertificateID or objectDigestInfo.
> 
> But my top priority is Steve's last recommendation - if either of the
> suggestions above are at all controversial, then forget about them.
> Let's move the AC profile forward.
> 
> Dave

------> 

X.509 is very clear on the situation where both entityName and
baseCertificateID are present. In clause 12.1, in the paragraph that begins
with "The entityName component, if present..., you'll find the following
text:

"If baseCertificateID and entityName are both present, only the certificate
specified by baseCertificateID may be used. In this case entityName is
included only as a tool to help the privilege verifier locate the identified
public-key certificate."

That is the reason that the syntax was made a SEQUENCE with all optional
elements. If you include only the baseCertificateID, what you have is the
"issuer" name and a serial number. This is probably not going to be terribly
helpful to a verifier that may need to try to locate that public-key
certificate for a holder in a repository. At present, at least, these
end-entity public-key certificates are typically stored in the subject's
directory entry. The issuer name isn't very helpful from a searching
standpoint. Therefore the ability to also provide an entityName (ie a name
that identifies the subject of referenced public-key certificate) for the
holder is there. There is NO requirement that the value of entityName also
be contained in the publicKeyCertificate pointed to by baseCertificateID
however. entityName is nothing more than helpful hints to the verifier to
try to locate the actual certificate that is REQUIRED to be used.

As X.509 editor, I believe that I inadvertently did not include the same
text for the combination of baseCertificateID with objectDigestInfo, the
combination of entityName with objectDigestInfo or the combination of all 3.
This is probably because we had followup discussions with the PKIX editors
following the X.509 meeting to finalize syntax and the primary issue was the
objectDigestInfo. Once we agreed the syntax, I suspect I forgot to add the
appropriate text. I have raised this with Hoyt Kesterson (who chaired the
X.509 meeting) and a few other folks who were present. Hoyt and I both agree
that the text should have been added and that the intent was identical to
that which is currently there for entityName baseCertificateID (i.e. that
the final present element is the ONLY one that is to be used and that any
other elements of the SEQUENCE that are also present are provided ONLY as
hints to enable verifiers to find the object. For objectDigestInfo then, if
it is present in the SEQUENCE, then that is the ONLY thing that can may be
used. entityName and baseCertificateID, if present are included only as
tools to help the privilege verifier locate the identified object. We have
not finished digging into our notes from that meeting to ensure that this is
in fact an editorial error, so I can't say for sure that this is how it will
be fixed. We also need to discuss it further with those who were present at
the meeting. However I did want to clarify that the entityName
baseCertificateID combination is valid and actually quite important from an
X.509 perspective. I believe the other combinations are as well. In some
operating environments, the object that was hashed (e.g. a public-key, a
public-key certificate, a software object), may be provided to the verifier
at the time the privilege is asserted. In those cases the additional hints
are not required. However in other operating environments, the object will
not be provided and the verifier will need to retrieve the object. If the
verifier has nothing other the hash it will have a very difficult time
locating the object.

Sharon

---

From: Steve Hanna <[email-masked]>
Date: Fri, 27 Oct 2000 12:59:47 -0400

I think there's an inconsistency here:

> Sharon Boeyen wrote:
> "If baseCertificateID and entityName are both present, only the
> certificate specified by baseCertificateID may be used. In this case
> entityName is included only as a tool to help the privilege verifier
> locate the identified public-key certificate."

... then later ...

> the final present element is the ONLY one that is to be used and that
> any other elements of the SEQUENCE that are also present are provided
> ONLY as hints to enable verifiers to find the object.

If baseCertificateID and entityName are both present, this would argue
that entityName should be the ONLY element used for validation (since
entityName is the second element in the Holder SEQUENCE and
baseCertificateID is the first).

Can you explain this?

-Steve