[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Last Call - Profile (Alt Name Criticality)



Tony:

S/MIME, TLS, and IPSec seem to be the biggest customers for PKIX
certificates (at least right now).  This is my understanding of the current
state of play:

	-  S/MIME needs Issuer DNs.
	-  TLS implementations currenly uses both issuer and subject DNs.
	-  IPSec does not see Issuer DNs as a burden.

Given the strong requirement for Issuer DNs in S/MIME and the use of Issuer
DNs in CRLs, I thak that the wording in the current document is correct.

Russ

At 05:32 PM 7/6/98 -0700, Tony Bartoletti wrote:
>At 05:16 PM 7/6/98 -0400, Russ Housley wrote:
>
>>A CA certificate should not ever have empty DN in the subject field;
>>however, an End Entity certificate might have empty DN in the subject
>>field.  End Entities without a DN in the subject field should have critical
>>Alt Names.
>
>Pardon me for being a pest;)
>
>I am often confused between what PKIX mandates regarding "conforming/
>compliant applications" and "valid certificate formats/contents".
>
>To wit, why do we not say "complying applications must be able to
>handle CA certificates which employ non-empty DNs"?  That is, CA certs
>"may" have empty DNs, and use instead the altName construct, but
>applications which require such are non-compliant.
>
>Alternately, if a CA-cert is required to employ the DN attributes,
>what degree of freedom exists in this respect?  Do these attributes
>flow from some authority on high, or would random numbers suffice.
>
>Apologies for cross-threading, but in the "Issuer DNs" thread you
>wrote:
>
>> S/MIME signed messages require the CA to have a X.500 Distinguished Name.
>> X.509 CRLs name revoked certificates by a combination of the Issuer's X.500
>> Distinguished Name and the certificate serial number. And, there are other
>> protocols that expect the CA to have a X.500 Distinguished Name too.
>
>So, the implication is that I cannot be a (PKIX compliant) CA if my certs 
>cannot support S/MIME signed messages, and where revocations are not
>reportable through X.509 CRLs, as well as support some unnamed set of 
>additional protocols.
>  
>___tony___
> 
>
>Tony Bartoletti                                             LL
>SPI-NET GURU                                             LL LL
>Computer Security Technology Center                   LL LL LL
>Lawrence Livermore National Lab                       LL LL LL
>PO Box 808, L - 303                                   LL LL LLLLLLLL
>Livermore, CA 94551-9900                              LL LLLLLLLL
>email: azb@llnl.gov   phone: 510-422-3881             LLLLLLLL
>