[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
>