RE: info and questions on CML

["Nicholas, Richard" <Richard.Nicholas@xxxxxxxxxxxxxxxx>]

Ken,

Answers to your questions are inline below.

>   <#1>
> 
>   CMAPI:
>   CM_Retrieve_key.c:
>   CMU_CPLBuildPath(...):
> 
>   	/* Check to see if certificate the same as the one passed in,
>   		if not, try another path */
>          if (CMU_CompareBytes(&pCertPath->asn1cert, 
> &origAsnCert) == FALSE)
>                continue;
> 
>   This code segment is causing a major problem for me, when 
> the path length
>   is exactly 2 (ie: one subordinate CA directly under a trust 
> anchor).  It
>   causes the trust anchor to be left off the path, which 
> causes subsequent
>   validation failure when the trust-path for a CRL 
> verification cannot be
>   established back to the anchor.
> 
>   I find that if I disable this code block, everything works fine.
>   Can someone perhaps explain why this test is in there.  It 
> sounds like
>   it's some sort of loop prevention, but I've never had it 
> trigger and do
>   something obviously useful.
> 
>   Is removing this block a security problem?
>   I'm just not convinced I understand it's purpose...

The check is performed because the call to CPL_DoPathDevelopment() which
precedes the check is not guaranteed to return the same target cert.
Without the check, you could potentially validate a different cert than the
one that was requested to be validated (it would have the same subject DN
and public key algorithm, however).  Removing the check opens a security
vulnerability.

The path that is returned from CPL_DoPathDevelopment() will not include the
trusted anchor cert.  So, a call to getNextCert() is called to complete the
path.

>   <#2>
> 
>   CMAPI:
>   CM_infc.c:
>   short CMU_BreakUpCertPath(...):
>         else if (totalElmtsLen1 != elmtLen0)
>          {
>            err = CM_ASN_ERROR;
>            goto ErrorExit;
>         }
> 
>   I've found several condition under which this safety check fails.
>   That's strange, as the path was just constructed a few 
> calls before by CML
>   itself.  It appears that a few "extra" bytes (usually 2 
> bytes) remain
>   after decoding.  If I disable this check, it always works.
> 
>   I suspect the actual bug is in the ASN1 encoding logic, but 
> haven't been
>   able to discover the pattern which causes failure yet (it's 
> complicated in
>   there...)  Anyone else had problems with this?

I'm not aware of any problem with either the building or parsing of encoded
paths.  However, that code is not generated by the SNACC compiler and could
have a bug that appears intermittently.  I agree with you that the problem
is likely in the CM_EncodeThePath() function which performs the ASN.1 path
encoding.

Both functions, CMU_BreakUpCertPath() and CM_EncodeThePath(), have been
re-written in CML v2.0, which is due out in 2 weeks.

- Rich
---------------------------
Richard E. Nicholas
Principal Secure Systems Engineer
Getronics Government Solutions, LLC
Richard.Nicholas@xxxxxxxxxxxxxxxx
(301) 939-2722