>From: "warwick (w.s.) ford" <wford(_at_)bnr(_dot_)ca>
>Subject: Re: X.509 v3 support
>Date: Mon, 16 Jan 1995 13:27:00 -0500
>within 6 months, there is no issue with ISO alignment. The ISO Draft
Technical
>Corrigendum which formally adopts the v3 format is going out now for its
final
>90-day ballot. Therefore the v3 format will be final in ISO in June or
July -
>the new IETF draft can reference it directly.
>
>Warwick
Warwick, Steve,
Here is some feedback under the IETF/JTC1 liason arrangements, and
the RFC procedures, and the pem-dev charter:-
contrary to that which Ned asserts, and ignoring all the associated
technical waffle, RFC 1422 already permits the 1992 certificate
attribute syntax, and therefore the v3 certificate once the technical
corrigenda is ratified. as, according to Galvin, MIME/PEM is equivalent
to Classic PEM, the procedures are also available to MIME/PEM
implementations, and must therefore be implemented by complete and conformatn
implementations - assuming the MIME/PEM I-D becomes an RFC soon, that is..
Obviously use of non-standard extensions in MIME/PEM and Classic PEM
profiled by market groups, is a choice of the business involved.
As the 1992 procedures are amended by defect, the proecedures for
implementations conformantly handling the syntax are well specified, as
per your contributions on criticality handling to this list. for the
purposes of 1422 which limits itself to issue of certificate attribute
syntax, I also find the discussion of X.500 conformance, and attribute
type OIDs not relevant, or even necessarily correct. it can be ignored, here.
However, There is scope for further work to 1422, whereby the 1422
procedures might make use of the std extensions. 1422 is "poor"
currently, in that it suggests use of the issuerUniqueIdentifier as a
qualifier for identitying the parent-CA key to be used to validate a CA
certificate. A defect to 1422 needs to be issued to change or facilitate better
handling of 1992 certificates to utilise the new standard extensions
which specifically have the function of solving the issue of a single CA
certificate being signed by multiple PCAs.The exploitation of a specific
syntactic and semantic contruct whose function it is to allow
originator selection between the available authentication channels
does extend 1422 certificate chain handling. I see this as a fallout of the
defect process, rather than a flaw of 1422.
An informational RFC is required only, specifying the use of the std
extension, as a defect, and exampling how multiple CA key sets and
multiple CA certificates for the same key cam be used to select a
unique authenication channel despite a CA being within multiple PCA
domains.
For 1422 use with PEM, as 1422 requires unique user certificate
issuance procedures, and through 1421 key distribution syntax bindings
ensures the signalling of the 1422 authentication channel into the
"representation syntax" - as Amanda calls 1421 and MIME/PEM - during
origination via the issuer/serial field, there is no ambiguity between
available channels when the recipient processes the 1421 syntax. (I do
see that there is ambiguity in the trust relations however in the case
of multiple PCA signing one CA certificate; but this is a fault-line
across the PCA notion in general.) Clearly, for MIME/PEM, there is channel
ambiguity during recipient asyymmetric oken handling. Attached go all the
associated vulnerabilities long known about when the non-dislcosure
protocol is not itself protected by a complete end-to-end identity
protocol assured using an identified channel.
But, back to 1422 comment,that the mechanism of the std extension can
simply replace the 1988 procedures and suggested 1992 procedures
specified in 1422 suggests the ISO committee have done a good job all
round.. We have discussed offline, the USPS operations have need to
adopt this mecahnism ASAP in order to ease the deployement of 1422 for
specific markets; the ratification is awaited eagerly.
At NASA, we have been using 1422 profiled X.509 to authenticate telnet
and ftp agents for some time, and as the community grows, tis becoming
increasingly necessary to allow CA to support multiple keysets, and for
CA to be accountable within the jurisdiction of multiple PCA
authentication domains managed by separate directory management
domains. That 1422 is proving flexible to account for our operational
needs in this area,, and can be assured to maintain an explicit
integrity and security policy (DMS), suggests that the time is ripe
for JTC1/IETF liason to nowto move onto the non-authentication-related
non-standard extensions in detail, and see their impact upon 1422. Bob
Juenemand has been doing this anyway for the last two years, and perhaps now
will start to see some results consolidate from this research work in
commercial liability, through its formalized handling within 1422 (v3)
certificates.
I see there is scope for a new work activity for the WG, in an
information RFC to address the impact of v3 certificates on 1422.
Peter.